Ошибка при обновлении joomla ajax loading error

Информация о материале

Опубликовано: 11 сентября 2019

Просмотров: 4772

Okay, tried that and it didn’t work — but now every time I try to bring up my website it tries to bring up a document that says:

<?php
/**
* @package Joomla.Site
*
* @copyright Copyright (C) 2005 — 2016 Open Source Matters, Inc. All rights reserved.
* @license GNU General Public License version 2 or later; see LICENSE.txt
*/

/**
* Define the application’s minimum supported PHP version as a constant so it can be referenced within the application.
*/
define(‘JOOMLA_MINIMUM_PHP’, ‘5.3.10’);

if (version_compare(PHP_VERSION, JOOMLA_MINIMUM_PHP, ‘<‘))
{
die(‘Your host needs to use PHP ‘ . JOOMLA_MINIMUM_PHP . ‘ or higher to run this version of Joomla!’);
}

// Saves the start time and memory usage.
$startTime = microtime(1);
$startMem = memory_get_usage();

/**
* Constant that is checked in included files to prevent direct access.
* define() is used in the installation folder rather than «const» to not error for PHP 5.2 and lower
*/
define(‘_JEXEC’, 1);

if (file_exists(__DIR__ . ‘/defines.php’))
{
include_once __DIR__ . ‘/defines.php’;
}

if (!defined(‘_JDEFINES’))
{
define(‘JPATH_BASE’, __DIR__);
require_once JPATH_BASE . ‘/includes/defines.php’;
}

require_once JPATH_BASE . ‘/includes/framework.php’;

// Set profiler start time and memory usage and mark afterLoad in the profiler.
JDEBUG ? JProfiler::getInstance(‘Application’)->setStart($startTime, $startMem)->mark(‘afterLoad’) : null;

// Instantiate the application.
$app = JFactory::getApplication(‘site’);

// Execute the application.
$app->execute();

unless I put index.php at the end of the website — so now I have two problems — I can’t update and can’t pull up the website either.

Help!

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!

The above answers pretty much cover what’s going on, but I hope I have something to add.

When you click the ‘Install the Update’ button in the Joomla Update component, the browser requests a URL based on the configuration variable JConfig::live_site, eg https://www.sitea.com. However, if you have a 301 redirect in your htaccess, you will be load the update page, but from the URL specified in the rewrite, eg https://www.siteb.com.

The update page makes an AJAX request to get components/com_joomlaupdate/restore.php, but it also uses JConfig::live_site as the base of this request, which in this example would be to https://www.sitea.com.

This means you have the update page loading from www.siteb.com, trying to make an AJAX request to www.sitea.com. Most browsers will block this request because of Cross Origin Resource Sharing rules.

The above will even come into play if the update page is non-www and the AJAX is trying to load from a www version of the same domain.

One way to spot whether this is a problem is to look at the URL in the browser when you get onto the page which pops the JavaScript Alert error. If this URL doesn’t match what you have in your configuration.php’s live_site variable, then you need to either modify the htaccess rewrite or modify the live_site URL.