Fix wp-env mu-plugins Docker mount failure

[obenland]

Summary

• Docker failed to start the plugin-directory wp-env because individual file mounts (wporg-query-filter.php, etc.) overlaid on top of a directory mount resolved outside the container rootfs
• Switches to a directory-first approach: map wp-content/mu-plugins to ./mocks/mu-plugins/, then overlay pub/ and wporg-mu-plugins/ on top — matching the pattern used in wporg-two-factor
• Consolidates all mock mu-plugin files into environments/mocks/mu-plugins/, reducing 6 mapping entries to 3

Test plan

• Run npm run plugins:env start — should start without Docker mount errors
• Verify all mu-plugins load: npx wp-env run cli -- wp plugin list --status=must-use
• Verify plugin import works: npx wp-env run cli -- wp eval-file wp-content/env-bin/import-plugins.php

🤖 Generated with Claude Code

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props obenland, dd32.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Copilot]

Pull request overview

This PR fixes the plugin-directory wp-env Docker startup failure by restructuring MU-plugin volume mappings to avoid problematic nested individual-file mounts.

Changes:

• Switch MU-plugins mapping to mount a local directory first, then overlay pub/ and wporg-mu-plugins/.
• Consolidate local mock MU-plugin files under environments/mocks/mu-plugins/.
• Simplify .wp-env.json MU-plugin mappings from multiple file mounts to three directory mounts.

Reviewed changes

Copilot reviewed 1 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
environments/plugin-directory/.wp-env.json	Reworks MU-plugin mappings to a directory-first overlay approach to prevent Docker mount failures.
environments/mocks/mu-plugins/wporg-query-filter.php	Adds a local-only query short-circuit MU-plugin to avoid queries to production-only tables.
environments/mocks/mu-plugins/wporg-dev-login.php	Adds a local-only one-click login helper on the login screen.
environments/mocks/mu-plugins/mu-plugins-loader.php	Adds a loader MU-plugin to bootstrap MU-plugins from pub/ and wporg-mu-plugins/.
environments/mocks/mu-plugins/mu-plugin-local-reminders.php	Adds a local-only admin notice to guide importing approved plugins that have no content.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[obenland]

@dd32 I wanted to propose this update again, the way it's setup in trunk currently just doesn't work on my machine.

I'm using Docker Desktop on MacOS which uses VirtioFS and when it tries to create file mountpoints inside an already-mounted directory, the paths resolve through /run/host_virtiofs/ which lands outside the container's overlay rootfs. Directory-on-directory mounts don't have this problem, which is why the mocks folder approach works for me.

Do you use a different setup?

[dd32]

@obenland I'm happy to merge this, but I'd like to understand why it's actually needed.. as AFAIK we were running the same environment :)

I'm running with VirtioFS as well, and /run/host_virtiofs sounds like there's something else at play here. I suspect it's a bug somewhere in the stack above this.. maybe wp-env? Are you using Docker VMM or Apple Virtualisation? Do you have the parent folder (/Users/?) of your git repo's as a shared folder in Settings -> Resources -> File sharing?

Hrrrmm... I was running Docker Desktop 4.40, i've updated to 4.67 and it's broken in a similar way to what you describe.. although this PR is also broken :/ Under 4.67 it's using /host_mnt/ for me.. where as before it was using shared folder bind mounts.

Okay, I'm running into a regression in 4.67.. docker/desktop-feedback#279 docker/desktop-feedback#264

...Rolled back to 4.66, and trunk still works for me, but so does this PR.

Anyway, claude has this to say:

Your PR (#587) is fine — and arguably more robust than trunk under this bug, because it reduces the number of nested file-level mounts to a single nested directory mount (pub and wporg-mu-plugins). But on Docker 4.67 even those two don't apply, so you can't validate it locally until the Docker side is resolved.

Let's just merge it.

[dd32]

...Rolled back to 4.66, and trunk still works for me, but so does this PR.

According to Claude, trunk doesn't work under 4.66;

Trunk config (without the fix): Still broken. The original Docker "mount outside rootfs" error doesn't appear anymore — instead, the individual-file mounts overlaid on top of the mu-plugins/ directory mount are silently dropped. The container starts, but wp-content/mu-plugins/{wporg-query-filter,mu-plugins-loader,wporg-dev-login,wporg-plugins-local-reminders}.php are missing inside the container, causing PHP Failed to open stream warnings and a fatal error in wporg-parent-2021/functions.php (because Global_Fonts\get_font_stylesheet_url() from the missing mu-plugins isn't loaded). The lifecycle script aborts and no containers stay up.

That sounds like the issue you were running into that lead to this, which I now see looks like it's landed in Docker Desktop 4.66, it's just that in 4.67 it was broken even further :)

Which version are you running?

[dd32]

I'm not a fan of moving mu-plugin-local-reminders.php into the generic mu-plugins folder you've made, I'd rather that be contained to the plugin directory.

I think we'd then have:

• mu-plugins/
• mu-plugins/pub/
• mu-plugins/wporg-mu-plugins/
• mu-plugins/plugin-directory/

Or maybe the local-reminders.php should be instead just added to the general plugin-directory codebase locked behind a 'local' === wp_get_development_type() branch.. yeah that's probably the best option..

[obenland]

That sounds like the issue you were running into that lead to this, which I now see looks like it's landed in Docker Desktop 4.66, it's just that in 4.67 it was broken even further :)

Which version are you running?

I was running 4.66. Looks like this bug might be fixed with 4.68 🤞