Admin Page Tree state save

[Soma]

I think the admin page tree would benefit from a state saving feature. In jsTree for example you can on state saving which uses cookies to save a hash with open nodes.

If there's already a option somehwere I missed, I'm sorry. Else do you think we can implement this feature?

[ryan]

If I understand what you are asking correctly, it wouldn't be hard to implement. ProcessWire already has a way to open any branch in the tree just by specifying the page's ID in the URL to the PageList with "?open=123" where 123 is the ID number of  the page. i.e. /processwire/page/list/?open=123. The only place where this doesn't currently work is with pages that are deep in levels of pagination.

It would be relatively easy to return to any state by saving it in a cookie. What are the scenarios where you'd want to use this?

[Soma]

Just looked at the ProcessPageList.js and seen that there's already something:

// ID sof the pages that we want to automatically open (default none)

openPageIDs: []

I thought it's especially useful in general at the page tree in the admin, everytime the user returns from editing a page to the page tree he often needs to do something in the same place or edit the next page in a sublevel or create a new page below... now going back and thinking about it again... now as you mentioned it, I discovered that clicking in the bradcrumbs parent link it gets me back to the page tree and opens it... really nice! Haven't payed enough attention to that yet I guess - I must be dreaming, cause I thought last time I klicked on the breadcrumb parent it got me to the parent page's edit page!?.. Anyway this puts it in a different light. I'm not sure anymore if state saving would really help as much as I thought, or as to not support this bad behaviour of returning to the admin page tree via top menu or breadcrumb "Pages"... and forcing the user to use the breadcrumb may makes sense. What are your thoughts? Would it be distracting from the "good practices"?

Edit: It may sometimes comes in handy, many people (as me) are used to use browser back intuitively ( you may enter a page editing just to look and use browser back button, or backspace)... it's just people are so used to something it's hard to train them differently... Also seeing it from a end user perspective it could help.

[Soma]

Again, although it seems obvious and makes sense to use breadcrumb, but still it's something that's "hidden" (that tree open functionality) to the user until he knows how to best navigate in pw. I'm just thinking if there could be a way to make it more obvious... (lol may it's really just poor me failing to see the most obvious)

[ryan]

The back button might not be a bad way to retain that state, and I think it should be possible to do live updates to the URL as they are clicking on pages in the PageList in order to remember where they were. But back buttons in a CMS are usually a behavior you want to steer people away from. You can possibly back up to previous versions of content and accidentally save, overwriting newer stuff. Though I can't say as though I've ever run into that problem myself. But as for remembering the state in other situations, I'm a little afraid to make assumptions about where the user wants to be. It seems okay in breadcrumbs, but would be a big assumption make that they want to return to the same spot whenever they click 'pages'? Though if one wants to configure that as the behavior (perhaps in PageList module settings), that's always a possibility.

[Soma]

I understand your point and agree, but are you really making assumptions if the user encounters the page tree as it was as he left it? If, then it should be not overriding the breadcrumb navigation behaviour, just when the user goes back or klicks on "Pages".

I think it may best to have it as an option.

[Mackski]

I agree with Soma here, most clients and users in general, will be annoyed at not seeing the previoiusly opened state in the page tree.
I decided to write my first module to solve this.

https://github.com/mackski/processwire-PageTreeState

Ryan, let me that this opportunity to congratulate you on an excellent piece of software.

I also wanted this to work with Somas Fancy Admin Module, I added the following to initFancyBox in FancyAdminMode.js, line 53:

callbackOnClose: function () {
  parent.location.reload(true);
}

[Pete]

Well I wouldn't agree that that's what most people want (are you always adding pages in the same section one after another? Probably not in most scenarios, probably on news sites though).

That said I like the idea of the module where it is useful.

There is another helpful module as well called something like page save actions that allows you to add another page after saving rather than even going back to the page list

[Mackski]

I think with the module you mention, you can save a default action after saving a page. Perhaps my module is more usefull in this senario as an alternate action like "Save and Restore Page List".
For now, my client is happy with the solution at hand, they mainly add news and blog items, multiples at a time in the same place, so it makes sense.

[Martijn Geerts]

While building FontawesomePageLabel the animation of the pagelist tree annoyed me a little.

( Thought Soma was talkin about that animation to. And the animation is to slow imo. (now 400ms) )

When clicked a ?open=1234 get url for a page deep inside the tree the animation time really adds up.

Say it's 5 deep, then you've to wait 2 seconds (5 * 400 ms). That's without the xhr request. *

I think it's better not to animation at all when you request that page with get ?open=1234 

* Ryan said XHR request is while animating.

Edited October 13, 2013 by Martijn Geerts

[ryan]

@mackski, thanks for your module, please add to the modules directory when you get the chance.

Say it's 5 deep, then you've to wait 2 seconds (5 * 400 ms). That's without the xhr request. *

To be honest, I can't tell the difference here on my desktop, but then just tried on my notebook and it did seem faster (maybe) but cutting out the animation. I went ahead and added it as a module configuration option for ProcessPageList (Modules > Process > PageList), now available on the dev branch. Try changing it from 200 to 50 ms (or even 0 ms) and see if it makes a difference? It might. I think we just need more people to test it. 

[Martijn Geerts]

Love the new speed at 100. Thanks