New post – A look at the new Page Edit Restore module

[ryan]

Following up from the module mentioned last week, the PageEditRestore module has been released and here's a new blog post with all the details. This module helps to prevent page edits in the admin from getting lost when the user’s session is lost—

https://processwire.com/blog/posts/page-edit-restore-module/

[wbmnfktr]

This is awesome!

[szabesz]

Thank you Ryan, reading the blog post I have one question: is it possible to somehow create a white/blacklist of roles/users/templates/fields so that we could fine tune when the restoring the operation should be offered in the first place?

[ryan]

@szabesz The roles/users/templates part would be possible. But for someone that has access to the page editor, is there any reason not to give them access to save/restore something that they lost? The tool doesn't give them the ability to restore any fields beyond what they already have access to. I guess I see it as something that ideally wouldn't be limited by access control since it's a tool to prevent lost work, rather than a tool providing any kind of enhanced access. Though maybe there are use cases I haven't considered yet. 

As for deciding what fields should be restorable, that part is a little more tricky because it doesn't actually have any idea what fields it's saving or restoring. It's not actually saving or restoring fields. Instead, it's saving and restoring the raw POST data from the request. It would be easy to identify a TinyMCE field named "body" in the POST, but it would be quite a bit more difficult to identify the the same field within a repeater or other more complex type. If it offered the ability to select which fields it can save/restore, then it would have to know the POST data naming conventions used by all of the fields and subfields within them. This is where it would get significantly more complicated to configure and maintain, and more prone to bugs. Whereas now it just simply restores your lost POST request, providing the same result as if your "Save" had worked, rather than failing due to session loss. It doesn't have to know what all the variables in the POST request are for, so by just saving/restoring it all, there's very little chance for the module to screw up anything. 

[szabesz]

Thanks for the detailed reply!

15 hours ago, ryan said:

As for deciding what fields should be restorable...

I see now that such a feature would not be feasible.

15 hours ago, ryan said:

The roles/users/templates part would be possible. But for someone that has access to the page editor, is there any reason not to give them access to save/restore something that they lost?

You must be right. I was just wondering if it is always a good idea to let the module kick in no "matter what".

[JayGee]

Hi @ryan does this module handle frontend edits?