Module: AdminSaveActions

[nik]

AdminSaveActions

(Was: After Save Actions - guess why the rename?)

Admin Save Actions adds the possibility to choose where the browser gets redirected after saving a page, template or field. Admin save actions are displayed just before the save button in a collapsed container.

Chosen action can be saved in a cookie for current user by checking "Remember this setting". By leaving this option unchecked upon save, the chosen action will not become the default.

Why?

Some of you wanted something like this to exists in ProcessWire - and so did I. I've read discussions here, here, here and here carefully trying to cover at least most of the options discussed. I know this implementation wont satisfy all the needs, but I'm looking into adding some things afterwards to cover even more of them.

I called the first version of this module PageEditRedirects but decided to to change the name in to a more descriptive one. So that module got deprecated as of now (and does not exists at GitHub anymore). This new version also does not require PW 2.3 but works just fine on PW 2.2 as well.

Special thanks

A module by Adam Kiss (ListAfterSave) implemented some of these actions a long time ago. Thanks to Adam for letting me use the ideas introduced by his module. There are actually some things there my module isn't going to cover even in future versions.

Links

AdminSaveActions can be found from the modules section.

AdminSaveAction is downloadable from GitHub.

(Edit: added link to the modules section. Edit 2: Implemented config option + version bump. Edit 3: Removed feature list - see GitHub.)

[Pete]

I'm all over this like a bad rash

[apeisa]

Nik: this seems to be great! although I am having little problem on my localhost when testing. I get this error msg after page save:

Unknown page

And url on address bar is this:

/processwire/page/edit/

I have just installed the module, not touched anything. This happen always when saving. Tried uninstall / install, saving multiple times etc, but same thing.

PS: I read the name After Shave Actions (whatever that means ) "After" actually feels little strange as module "headline" - how about AdminSaveActions? Admin would be general enough to keep more modules of this kind.

[nik]

@apeisa: Damned, I did a little 'refactoring' just before committing... Seems I've broken it down, have to take a look at it a bit later (found one bug right away, but it didn't fix the whole issue).

Sorry everyone. Fail. 

And that naming. I couldn't come up with a good name - but it was too obvious. We'll see if this module gets a third name before it becomes stable.

[Soma]

Nik, don't worry It sounds very familar to myself, ... before release some refactoring (ah lets change those var names before release lol) and best of is you recognize it immediately after releasing.

[Soma]

Why not AfterShaveActions ?

Lol didnt read apeisas end. Just after

[nik]

Phew, sleeping is overrated. Coding is much more fun.

@Antti: I just pushed a new version to GitHub and the bug you reported should be fixed now.

@Pete: As an added bonus I added the option to choose between radios in a container and a dropdown near the save button. This latter behaviour is somewhat experimental as I could use half a year trying to style the dropdown (+checkbox) and still get it awfully wrong. So there it is, plain and simple. Feel free to suggest (anyone?) suitable markup for the dropdown version. I just might give it a try myself someday, but I doubt it will become anything suitable for anyone not wanting to damage their eyes.

@Soma: And I even managed to do it at such a time I was going away from the computer for some time. Plain stupid of me. But hey, didn't I say some time ago I'd try to publish stuff sooner than later: "if you’re not embarrassed when you ship your first version you waited too long". Check. And it wasn't even first version I messed up with  .

[Pete]

Amazing, I'll have a look at this later today

[ryan]

Great module, thanks Nik!

[Adam Kiss]

Woohooo! I was thanked! What a day!

[Soma]

I have this installed recently on a latest PW, and it doesn't do anything after saving. Also the remember setting doesn't do remember. Any ideas?

[kongondo]

Same here but in my case actions work when saving fields and templates; just not pages. Remember also works in these two cases.

[nik]

Thanks for the report guys!

Redirect url on page save has changed a couple of months ago a bit and my regex was too picky. This is fixed now. I also fixed the action when field is being edited in some other context than default one. Module version is now 0.0.7 both in GitHub and modules directory.

[kongondo]

Nik,

Thanks for the update. 

Feature request please: An option to "after save, edit next sibling" (an implementation of $page->next). Thanks.

[nik]

@kongondo: Thanks for the request - and sorry for the delay. I've been a bit too busy lately and unfortunately will be in the near future as well. That feature has been on my todo-list since the first version of this module though. While it's straightforward to add, I'd like to come up with a decent solution for situations where there are a lot of siblings as well.

