A regular client who subcontracts work to us emailed us that he wasn’t able to update the website of one of his clients from Joomla 3.8.3 to Joomla 3.8.5. He told us that the update would fail halfway through with the following error:
AJAX Loading Error: error
Of course, the first thing that we thought was a blocked restore.php file, despite the fact that the error was a bit different. So, we checked whether there was a rule in the .htaccess file blocking direct execution of PHP files other than the index.php file, but, not only we didn’t find any blocking rule, we didn’t find any .htaccess file at all. Additionally, all the permissions on the restore.php file were correct as we were able to directly access the file from our browser by using the following URL: http://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php (it was returning the following json ###{“status”:false,”message”:”Invalid login”}###).
So, we tried to update the website ourselves (after backing up the filesystem and the database) and, at first, everything went smoothly. However, at exactly 56% of the update process, the progress stopped. About 30 seconds later, we saw the same error that our client was seeing. Not only that, we were blocked from accessing the website for about 5 minutes (we checked the website through a proxy and it was working there). Hmmm!
We were a bit suspicious of this whole 5 minute block thing, but, at first, we didn’t think of it much as we assumed it was just a coincidence. So, we did a research on the issue (yes, sometimes we rely on other people’s answers to the problem), and some were stating that the presence of a $live_site value in the configuration.php file was causing the same problem for them. So, we checked the configuration.php file under the main directory of the Joomla website, and, to our disappointment, the $live_site value was already empty. Others claimed that clearing the cache may solve the problem, so, we cleared the Joomla cache (there was about 1 GB of cached files, which was quite a lot, even more so when you take into consideration that the website was extremely simplistic), and then we tried the update again, but it didn’t work. Not only it didn’t work, but we were also blocked again. Double hmmm!
Once we were unblocked, we tried the update using Google Chrome while having the console open (you can open the console in Google Chrome by pressing F12), and we saw the following messages:
update.js?73ddd8fdd62da3333508a24283f9db89:171 XHR finished loading: POST "https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php". update.js?73ddd8fdd62da3333508a24283f9db89:171 POST https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php net::ERR_CONNECTION_TIMED_OUT update.js?73ddd8fdd62da3333508a24283f9db89:171 XHR failed loading: POST "https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php".
Now, if you read the second line a bit more closely, you will notice that the browser is complaining about timing out while posting to the restore.php file. We immediately thought of 2 things that may have been causing the issue:
- A small value of the max_execution_time PHP setting.
- A weird rule triggered by an application firewall, such as ModSecurity.
We were able to immediately dismiss the first issue above as the Joomla backend was reporting 300 seconds as the value of the max_execution_time. Still, just to be 100% sure, we added a .user.ini file under the main directory of the Joomla website and then we added to that file the following line:
max_execution_time = 300
We tried the update again (just in case), and, unsurprisingly, it failed.
So that left us with the firewall theory, which made the most sense, since our IP was blocked temporarily every time we tried to update the site, which was a huge sign of a firewall’s foul play. Unfortunately, we were not able to confirm that theory because we didn’t have root access to the server, and neither did the client (and nor the client’s client, for that matter). So, we communicated our findings to the client, and asked him to route these findings to the host. The host was immediately responsive, and stated that a security module called OSSEC (which we have never heard of before) caused this issue. They then whitelisted the client’s IP and he was able to finally perform the update. Hooray!
So, our dear, dear reader, if you are seeing an AJAX Loading Error: error popup when you are trying to update your Joomla website, then check your max_execution_time value in PHP’s settings. If it’s too low, then increase it, and see if the problem is solved. If not, then clear your Joomla cache and make sure that $live_site has an empty value in the configuration.php. If that doesn’t solve the problem, then check your server for any security rules being triggered. If that also fails to solve the problem, then you can always contact us. We will fix the problem for you quickly, cleanly, and affordably!
Thanks for this useful page but it did not resolve my issue. I have 4 Joomla sites and two worked while two failed with this error. I finally discovered that pausing Cloudflare (which I use to speed up the sites) allowed the update to run.
This may assist others.
Thanks for this great contribution. But it did not solve the problem for me either. But afterwards I found out that I had installed a too new PHP version on my server. Joomla version 3.9.20 had to update to 3.9.21. My installed PHP version was the current 7.4.x version. After changing the PHP version to 7.3.17 it worked fine again.
Maybe this helps others too.
Thank you for sharing this information. I tried to upgrade Joomla from 3.9.22 to 3.9.33 and this error appears for the first time to me. The fix was to set the $live_site to an empty value in the configuration.php
My problem was slightly different then the ones you listed but your description of how you went about trying to solve the problem lead me to my solution.
As you had suggested, I opened up the Chrome console while running the upgrade and noticed that I received a 403 error when trying to run the restore.php file. As with your client’s server, my server did not have an .htaccess file. It turns out that an .htaccess file is not the only way to restrict what can be executed. The virtual server entry for my website in the httpd.conf file on openBSD was set up to be very restrictive. Only index.php files could be executed. This effectively blocked restore.php from running. The virtual server entry was changed to allow the restore.php file to run and I was then able to run the upgrade.
Thank you for this article!
On my website (upgrade 3.10.11 -> J!4.2.x), I checked everything you wrote and it still didn’t work. I had the continue my research deeper.
After quite a while, finally I found an .htaccess in a administrator/components/ that blocked the update!
Sometimes a few .htaccess lines could block an Joomla! update, also in an unusual place!