3

I am having a couple of issues with a Joomla 3.6 site that I maintain.

  • Issue 1 is with the Joomla update component. When the update attempts to run it gets an Ajax alert error, and the following error in console:

    XMLHttpRequest cannot load http://www.example.com/administrator/components/com_joomlaupdate/restore.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://example.com' is therefore not allowed access.

  • The second issue is with uploading images. Whenever I try to upload an image either in the media manager, an article or module, the site acts like it's uploading the image, refreshes, but never actually uploads the image.

    I have error reporting turned on maximimum and still no errors after the routine finishes. I have to say I am completely beside myself as to what is going on.

I can only assume the two issues are related.

4 Answers 4

4

I recently encountered this XMLHttpRequest error myself. The root of the problem caused 3 different issues.

SOLUTION: In my case, the problem was caused by an incorrect setting for the public $live_site variable in the configuration.php file (which is located in the Joomla root folder). The website was https://website.com but I had set the public $live_site = 'https://www.website.com'; <- The www should not have been there.

In the end I set public $live_site = ''; but public $live_site = 'https://website.com'; would have worked as well.

Alternatively, you could probably set cors to enable cross-origin resource sharing, but this is a server side solution which in my case was unnecessary. Also if you set it incorrectly it can be a security risk.


Incorrectly setting $live_site in configuration.php caused 3 problems.

  • When logging into https://website/administrator I was not notified of new extension updates. When I logged into website.com/administrator with the console open (Ctrl + Shift + i) I could see the error -Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.website.com/administrator/index.php?option=com_installer&view=update&task=update.ajax&cbe7c724489164bc62ef5fd63d87884b=1&eid=0&skip=700. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
  • The 2nd problem occured when I tried to reinstall Joomla by going to Administrator -> Components -> Joomla!Update -> Live Update. For installation method I chose to Overwrite files. I got a message saying
    Error: AJAX loading Error:error

    "Error: AJAX loading Error:error" and then in the console I could see

    Joomla Ajax XmlHttpRequest error Update

    with the following message Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.website.com/administrator/components/com_joomlaupdate/restore.php. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

  • The third problem I wasn't aware of until I this question. When uploading images either in the media manager, in an article or in a module, the site acts like it's uploading the image, refreshes, but never actually uploads the image.

All these problems were caused by an incorrect value for the $live_site variable in configuration.php.

I eventually stumbled onto the answer thanks to a reference found in https://www.itoctopus.com/ajax-loading-error-error-when-updating-your-joomla-website

2

Update

I had the issue again today, renaming the htaccess only without disabling Admin Tools and then updating worked for me. So it seems to have to do with the rules, set in the htaccess by Admin Tools.

Initially given answer:

For the update error "Ajax Loading Error: forbidden" try:

1) Disabling Admin Tools (if installed / component + system plugin)

2) Disabling Akeeba Backup (if installed / package + component + file_akeeba)

3) Rename htaccess

I did all 3 steps together and it worked for the 3.8.3 update.

After update finished, you can redone step 1-3. If htaccess was deleted or can't be renamed back again, you can generate a new one via Admin Tools -> htaccess Maker

1
  • 1
    This is good advice. On one site with the "AJAX Loading Error: Forbidden" error, I had to bypass Sucuri as an administrator by adding an entry in my local hosts file to access the website via its direct IP address. The update then worked fine. Commented Feb 8, 2018 at 8:02
2

Typically this happens when you have an .htaccess rule (possibly originally inserted for additional security) blocking access to the restore.php file. We have written about this here.

Having said that, one has to wonder, why does Joomla need access to the restore.php file, which seems to be completely dedicated to Akeeba Backup, even when Akeeba Backup is not installed? Frankly, we haven't investigated the issue thoroughly (maybe Joomla needs a function from that file) - still, that file is an Akeeba specific file and it shouldn't be in the core.

3
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.