2.3.4

• Fixed an issue where assets such as CSS and JavaScript were mapped on login/register pages, even if the URL is on the admin domain. This was found in the forthcoming 3.0.0 release.
• PHP 8.1 compatibility fixes and tweaks. Dark Matter now supports versions 7.0 to 8.1, in line with WordPress Core.
• Plugin development changes:
  • Added GitHub Dependency Review action, which runs on every pull request. More information can be found on GitHub here.
  • Temporarily disabled the Snyk check due to a peculiar error.
• Composer and NPM dependencies updated.
• Tested upto WordPress 6.1

Full Changelog: 2.3.3...2.3.4

2.3.3

• Updated the dependencies for Composer and Node.
• Added version bump dependency to aid in future releases of Dark Matter.
• Tested upto WordPress 6.0.3

2.3.2

• Fixed an uncaught issue with the way the cached domain is cast into an object.

Full Changelog: 2.3.1...2.3.2

2.3.1

• Fixed a major performance issue introduced in 2.3.0 for excessive database calls for primary domains. (#99)
  • This was caused by a malformed cache set for primary domains, after it was moved to resolve an issue previously where it would update only the database when a new primary domain was set.
  • Also removed an old call to set a primary domain, which is no longer needed and was causing irrelevant UPDATE SQL queries (it was essentially update the values to exactly what they were already).
• Moved the primary domain cache set when retrieving a domain to slightly later in the process.
• Atypical installations should not need to flush the cache. However, you may need to use WP CLI wp cache flush - or equivalent - after upgrading.

Full Changelog: 2.3.0...2.3.1

2.3.0

• Added switch_to_blog() support for Media Domains. (#97)
  • When using the various attachment functions within the switch_to_blog() context, it will now respect media domain settings on a per site basis.
  • Setting media domains through the DM_NETWORK_MEDIA constant now works more fully.
  • It is now possible to controlled media domains through the network_media property on DarkMatter_Domains, to enable more sophisticated logic in code.
• Tweaked the way mapped domains are detected to better support scenarios involving switch_to_blog(). (#96)
  • No longer relies solely on the DOMAIN_MAPPING constant, set when a request is processed through a primary domain.
  • Essentially, if the website handling the request is being viewed through its primary domain, then URLs within a switch_to_blog() context will be mapped if applicable (i.e. the blog switched to has an active primary domain).
  • And vice-versa - if a request is through the admin domain ("unmapped"), then URLs in the switch_to_blog() context will be unmapped as well (to prevent cross-domain compatibility issues / warnings in browsers).
• Fixed an issue where setting and unsetting the Primary Domain would update the database only, and not the cache. (#94)
  • DarkMatter_Domains now handles the cache state for both primary and general domain caches.
  • Also removes some duplicate database update logic.
  • The third parameter of action hooks darkmatter_primary_set and darkmatter_primary_unset is now deprecated. It is always true as the database is always updated now, therefore it is redundant.
• Domains are now ordered alphabetically - A to Z - when returned by get_domains_by_type(). (#95)
• Fixed a typo preventing the cache retrieval for Restricted Domains working properly. (#89)
• Fixed a malformed header for the 2.2.3 release in readme.txt file.
• First iteration of unit tests added to the project to improve quality assurance of this release and future releases. (#88)
  • Uses PHP Unit and based on the setup provided by the WP CLI scaffold.
  • Issues / fixes in this release were found by the new unit tests.
  • Unit tests are not included with the release version of the plugin, and are accessible via Github repository: https://github.com/cameronterry/dark-matter/
• Updated NPM dependencies to their latest versions.
• Tested with WordPress 6.0 RC1.
• We have incorporated Snyk scanning for dependencies in Composer and NPM. (#76)

Full Changelog: 2.2.3...2.3.0

2.2.3

• Updated Composer and NPM dependencies.
  • No change in any logic code.
  • Some lint fixes in JavaScript and PHP files.
  • Switched eslint-loader for eslint-webpack-plugin.
• PHP CodeSniffer set to test PHP 8.0 to ensure compatibility and support going forward.
• Tested up to WordPress 5.9.3.

Full Changelog: 2.2.2...2.2.3

2.2.2

• Updated Composer and NPM dependencies. No code changes made to CSS and JS files. (Security scans can be found on: #83)
• Tested with WordPress 5.9 "Joséphine".
• Checked for basic compatibility with Rank Math 1.0.81 and Yoast SEO 18.

Full Changelog: 2.2.1...2.2.2

2.2.1

• Fixes an issue caused by a discrepancy between eslint setup.
• This caused the build script to fail and was missed in 2.2.0, meaning the UI broke at the final deploy stage.
• Apologies for the inconvenience.

2.2.0

• New Features:
  • Say hello to "Media domains"; a new type of domain to Dark Matter that can be used to serve media assets from a different domain name.
    • Useful for separating infrastructure which is used for static assets from servers powering PHP requests.
    • Or powering images through a dedicated / dynamic service such as Tachyon.
    • Can be hard-set using an array of domains in a constant called, DM_NETWORK_MEDIA.
    • Supports all extensions that are supported by the Media Library. So if you add SVG upload support, "Media domains" will support it too.
    • Updating the existing CLIs to support domain types and management of "Media domains".
  • WordPress' plugin screen will now notify you of future releases and to update.
    • Added support for WordPress auto-update functionality.
    • Releases after 2.2.0, you will be able to update Dark Matter through WP CLI or admin interface (depending on your setup / file permissions).
    • Servers are renewable powered!
• Bug fixes and maintenance:
  • Updated the readme.md file to include CLI examples for Media Domains.
  • Updated the readme.md file to include notes on two constants that can be used with Dark Matter for disabling SSO and configuring Media Domains for an entire Multisite.
  • Improved the domain validation when adding new domains.
  • Added plugin header comment block to the sunrise.php dropin.
    • There is no code and / or logic changes, however you will need to run wp darkmatter dropin update --force.
    • This will provide better information on WordPress plugins screen, clearly identifying Dark Matter's sunrise dropin from others.
    • This also improves diagnostic data for other plugins, such as Redis Cache / wp redis status.
  • Tweaked the release shell script to better support wp-update-server.
  • Updated composer dependencies and support for Composer 2.2.x version.
  • Updated npm dependencies, excluding eslint.

Media Domains

Dark Matter 2.2.0 introduces the concept of "Media Domains" which means that a WordPress Multisite can be configured to change media library files to be on a different domain. Please note: this will not upload your files to a separate service, just altered the URLs when referenced by WordPress.

In effect, this will take media library files that were previously served over the admin domain or the primary domain to be served by a separate, specified, domain. For example: if the admin domain is admin.example.com and the primary domain of one of the sites on the Multisite is mypersonalsite.blog, the Media library files will be a mixture of the following:

https://admin.example.com/mypersonalsite/wp-content/uploads/sites/2/2022/01/executium-2YIwvJx8IWs-unsplash-scaled.jpg
https://mypersonalsite.blog/wp-content/uploads/sites/2/2022/01/pexels-yovan-verma-2082103-scaled.jpg

If a media domain is configured as example.mycdn.com, then those links will change to the following (note the admin domain version has replaced both the domain and the site slug, /mypersonalsite/, as well):

https://example.mycdn.com/wp-content/uploads/sites/2/2022/01/executium-2YIwvJx8IWs-unsplash-scaled.jpg
https://example.mycdn.com/wp-content/uploads/sites/2/2022/01/pexels-yovan-verma-2082103-scaled.jpg

The benefits of serving your media library assets on a separate domain include, but are not limited to, the following:

• Increase the number of simultaneous connections. For example: Firefox, by default, will limit to 6 connections.
• Separate domains can be used to either split up bandwidth expenditure as well as reducing it, by removing cookies used by the primary domain - such as the WordPress login cookies, etc.. For example: if you are using a reverse proxy technology that charges by bandwidth, then it may be desirable to separate website requests from media requests by domains to reduce cost.
• Take advantage of image serving technologies, such as Tachyon or dynamic image processing techniques with technology such as OpenResty.

To configure Media Domains, you can use the CLI or a constant in your wp-config.php, depending on whether you want to have unique media domains for individual sites or one set of media domains for all sites on the WordPress Multisite.

CLI Examples

Set a media domain for a site.

wp --url="sites.my.com/sitefifteen" darkmatter domain add example.mycdn.com --type=media

Convert a secondary domain into a media domain. Useful for when repurposing an old domain for use a CDN for media assets.

wp --url="sites.my.com/siteone" darkmatter domain set example.mycdn.com --type=media

Convert a Media domain to a main domain. This is useful in scenarios when a media domain is redundant and to ensure it redirects to the website.

wp --url="sites.my.com/siteone" darkmatter domain set secondarydomain.com --type=main --secondary

DM_NETWORK_MEDIA

Alternatively, media domains can be set by adding the DM_NETWORK_MEDIA constant to the wp-config.php file. This will override any configured media domains and force all websites within your WordPress Multisite to use the specified media domains instead.

/* That's all, stop editing! Happy publishing. */
define( 'DM_NETWORK_MEDIA', [
    'example.mycdn.com',
    /** Add additional domains here if desired. */
] );

Setup Example

Using the example noted previously, NGINX can be configured in the following manner to server images on example.mycdn.com domain for media library files. This example assumes the media library assets are hosted with a service such as Amazon Web Services S3 storage or Linode Object Storage using a plugin such as S3 Uploads plugin.

A site can be configured on NGINX to respond and server assets from the storage bucket. This can be setup on on a load balancer or entirely separate server.

server {
    server_name example.mycdn.com;
    root /srv/example.mycdn.com;
    index index.html;
    error_page 404 /index.html;

    # Other settings and custom configuration such as SSL certs.

    location ~ /?.*/wp-content(?<img>/uploads/.*) {
        expires 1d;

        log_not_found off;
        access_log off;

        resolver 8.8.8.8;

        proxy_http_version 1.1;
        proxy_cache s3bucket;

        proxy_set_header Host s3bucketurlhere.com;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass https://s3bucketurlhere.com;
    }
}

Side Note: it is worth stating that another option, if you are using Amazon Web Services especially, is to use Dark Matter to change the URLs to one hosted by Cloudfront rather than rolling out an NGINX server. Likewise for DigitalOcean's Spaces Object Storage.

If Media Library files are stored on an NFS or with software such as GlusterFS, a similar setup can be deployed by mounting the shared disk onto a server running NGINX and responding to the example.mycdn.com domain (in this example).

2.1.9

• Fixed an issue with Webpack that prevents the admin UI working when SCRIPT_DEBUG is used.
• Unlikely to experience issue except for staging and local developments.
• Problem spotted during development of the 2.2.0 release.