Compatibility

Requirements #

PHP 7.4 is the floor because users on shared hosting are the whole audience. No match, no named arguments, no constructor promotion, no nullsafe operator — the plugin is written to run where people actually run WordPress.

Page builders #

The folder tree appears in the media modal of twenty builders. There is nothing to switch on: the plugin recognises a builder when its editor loads and adds the tree there, and does nothing on a builder you do not use.

Verified in a browser #

Elementor · WPBakery · Beaver Builder · Brizy · Zion · Divi 5

Wired to the builder's documented hook, best effort #

Divi 4 · Bricks · Oxygen · Breakdance · Avada / Fusion Builder · Thrive Architect · Cornerstone (Pro / X) · YooTheme · BeTheme / BeBuilder · Themify · Tailor · Oshine · LearnPress front-end editor · Dokan vendor dashboard

Those fourteen use each builder's own published hook and are expected to work, but they have not been clicked through in a browser. That distinction is published here and in the plugin's readme rather than glossed over — if one of them does not work for you, it is worth a bug report and it will be fixed.

Plugins tested #

Each was activated alone, tested against nineteen assertions, and deactivated; then fourteen of them were activated together, which is the configuration real sites are in.

All nineteen checks pass with fourteen of them active together. Divi Builder, WPML and WP Rocket together with this plugin also pass all nineteen.

What the nineteen checks are #

• The media grid toolbar renders, with its filters, on two rows and with no duplicate element ids
• Core's filters-heading screen-reader element survives
• Attachments load through the real query-attachments endpoint
• Search by taxonomy term, by title, and a nonsense term returning nothing
• List view, the bulk term picker, the bulk action, the taxonomy column
• All three settings screens
• The media modal inside the editor
• No JavaScript error attributed to this plugin's files
• No PHP notice, warning or fatal naming this plugin in debug.log

JavaScript errors are attributed by source URL. A companion plugin shouting about its own missing API key is not this plugin's failure, and lumping the two together would either hide a real conflict or invent one.

Errors observed from companions, not from this plugin #

Present with this plugin switched off, so not ours: NextGEN's photocrati_ajax is not defined on non-NextGEN admin screens, Yoast's React defaultProps deprecation warning, and ShortPixel's "No API Key set for this site".

Divi Builder and WP_DEBUG_DISPLAY #

Divi Builder fails every check on a site with WP_DEBUG_DISPLAY on — including logging in — and it fails with this plugin deactivated too, so it is not a conflict. The chain: something loads a textdomain before init, WordPress prints a _doing_it_wrong notice, that output precedes the auth cookie, and wp-login.php then cannot set headers.

With display off, which is how production runs, Divi Builder passes all nineteen checks alongside this plugin.

Worth knowing, because a developer running a debug site will see a broken login and reasonably suspect whichever plugin they installed last.

Upgrading from Enhanced Media Library #

The path every existing install takes, and the one where breakage costs most. It has its own suite: EML 2.9.4 installed and activated, its settings moved off their defaults, terms created and files filed; then EML deactivated and this plugin activated. Eighteen checks pass:

• Every value EML held is present and unchanged — library options, taxonomy definitions, taxonomy options, custom MIME types
• EML's own wpuxss_eml_* options are left untouched, so rolling back still finds its settings
• Every term assignment on every file survives
• Both taxonomies are still registered against attachments
• The site survives both plugins active at once — the careless upgrade, where someone installs this before deactivating EML. Media library and settings screens both return 200 with no fatal

Two notes on reading that. The migrated options are a superset of EML's: activation merges in this plugin's own defaults, including settings EML never had. The test asserts nothing is lost or altered rather than asserting equality, because equality would fail on a correct migration. And the settings are moved off their defaults first — a setting that already equals the default cannot show whether it was carried over or merely re-created.

Multilingual #

Polylang was run with English and Dutch configured and media_category switched on as a translated taxonomy, which is the state that matters. Twelve checks, all green:

• The folder tree shows every folder in both languages. Polylang's language filter on get_terms() does not apply on the admin side, and that is the outcome worth having — the alternative, half the tree silently missing, would have looked exactly like working software.
• A file can sit in folders of different languages at once, and both count it correctly.
• The CSV export writes both languages out, and the round trip is unaffected.
• No compatibility shim was needed. Folders are terms, and Polylang already translates terms.

Polylang costs one extra query per request — measured on an endpoint that never touches folders, which is how it was identified as Polylang's rather than ours. Nothing to fix; worth knowing.

WPML is not proven by that. The base Sitepress plugin passed the stack test above, and both plugins translate taxonomies through the same core machinery, so the structural argument carries — but it is an argument and not a measurement. Treat WPML as expected to work, untested at this depth. WPML's separate media translation add-on, which duplicates attachments, has not been tested.

Multisite #

Network activation provisions every site, including ones created later. A network-wide licence key can be set and optionally locked. Per-site safe mode means one subsite's fatal cannot take features off the whole network.

The compatibility campaign above was run single-site. Multisite is supported and exercised, but is not part of that matrix.

Not covered #

• Jetpack in the full stack. Jetpack makes blocking outbound calls to wordpress.com; in an offline test container those never resolve and the whole bootstrap hangs — with this plugin switched off as well, so it is the sandbox and not a conflict. Jetpack passes on its own.
• Divi as a theme. The Divi Builder plugin was tested; the theme was not.

The nightly watch #

Every night an automated watch looks for new releases of WordPress, PHP and the plugins and themes this plugin integrates with, greps each new release for every hook and field the plugin relies on, upgrades a staging site and runs the checks there.

What passed is recorded in the plugin's readme, newest first, with dates. That is also where the "tested up to" figure comes from — it is a measurement rather than a number somebody typed.

A note for anyone debugging a conflict #

This plugin filters posts_search, posts_join and posts_distinct on attachment queries and replaces core's search clause. That is necessary so search columns can be switched off, but it means every attachment query in the admin passes through it.

It also wraps core media views rather than replacing them. Seven replacements remain in the codebase and are the most likely source of a future conflict with a plugin that ships its own media frame. That number is published rather than implied, and it goes down with each release.