One of the most annoying problems with the System – Page Cache plugin is the fact that when you update an article, then that update won’t reflect on the website immediately, as the cached page would still be served to the visitors and won’t be refreshed until it “expires”. In fact, the absolute majority of Joomla news websites completely avoid the “System – Page Cache” core plugin just because of this issue, and instead use a 3rd party extension to fulfill their caching needs, which is a far-from-ideal solution, as 3rd party caching extensions have their own “quirks”.
So, what is the ideal solution?
The ideal solution is, of course, to have the System – Page Cache plugin refresh all the affected pages when an article is updated. An almost ideal solution is to develop a plugin that will refresh the affected pages when an article is updated, and this is exactly what we did at itoctopus!
We developed a system plugin that cleaned the following pages when an article was updated:
- The article’s page
- The print version of the article’s page
- The article’s category page
- The article’s category RSS page
- The homepage
- The main RSS feed page
In essence, we did the above when the onContentAfterSave and the onContentChangeState events were triggered, and when the $context was “com_content.article”. We cleaned all the cache entries when $context was not “com_content.article”. We also cleaned all the cache entries when the onExtensionAfterSave event was triggered (so, for example, when a module, any module, is saved, then the whole cache is wiped out).
We deployed the plugin on a major website and the whole thing worked like a breeze: the server’s load decreased substantially (at this very moment, the 15 minute load is 0.84, which is really hard to beat on a website receiving a 100,000 page loads every day). Not only that, the staff was much happier, everything responded quicker than before, and their changes were reflected instantly (so they got the best of both worlds).
We were happy because the client was happy and because of the major performance gain on the server, but we were also concerned. Our heavy and low level work with the Joomla caching mechanism revealed that the latter needs a substantial overhaul as it doesn’t seem to have been planned well. For example, it is very easy to generate and delete a cached version of a page when you are actually on that page, but it is very hard to do anything with the cached version of a page if you are not on that page (especially if you are trying to do it from the backend).
We hope that you found this post, and our concept for efficiently refreshing the cache, useful. If you have any questions, or if you need us to implement the above on your Joomla website, then please contact us. Our fees are right, our work is clean, and we are experts in Joomla performance.