Missing filter to customize content URL for the DeliverAnonymousAsset class

Hey @mcaskill !

Thanks for your message.

Unfortunately, we have not added a filter for the resulting URL as the folder needs to be checked if writable with wp_is_writable, this cannot be done with a URL.

How does your added filter look like and what’s the cause for the 302 redirection?

[…] we have not added a filter for the resulting URL as the folder needs to be checked if writable with wp_is_writable, this cannot be done with a URL.

But you wouldn’t use getContentUrl() to check if the path is writable, you would use getContentDir().

This is the hook I used to test the feature:

add_filter( 'DevOwl/DeliverAnonymousAsset/ContentDir', fn ( $content_dir ) => wp_upload_dir()['basedir
'] );

This filter works as expected, the anonymized assets are stored in the desired location (in this case, in the uploads directory).

Hi again @mcaskill !

I have tested the following filter:

add_filter( 'DevOwl/DeliverAnonymousAsset/ContentDir', function ( $content_dir )  {
    $folder = trailingslashit(wp_upload_dir()['basedir']);
    return $folder;
});

And it works as expected:

Looking at the left screenshot, the URL is still pointing to /wp-content/XYZ.js.

I forgot to mention that when one changes the content directory path, the previous path will still contains the initial anonymized assets. They are not automatically deleted. If you force new hash file names, you’ll see these JS resource requests fail since the new content directory will be the one with the newly named files.

Hey @mcaskill !

Looking at the left screenshot, the URL is still pointing to /wp-content/XYZ.js.

Attached, you will find a pre-release of the plugin. This solves the problem you mentioned. You can simply upload this version to your WordPress and replace it with the current version (Plugins > Add new > Upload Plugin; Screenshot). When the next version of the plugin incl. the pre-released feature is available for all users, you will see it as a normal update in your WordPress.

Download pre-release: https://storage-dev-1.owlsrv.de/prereleases/72408341-1b94-422d-b85e-0022eb40b2a8/real-cookie-banner-3.7.3-5484-plugin.zip

They are not automatically deleted

I have added this as a bug to our backlog, but unfortunately can’t promise you a date when we will be able to implement this.

The changes in the pre-release introduce a couple of issues.

In the getContentDir() method, the added wp_mkdir_p() function returns either true or false whereas the method expects either a string (the path) or false. If that mkdir function returns true (which will be the case upon the first attempt), it will break file paths on that first request:

  $folder = \apply_filters('DevOwl/DeliverAnonymousAsset/ContentDir', $folder);
  if (!\wp_is_writable($folder)) {
-     return \false;
+     return \wp_mkdir_p($folder);
  }
  return $folder;

In generateSrc() method, using ABSPATH assumes the Web site is installed in a classic WordPress fashion (where WordPress is the document root). This won’t work with any modern structure like Bedrock that puts WordPress in an adjacent subdirectory of the document root:

+ if (\has_filter('DevOwl/DeliverAnonymousAsset/ContentDir')) {
+     // This is more expensive (https://wordpress.stackexchange.com/a/264870/83335), so check if a filter is given
+     return \str_replace(\wp_normalize_path(\untrailingslashit(ABSPATH)), \site_url(), \wp_normalize_path($contentPath));
+ }
  return self::getContentUrl() . \basename($contentPath);

Unfortunately, there’s no reasonable way to resolve the document root in relation to the filtered content directory.

If adding a ContentUrl filter to pair with ContentDir is not an option, the ContentDir filter could be changed to be a path relative to WP_CONTENT_DIR:

/**
 * Get the content directory where anonymous assets should be placed.
 *
 * If you change the directory, the old assets are not deleted automatically as this could break
 * the cache of caching plugins like WP Rocket.
 *
 * @hook DevOwl/DeliverAnonymousAsset/ContentDir
 * @param {string} $folder
 * @return {string}
 */
$folder = \wp_normalize_path(\constant('WP_CONTENT_DIR') . '/' . \apply_filters('DevOwl/DeliverAnonymousAsset/ContentDir', ''));
if (!\wp_is_writable($folder) && !\wp_mkdir_p($folder)) {
    return false;
}
return \trailingslashit($folder);

Hey @mcaskill !

Sorry for this. I have now decided that the filter must always return a folder within the defined WP_CONTENT_DIR, so we can map this path accordingly to a URL.

Attached, you will find a pre-release of the plugin. This solves the problem you mentioned. You can simply upload this version to your WordPress and replace it with the current version (Plugins > Add new > Upload Plugin; Screenshot). When the next version of the plugin incl. the pre-released feature is available for all users, you will see it as a normal update in your WordPress.

Download pre-release:?https://storage-dev-1.owlsrv.de/prereleases/3e76cd76-4335-4b4d-baca-3cdd6ed97388/real-cookie-banner-3.7.3-5492-plugin.zip

Can you please check if this works for you?

The latest pre-release (v3.7.3-5492) looks good on my end.

Thank you for the fix.