Set CMS Root in "civicrm_paths" more reliably

[christianwach]

Overview

Builds on https://lab.civicrm.org/dev/core/issues/1412 to set $civicrm_paths['cms.root']['path'] more reliably during the following requests:

• WP-CLI
• "Heartbeat" AJAX
• WordPress pseudo-cron

Before

CRM_Utils_System_WordPress::cmsRootPath() would be called without $civicrm_paths['cms.root']['path'] being set for the above requests, causing the unreliable directory-traversal code to be run.

After

CRM_Utils_System_WordPress::cmsRootPath() runs with $civicrm_paths['cms.root']['path'] being correctly set.

[kcristiano]

• (r-explain)Pass
• (r-test) Pass
• (r-code) Pass
• (r-doc) Pass
• (r-maint) Pass
• (r-run) Pass:

• Standard installl with PR Applied.
  • pass on mailings, searches, contrib pages, wp-cli, and cv
• WP in it's own directory
  • pass on mailings, searches, contrib pages, wp-cli, and cv
• WP in it's own directory and wp-content moved
  • pass on mailings, searches, contrib pages, wp-cli, and cv

• (r-user) Pass
• (r-tech) Pass

This looks good to merge.

@seamuslee001 any further thoughts?

[kcristiano]

As far as testing:

• "Heartbeat" AJAX
• WordPress pseudo-cron

@christianwach Are there any specific tests that you can think of?

wp cron is running properly in my test scenarios, heartbeat is not tossing errors. Is there an example where CiviCRM uses admin-ajax? I don't see it, am I missing the obvious?

[christianwach]

As far as testing:

• "Heartbeat" AJAX
• WordPress pseudo-cron

@christianwach Are there any specific tests that you can think of?

"Heartbeat" AJAX

I can't think of anything specific right now, but that's not to say that other plugins might not hook into Heartbeat operations - for example doing something when a draft post (or post revision) is saved. Given we have been thinking about CiviCRM Entities syncing with WordPress CPTs, this might prove an important fix in future.

WordPress pseudo-cron

Again, struggling to think of anything that's guaranteed to be affected. One of the options in CiviCRM WP Member Sync allows it to hook into WordPress pseudo-cron and trigger processes that rely on proper CiviCRM configuration. That it works as it stands would seem to be fortuitous rather than by design.

I think the test is simply that $civicrm_paths['cms.root']['path'] is correctly set when triggered via these routes. I have confirmed that it is. Throw some error logging in at the very top of CRM_Utils_System_WordPress::cmsRootPath() if you want to confirm this:

    $e = new Exception;
    $trace = $e->getTraceAsString();
    error_log( print_r( array(
      'method' => __METHOD__,
      'civicrm_paths' => $civicrm_paths,
      'backtrace' => $trace,
    ), true ) );

The backtrace will show you the origin of the request and as long as $civicrm_paths is populated, then all's well.

[kcristiano]

Thanks @christianwach Based on the testing, I'll merge