We received the following email from a client yesterday:
“I’ve had a problem for about a year with my company website. It makes me attempt the login 3-5 times before getting into the backend, and then when I’m in, I have to save any change I make to the site either 2, 3, or 4 times. I just dealt with this weird issue for a while but I can’t take it anymore. I don’t have any coding or technical experience (I’m a long-term amateur Joomla guy). I’m wondering if you guys could help.”
We were perplexed, because we really haven’t seen anything like this before, except maybe for this, but it really didn’t apply to our client since he wasn’t being redirected from www to non-www (or vice versa) when he tried to login and the problem was also happening when he was trying to save articles (or any content item, as we later discovered).
So, we started testing the website and it was very annoying, every time we tried to login we had to login multiple times. The first time it was showing a blank page, and the second time it was showing the following error:
The most recent request was denied because it contained an invalid security token. Please refresh the page and try again.
The third time the website displayed the above error again, and then, when we went to the login page the fourth time (or the fifth time), the website logged us in immediately (without even having to re-enter the username and password).
Now, of course, we wanted to know why the website was showing a blank page the first time we tried to login… So, we set error reporting to Maximum in the configuration.php file and then we tried to login again, and this time, the first time we tried to login, we saw the following error:
Fatal error: Call to a member function checkSession() on a non-object in plugins/user/joomla/joomla.php on line 216
A quick research on the above error revealed that the cause of the problem was the presence of the folder libraries/joomla/plugin folder, which was there from a previous Joomla version, and so we deleted the libraries/joomla/plugin folder, thinking that this would solve the main problem. But it didn’t, it just redirected us to the login page the first time we tried to login (the second time [and the third time, and the fourth time] it still showed the error “The most recent request was denied…”), and so we continued testing and experimenting.
We then remarked something: when we modified an article in the backend, it was modified immediately in the database, but it was still loading the old article in the backend, which meant that the issue was caused by an aggressive type of browser caching. Aha!
So, in order to fix the problem, we instructed the browser not to cache the pages on the Joomla website by adding the following to the very beginning of the .htaccess file (located under the main directory of the website, but we could also have created a different .htaccess file and placed it under the administrator folder):
<FilesMatch "\.(html|htm|php)> FileETag None Header unset ETag Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate" Header set Pragma "no-cache" Header set Expires "Mon, 01 Jan 1990 00:00:00 GMT" </FilesMatch>
As soon as we added the above code, everything worked normally: we only had to login once and we only had to save content items once. The problem was solved! Hooray!
But what caused that aggressive browser caching in the first place?
The website was on a shared hosting, so we assume that the host has enabled this aggressive browser caching at the Apache level in order to reduce the server’s overall traffic (and load).
Now, if you have to login multiple times to your Joomla website and/or you have to save the same article multiple times until you see your changes in the backend, then try adding the above code to your .htaccess file to disable browser caching. If the problem persists, then please contact us. We’ll be happy to help, we always find a solution, and our fees are super affordable!
Thanks so much for this post. We’ve been plagued with a similar problem for the past few months (back-end caching) and this seems to have fixed the problem. Kudos.
I added this to the main, root, .htaccess and it has stopped front-end 403 errors on Internet Explorer 11. Thank you. However, does this mean that all browser caching is now disabled for all website visitors or just for logged-in users with editing access?
Hi Gillian,
If you added the above code to the main .htaccess file, then browser caching will be disabled for all visitors. You should add it to the .htaccess in the administrator folder (if an .htaccess file in the administrator folder does not exist, then you should create it).
Hi everyone. This information is still current and thank you very much for leaving it published. Take care of your health!