Reording pages causes all pages to save?

[Pete]

Hi guys

This may be one that only ryan can answer, but I'll ask you all just in case

I've been working on a module that hooks into the page save function to add/update a forum topic associated with a news article on my site. It works fine for the most part, and I've been able to debug it using Firebug (useful as dragging items to trash and moving pages to another parent from the main pages list in the admin is done via AJAX).

It does seem to work very happily now, however I noticed something a little unexpected. When I drag an item out of the trash and into the site root for example, my AJAX debugging (basically echoing "hi" on page save) seems to suggest that it saves the page twice (in Firebug this echos "hihi" to the console ).

Every other way of moving it only saves the page once. Is there any reason why it saves the page twice when it's moved out of the trash? As a side effect, my code doesn't like that (not that that's a problem with your code by any means, just that my code for some reason loves moving anywhere else but out of the trash because of the two page saves for some reason). If there was a way once a page is moved from the trash to only run the hook ONCE then that would also be a good way, but as I don't know what it's doing the second time around it's hard to solve.

[Adam Kiss]

An idea: could you add an page ID to your 'hi' call? I have suspicion, that one of the 'hi's is actually old / new parent of that page.

[ryan]

The 'sort' and 'move' are considered two different operations, and they each do their own save, so I think that's why you are seeing the save occur twice.

Another thing to note is that when you change the order of a page, it also has to save all the pages that would have their order affected. Meaning, all sibling pages that appear above the original location and new location. Though if a the parent is set to automatically sort it's children by some field, then it doesn't have to do that.

In your case, it sounds like you want to avoid the same page coming up twice in your hook. The best way to do that is basically what Adam suggested and keep track of what you've already saved.

<?php
public function yourHook($event) {
    static $saved = array();
    $page = $event->arguments[0];
    if(in_array($page->id, $saved)) return; // skip if we already saved     
    $saved[] = $page->id; 
    // your hook code here
}

[Adam Kiss]

...it also has to save all the pages that would have their order affected...

OT: Everytime I read things like this from Ryan, I realize how magnificently efficient is processwire.

And then I remember one company I worked for, which had in-house LAMP CMS. On one page, they'he shown hundred pages in table (all good). The thing was, that they had to compile a 100 records big list from two tables. Instead of one join/limit query, programmer solved it with loop, which went 100 times and one-queried first table, then one-queried second one. So two have have set of 100 records compiled from two tables, it ran 200 queries (not to mentioned the ones getting menus, templates, ...). And I shudder.

[Pete]

Hehe, I knew it would be a simple answer and it works perfectly - thanks

[ryan]

Adam thanks for the props but don't give PW too much credit in this area. To be fair, I don't think we've got the perfect sorting solution in place yet. The sorting doesn't scale particularly well because it has to load all the sibling pages to do it's thing. Depending on where you sort the page to, it might also have to save a boatload of pages. If we're talking about a few hundred pages, it's going to be slow. If we're talking about a few thousand pages, then it might just run out of memory. But who wants to manually sort thousands of pages? ... Luckily, most situations where you would have a lot of pages, you are also going to have a default sort setup (like name, title or date). Manual sorting is really only useful for smaller things like navigation. But I still want to make the manual sorting a lot more efficient at some point in the future. It's just not a major priority since the potential problems with it are unlikely to show up in regular use.

[Adam Kiss]

OT: Ryan: Okay than, it's really slow as hell, clumsy and unusable for 300+ pages... but it still feels blazing fast, and that's what matters when it comes to administration and user perspective.

[Pete]

Yup - admittedly in the scenarios I was thinking of when I was worrying at the beginning of this thread were actually for pages in a category sorted by date, descending, so there was no need to be worrying about that really.

I think you're right - it's going to be very rare that that's an issue, so it's lower priority.

There is a more efficient way of storing, retrieving and updating "tree" data though, but every time I've looked at it in the last few years it messes with my head: http://www.sitepoint.com/hierarchical-data-database-2/

[ryan]

I bookmarked that to read in more detail later, but I think they may be talking about the nested set model. There are a few reasons why this isn't a good model for PW (http://processwire.com/talk/index.php/topic,43.0.html), but I'll enjoy reading the article nevertheless.

Also, what would make the sort routine fast is for me to just recode it to use SQL queries rather than API calls... that would make it lightning fast even with a thousand pages. But I'm trying to avoid going there except where necessary, because it means thinking about all the other stuff that happens when a page is loaded or saved, like hooks. If I go and manipulate the DB directly, I don't have to load or save any pages, but likewise none of the load or save hooks would get executed.

[Pete]

I think that now I've re-read the article the main area it saves on overhead is retrieving a large tree from the database, and unless you're insane you're not going to have a sitemap for users that lists every page for an x-thousand page site anyway.

And then, as you say, you're back to excluding hooks from running at that point.