Better caching plugin integration

[swalkinshaw]

We've struggled with a good way of using WP caching plugins in the past with Bedrock due to limitations with WP itself and how the plugins worked.

These plugins rely on "drop-ins" which are counter to Bedrock's goals because they conflict with proper version control.

The good news is that as of WordPress 5.1, object caches can be properly conditionally loaded. Before these plugins instructed people to manually copy object-cache.php into the WP content dir (/app in Bedrock) or they'd try and use the WP filesystem API to do it themselves. Or you needed really ugly hacks.

Solution

With this fixed in 5.1, Bedrock could include a standard app/object-cache.php file which would act as a loader only. Depending on some configuration value(s), it would require a file in a plugin. If not, the default WP object cache behaviour would happen as usual because awp_cache_init function wasn't defined.

Ignoring the hacks that were previously necessary, even the past solutions had hardcoded assumptions about class names or globals. Example: https://gist.github.com/bjornjohansen/eefbe3bfa4f5f0270a3e#file-object-cache-php-L11-L28

Ideally we just rely on Bedrock's configuration model to handle this properly. I'm not exactly sure the best way to do this yet since we'd need to require an actual filepath within a plugin. Most of these plugins have the standard <plugin_name>/object-cache.php but we may not be able to rely on that.

The simplest solution is:

Config::define('OBJECT_CACHE_PLUGIN_FILEPATH', 'plugin-name/src/object-cache.php');

If OBJECT_CACHE_PLUGIN_FILEPATH is defined, then the loaded requires it. If not, nothing happens as usual.

Composer metadata

It would be nice if object cache plugins could set this via metadata in their Composer package and then Bedrock could use it. But I'm not sure how realistic it is to get these developers to add that (or how it would actually work yet).

Feedback on this is welcome 😄

cc @austinpray @QWp6t

[CJohnson25]

I believe I have a solution to this issue, or at least a similar one.

I was having a problem with Some plugins loading resources on a multi-site using wp-super-cache.

underneath the hood. wp-super-cache was using the WP_CONTENT_URL, to load cached assets through the whatever that constant resolved to. In config/application.php WP_CONTENT_URL is set based off of the WP_HOME variable by default. This results in an improper URL. I used the following snippet to resolve this issue:

#Config::define('WP_CONTENT_URL', Config::get('WP_HOME') . Config::get('CONTENT_DIR'));

$request_url = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on' ? "https" : "http") . "://$_SERVER[HTTP_HOST]";
$trimmed_request_url = rtrim($request_url, "/");
if (strcmp($trimmed_request_url, Config::get('WP_HOME')) !== 0) {
        Config::define('WP_CONTENT_URL', $trimmed_request_url . Config::get('CONTENT_DIR'));
} else {
        Config::define('WP_CONTENT_URL', Config::get('WP_HOME') . Config::get('CONTENT_DIR'));
}

There may be a more elegant way of doing this, but it works for us.