Aller directement à la fin des métadonnées
Aller au début des métadonnées

One of the issues we need or at least should tackle before resubmitting CiviCRM 4.7.x to the WP plugin repo is address the issue of WordPress in it's own directory.   While this is not the standard or common way of installing, it is used.  It is more common for Agency installed or Enterprise sites than stand alone smaller organizations.  

Currently CiviCRM does not handle this well.  WordPress ends up with two urls - one for the home page and one fro the admin.   So is the public facing web site, and is the path to wp-admin, the content directory and CiviCRM.

The settings appear in the admin as follows:

Then when we install CiviCRM we get the Green Light:

And the directories are set as follows:

In civicrm.settings.php we get the following:

The CMS settings are now set to have the basepage set to:



First issue is when we try and add a CiviCRM component via the shortcode button. 


If we try and use a CiviCRM link such as  WP sends us to  This results in a 404 error.


If we go and make the base page 'civicrm' a child page (using a parent named 'wp') then this link becomes valid and works. 

However, the shortcode button is still broken.


Testing and Planed fixes:

  1. In the file: civicrm/CRM/Utils/System/WordPress.php replace the function private function getBaseUrl($absolute, $frontend, $forceBackend) with the following:

With this change, the backend and full CiviCRM links on the front end work fine.  Needs more testing on standard installs and subdirectory installs. 

Corresponing updates to civicrm.settings.php can be made to set the above constants:



The shortcode button is still an issue.  

2. In the file
civicrm\includes\civicrm.shortcodes.modal.php replace existing function add_form_button() with the following:

 Modal had been called with a hardcoded link to wp-admin, so the modal could not display,


Update June 8 2016:

Created the following PRs:

These PRs are the foundation to support WP In it's own Directory.


Update Installer with settings to support




If wp-config.php has defined an alternate WP Content directory :

Test to see if the option 'home' matches the option 'siteurl'

If WP is in it's own directory these will not match


If either condition exists, then enable the below override



Jefferson Sprint Sept 27 2016

Tested 4.7.12-rc against following WP alternate configurations:

A) WordPress wp-content directory moved

Result – Success

B) WP plugins folder moved

Result - Success

C) WordPress wp-content  and uploads directories moved:


Result - Success

D) WordPress in it's own directory and moving wp-content, plugins and uploads directories


Result - Failure on install - Uploads directory cannot be moved along with WP in it's own directory.  Or at least I have failed at this test.

E) WordPress in it's own directory and moving wp-content, plugins  directories

Update civicrm.settings.php with the following code block, replacing installer's CIVICRM_UF_BASEURL section

Then add the following:

This is because the [civicrm.root] variable returns -  instead of

After above changes:  Result - Success



Next Steps


Update installer - test for site_url() home_url() and admin_url() and set as below - look at getCiviSourceStorage in \Civi\Core\Paths  – determine if this can be corrected for alternate wp-content plus WP in subdirectory.  If not set at install:


Update from Edale Sprint 2016:


 Diff Link

23 April 2017:

PR:  and PR: implements the above.   Currently adds the civicrm.settings.extra.php file for WP only and  adds the minimum number of defines to get all common install scenarios automated.

17 October 2017

Changes Merged Release scheduled 4.7.27

19 October 2017

