• Wordpress 5.3.1 (on Siteground)
  • [upgrading from CiviCRM 5.19.2 to] CiviCRM 5.20.1/2

Apart from a (quite lengthy) list of templates that might be affected by the db upgrade, this process goes as expected. But upon reloading, I lose the CiviCRM menus and get, instead, the weird mile-long mess at the bottom of the page.

I can confirm a 404 error on the crm-menubar css, and I can also see that the path to that file has changed from the previous installation. The previous path had been:


in version 5.20.2, it is:


So I've changed the $civicrm_root (in the settings file) to:


But I'm still getting the 404.

I have:

  • double checked the directory permissions (though it isn't clear why these might have changed)
  • cleaned up the caches and updated the paths
  • read about a whole lot of similar cases, here

This isn't (yet) a crisis or anything, but I do keep reverting back to the previous version, as it's a lot pleasanter to deal with (though the security warnings are working as they should, and I'd really like to get this patch).

I suspect that this is related to resource URLs, but I'm not sure what additional steps to take.

2 Answers 2


The definition of $civicrm_root was indeed the problem; in my settings.php (which had been working for a while) the path used Siteground username (as does DocumentRoot), whereas this should be replaced by the generic 'customer.'

How I got there:

It was obvious that something was wrong with the Resource URL, but I couldn't figure it out (as the comments should make clear). So I reverted to 5.19.2, made a full-site backup, and then uninstalled CiviCRM completely: plugins/civicrm, uploads/civicrm, and the db. Then ran a fresh install to autogenerate a new settings.php file, which I downloaded.

Then I restored the full-site backup & ran the CiviCRM update as normal, except that I put the newly-generated settings.php file in place before upgrading the db. This worked, fortunately, and the only difference between the settings files was the one described above.


Can you make sure the directory path defined for $civicrm_root of your site matches with DocumentRoot mentioned in your apache2/nginx conf setting. They should match with each other.

The other option is to set 'CiviCRM Resource URL' in Resource url setting to http://www.mysite.org/public_html/wp-content/plugins/civicrm/civicrm/

  • DocumentRoot: /home/user_name/www/mysite.org/public_html $civicrm_root: /home/user_name/www/mysite.org/public_html/wp-content/plugins/civicrm/civicrm/ So that looks OK, no? The resource URL setting is read-only.
    – mc_burger
    Commented Dec 14, 2019 at 6:52
  • OK, adjusted the settings.php file so that I could change the resource URL -- set it as suggested here and then updated the paths. Same result (i.e., still showing a 404 error).
    – mc_burger
    Commented Dec 14, 2019 at 8:49
  • I'm thinking it may make sense to wipe out everything in plugins & uploads, install CiviCRM as a new plugin, and then restore the db. Would this work? Or is it pointless, as I can't really imagine the resource paths getting any clearer than they are? Maybe I'm barking up the wrong tree, here. Or I revert to 5.19, with the scary security warning? A bit lost . . .
    – mc_burger
    Commented Dec 14, 2019 at 10:41
  • For comparison, the menu .css that's not found (404): Request URL:mysite.org/home/user/www/mysite.org/public_html/wp-content/… VS The rest of everything else, loading from the plugin directory: Request URL:mysite.org/wp-content/plugins/civicrm/civicrm/css/… Shouldn't these be the same paths, up to /plugins or /uploads?
    – mc_burger
    Commented Dec 14, 2019 at 10:52

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.