I'll try and find some time to try this out as soon as possible.

[Martijn Geerts]

Feature request: ( Same as Kongondo )

For the select / radio options.

Edit next / previous sibling, include all. (hidden, unpublished etc.)

side note: Don't know if that is possible with $page->next, (does that include all ?)

But could be done with $page->next($page->siblings("include=all")) for sure.

[Martijn Geerts]

Sorry Nik, didn't read your post very well. I agree on the sibling issue.

---

ps, customised your wonderful Module, ( + added some permission related things in it only useful in this instance )

I called it afterShaveActions.

Thanks for creating AfterSaveActions.

Love your coding style !

Edited January 11, 2014 by Martijn Geerts

[nik]

Thanks Martijn!

I really should look into adding "edit next sibling" as it probably works just fine in most cases (I forgot kongondo's feature request, sorry!). And maybe I should also go with Antti's suggestion and rename the module to AdminSaveActions - I thinks there's been enough of after shave already .

I'll take a better look at this after work/shave today.

[Martijn Geerts]

+1 for the name change.

( And afterShave is a good name for my modified one )

[kongondo]

...I went ahead and hackishly implemented my feature request (edit next sibling)    . Seems to work OK?
 
Code: Github
 
Short demo:

 
Feature only implemented for pages minus "home", "hidden" and "unpublished". User is redirected (with a status message) to the page list when there is no next sibling to edit...I used page->next.
 
Btw, I don't understand this quote
 

http://processwire.com/api/variables/page/
 
†The siblings, next and prev properties and methods may not be efficient to use when the page has a lot of siblings. Care should be taken on large sites in consideration of the fact that these properties will load all sibling pages. In large scale use, you should make use of the function/method equivalent versions: siblings(selector), next(pageArray), and prev(pageArray), so that you can control the number of pages loaded.

 
...I thought page->next will only grab one page (i.e. it is not an array but an object?)...

[Martijn Geerts]

Siblings are all loaded in memory. Say you have hundreds of siblings, next & prev has to find out where it is compared to his brothers.

So have to load them all. If the list contains not much siblings, there's nothing wrong. 

A real time case case ( you actually build it  ) will point out if it's still functioning well or not. It's not unlikely that we see more problems then that there actually are.

The thing I needed, was the next unpublished sibling, as those pages came from automatic import (cron).

[kongondo]

Thanks for the explanation Martijn....then as suggested in the docs, this is the way to go, no? [to make it foolproof]
 

$page->siblings($selector)

//or

$page->next($pageArray)

Can limit to 1, etc....

Edited January 29, 2014 by kongondo

[Martijn Geerts]

The first one I used for finding the next unpublished.

[nik]

Thanks for the input guys!

I made a (classic, for me at least) mistake trying to make other modifications at the same time and ended up not publishing any of my changes. But Kongondo's code and Martijn's comments both revealed some things I hadn't taken into account. I'll try and publish the changes as soon as possible but I won't promise anything as it seems I never keep them anyway. Sorry.

That possible performance issue is not solved just by using selector version of next(). The problem is we've got no general form of selector that would for sure limit the pages getting loaded there. Like Martijn explained, all the siblings have to be loaded to find out the current page's place among them before it's possible to say which page would be the next (no way to do this in the database, without stored procedures at least ). So using "limit" is not the answer here as you'd only get an incomplete PageArray possibly not even including the current page.

I'm trying to get there by offering "edit next sibling page" as an option only if there are less than 100 siblings (could be made configurable of course). This way there's always a safe net to make sure editing a page doesn't slow down too much because of this module.

[nik]

There you go.

Pushed a new version to GitHub and updated modules directory + opening post accordingly.

Changed the name to Admin Save Actions (though the damage has been done). Don't know how this affects those trying to update the module via ModulesManager - probably you need to remove and reinstall the module, sorry for that.

Added "edit next sibling page" as described in some of the earlier posts. Basically does what Kongondo's version does too - a bit different route though. There's also a config option to set a safety net for this: option will not be show if there are more siblings (defaults to 100). Option is not shown also when there is no next sibling available (root page or last visible and published page under this parent).

@Martijn: I didn't go for hidden/unpublished pages at this time. But I'm thinking of modifying this a bit so that when the edited page is hidden/unpublished also siblings are searched with "include=all". Do you think that would be logical?