Further testing due to CRM-21297 has uncovered that if wp is in its own directory AND the content directory has been moved there is an issue with ckeditor.  uses "[civicrm.root]" and does not find the new settings via civicrm.settings.php. uses "[civicrm.files]" and this also does not find the overridden settings.

  • Aucun
  1. Feb 02, 2016

    The tests I've done confirm what is outlined above in the issues. It's basically front-end display of CiviCRM data is inaccessible without the 'hack'

  2. Feb 02, 2016

    Further, even with the hack the shortcode button will not work

  3. Feb 02, 2016

    Tim Otten dit :

    Pseudocode discussed a bit with Kevin for providing a separate define() for the admin URL:

  4. Feb 03, 2016

    I've tested this and can confirm the problem.

    My first thought is that this is related to the problem of CiviCRM being active on WordPress Multisite configured with subfolders, where CiviCRM is enabled on a site that is not the main site. A similar situation occurs with this set-up such that the `baseurl` is different to the filepath. For example, a site that is not the main site may have the URL and its admin would be at The filepaths will not contain the 'subsite' string however, which leads to CiviCRM's interface being rendered non-functional.

    Perhaps we can work towards a fix that can accommodate both of these cases? A starting point would be to remove the reliance on CIVICRM_UF_BASEURL and split it into CIVICRM_UF_SITEURL and CIVICRM_UF_ADMINURL or something to that effect - although I expect this will have plenty of consequences throughout the CiviCRM codebase.

    FWIW, I also tested a non-multisite WordPress where the 'wp-content' directory has been moved and all appears to be well. Next steps for me are to look at individually moved 'plugins', 'themes' and 'uploads' folders. And then repeat the process with Multisite.

  5. Feb 03, 2016

    Heh, well, that'll teach me to refresh the page before posting a comment.

    So, I agree with the gist of the pseudocode, but would like to see it extended to accommodate the multisite pattern in my previous comment. It might require the addition of another constant. But seeing as this process is underway, it seems like an opportune moment to consider this common Multisite configuration as well.

  6. Feb 03, 2016

    I'd suggest the following for generating the shortcode URL - just because it removes reliance on the constant completely:

    $url = admin_url( 'admin.php?page=CiviCRM&q=civicrm/shortcode&reset=1' );
  7. Feb 03, 2016

    Agreed and changed.

  8. Feb 04, 2016

    One more thing to consider: WordPress doesn't really have a concept of relative URLs: see this thread from 7 years ago and this recent one for the reasoning (as stated by one of the core devs) behind this. We may or may not agree, but that's the way it's been since the outset. So, given that there will never be a situation in WordPress where we'd request a relative URL, then it occurs to me that CIVICRM_UF_ADMINURL will always be admin_url() and CIVICRM_UF_WP_BASEURL will always be either home_url() or site_url() depending on whether we're after the "Site Address (URL)" or the "WordPress Address (URL)" settings respectively. Likewise, the 'basepage' URL will always be more reliably retrieved via get_permalink() function.

    Given that CRM_Utils_System_WordPress::url() bootstraps WordPress when 'get_option' is unavailable, I'm left wondering why we need these constants at all.

    So, my question is: are we just over-complicating things? Instead of replicating all the complexity of possible WordPress configurations, why don't we simply use the WordPress functions? Are there any situations where we need these URLs when WordPress is not bootstrapped? And if so, why not bootstrap WordPress at that point?

    Edit: adding link to good discussion of the difference between site_url() and home_url().

    1. Feb 09, 2016

      I want to use the WP functions.  I do think that they should be used wherever possible.   I think the only reason not to is when WP is not booted, but as we've mentioned we have a setting to find that path.  I agree we should use the WP functions wherever possible.  

  9. Mar 21, 2016

    I'm working with a Wordpress site installed in a subdirectory and CiviCRM 4.7.1 I've applied the changes as per patch #1 (private function getBaseUrl) and #2 (add_form_button()) but I had a hard time testing it because the site got stuck in re-authentication mode - every page was requesting a login, adding reauth=1 to every URL. Cleaning cache, cookies etc. didn't help. Not sure if this is related to the changes, just wanted to mention it in case.

    As to the testing results, the shortcodes are working now.

  10. Mar 21, 2016

    Kasia Wakarecy  I would look at 4.7.4 as there were further updates in it  that could help.  Also, the Contstants referred to  above can be set in civicrm.settings.php

    Lastly, test ant extern/ functions as these do not boot the CMS and can be especially problematic.  Let us know what you find aswe can start submitting PRs as this gets tested. 

  11. Mar 21, 2016

    Kasia Wakarecy This error " I had a hard time testing it because the site got stuck in re-authentication mode - every page was requesting a login, adding reauth=1 to every URL"  is typically due to the CIVICRM_UF_BASEURL not matching the siteurl that WP has in it's option table.   On my test install I have this:

  12. Mar 22, 2016

    I'm happy to report that after the following steps, the supplied patches resolved issue with both the CiviCRM links to contributions/events etc. live pages as well as the shortcodes button.

    The tests were performed on CiviCRM 4.7.4 with Wordpress 4.4.2.

    To address a separate issue with being requested to constantly relogin to the site after applying the patches, I modified, as per Kevin's suggestion, the civicrm.settings.php file (from wp-content/uploads/civicrm). I'm repeating the code here again, because there was was a typo (in ADMINURL):

    if (!defined('CIVICRM_UF_WP_BASEURL')) {
      define( 'CIVICRM_UF_WP_BASEURL'      , '');
    if (!defined('CIVICRM_UF_BASEURL')) {
      define( 'CIVICRM_UF_BASEURL'      , '');
    if (!defined('CIVICRM_UF_ADMINURL')) {
      define( 'CIVICRM_UF_ADMINURL' , '' );
  13. Mar 22, 2016

    Good catch on the typo.  I have this working on a local install and one of our test sites.  Truly appreciate the feedback.  Will start preparing the PRs for this.   I will separate them into small chunks so we can get better testing coverage.  testing on WP is very lite.  I'll start with the shortcode modal as that is arguably hard coded right now.  

  14. May 19, 2016

    Kevin and all - I would be interested in porting and testing on 4.6 LTS once all is done on 4.7. Please keep me updated on your progress.

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.