Item10682: Add upgrade advice to reset PageCache
Priority: Normal
Current State: Closed
Released In: 1.1.4
Target Release: patch
Applies To: Engine
Component: Configure,
PageCache, Install
Branches: trunk
GeorgeClark helped an IRC user having trouble with their
TinyMCEPlugin, where the ultimate solution turned out to be resetting/disabling PageCache. Let's make it clear that this needs to be cleared on upgrade.
--
PaulHarvey - 26 Apr 2011
Is it really the PageCache or is it the browser cache needing a refresh? If it is the PageCache, then what's the explanation?
--
MichaelDaum - 26 Apr 2011
Not sure of all the issues, but the %WIKIVERSION% was wrong on some pages, so there was a mixture of 1.1.2 or 1.1.3 being reported as being installed. Main.WebHome, System.WebHome and System.InstalledPlugins didn't agree on API or Foswiki versions. That's the issue that was exposed by the page cache. I don't think we were 100% sure that the
TinyMCE issue was due to the page cache as multiple things were changed. It was not the browser cache - cleared multiple times and even tried different browsers.
TinyMCE was initially resolved by removing the comment from the line
* #Set TINYMCEPLUGIN_INIT_TOPIC = TinyMCEPlugin
in the System.DefaultPreferences. Reporter was going to revert the prefs change and re-test with the cache disabled but didn't report back if it was successful.
--
GeorgeClark - 26 Apr 2011
There were some new settings introduced in the 1.1.3
TinyMCEPlugin, and also, the way they are encoded was changed. So the edit screen needs to be rendered with different HTML to properly populate the javascript variables the new version requires.
In other words, I suspect that the new javascript didn't like the config JSON it was getting on the edit screen. This would been easy to verify if we asked the user to edit some other topic that had never been edited before.
However, now that I think of it, the failure mode shouldn't have been that " TINYMCEPLUGIN_INIT missing" error... so now I'm not so sure.
--
PaulHarvey - 27 Apr 2011
So what do we do with this report? Somebody needs to verify whats going on here. Actions documented should be well understood before adding it to the upgrade procedure.
--
MichaelDaum - 27 Apr 2011
We could:
- Advise users to always clear their pagecache on every upgrade, or
- Advise users to clear their pagecache when there are likely to be problems (for example, if we again change the default TinyMCEPlugin configuration, I will try to remember to add this to the upgrade notes; also if we change skin .tmpl files).
It's worth noting that if upgrade packages were "installed" (system topics checked-in), this should have fired a dependency which would have invalidated the edits screens.
--
PaulHarvey - 27 Apr 2011
I take it that with the upgrade, any system rendered macros that would be modified by the upgrade are going to be the problem areas. %WIKIVERSION%, %PLUGINDESCRIPTIONS%, %PLUGINVERSION{}% are all potentially going to be incorrect after an upgrade if the containing page is cached.
I'm not all that familiar with the page cache - I've never tried it. But would this also be true for any topics shipped with Foswiki? For example, would the 1.1.3
ReleaseNotes01x01 be cached and still display the 1.1.2 version after the 1.1.3 upgrade?
As Paul suggests, it would probably be safest to reset the pagecache after any upgrade to avoid any side effects of the caching.
Good point about the installers, though we are trying to avoid checking in files to minimize rcs overhead. The package installer will currently only check in a topic if an rcs file exists for the topic. And regardless of topic checkins, an upgraded plugin can impact the rendered results of macros that might be in the cache really anywhere in the wiki, it would probably be safer to have the installer do a full cache reset after an upgrade (or uninstall) so that stale results are not kept in the cache.
--
GeorgeClark - 28 Apr 2011