WP - Change definitions of cms.root, civicrm.root

[totten]

Overview

This is an alternative to #17353.

Before

The logic for computing path/URL defaults is in Civi/Core/Paths.php.

On WP, normal Civi pages and standalone extern scripts use the same logic for computing paths/URLs.

After

The base logic for computing path/URL defaults is in Civi/Core/Paths.php.

For Civi-WP, certain variables (which are easier to compute via WP APIs) are overridden in CRM/Utils/System/WordPress.php.

On WP, the path/URL logic for has been split:

• One codepath for normal Civi pages - based on WP APIs
• Another codepath for older, standalone extern scripts - based on the same logic as before

Technical Details

Some key differentiators vs #17353:

• Uses the existing Civi::paths()->register() interface
• Doesn't add a long list of getFooStorage() functions
• If you use any normal page or any newer extern-like end-points, then it uses the prettier callpath.
• If you have external references to the standalone extern/* scripts, and if those scripts are currently working, then they should continue working in the same way as before.
• Moves the wp.frontend, wp.backend, etc variables (which are really WP-specific) out from Civi/Core/Paths.php to CRM/Utils/System/WordPress.php.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[mattwire]

Ping @christianwach

[christianwach]

Thanks for this @totten - it looks like this is functionally identical to #17353 with the bonus that the legacy routes (which I ignored) are still accommodated 🥇

Do later declarations of Civi::paths()->register('foo') replace existing callbacks or add to them? (I assume the former but would appreciate confirmation)

[totten]

Later declarations replace earlier ones ✅

civicrm-core/Civi/Core/Paths.php

Lines 131 to 134 in 8d0e37b

	public function register($name, $factory) {
	$this->variableFactory[$name] = $factory;
	return $this;
	}

There's a small element of luck in how this patch worked out -- given that register() can replace the callback, one still has to re-register() at the right moment (i.e. after Civi\Core\Paths is instantiated but before anyone tries to read the given path/url/var). It worked out that the CRM_Utils_System_*::initialize() is demonstrably opportune:

civicrm-core/Civi/Core/Container.php

Lines 501 to 505 in 8d0e37b

	$bootServices['paths'] = new \Civi\Core\Paths();
	$class = $runtime->userFrameworkClass;
	$bootServices['userSystem'] = $userSystem = new $class();
	$userSystem->initialize();

Firing a hook in getVariable() would also be fairly opportune (at least... it works out in my mental model...), but admittedly there are caveats/risks with hooks during bootstrap, and this is a smaller patch.

[christianwach]

@totten Thanks for the clarification - it's all clear to me now. I like this approach and it would certainly be a major step forward from where we currently are. I'll close #17353 in favour of this. Happily so :-)

[mattwire]

@christianwach Have you specifically tested this PR and are you happy that it should be merged?

[kcristiano]

I'd like to see this in 5.27 if I had my way, but lost track of it.

I have done r-run locally and have tested basic functionality and it looks good. I'd like it in 5.27 so we can get a full RC cycle. Then I can test all extern points which have always been the most problematic.

@totten any thoughts on having this in 5.27 as the RC just dropped?

[seamuslee001]

Jenkins re test this please

[seamuslee001]

Test fails unrelated