Is there a way to configure Moodle so that when you're viewing a page, you can click on another link, and then return to your original position in the previous page? Doing productive work on Moodle really bogs down when, say, you're working your way through a list of assignments, click on an assignment to grade, and the return to find yourself at the top of the page again. I have assignment pages that span several browser windows, so by the time I get to the end of the list, things start to really slow down.
I can certainly open up other tabs in my browser, but that still doesn't resolve the problem. Am I missing a page cache setting somewhere?
--Brian
No takers on this? Surely I'm not the only one that has noticed this!
I could be wrong, but I thought that Moodle did this intentionally (or at least was actively doing something to prevent your browser's back button taking you back to where the link you clicked is located).
I did however, also think that this had been corrected, though when I tried it a moment ago it didn't work the way I thought it would.
David, do you know how to re-enable that functionality?
No, but this thread suggests it may be to do with nocache headers:
David, you may be on to something...it does look like Moodle sends browser directives that prevent caching. Here's part of a header capture from a Lynx session:
HTMIME: PICKED UP Cache-Control: 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
This would explain the performance issues that arise when switching between very extensive Moodle pages.
Another item to add to my usability issues list!
Thanks for the pointer. The obvious question now is: Why does Moodle default to a "no-store no-cache" browser preference?
--Brian
HTMIME: PICKED UP Cache-Control: 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
This would explain the performance issues that arise when switching between very extensive Moodle pages.
Another item to add to my usability issues list!
Thanks for the pointer. The obvious question now is: Why does Moodle default to a "no-store no-cache" browser preference?
--Brian
Page caching appears to be disabled by default in PHP v. 4.3.3 (and probably other versions as well). This overrides any cache/no-cache directives generated by Moodle. So while Moodle may permit page caching, if PHP is configured to disallow page caching, those settings will override the Moodle settings.
To modify this behavior, open php.ini and change this line:
to this:
Don't forget to stop/start your server after making this change.
Why would you want to do this? If you are annoyed by being returned to the top of long HTML pages (such as a course view with several weeks or topics, or a busy assignment view) whenever you hit the browser's "back" button, making this change should eliminate this particular usability issue.
--Brian
To modify this behavior, open php.ini and change this line:
session.cache_limiter = nocache to this:
session.cache_limiter = private Don't forget to stop/start your server after making this change.
Why would you want to do this? If you are annoyed by being returned to the top of long HTML pages (such as a course view with several weeks or topics, or a busy assignment view) whenever you hit the browser's "back" button, making this change should eliminate this particular usability issue.
--Brian
Brian-What does one do on a shared server where one does not have the ability to stop/start it?
Koen's solution does not require restarting the server or access to php.ini (see below).
If that's the sollution, it can be overridden by the page
http://www.programmershelp.co.uk/docs/phpmanual/function.session-cache-limiter.html
http://www.programmershelp.co.uk/docs/phpmanual/function.session-cache-limiter.html
I added
/* set the cache limiter to 'private' */
session_cache_limiter('private');
$cache_limiter = session_cache_limiter();
to config.php and that seems to do the trick.
!!unsupported trick from someone with no program capabilities!!
Works great! I like your idea better in that it doesn't require a system-wide change in functionality. This is probably something that should be included in config.php in future releases...
I'm a little bit worried since this intensively changes the caching behaviour of the browser.
I've looked at the quiz module to check if it is possible to take a test, look at the sollution and then redo the test, but there is taken care for.
I have been working a few hours on my testserver using this hack. It has some advantages: when you make an error in a form (e.g. make a match question and provide only 2 answers instead of the required 3) you have everything still filled in when you return with the back-button of the browser
Also disadvantages: when you create a forum post and save it, read it, are not happy and hit the back-button, edit the forumposte and post it again, the post appears twice (the first one and the edited one)
So implementing this could may be better done ONLY in pages where it is safe to do so in stead of puttin it in config.php for the whole moodlesit.
I've looked at the quiz module to check if it is possible to take a test, look at the sollution and then redo the test, but there is taken care for.
I have been working a few hours on my testserver using this hack. It has some advantages: when you make an error in a form (e.g. make a match question and provide only 2 answers instead of the required 3) you have everything still filled in when you return with the back-button of the browser
Also disadvantages: when you create a forum post and save it, read it, are not happy and hit the back-button, edit the forumposte and post it again, the post appears twice (the first one and the edited one)
So implementing this could may be better done ONLY in pages where it is safe to do so in stead of puttin it in config.php for the whole moodlesit.
print_header() (in weblib.php) allows the caller to turn off caching on a page-by-page basis. If print_header() is called with caching disabled, it might also require having to reset session-level caching directives. This would require a change in the function body of print_header().
Form submission should not allow double submissions anyway. This can be controlled by what my Core J2EE Patterns book refers to as a Synchronisation (or Déjá Vu) Token.
Basically each form has a unique token in a hidden field which is checked and discarded at submission. If the same token is submitted for a second time then there is an error that can be dealt with gracefully.
In this case you could either chasten the user for doing something crazy (note that their browser will give them a scary warning about "post" data), or second-guess their intentions and take them directly to an edit view of the original post.
This clearing of form fields may help explain some of the strange intermittent error reports we have been receiving from users, where simple and expected errors (e.g. timeouts) result in dataloss because the back button won't retrieve the form contents.
Yes, I was hoping this last problem would have been solved with the session_cache setting, that's why I started trying several forms in combination wiht the back button, but it doesn't seem to solve the dataloss problem all over Moodle (e.g. the forums) : the dataloss problem is solved, causing another problem.
David, are you suggesting this double post problem can be solved by a better handling of some forms?
David, are you suggesting this double post problem can be solved by a better handling of some forms?
After some additional testing, it does appear that caching causes certain areas of Moodle to perform poorly. For instance, posting to a forum, and then going back to review the forum, fails, even if you refresh the browser. (Of course, clearing the cache and reloading the page fixes the issue, but I don't expect students to have to do this.)
It looks like there needs to be a better balance between (1) defaulting all Moodle pages to 'private', with an appropriate max_age value, and (2) modifying the weblib.php code so that session caching can be overridden on a page-by-page basis. Right now, page caching appears to be all-or-nothing.
It looks like there needs to be a better balance between (1) defaulting all Moodle pages to 'private', with an appropriate max_age value, and (2) modifying the weblib.php code so that session caching can be overridden on a page-by-page basis. Right now, page caching appears to be all-or-nothing.
Brian, and all,
with a webapp like moodle, the usual approach is to be non-cacheable by default, and maybe some pages are marked as cacheable.
We can setup the code to accept an override to mark the page as cacheable.
But when you look at it, I suspect that very few, if any, actually qualify to be cacheable, and then only under very specific conditions.
Have you got a list of pages that are safe to cache?
The other thing to consider is that there's a plethora of misconfigured or buggy proxies out there. As soon as the page looks somewhat cacheable they *will* cache it, usually not honouring 'private' and other HTTP 1.1 cache-control headers.
MS Proxy combined with MSIE make a deadly duo. Some knowledge base articles in microsoft.com will tell you exactly how they will ignore cache-control in defiance to the RFC -- for some reason they consider this desirable behaviour. I wish I had the link handy.
with a webapp like moodle, the usual approach is to be non-cacheable by default, and maybe some pages are marked as cacheable.
We can setup the code to accept an override to mark the page as cacheable.
But when you look at it, I suspect that very few, if any, actually qualify to be cacheable, and then only under very specific conditions.
Have you got a list of pages that are safe to cache?
The other thing to consider is that there's a plethora of misconfigured or buggy proxies out there. As soon as the page looks somewhat cacheable they *will* cache it, usually not honouring 'private' and other HTTP 1.1 cache-control headers.
MS Proxy combined with MSIE make a deadly duo. Some knowledge base articles in microsoft.com will tell you exactly how they will ignore cache-control in defiance to the RFC -- for some reason they consider this desirable behaviour. I wish I had the link handy.
One of the pages that it would be useful to cache would be "recent activity" since every time you go back to it it scrolls back to the top of the page, and it makes looking at recent activity rather a hassle.
by allowing caching you may get rid of this 'hassle' that is purely a browser thing (as Martin Dougiamas pointed out). On the other hand, "recent activity" won't show really recent activity anymore ;)
Instead, it will show activity as of the last time it was cached. Hopefully the browser does obey cache-control properly. But there's a myriad of associated problems.
Instead, it will show activity as of the last time it was cached. Hopefully the browser does obey cache-control properly. But there's a myriad of associated problems.
Can anyone then explain why slashdot which, according to Firefox's "Live HTTP Headers" extension, is using no-cache but not no-store is able to show this behaviour (returning to the clicked link on 'back')?.
Not sure how they achieve that.
Some comments regarding slashdot's caching, though. They have a different app can cache a lot more.
In fact, you never see the very latest page. They have swarms of people posting and reading. They can't scale generating a 'correct' and up-to-date page for every reader.
So they pre-output the flat/threaded/nested views of their forums every 5', and they serve that, instead of hitting the database and constructing the forum page for every user.
The scalability tricks they use are quite well documented. They are fun, but I don't know if Moodle wants to go that way.
Slashdot does that because it assumes all pages are public and seen the same way for most users.
Some comments regarding slashdot's caching, though. They have a different app can cache a lot more.
In fact, you never see the very latest page. They have swarms of people posting and reading. They can't scale generating a 'correct' and up-to-date page for every reader.
So they pre-output the flat/threaded/nested views of their forums every 5', and they serve that, instead of hitting the database and constructing the forum page for every user.
The scalability tricks they use are quite well documented. They are fun, but I don't know if Moodle wants to go that way.
Slashdot does that because it assumes all pages are public and seen the same way for most users.
That may be possible for non-logged in users but surely that approach is not efficient for logged in users, like myself, who have customised many of the available options? Maybe they cache at the database level for such users?
Either way they seem to be avoiding the original problem in this thread which means it is perhaps possible to solve it while leaving the "cache/don't cache" and "double-form-submission" problems for later.
Can someone try removing the 'no-store' header, leaving the 'no-cache' one intact, and see what difference that makes?
Sorry, David, I'm still on the "add that line there"-level. I want to try this, but first I have to find out how to do that. (something for after this working day 
)
Right now, the amount of time I'm spending clicking around to configure courses is comparable to the clickfest hell on Blackboard, which is one of the reasons I moved away from BB!
If the Moodle developers don't see this as a usability issue, so be it. But as I begin to develop more complex course structures, I begin to see Moodle slowly migrate back towards BB in terms of usability.
If the Moodle developers don't see this as a usability issue, so be it. But as I begin to develop more complex course structures, I begin to see Moodle slowly migrate back towards BB in terms of usability.
Just to add another tuppence worth, in reaction to Brian's:
If the Moodle developers don't see this as a usability issue, so be it. But as I begin to develop more complex course structures, I begin to see Moodle slowly migrate back towards BB in terms of usability.
... I wouldn't be quite as apocalyptic as that, but certainly I do also find this a serious usability issue: it would be great if it could be improved. My own instinct is on the side of those who would default to allow caching and only override this where there is an identifiable problem. The back button is (supposedly) the second most commonly used navigational device in web browsing. Most users do understand the use of the page refresh button sufficiently to be trusted to request updates for dynamic data when then want/need them.
And, of course, a side-effect of every back-button invocation (where we disallow caching) is to ratchet up the load on the server.
Best - Barry.
Unfortunately, even using refresh isn't always good enough to overcome caching in IE. Often you need to do a SHIFT-refresh, which I feel safe in guessing most people do not know about.
This is exactly the problem people see when their profile images doesn't appear to update.
Imagine that happening all over Moodle ... it would not be pretty. Imagine students saying to each other, "Oh you have to wait for about ten minutes for your new discussions to show up on the forum in Moodle, it's so slow". No, I'm not keen for that.
But there are some pages we can target that will reduce the hassle somewhat for those old back-button users - let's make a target list.
This is exactly the problem people see when their profile images doesn't appear to update.
Imagine that happening all over Moodle ... it would not be pretty. Imagine students saying to each other, "Oh you have to wait for about ten minutes for your new discussions to show up on the forum in Moodle, it's so slow". No, I'm not keen for that.
But there are some pages we can target that will reduce the hassle somewhat for those old back-button users - let's make a target list.
There is a possible solution for the profile images, uploaded documents and CSS files i.e. any file that you want cached for a long period of time before being instantly updated, and then cached for another long period.
I believe a common trick is to add a 'counter' to the url or filename. When the image (or CSS etc.) is updated you also change the counter. To the browser it seems like a file it has never seen before and so it downloads it for sure.
I also noticed when I was messing around with the Headers Display in Firefox that some of the Moodle images (e.g. Resource type, emoticons) are set to expire after 5 minutes. Was this a conscious decision or is it just the default set by Apache?
That last comment about images, I misread my screen. It's actually the styles.php file that's got a 5 minute life. The cacheability checker also says that when it does a conditional GET on this file, the file is sent again, even though it is identical to the one already downloaded.
This brought me the idea of examining the stats of the webserver.
The most served page IS styles.php
(10% of the KBytes trafic on my server!)
Other candidates from wich the caching can be improved is htmlarea.css (editor), overlib.js, and of course al kinds of view.php
The most served page IS styles.php
Other candidates from wich the caching can be improved is htmlarea.css (editor), overlib.js, and of course al kinds of view.php
I'd been meaning to look into some of the other files downloaded by Moodle after I ran it past the Web Page Analyzer.
The spellchecker.js file is relatively new. I take it if you switch off the editor, then you don't need it at all, along with htmlarea.css?
There is also the massive overlib.js, which I'm unsure as to it's purpose. I think maybe it helps with the pop-ups for the calendar but I'm not sure what else.
overlib.js is only used for the calendar popups and the cloze question feedback right now, but I'd like to add more non-essential popups around the place in future. It should be nicely cached that one - PHP is not involved at all.
.. but it is loaded a lot. I don't know if my interpretation is correct, but if it is cached, it is not loaded so it shouldn't generate traffic 
This may be something at the client level, I'm not sure. Also, some of those "hits' may simply be "checks" by the browser looking at the last-modified date.
See the cacheability check for my copy on moodle.org, and the same check and results for your site.
See the cacheability check for my copy on moodle.org, and the same check and results for your site.
Hmm, yes it is. Nice tool by the way.
It's true the hits are not interesting, that's why I showed the kbytes ordered table.
May be it's a setting on our proxyserver, since most of the activity on moodle is done from school and the server is on the internet. (by the way, it's a Microsoft Proxy
(ISA) )
It's true the hits are not interesting, that's why I showed the kbytes ordered table.
May be it's a setting on our proxyserver, since most of the activity on moodle is done from school and the server is on the internet. (by the way, it's a Microsoft Proxy
(ISA) )I believe I've read that proxies can be a bit funny with .js files, some of the optimisation sites recommend embedding smaller scripts within pages for this reason. Unfortunately though I can't locate a good link on the topic right now.
There are other techniques that may apply if anyone thought it worth the time and effort:
- gzip compression
- whitespace and comment stripping
- only including used code (assuming not all of the library is used)
However, I'm wondering if there isn't an alternative approach for pop-ups, maybe even something as simple as title tags.
Please explain how a compliant browser is expected to cache a non-cacheable page. This isn't a browser issue; it's a server-side issue. Maybe there are some non-compliant browsers out there that do cache when they're not supposed to, but I hardly think that qualifies caching control on a compliant browser as being a "browser thing."
Does anyone understand the interaction and differences between 'no-cache' and 'no-store'?
As far as I can tell 'no-store' is intended as a security measure to prevent people from browsing your history and seeing what you filled in to forms etc. This may, as I mentioned earlier, be the eventual cause of users losing their written entries when they try to recover from other errors by using the back button.
This seems to be different from 'no-cache' which (logically at least) should only apply when the browser is deciding whether to load the page again or re-use a cached copy and not when browsing your history.
I can understand why Moodle would want to avoid using the cache but I don't think it's as clear cut why it shouldn't store previously visited pages.
The other thing to consider is that there's a plethora of misconfigured or buggy proxies out there.
So we have to work around MS's arrogance, IOW? I'm being somewhat facetious, but at some point the handholding and special workarounds has to stop.
But when you look at it, I suspect that very few, if any, actually qualify to be cacheable, and then only under very specific conditions.
Actually, I see it just the opposite way: Very few pages need to be marked as non-cacheable. Forum pages, admin pages, assignment submission pages -- those pages that a student would expect to change when they perform some action.
The main usability problem here is that very long HTML pages that aren't cached cannot be returned to with the "back" button. For a teacher who is working on a course with 16 topics, each with 5-8 assignments, multiple quizzes, forums, etc., with 30 students, it quickly becomes painful to move back and forth between assignment/quiz views, grading views, etc. when the "back" button won't return you to the place you started.
Maybe the solution is to serve up HTML pages a screenful at a time, rather than as one long HTML stream. This would probably serve to increase performance (or at least the perception of performance) as well.
Another way to work around this is to set a very short max_age parameter, so any caching that is done will quickly expire.
It's not just IE, it's also some proxies. Yes, it would be easy to arrogantly ignore them but there are real people living in the real world who don't know much about technology and need us to make things robust. I'm sure we can improve on the current situation, even if it's not simple.
Yes, I too would be interested as I often have teh same problem you describe.
Joe
Joe
It's not a "moodle" thing AFAIK ... it's exclusively a browser trait ...
I disagree, Martin. I have used several different browsers on Moodle (IE, Firefox, Opera, Netscape) and all respond the same.
Go check out slashdot.org for an example of what I'm talking about...pick an article, go to the comments, then click on a link in one of the comments, and hit the back button. You're always returned to the same place you were when you clicked the link.
--Brian
Go check out slashdot.org for an example of what I'm talking about...pick an article, go to the comments, then click on a link in one of the comments, and hit the back button. You're always returned to the same place you were when you clicked the link.
--Brian
Yes, you're right - I can see the problem now.
I never encounter it normally because I actually never use the Back button myself! By habit I always middle-click on links to open them in new tabs.
The reason for disabling caching on most of the HTML pages is because they are dynamic. In a forum, posts change, ratings change etc. In the early days I was getting a lot of complaints from people who were changing stuff and not seeing any result from it (epecially IE users), hence the decision to be rather forceful with the cache-killing.
Note that heavier repetitive items like the profile images, the stylesheet, and any uploaded content ARE deliberately being cached (and there is still a small but steady flow of confusion arising from those).
It's a tricky problem, which does not have an all or nothing solution that I can see. I don't think a short time-out is the answer, unfortunately - it will lead to uncertainty in users as to what is happening.
I think we need to identify the specific pages that need improvement (such as assignment reports) and enable the caching for them using that parameter to print_header(). So, Brian, which pages are your pet peeves? (in order from most annoying down)
There are also long-time plans for adding paging to discussions and assignment reports, which should help usability.
P.S. I just moved this from General Problems to General Developer Forum.
I never encounter it normally because I actually never use the Back button myself! By habit I always middle-click on links to open them in new tabs.
The reason for disabling caching on most of the HTML pages is because they are dynamic. In a forum, posts change, ratings change etc. In the early days I was getting a lot of complaints from people who were changing stuff and not seeing any result from it (epecially IE users), hence the decision to be rather forceful with the cache-killing.
Note that heavier repetitive items like the profile images, the stylesheet, and any uploaded content ARE deliberately being cached (and there is still a small but steady flow of confusion arising from those).
It's a tricky problem, which does not have an all or nothing solution that I can see. I don't think a short time-out is the answer, unfortunately - it will lead to uncertainty in users as to what is happening.
I think we need to identify the specific pages that need improvement (such as assignment reports) and enable the caching for them using that parameter to print_header(). So, Brian, which pages are your pet peeves? (in order from most annoying down)
There are also long-time plans for adding paging to discussions and assignment reports, which should help usability.
P.S. I just moved this from General Problems to General Developer Forum.
If I understand the issue correctly it is not that we want some pages to be always cached and others never. Rather we want all pages to be cached for the purpose of getting back to them with the browser's back button but we want fresh versions of almost all pages when we follow a link to get there.
Also if I understand the discussions in this thread correctly, many browsers are too stupid to understand this distinction between using the back button and following a link.
I haven't thought hard about this issue but one solution would appear to be the following: always turn caching on but when generating links to Moodle pages include an additional unique parameter (which is ignored by the called script). That way we force a new version of the page to be generated in spite of caching being on. Of course this requires changes of all links all over Moodle to include this extra parameter but this could be feasible by doing a careful search and replace replacing ? in links by something like ?time='.time().'&'
Of course this wouldn't have to be implemented for all pages at once. We could concentrate on the hit list that Martin wants us to compile.
I certainly feel that the course home pages should be on the list of pages that should be cached for the purpose of the back button.
Gustav writes:
"Also if I understand the discussions in this thread correctly, many browsers are too stupid to understand this distinction between using the back button and following a link."
The HTTP protocol doesn't define the two actions as different, and for good reasons. Part of the problem is that some browsers try and be smart about things like this, when they shouldn't ;)
There's a lot of literature on the perils of misunderstanding and/or mismanaging idempotency in the HTTP protocol and in client-server protocols in general.
Hmmm. I sound like a cranky old man, don't I? It's because as soon as you try and allow 'some' caching, browsers and proxies (in particular from MS) try and be smart about things when they shouldn't.
If you have a website or web app that can tolerate users viewing 'old' data, or data produced for another user (based on an auth cookie), then that's fine. If you cannot tolerate that, there are some cache-control directives that will allow you to define exactly when and how it can be cached.
Only, they are ignored by MSIE. And doubleplus ignored when MSIE is behind an MS Proxy. They just see the 'can cache' part of the instructions, and discard the conditionals.
I have seen a lot of pain from this kind of issues.
"Also if I understand the discussions in this thread correctly, many browsers are too stupid to understand this distinction between using the back button and following a link."
The HTTP protocol doesn't define the two actions as different, and for good reasons. Part of the problem is that some browsers try and be smart about things like this, when they shouldn't ;)
There's a lot of literature on the perils of misunderstanding and/or mismanaging idempotency in the HTTP protocol and in client-server protocols in general.
Hmmm. I sound like a cranky old man, don't I? It's because as soon as you try and allow 'some' caching, browsers and proxies (in particular from MS) try and be smart about things when they shouldn't.
If you have a website or web app that can tolerate users viewing 'old' data, or data produced for another user (based on an auth cookie), then that's fine. If you cannot tolerate that, there are some cache-control directives that will allow you to define exactly when and how it can be cached.
Only, they are ignored by MSIE. And doubleplus ignored when MSIE is behind an MS Proxy. They just see the 'can cache' part of the instructions, and discard the conditionals.
I have seen a lot of pain from this kind of issues.
I put in a vote for the recent activity page.
This is a very good page to start with. I went to fix it just now and then just noticed/remembered that according to Moodle this page is in fact ALREADY meant to be privately cacheable (as are many other pages throughout Moodle) - so at the very least we have uncovered a bug here.
It seems PHP is forcing no-caching on everything, similar to what Koen wrote above.
Using session_cache_limiter('private') in print_header does nothing for me, though, this works better:
@header('Cache-Control: private');
@header('Pragma: ');
@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
Try this link now - it's much faster and is caching as originally intended.
The strange thing is that when I go back that page loads fast but is not always scrolling down to my last click! Anybody got any ideas on that one? Tool around moodle.org for a bit and see if it feels faster.
It seems PHP is forcing no-caching on everything, similar to what Koen wrote above.
Using session_cache_limiter('private') in print_header does nothing for me, though, this works better:
@header('Cache-Control: private');
@header('Pragma: ');
@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
Try this link now - it's much faster and is caching as originally intended.
The strange thing is that when I go back that page loads fast but is not always scrolling down to my last click! Anybody got any ideas on that one? Tool around moodle.org for a bit and see if it feels faster.
Here is the change I made in lib/weblib.php for you to experiment with:
Index: weblib.php
===================================================================
RCS file: /cvsroot/moodle/moodle/lib/weblib.php,v
retrieving revision 1.282.2.17
diff -c -r1.282.2.17 weblib.php
*** weblib.php 21 Nov 2004 06:27:01 -0000 1.282.2.17
--- weblib.php 24 Nov 2004 06:28:07 -0000
***************
*** 1122,1128 ****
$direction = " dir=\"ltr\"";
}
! if (!$cache) { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
--- 1122,1134 ----
$direction = " dir=\"ltr\"";
}
! if ($cache) {
! @session_cache_limiter('private');
! @header('Cache-Control: private');
! @header('Pragma: ');
! @header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
! @header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
! } else { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
Index: weblib.php
===================================================================
RCS file: /cvsroot/moodle/moodle/lib/weblib.php,v
retrieving revision 1.282.2.17
diff -c -r1.282.2.17 weblib.php
*** weblib.php 21 Nov 2004 06:27:01 -0000 1.282.2.17
--- weblib.php 24 Nov 2004 06:28:07 -0000
***************
*** 1122,1128 ****
$direction = " dir=\"ltr\"";
}
! if (!$cache) { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
--- 1122,1134 ----
$direction = " dir=\"ltr\"";
}
! if ($cache) {
! @session_cache_limiter('private');
! @header('Cache-Control: private');
! @header('Pragma: ');
! @header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
! @header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
! } else { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
Martin, that seems to do the trick! The two pages where I think it's needed most (course view and assignment view) now work in a much more user-friendly way (especially the course view when setting up topics or weeks that require many page reloads). As someone mentioned uptopic, a vast improvement...
Your link brings up a good point: What's good for an admin isn't necessarily good for a student.
I am now working on a patch that would offer admins and instructors the ability to completely disable caching on the fly, but only for pages that are served up to their own browser. Other users wouldn't be affected. The problems with caching seem to arise most when trying to create or administer very large courses, with pages that span multiple browser windows. An instructor who is grading assignments doesn't really need caching; they need the ability to move quickly back and forth between pages, without having to scroll down after every page refresh. Creating a course with a lot of content can be a very trying experience when every page refresh that happens after placing a module link causes the focus to return to the top of the page. Being able to temporarily disable page caching on a per-user basis (maybe only limited to instructors and admins) would resolve these issues.
I am now working on a patch that would offer admins and instructors the ability to completely disable caching on the fly, but only for pages that are served up to their own browser. Other users wouldn't be affected. The problems with caching seem to arise most when trying to create or administer very large courses, with pages that span multiple browser windows. An instructor who is grading assignments doesn't really need caching; they need the ability to move quickly back and forth between pages, without having to scroll down after every page refresh. Creating a course with a lot of content can be a very trying experience when every page refresh that happens after placing a module link causes the focus to return to the top of the page. Being able to temporarily disable page caching on a per-user basis (maybe only limited to instructors and admins) would resolve these issues.
Creating a course with a lot of content can be a very trying experience
when every page refresh that happens after placing a module link causes
the focus to return to the top of the page.
There is a built in feature to alliviat this: maximize the topic or week.
Our nav block (in CVS/contrib) makes this even easier by making a left menu that controls the maximizing of different topics/weeks.
gradebook_cdc (also in contrib) has a number of features to make it easier to grade large courses (single student view, reprinted headers, sorting by name or grade, etc.).
However, these caching changes that got stuck into 1.4.2 have made it alot harder to manage courses on IE, they've made it harder for me as an admin because I have to constantly explain to folks they need to force refresh, which more than uses up any time I save (actually I save very little time because by habit I right click and open in a new window when I want to view/edit a linked item while keeping my place in the originating page).
There is a built in feature to alliviat this: maximize the topic or week.
Our nav block (in CVS/contrib) makes this even easier by making a left menu that controls the maximizing of different topics/weeks.
gradebook_cdc (also in contrib) has a number of features to make it easier to grade large courses (single student view, reprinted headers, sorting by name or grade, etc.).
However, these caching changes that got stuck into 1.4.2 have made it alot harder to manage courses on IE, they've made it harder for me as an admin because I have to constantly explain to folks they need to force refresh, which more than uses up any time I save (actually I save very little time because by habit I right click and open in a new window when I want to view/edit a linked item while keeping my place in the originating page).
If you're talking about the small white blocks that allow the viewing of just one week/topic, along with the drop-down menu, they are of limited assistance when creating a lot of content, especially since you can't minimize away topic/week 0. So if topic/week 0 is pretty big, it defeats the purpose of minimizing anything else, since every activity placement will return focus to the top of the page.
I right click and open in a new window when I want to view/edit a linked item while keeping my place
So please explain to me how you use this to help with course design. I've yet to figure out a way to place an activity link in a topic or week without a page refresh, and I don't see how opening a new tab or window helps.
Per-user caching would solve a lot of these issues.
I right click and open in a new window when I want to view/edit a linked item while keeping my place
So please explain to me how you use this to help with course design. I've yet to figure out a way to place an activity link in a topic or week without a page refresh, and I don't see how opening a new tab or window helps.
Per-user caching would solve a lot of these issues.
Hi Brian, I don't recommend putting much if anything in topic 0. IMO, if you maximize topic 3, that is what should be at the top of your course screen, it shouldn't be stuck beneath a bunch of information you've already been seeing (this is supported by research as well, see Richard Mayer on cognitive overload).
Per-user caching would solve a lot of these issues.
How? If you place a new activity, of course you need a page refresh to view it. In fact, with the new caching code in 1.4.2+, this is a major irritant, as (in IE6) new activities don't show up after being placed automatically, you have to force a refresh.
I use right click-new window when I am editing activities or grading, as it then preserves my original state. When I'm designing a course, I want an automatic page refresh everytime I place something or move something, as it used to be in 1.4.2. The little white squares are actually a big help in course design, to help keep things focused on a topic or week, esp. when used with our nav block.
In fact, with the new caching code in 1.4.2+, this is a major irritant, as (in IE6) new activities don't show up after being placed automatically, you have to force a refresh.
Maybe you should consider switching to a browser that caches pages in a standard way. We have over 500 students enrolled in our Moodle courses, and we strongly recommend to them that they use a browser such as Firefox that properly caches pages. The major irritant here isn't the caching fix -- it's the use of non-standards compliant browsers. As I've mentioned in other posts, at some point we have to make a stand and start educating our users on the deficiencies of certain browsers, rather than coming up with kludges to accomodate them.
Maybe you should consider switching to a browser that caches pages in a standard way. We have over 500 students enrolled in our Moodle courses, and we strongly recommend to them that they use a browser such as Firefox that properly caches pages. The major irritant here isn't the caching fix -- it's the use of non-standards compliant browsers. As I've mentioned in other posts, at some point we have to make a stand and start educating our users on the deficiencies of certain browsers, rather than coming up with kludges to accomodate them.
I often use firefox/netscape often, but that is besides the point. I have 8500 faculty and staff customers, 90% of which use IE.
IMO, code that breaks on 90% of my customers machines is broken code, regardless of whether it adheres to standards (standards few of my customers know about and fewer care to spend their time adhering too).
We have over 500 students enrolled in our Moodle courses
They must be very accomodating. I know that if I put out a system that broke on 90% of my clients machines as running, we would be either looking for a new system or a new person for my job.
Heck, we spend alot of time making sure things work on Netscape, even though only 10% of our customers use it, that is just part of being a professional developer, IMO.
IMO, code that breaks on 90% of my customers machines is broken code, regardless of whether it adheres to standards (standards few of my customers know about and fewer care to spend their time adhering too).
We have over 500 students enrolled in our Moodle courses
They must be very accomodating. I know that if I put out a system that broke on 90% of my clients machines as running, we would be either looking for a new system or a new person for my job.
Heck, we spend alot of time making sure things work on Netscape, even though only 10% of our customers use it, that is just part of being a professional developer, IMO.
IMO, code that breaks on 90% of my customers machines is broken code,
regardless of whether it adheres to standards (standards few of my
customers know about and fewer care to spend their time adhering too).
You are certainly entitled to your opinion, as I am mine. Fortunately, my 500 students are computer literacy students (for the most part), so I consider this type of education a value-added part of their course work.
Heck, we spend alot of time making sure things work on Netscape, even though only 10% of our customers use it, that is just part of being a professional developer, IMO.
Been there myself. Which is why I no longer go out of my way to support Microsoft arrogance. It's too bad so many continue to do so...
You are certainly entitled to your opinion, as I am mine. Fortunately, my 500 students are computer literacy students (for the most part), so I consider this type of education a value-added part of their course work.
Heck, we spend alot of time making sure things work on Netscape, even though only 10% of our customers use it, that is just part of being a professional developer, IMO.
Been there myself. Which is why I no longer go out of my way to support Microsoft arrogance. It's too bad so many continue to do so...
I do not want to be rude, but could somebody test this change in weblib.php?
I am not able to replicate this on my test servers, so I NEED testers to fix it!!!
original code:
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
} else { // Do everything we can to prevent clients and proxies caching
new code:
if ($cache) { // Back should work without reload, clicks on links should always reload
@session_cache_limiter('private');
@header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');
@header('Pragma: no-cache');
@header('Accept-Ranges: none');
@header('Expires: ');
} else { // Do everything we can to prevent clients and proxies caching
It is safe to test it on production server.
skodak
I am not able to replicate this on my test servers, so I NEED testers to fix it!!!
original code:
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
} else { // Do everything we can to prevent clients and proxies caching
new code:
if ($cache) { // Back should work without reload, clicks on links should always reload
@session_cache_limiter('private');
@header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');
@header('Pragma: no-cache');
@header('Accept-Ranges: none');
@header('Expires: ');
} else { // Do everything we can to prevent clients and proxies caching
It is safe to test it on production server.
skodak
I suspect the problem may be with Expires: see php man.
I have edited the post above to reset it too.
Now I am 70% sure it will work
I have edited the post above to reset it too.
Now I am 70% sure it will work
Hi Petr, that seems to work, at least with my simple test:
login as someone else, now the "you are logged in as" message displays, w/as with the previous code it didn't without a force refresh.
I didn't see this new code before now, over here it was pasted as:
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
//@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
//@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
} else {
Which didn't help (it was the same as was in weblib previously).
Thanks!
login as someone else, now the "you are logged in as" message displays, w/as with the previous code it didn't without a force refresh.
I didn't see this new code before now, over here it was pasted as:
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
//@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
//@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
} else {
Which didn't help (it was the same as was in weblib previously).
Thanks!
Seems to work either way here.
Thanks!
Thanks!
Testprocedure:
result with IE: exactly the same.
Hope this helps, if not, just tell me what to do
- created an online assignement
- logged in as a student
- uploaded document1
- looked at document1
- uploaded document2 with the same filename as document1
- looked at document2
result with IE: exactly the same.
Hope this helps, if not, just tell me what to do
Hi Koen, I think this is item caching issue, it was same in Moodle 1.3x, AFAIK there isn't a way for the page to control item caching, that is controlled by client settings. So changing an uploaded item with the same name is going to require a refresh in any event.
Page caching on the other hand should be browser controllable. The problemis , different browsers work differently in this area. For instance, in standard 1.4.2+, if you login as a student in IE 6, it would not show that you had logged in as someone else, while in Firefox/NS it would.
Other page contentn change things like editing forum posts or changing assignment names also appear not to change in IE6 with the 1.4.2 version of weblib (without a forced refesh), causing endless teeth gnashing among students and teachers, but Petr's change appears to fix that.
Page caching on the other hand should be browser controllable. The problemis , different browsers work differently in this area. For instance, in standard 1.4.2+, if you login as a student in IE 6, it would not show that you had logged in as someone else, while in Firefox/NS it would.
Other page contentn change things like editing forum posts or changing assignment names also appear not to change in IE6 with the 1.4.2 version of weblib (without a forced refesh), causing endless teeth gnashing among students and teachers, but Petr's change appears to fix that.
Thanks for pointing that out Michael.
I hoped the changes would have impact to the assignements also.
At school we experience terrible cachingproblems in that area, using internet explorer and isa proxyserver. Clearing the cache of IE doesn't do the trick, so I encourage my students to change the filename, what very often results in deleted dots between name and extention etc
For that area it would be nice Moodle added an index automaticaly to the filename, but that is another discussion.
I hoped the changes would have impact to the assignements also.
At school we experience terrible cachingproblems in that area, using internet explorer and isa proxyserver. Clearing the cache of IE doesn't do the trick, so I encourage my students to change the filename, what very often results in deleted dots between name and extention etc
For that area it would be nice Moodle added an index automaticaly to the filename, but that is another discussion.
Hi Koen!
By index automatically do you mean the ability to do the following.
WP1
By index automatically do you mean the ability to do the following.
- Add additional information to an uploaded file along with the file name assigned by the student.
- Student John Doe uploads an assignment named "my_assignment_week_10.doc"
- The system would add something like, "Assignment_10_submitted_120704_ID44_John_Doe_my_assignment_week_10.doc"
WP1
Sort of, yes. I intended something like: uploaded document mydocument.doc, wich becomes mydocument_1.doc, the second time it becomes mydocument2.doc.
This system would be a workaround the cache-problem with something extra
You added already a lot of other fancy stuff to the idea WP
. Having the student name in the file would make it easyer to correct with more then one file open.
This system would be a workaround the cache-problem with something extra
You added already a lot of other fancy stuff to the idea WP
Creating a course with a lot of content can be a very trying experience when every page refresh that happens after placing a module link causes the focus to return to the top of the page.
Rather than discuss the shortcomings of Internet Explorer, it might be more constructive if we fix the problem. In this case, if we assume that people creating a resource want to see it in context we can simply add the id of the relevant section to the end of the url that you are redirected to after adding the resource.
e.g instead of:
http://moodle.org/course/view.php?id=5&topic=all
use this instead:
http://moodle.org/course/view.php?id=5&topic=all#section_2
I know this only works in some browsers, hopefully IE6 is one of them. Can anyone confirm this?
Hmm, why not use that handy icon "Show only topic #" (small white rectangle) in this case???
IMO pages should be cached only when going back. (Uploaded files should be cached by default, except for assignments.)
IMO pages should be cached only when going back. (Uploaded files should be cached by default, except for assignments.)
works fine in firefox ... but not in IE
Did this get pushed into 1.4.2+ and is this why IE/Win suddenly (after upgrading from 1.4.1) so often needs to be force-refreshed to show changes now?
I've tried a variety of cach settings, including refresh every time the page is viewed, and IE consistently fails to refresh the page. Netscape/Firefox doesn't have the problem.
Martin, did you really intend to make this "change I made in lib/weblib.php for you to experiment with" in Moodle 1.4? Surely experimental code should go into Moodle 1.5 dev only?
Normally so, yes.
When testing it at the time this small bugfix for caching (to make it work like it was always supposed to) worked quite well on all my browsers, and the performance benefits were substantial. I tried it on moodle.org for a while and no-one reported anything.
I hadn't noticed what it was doing to the course editing page under IE, though ... My sincere apologies!
When testing it at the time this small bugfix for caching (to make it work like it was always supposed to) worked quite well on all my browsers, and the performance benefits were substantial. I tried it on moodle.org for a while and no-one reported anything.
I hadn't noticed what it was doing to the course editing page under IE, though
... My sincere apologies!
It's scrolling down for me. This is a vast improvement. I used to find recent activity to be a very cumbersome page to use but not anymore.
Totally cool, seems to work for me with IE. 
So, Brian, which pages are your pet peeves?
Where do I start?
Just kidding
I don't want this to be "Brian's list." If the consensus is that this isn't a problem, and that I should be ctrl-clicking links and opening a new tab, I can live with that. From what I've read here and from my own research, it's not an easy problem to solve. I was on eBay tonight, and noticed that at their "My eBay" page, you can modify the page in some way, and the page will refresh and display at exactly the same point where it was prior to the refresh. So I know it's possible, but at what cost?
Sounds like I'm backpedaling here, but I don't want to harp on something that, in the end, might require more effort than it's worth. I write software too, and am all too familiar with expending energy on something that's more of a personal issue than a real problem. Maybe future paging efforts that you mention will simply make this a non-problem.
Delightful though it is to hint at the limitations of Microsoft Browsers , I suspect that the "features" of some caching systems can be just as exciting.On My page at
http://www.examulator.com/phezam/question.php
I have tried many permutations to force no cache so that each day users see a shiny new question of the day. At home it works on every browser I use. At college it is knacked, and I am fairly sure it is because of our poxy server. Every so often I get someone suggesting it is not working and they see the same question every day, whereas their cache is keeping the truth from them. I even toyed with a scheme to append random numbers to the URL to really, really force things but settled on a little text hint instead.
http://www.examulator.com/phezam/question.php
I have tried many permutations to force no cache so that each day users see a shiny new question of the day. At home it works on every browser I use. At college it is knacked, and I am fairly sure it is because of our poxy server. Every so often I get someone suggesting it is not working and they see the same question every day, whereas their cache is keeping the truth from them. I even toyed with a scheme to append random numbers to the URL to really, really force things but settled on a little text hint instead.
So let me make sure I understand what's going on:
1. A performance bottleneck is identified.
2. Code that should have been working isn't, so it's fixed properly.
3. Folks complain because they are behind a brain-dead proxy, or are using a non-compliant browser.
4. Changes are backed out, reverting to original bottleneck.
5. End of issue.
How about a compromise: What if the user setup page was modified to include a "caching enabled" option, and the course view was modified to add a "Enable caching" button right below the "Turn editing on" button? This would allow a quick override for those who have caching turned off by default, but want to be able to work productively? The "caching enabled" option would allow users who are aware of the caching issues to enable them anyway.
This isn't a new feature; this is something that should have been enabled already.
Thoughts?
1. A performance bottleneck is identified.
2. Code that should have been working isn't, so it's fixed properly.
3. Folks complain because they are behind a brain-dead proxy, or are using a non-compliant browser.
4. Changes are backed out, reverting to original bottleneck.
5. End of issue.
How about a compromise: What if the user setup page was modified to include a "caching enabled" option, and the course view was modified to add a "Enable caching" button right below the "Turn editing on" button? This would allow a quick override for those who have caching turned off by default, but want to be able to work productively? The "caching enabled" option would allow users who are aware of the caching issues to enable them anyway.
This isn't a new feature; this is something that should have been enabled already.
Thoughts?
Here's a working example of what I'm talking about (apply this after Martin's original caching patch):
*** blocks/admin/block_admin.php 2004/12/08 06:44:41 1.2
--- blocks/admin/block_admin.php 2004/12/08 21:08:50
***************
*** 88,93 ****
--- 88,101 ----
} else {
$this->content->items[]='<a href="view.php?id='.$this->course->id.'&edit=on">'.get_string('turneditingon').'</a>';
}
+
+ $this->content->icons[]='<img src="'.$CFG->pixpath.'/i/edit.gif" height="16" width="16" alt="">';
+ if (iscaching($this->course->id)) {
+ $this->content->items[]='<a href="view.php?id='.$this->course->id.'&cache=off">'.get_string('turncachingoff').'</a>';
+ } else {
+ $this->content->items[]='<a href="view.php?id='.$this->course->id.'&cache=on">'.get_string('turncachingon').'</a>';
+ }
+
$this->content->items[]='<a href="edit.php?id='.$this->course->id.'">'.get_string('settings').'...</a>';
$this->content->icons[]='<img src="'.$CFG->pixpath.'/i/settings.gif" height="16" width="16" alt="">';
*** lang/en/moodle.php 2004/12/08 06:44:14 1.2
--- lang/en/moodle.php 2004/12/08 21:07:03
***************
*** 1018,1023 ****
--- 1018,1025 ----
$string['topicoutline'] = 'Topic outline';
$string['topicshow'] = 'Show this topic to $a';
$string['total'] = 'Total';
+ $string['turncachingoff'] = 'Turn caching off';
+ $string['turncachingon'] = 'Turn caching on';
$string['turneditingoff'] = 'Turn editing off';
$string['turneditingon'] = 'Turn editing on';
$string['undecided'] = 'Undecided';
*** course/view.php 2004/12/08 21:09:08 1.1
--- course/view.php 2004/12/08 21:13:53
***************
*** 58,63 ****
--- 58,74 ----
$rightblocks = explode(',', $rightpart);
}
+ if(!isset($USER->caching)) {
+ $USER->caching = false;
+ }
+ if (isset($cache)) {
+ if ($cache == "on") {
+ $USER->caching = true;
+ } else if ($cache == "off") {
+ $USER->caching = false;
+ }
+ }
+
if (!isset($USER->editing)) {
$USER->editing = false;
}
***************
*** 72,77 ****
--- 83,89 ----
$USER->editing = false;
}
}
+
$editing = $USER->editing;
*** lib/weblib.php 2004/12/08 21:14:43 1.1
--- lib/weblib.php 2004/12/08 21:18:42
***************
*** 1122,1128 ****
$direction = " dir=\"ltr\"";
}
! if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
--- 1122,1128 ----
$direction = " dir=\"ltr\"";
}
! if (isset($USER->caching) && $USER->caching) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
*** blocks/admin/block_admin.php 2004/12/08 06:44:41 1.2
--- blocks/admin/block_admin.php 2004/12/08 21:08:50
***************
*** 88,93 ****
--- 88,101 ----
} else {
$this->content->items[]='<a href="view.php?id='.$this->course->id.'&edit=on">'.get_string('turneditingon').'</a>';
}
+
+ $this->content->icons[]='<img src="'.$CFG->pixpath.'/i/edit.gif" height="16" width="16" alt="">';
+ if (iscaching($this->course->id)) {
+ $this->content->items[]='<a href="view.php?id='.$this->course->id.'&cache=off">'.get_string('turncachingoff').'</a>';
+ } else {
+ $this->content->items[]='<a href="view.php?id='.$this->course->id.'&cache=on">'.get_string('turncachingon').'</a>';
+ }
+
$this->content->items[]='<a href="edit.php?id='.$this->course->id.'">'.get_string('settings').'...</a>';
$this->content->icons[]='<img src="'.$CFG->pixpath.'/i/settings.gif" height="16" width="16" alt="">';
*** lang/en/moodle.php 2004/12/08 06:44:14 1.2
--- lang/en/moodle.php 2004/12/08 21:07:03
***************
*** 1018,1023 ****
--- 1018,1025 ----
$string['topicoutline'] = 'Topic outline';
$string['topicshow'] = 'Show this topic to $a';
$string['total'] = 'Total';
+ $string['turncachingoff'] = 'Turn caching off';
+ $string['turncachingon'] = 'Turn caching on';
$string['turneditingoff'] = 'Turn editing off';
$string['turneditingon'] = 'Turn editing on';
$string['undecided'] = 'Undecided';
*** course/view.php 2004/12/08 21:09:08 1.1
--- course/view.php 2004/12/08 21:13:53
***************
*** 58,63 ****
--- 58,74 ----
$rightblocks = explode(',', $rightpart);
}
+ if(!isset($USER->caching)) {
+ $USER->caching = false;
+ }
+ if (isset($cache)) {
+ if ($cache == "on") {
+ $USER->caching = true;
+ } else if ($cache == "off") {
+ $USER->caching = false;
+ }
+ }
+
if (!isset($USER->editing)) {
$USER->editing = false;
}
***************
*** 72,77 ****
--- 83,89 ----
$USER->editing = false;
}
}
+
$editing = $USER->editing;
*** lib/weblib.php 2004/12/08 21:14:43 1.1
--- lib/weblib.php 2004/12/08 21:18:42
***************
*** 1122,1128 ****
$direction = " dir=\"ltr\"";
}
! if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
--- 1122,1128 ----
$direction = " dir=\"ltr\"";
}
! if (isset($USER->caching) && $USER->caching) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
Folks complain because they are behind a brain-dead proxy, or are using a
non-compliant browser.
Folks complain because Moodle was working fine one day and then after what should a bug fix, doesn't work. (rule of thumb: 'improvements' shouldn't break existing installs in a current version--especially installs in active use, toward the end of the semester!)
Solution:
Test the code in a beta/development version until it works on the browsers and servers that Moodle worked fine on before or put the new code in a version upgrade with new system requirements cleary stated.
If a change is going to break existing installs, it should put into a new version number, so that folks can test it and decide when try and get proxy settings changed or everyone to switch browsers at a time of their choosing (or stay with the current version because the increase in requirements is too expensive to meet).
PS I don't think the change was "backed out of" rather it was pushed into a development version, where it can be tested on non-production sites until it works everywhere Moodle currently works or can be put into a upgrade that has new system requirements.
Folks complain because Moodle was working fine one day and then after what should a bug fix, doesn't work. (rule of thumb: 'improvements' shouldn't break existing installs in a current version--especially installs in active use, toward the end of the semester!)
Solution:
Test the code in a beta/development version until it works on the browsers and servers that Moodle worked fine on before or put the new code in a version upgrade with new system requirements cleary stated.
If a change is going to break existing installs, it should put into a new version number, so that folks can test it and decide when try and get proxy settings changed or everyone to switch browsers at a time of their choosing (or stay with the current version because the increase in requirements is too expensive to meet).
PS I don't think the change was "backed out of" rather it was pushed into a development version, where it can be tested on non-production sites until it works everywhere Moodle currently works or can be put into a upgrade that has new system requirements.
rule of thumb: 'improvements' shouldn't break existing installs in a
current version--especially installs in active use, toward the end of
the semester!
I have my own rule of thumb: Never make changes to a production server towards the end of the semester (or anytime during the semester, actually). I run several "test moodles" for this purpose. You should consider the same.
But the point's moot...I've proposed a viable solution that will (1) fix the current bug and (2) give everyone what they want.
I have my own rule of thumb: Never make changes to a production server towards the end of the semester (or anytime during the semester, actually). I run several "test moodles" for this purpose. You should consider the same.
But the point's moot...I've proposed a viable solution that will (1) fix the current bug and (2) give everyone what they want.
I run several "test moodles" for this purpose.
O yes, that is surely a good idea. The problem is 1.4.2+ should be perfectly fine to run on a production server. It should in fact be better than the previous release, since it's only supposed to contain bug fixes, as stated in the download screen.
It was a mistake to load the inadequately tested caching code into 1.4.2+, cool, people make mistakes.
Now we can acknowledge, and move on.
O yes, that is surely a good idea. The problem is 1.4.2+ should be perfectly fine to run on a production server. It should in fact be better than the previous release, since it's only supposed to contain bug fixes, as stated in the download screen.
It was a mistake to load the inadequately tested caching code into 1.4.2+, cool, people make mistakes.
Now we can acknowledge, and move on.
As I've explained, the recently "added" caching method did pass all the testing that was reasonably possible. It only breaks on proxy/browser combinations that are themselves broken (and that I have no access to).
Moving on, I would like those who did experience this caching problem to please put their energy into testing Petr's recently-posted alternative headers on your testing servers during the next few days. I've also installed it here on moodle.org for you to try.
Edit lib/weblib.php in the latest STABLE CVS version, and find:
$cache = false; //// FIXME: This is a temporary hack until caching is solved better
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
} else { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
@header('Cache-Control: post-check=0, pre-check=0', false);
@header('Pragma: no-cache');
$meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
$meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
}
then replace it with:
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');
@header('Pragma: no-cache');
@header('Accept-Ranges: none');
@header('Expires: ');
} else { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
@header('Cache-Control: post-check=0, pre-check=0', false);
@header('Pragma: no-cache');
$meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
$meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
}
Moving on, I would like those who did experience this caching problem to please put their energy into testing Petr's recently-posted alternative headers on your testing servers during the next few days. I've also installed it here on moodle.org for you to try.
Edit lib/weblib.php in the latest STABLE CVS version, and find:
$cache = false; //// FIXME: This is a temporary hack until caching is solved better
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private');
@header('Pragma: ');
@header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
} else { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
@header('Cache-Control: post-check=0, pre-check=0', false);
@header('Pragma: no-cache');
$meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
$meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
}
then replace it with:
if ($cache) {
@session_cache_limiter('private');
@header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');
@header('Pragma: no-cache');
@header('Accept-Ranges: none');
@header('Expires: ');
} else { // Do everything we can to prevent clients and proxies caching
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
@header('Cache-Control: no-store, no-cache, must-revalidate');
@header('Cache-Control: post-check=0, pre-check=0', false);
@header('Pragma: no-cache');
$meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
$meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
}
Hi Martin -
I saw, what I believe was this problem, in two different installations. One of them was my own internal test server, running FreeBSD and no proxies. The other was a client, who was testing the new release on his servers (not the one with actual students
).
Of course, I never saw the problem either - lately, I keep forgetting to check *everything* in IE as well.
When I did test it with IE on my server, I saw the problem. In my case, clicking the 'turn edit on' button did nothing until after a certain amount of time passed, or I used <shift> refresh. I don't run a proxy.
Anyway, the fix that Petr posted seems to be working. At least, I can't duplicate the problem in the same way.
mike
I saw, what I believe was this problem, in two different installations. One of them was my own internal test server, running FreeBSD and no proxies. The other was a client, who was testing the new release on his servers (not the one with actual students
).Of course, I never saw the problem either - lately, I keep forgetting to check *everything* in IE as well.
When I did test it with IE on my server, I saw the problem. In my case, clicking the 'turn edit on' button did nothing until after a certain amount of time passed, or I used <shift> refresh. I don't run a proxy.
Anyway, the fix that Petr posted seems to be working. At least, I can't duplicate the problem in the same way.
mike
Hi Martin, Petr's fix works here on all the tests that were causing problems before (my big ones were adding/changing resources/activities and logging in as student).
Our server may be broken, but its a stock RHE with Moodle set up per Moodle's install instructions, and all our other php sites work fine (postnuke, scout/CWIS, phpbb, and test sites of tikiwiki, atutor dotproject, programE & mambo).
PS huge <THANKS> to Petr for all the work he's doing sorting this out!
Our server may be broken, but its a stock RHE with Moodle set up per Moodle's install instructions, and all our other php sites work fine (postnuke, scout/CWIS, phpbb, and test sites of tikiwiki, atutor dotproject, programE & mambo).
PS huge <THANKS> to Petr for all the work he's doing sorting this out!
I read the PHP manual again and did some testing, it seems that @session_cache_limiter('private') can be used only before the session_start(), here it is IMO ignored (because it seems that default headers are produced at session start only). Anyway it is not a problem here, it is possible to tweak/remove it later in 1.5dev.
I would also move Accept-Ranges after the if-else, so that it is sent for both cases, just to be sure no client tries to request ranges - because they AFAIK do not work in PHP. The only clients I know that are regularly requesting ranges are mass-downloaders. The downloads will not be resumable, but at least they will work.
skodak
I would also move Accept-Ranges after the if-else, so that it is sent for both cases, just to be sure no client tries to request ranges - because they AFAIK do not work in PHP. The only clients I know that are regularly requesting ranges are mass-downloaders. The downloads will not be resumable, but at least they will work.
skodak
Makes sense - below is the latest code in HEAD now. If anyone knows why this code and 1.4.3 should not be joined together in holy matrimony, speak now or forever hold your peace.
if ($cache) { // Allow caching on "back" (but not on normal clicks)
@header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');
@header('Pragma: no-cache');
@header('Expires: ');
} else { // Do everything we can to always prevent clients and proxies caching
@header('Cache-Control: no-store, no-cache, must-revalidate');
@header('Cache-Control: post-check=0, pre-check=0', false);
@header('Pragma: no-cache');
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
$meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
$meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
}
@header('Accept-Ranges: none');
if ($cache) { // Allow caching on "back" (but not on normal clicks)
@header('Cache-Control: private, pre-check=0, post-check=0, max-age=0');
@header('Pragma: no-cache');
@header('Expires: ');
} else { // Do everything we can to always prevent clients and proxies caching
@header('Cache-Control: no-store, no-cache, must-revalidate');
@header('Cache-Control: post-check=0, pre-check=0', false);
@header('Pragma: no-cache');
@header('Expires: Mon, 20 Aug 1969 09:23:00 GMT');
@header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
$meta .= "\n<meta http-equiv=\"pragma\" content=\"no-cache\" />";
$meta .= "\n<meta http-equiv=\"expires\" content=\"0\" />";
}
@header('Accept-Ranges: none');
Thanks for not sweeping this one under the rug...I think performance isn't something that should be sacrificed in lieu of added functionality (I know my views aren't shared by all on this). If I ruffled some feathers, I hope they can smooth back down again
Tested Petr's latest changes on Firefox 1.0+, Safari 1.2.4, and IE 5.2 (yes, I keep a copy around), all on the Mac. Works great! Much more performance in so many ways.
I still think there are some performance-related issues that can be addressed in terms of how page redirects are called, etc..I'll continue to work on these, and maybe they can be considered for inclusion in 1.5.
--Brian
Tested Petr's latest changes on Firefox 1.0+, Safari 1.2.4, and IE 5.2 (yes, I keep a copy around), all on the Mac. Works great! Much more performance in so many ways.
I still think there are some performance-related issues that can be addressed in terms of how page redirects are called, etc..I'll continue to work on these, and maybe they can be considered for inclusion in 1.5.
--Brian
Not sure why you would think any rug-sweeping was necessary 8-0 , but performance is as important to me as anyone and I want to see this resolved postitively.