Can I Stop Page Expiration in Browser
Hello. I'm getting some complaints from my users about the way the pages in Drupal 4.5.0 behave when entering new content. I'm speaking here of the "create content", "add new blog entry", "submit forum topic", and "add new comment". The troubling behavior comes up in two different scenarios:
1) start new content using one of the pages mentioned above; enter a title, enter some text in the body; leave the page, either by going Back in the browser or going to some other page; use the Back or Forward button (as the case may be) to come back to the page where you were entering comment; when the page finishes rendering, the partially entered content is gone.
2) start new content using one of the pages mentioned above; enter a title, enter some text in the body; click "preview"; preview page comes up; go to some other page, including previewing an image that you might have attached to your post; come back and the page has expired; you better click "Retry" or you're going to lose what you had typed in.
Scenario 2 happened to one of my users yesterday after he spent over an hour working on a post. Needless to say he was pissed when his content was gone forever because he accidentally failed to click "Retry" when he came back to the preview page after looking at one of the images attached to his post.
The first thing that comes to mind is can we change Drupal so that neither of these scenarios occurs? For example, I can go into Yahoo Mail, start an email, leave the page, come back to the page, and the email I was working on will still be there. Neither scenario 1) nor 2) happens in Yahoo Mail. What is Yahoo Mail doing that Drupal is not doing?
The other idea I thought of is that it would great if, when the user clicks "preview", Drupal stores the post in the database in a "draft" status, so that even if the user accidentally unplugs his computer before committing the post we'll have that draft copy. A "save as draft" feature would be great also as an explicit option when working on a post. Many posts take longer than a few minutes to complete, and it would be great if Drupal supported working on a post over multiple sessions before committing it.
The "draft" thing is more of a suggestion for some future version of Drupal, or perhaps as a project for myself once I get far enough along with Drupal to start working with the code. However, the page expiration/form reset problems described above are, to me, serious issues right now (I won't call them "bugs", but I think a couple of my pissed off users would be happy to call them that).
Any thoughts?
Thanks,
Dan Read
More Information
I just did a little experiment in the Drupal.org site. I can't test stories or blog entries since I don't see those options here, but I did test the "submit forum topic" form. I tested both scenario 1) and 2) as described in my original post. I got different results than I see on my own installation of Drupal 4.5.0.
First, for scenario 1), when I leave the "submit forum topic" page and come back, the Title field resets itself to empty, but the main body form keeps what it had. On my site, the main body field will reset itself.
Second, for scenario 2), the preview page does not expire and require a "retry" to get it to come back up. It just comes back up.
What's different here at drupal.org than at my own site that would cause two installations of 4.5.0 to act differently this way? Is it a theme issue? A configuration issue?
Thanks,
Dan Read
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com
purely browser problem
At no point Drupal refills your fields. Never! it will only prefill those fields if you are editing an *existing* article. An existing node would be a node that has been totally submitted.
All other behaviour depends on your browser. My firefox remembers the fields I fill in well, so does my konqueror. Firefox in secure mode does not. I do not know about other browsers and settings. But in any case this is not a Drupal issue, at all.
And if this solved you problem, would you be so kind to report back that it helped? This will help others whom are looking for the same solution.
[Ber | Drupal Services webschuur.com]
Hi Ber, Thanks for your in
Hi Ber,
Thanks for your input. I believe what you're saying, but perhaps you could help me solve this mystery: on my site (using Drupal 4.5.0) I go to node/add/forum, follow scenario 1) and when I come back to the "Submit forum topic" page, the text I had entered in the Body field is gone. Using the same exact browser on the same exact computer, I go to Drupal.org's node/add/forum, and following scenario 1) when I come back to my page my text is still there in the Body field.
Same with scenario 2): on drupal.org, when I have a post on the Preview screen, if I leave the screen and come back everything is perfect--the Preview page is just as I left it. However, on my site (again, using the same exact browser on the same machine) when I come back to the page, I am told the page has expired and I have to use Refresh (then the Retry button) to bring the Preview page back up.
Just to be thorough, I just repeated my tests with Firefox 1.0PR. Scenario 1) works fine on my server. In fact, it works even better--not only does it remember what was in the Body field, but the Title field also. Firefox with scenario 2), though, still exhibits different behavior between my site and drupal.org: on my site, when I try to use the Back button to return to the Preview page, I get a POSTDATA expired message; on drupal.org, Back goes back to the page just fine without any expiration message.
From these experiments I have to conclude that the browser is not the only factor here. It may not be drupal, it may not be the theme, but it has to be something server-side. A PHP or Apache setting, perhaps?
Any advice will be appreciated. I'd really like to get this solved.
Thanks again,
Dan
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com
Not Sure If I'm Explaining This Properly
Hi, Ber, I just re-read your post, and based on this paragraph I'm not sure whether we're connecting:
"At no point Drupal refills your fields. Never! it will only prefill those fields if you are editing an *existing* article. An existing node would be a node that has been totally submitted."
Are you saying that Drupal is specifically designed to expire a page and not remember what you were typing into the post? When you say, "At no point Drupal refills your fields. Never!" it sure sounds like you are saying that. I would consider this a huge downside of Drupal if that's what you mean. Why would anyone consider it a good thing that if you use Back and Forward in the browser while working on (or previewing) a new post that it would be a good thing if Drupal throws away what you were working on?
So I'm thinking perhaps I'm not communicating properly here. Has anyone else seen this behavior? Does anyone have a moment to do a quick experiment (based on scenarios I describe above) in their own installations of Drupal? Do the submission forms reset when you go Back and Forward? Does the Preview page expire? Has anyone else received complaints from their users about losing in-progress posts because of this behavior?
Does anyone have an ideas about the cause? Given that the behavior does not happen on drupal.org, there has to be a Apache or PHP or .htaccess setting or something that affects this. Please help.
Thanks,
Dan
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com
Not at all
What Ber means is that Drupal has nothing to do with this. The data you enter is stored in your own browser on your own computer, and is not saved to your Drupal site until you click "Submit". If your browser (Internet Explorer) is too stupid to throw away your data when you use back/forward, then there is not much we can do about it .
As has been said already, many alternative browsers (Mozilla Firefox, Opera, Konqueror) don't suffer from this usability bug. Switch to them, and enjoy a safer, better, faster web.
Thanks, Steve, for the additi
Thanks, Steve, for the additional input. I figured there was just a communication misunderstanding there. Regardless, this turned out be a server configuration issue, not a browser issue (see below). FWIW, I saw the same form reset and page expiration behaviors in Firefox as I did in IE. Now that the server configuration is right, the problems have gone away in both Firefox and IE.
Thanks again,
Dan
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com
Code Inside "IfModule mod_php4.c"
Using phpinfo(), I've gotten as far as figuring out that it appears that the block of code in .htaccess inside of the "IfModule mod_php4.c" block is not executing. I've also tried "IfModule sapi_apache2.c", but I'm not running on Apache 2. Any other ideas why this might not be executing? If I have a phpinfo() file running in the same folder as my Drupal .htaccess, that should show the overridden directives in the "Local Value" column, right?
Also, I can no longer reproduce the form reset behavior (scenario 1) in Firefox on my site. It still happens consistently in IE, though. The page expiration of the Preview page (scenario 2) is still happening in both browsers.
I also found this page, which contains a lot of conflicting, but interesting, information about this subject:
http://www.php.net/manual/en/function.session-cache-limiter.php
In particular, there is one post that mentions the form reset problem specifically. But since the .htaccess settings I do have don't seem to be working, I'm not really in a position to experiment until I figure that one out. I might give up and try to set the HTTP headers myself in drupal_page_header() in bootstrap.inc.
Any thoughts are most welcome.
Dan
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com
htaccess settings were not firing
Well, I don't consider this solution permanent, but at least I know more about what was happening, and I have the problem fixed for now. The reason the form reset and page expiration thing was happening is that for some reason the php_value lines in the .htaccess file were not firing--or were for some reason being overridden or ignored. So the session, cookie, lifetime, and cache settings were not happening.
What I did to fix it was to put equivalent ini_set lines in the session.inc file, at the top, before the call to session_set_save_handler. So this in the htaccess file:
php_value session.cookie_lifetime 2000000
becomes this in session.inc:
ini_set('session.cookie_lifetime', '2000000');
Since I couldn't get htaccess to work, I decided on a more brute force approach.
If anyone is reading this and knows anything about this, I would appreciate any feedback you might have. Any ideas why the htaccess settings would not fire? I know the htaccess file is being applied, because I see other things working. But nothing inside the IfModule block would fire--and I tried it with the Apache 2 syntax also, even though I'm on 1.3.
I would like to find a more proper and permanent solution to this if I can.
Thanks,
Dan
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com
PHP Running as CGI Causes Ignore htaccess php_value
OK, I think I've finally gotten to the bottom of this whole thing. I've been running a parallel thread on the Lunarpages support forum and someone there was able to explain to me why the php_value lines inside the IfModule block were not working: Lunarpages is running PHP in CGI mode, so that module is not there. Armed with that information, I was able to find this thread:
http://drupal.org/node/11861
This comment spells out the solution:
http://drupal.org/node/11861#comment-18597
I checked with Lunarpages and they confirmed that, since PHP is running in CGI mode, I can put a php.ini file in the same folder where the htaccess file is.
Hopefully all this will help someone in the future.
Dan
---------------------------------------------------------------
developer.* - The Independent Magazine for Software Developers
http://www.developerdotstar.com