Last modified: 2013-03-01 17:05:11 UTC
The caching behavior is a source of confusion for users, especially when they interact with EducationProgram pages and cause the page to reload (for example, by pressing Submit) and the reloaded page does not contain the expected content because it is a cached version. If we cannot easily get rid of the caching behavior altogether, is it possible to automatically update the cached version when relevant actions are done (such as any Submit action for modifying a course page, or any time a student enrolls)?
If you edit an course or org page, its cache will be invalidated. Pages that aggregate information, such as Special:Courses or Special:StudentActivity won't be automatically updated. There is no easy silver bullet solution here as far as I can see. Can you list the workflows (or pages) where people really have a problem with it? Then I can look into those and see if we can do invalidation somehow. Could also create refresh jobs, though that will be some work.
I will investigate more. One place it occurs is after a student adds an article. See around 5:30 of this video: https://commons.wikimedia.org/wiki/File:Informal_walkthrough_of_using_course_pages_in_early_2013.ogv I'll keep a close eye out for other situations where the caching is disruptive.
I just ran into that exact usecase. Indeed very confusing. Invalidation here is definitely possible and thus should happen.
I'm bumping the priority on this, because we're seeing a lot of reports of confused students. When you add an article, the cache is not invalidated and so a student can easily get confused and frustrated when their article does not appear when the page reloads.
Ok, have assigned it to myself and will look at it soonish.
This would also be easier to do when switching to Content Handler, as then we could use the parser cache. The way the caching is currently done makes it very hard to invalidate on a lot of places. Could also change the way the caching is done without switching to CH, though either way, that is some work...
The page cache can be disabled using $egEPSettings['enablePageCache'] = false; This is likely not acceptable on WP though. Building a course page involves some stuff, and though it is not that expensive, it's likely not something you want to have done on every view.
If you can't do a fix for this within, say, the next two weeks, then perhaps waiting on the ContentHandler switch makes sense. Right now, and for the next few weeks, is when the caching is going to be causing the most problems for classes. After that, most students will have listed their articles already, so a a short-term fix that delays other work makes less sense. We have a notice up at the top on all the course pages, though, so it shouldn't cause too terrible of problems in the meantime... I haven't had any additional complaints about articles not appearing in the table since I put it up.
Just realized that the course pages are not supposed to be cached for logged in users to begin with. That's a bug. I fixed it with https://gerrit.wikimedia.org/r/49669 I suspect this solves most of the issues you are running into, so decreasing bug priority. If there are remaining places where users often get confused, please increase it again.
Excellent! Yes, that should totally totally take care of it. Only logged in user can make changes that will require cache invalidation anyway.
I'm going to close this as your main reason for opening this bug has been fixed. If there are specific issues elsewhere related to caching, please create a bug for each of them.
As of now, there aren't an problems with caching that I'm aware of.
