CRM-17633 WIP Changes to support WP in it's own directory …

[kcristiano]

… Replaced #103

[kcristiano]

dependency- civicrm/civicrm-core#9106

[christianwach]

@kcristiano Thanks for working on this. I have a couple of queries:

• I see that the CRM_Utils_System_WordPress::getBaseUrl() and CiviCRM_For_WordPress::get_base_url() methods are now identical. Would it not be simpler to change the method access for CRM_Utils_System_WordPress::getBaseUrl() to public and then we could dispense with get_base_url() entirely?
• Is there a reason for using a hard-coded directory name? There are a number of ways of changing from 'wp-admin' to something else: e.g. this plugin and this technique.
• Finally, is there any assumption about whether or not WordPress is bootstrapped when either CRM_Utils_System_WordPress::getBaseUrl() or CiviCRM_For_WordPress::get_base_url() is called? If WordPress is always bootstrapped, then wouldn't it make more sense to use native WordPress functions to discover the URL?

Cheers, Christian

[kcristiano]

@christianwach Thanks for the feedback.

• it's possible we could change the method - I am trying to keep compatibility with other code. Backwards compatibility and all :)
• I am using 'wp-admin' hardcoded as my attempts to get it to return via the admin_url failed due to issues with the bootstrap process.

I worked yesterday on all edge cases - changing uploads folder, changing plugins folder and did not even attempt to change wp-admin. I think we need to draw a line and decide what we can support. The possible permutations are causing issues - mostly from 'extern' calls and when the CMS is not boostrapped.

• Lastly we are assuming WP is not bootstrapped - hence why I want the values defined in the civicrm.settings.php file. Tim's civicrm.config.php can find the settings file and we need those paths for the bootsrap process.

Perhaps I am getting 'testing blind' over this - so if you see a way to improve that would be great.

[christianwach]

we are assuming WP is not bootstrapped

@kcristiano thanks for clarifying. If that's the case, then my only request would be for more documentation - I'm unclear where the various constants are set (or could be set) so it would be really helpful to leave some breadcrumbs for developers in the respective method docblocks.

Cheers, Christian

[kcristiano]

@christianwach added a docblock - I also updated https://wiki.civicrm.org/confluence/display/CRM/WordPress+installed+in+its+own+directory+issues with all the testing I have done.

The next step is fixing the installer to handle this and more testing. We will need to update README.md and readme.txt to cover these changes.

[alifrumin]

I tested this and it worked for me!

[kcristiano]

jenkins test this please

[kcristiano]

civicrm/civicrm-core#10214 is dependent on this PR

[kcristiano]

@totten tested and merged your improvements. Works fine. Would like this in early in an RC cycle to get more eyes/hands on the rela world testing.

[kcristiano]

civicrm/civicrm-core#11031 is now the matching PR in civicrm-core

[alifrumin]

I tested this pr and civicrm/civicrm-core#11031 on a wordpress install with wordpress in the root site directory and with wordpress in its own directory and did not get any issues regarding directories or resource urls.

[eileenmcnaughton]

Merging per related PR #11031