I love this module. It has the opportunity to solve one of the biggest usability problems in Drupal.

When users edit a node and click "Save" to save their changes, they are taken to the node view page. Then the average user sees they made a typo. Instead of clicking "edit" the user just hits "Back" on their browser, makes a few more edits, then clicks submit.

This is a big problem. Although they may have thought they were just making a few more edits to the page, they were editing an expired version of the node edit form which causes all kinds of problems, including the unhelpful error:

This content has been modified by another user, changes cannot be saved.
Your lock has been removed due to inactivity or by an administrator. Failed to regain the lock since the document has been changed since.

First, they can't figure out who else edited the page. (Because it told them it had been modified by another user, which isn't true.)

As soon as they use the back browser to go back to the previous page, an ajax callback should check the validity of the form. If the form has expired, it should stop the user from editing the page and ask them to reload the page. (Or better yet, it should just reload the node/##/edit page for them.)

(Even simply storing this in a cookie via javascript would fix the problem for most users while still providing a graceful fallback. I'd be happy to provide some example code if that would be helpful.)

Let me know if I can help in any way.

CommentFileSizeAuthor
#15 back_button_disable.zip1.35 KBsteven snedker
#2 dd_back_button_protect.zip3.2 KBMac Clemmens

Comments

Mac Clemmens’s picture

Mac Clemmens commented

I found some more information about the usability problem here: http://drupal.org/node/394694

Mac Clemmens’s picture

Mac Clemmens commented
StatusFileSize
new dd_back_button_protect.zip3.2 KB

I have created a module which overcomes this issue, in response to the usability issue on Drupal Core:
http://drupal.org/node/394694#comment-3869546

I hope this is helpful -- feel free to let me know if you have any questions or ideas on how to improve it.

~ Mac

eugenmayer’s picture

eugenmayer commented

very interesting point!

Is there any reason why you build a new module? Iam just a bit confused. Eventhough i like to have this kind of functionality in the module, iam not sure why you created a new extra module. Could you explain shortly?

Mac Clemmens’s picture

Mac Clemmens commented

I created a separate module only because I didn't know if/how you would want to integrate it into the module. (Because of the javascript, etc.) I am also trying to get it committed into core pending two improvements:
1. a non-JS fallback, including a more intelligent message for the user, depending on whether the user is overwriting their changes or someone else's
2. a timer which checks if the form has expired every 30 seconds, just in case the user had two tabs open of the same form.

Please feel free to use any part of it in your module. I think this would be a good place for it, and it could be removed if it gets into Drupal core someday or graduated into its own sub-module. What do you think?

eugenmayer’s picture

eugenmayer commented
Status: Active » Needs review

Thats sounds good. I have to review it though, but the functionality is fine.
Iam not going to include the interval-check because that could mean a lot of traffic / load OOTB

youkho’s picture

youkho commented

Subscribe

jzornig’s picture

jzornig commented

subscribe

izmeez’s picture

izmeez commented

subscribing.

izmeez’s picture

izmeez commented

@MacClemmens: Is the problem you have with a specific browser?

I don't see this behaviour happening. I am using Firefox 3.6.x
When a node is saved, using the back button takes user back to the edit form but it is a fully refreshed page with the changes.

ohnobinki’s picture

ohnobinki commented
Version: 6.x-2.4 » 6.x-2.5

@MacClemmens: Is the problem you have with a specific browser?

I see this behavior on many sites in my own web-browser. I consider it a feature that my browser is able to, most of the time, remember a page's form input states. Occasionally I find myself using the ``back'' button to fetch otherwise lost typing so that I may copy/paste it somewhere to reuse it if the form submission failed, etc. Yet when I do this, I recognize that I will often have to reload the page with a form submission to retry submitting the data — I have a vague idea that my browser has cached the old page and have learnt from mantisbt error messages about form tokens (and yes, I know also that drupal has form submission tokens too). Thus, I personally consider this sort of bug to be more of an “educate the user” bug than a bug in the webapp.

I'm not sure if this problem is supposed to be prevented through certain values to HTTP headers controlling caching. I don't know how it varies between browsers.

But this phenomena does exist. However, solving this problem doesn't seem to me to be content_lock's job. Nevertheless, I'll leave the bug open because I'm not decided one way or the other on it yet ;-).

izmeez’s picture

izmeez commented

@ohnobinki Thanks for the reply.

I was wondering if I am not seeing this behaviour because of other configurations on my sites:

One is described in this particular comment http://drupal.org/node/197786#comment-1055633 and that discussion thread illustrates the confusion around what the best approach is. I rather suspect this is the reason why I don't see the old edit form when going back.

The second is the save_edit module. This works fine in conjunction with content_locking and the former checkout, but I don't think it would have any effect on what is displayed on back.

YK85’s picture

YK85 commented

subscribing

ohnobinki’s picture

ohnobinki commented
Status: Needs review » Needs work
pandaski’s picture

pandaski commented
Version: 6.x-2.5 » 7.x-2.x-dev
Status: Needs work » Closed (outdated)
steven snedker’s picture

steven snedker commented
StatusFileSize
new back_button_disable.zip1.35 KB

I, too, made a small module to mitigate this error. Back Button Disable Module.
I won't upload it as a proper Drupal module. Drupal 7 is soon end of life and uploading modules to drupal.org is a hideous and time-consuming chore.