PHP: Use auto_prepend_file to preload mu-plugins (instead of creating them in wp-content/mu-plugins)

[adamziel]

Problem addressed by this PR

This PR moves the Playground mu-plugins from /wordpress/wp-content/mu-plugins, where they may interfere with the user-provided files and pollute the git repository, to /internal/mu-plugins, where they're invisible to the Playground consumer and don't show up in exports or OPFS mounts.

Closes #1318

Changes made

Technically, this PR uses the auto_prepend_file PHP options to pre-load the following script:

<?php
foreach (glob('/internal/preload/*.php') as $file) {
	require_once $file;
}

From here, preloading files is as simple as creating them in /internal/preload. This PR ships a few such preloaded files:

• consts.php, that enables predefining PHP constants without affecting wp-config.php.
• env.php, that preloads mu-plugins from /internal/mu-plugins using the method described by @brandonpayton.
• phpinfo.php, that just calls phpinfo(); when the request URL is /phpinfo.php – this prevents creating an actual phpinfo.php file in the document root. This involves a slight change in the path resolution logic which will have to change even more soon to solve Static files run as PHP when path includes directory like <some-dir>.php/ #1365.

From there, the SQLite integration plugin and the Playground mu-plugins are placed in /internal/mu-plugins and do not affect the WordPress file structure.

This PR also reduces code duplication by moving some parts of the WordPress setup to the @wp-playground/wordpress package where they can be imported by both the web and the CLI versions of Playground. We'll only see more of these moving forward.

Follow-up work

• Define clear use-cases and behaviors related to the location of Playground-provided files. E.g. Full site export, where we want to keep the SQLite integration plugin, or a GitHub repo, where we only want to keep track of our changes in wp-content.
• Use @wp-playground/cli to build and setup WordPress in packages/playground/wordpress-builds/build/Dockerfile
• Playground web: do not ship the SQLite integration plugin in the pre-built wp-content directory. Source it from the /internal/mu-plugins directory same way as in the CLI build.
• Do not create the drop-in plugin wp-content/db.php
• Do not install the WordPress importer plugin in wp-content/plugins
• Figure out how to avoid touching wp-config.php – defining PHP constants may require rewriting it and it might be desirable to keep those changes on export

Testing instructions

• Confirm the tests pass
• In the browser – export Playground as zip, import it, also refresh the page and import again, confirm it all worked.

[bgrgicak]

I like the use of auto_prepend_file here, it seems like a better solution from mu-plugins.

One thing that came to my mind is that some plugins might want to use auto_prepend_file, for example Wordfence.
This is an edge case and they could add their PHP file to /internal/preload.

[bgrgicak]

Why store this PHP code in JS? Would it be possible to load it from PHP files?

[adamziel]

I couldn't figure out a way to do it that would work with all the build systems (Bun, ESBuild, Rollup). Bun has a .toml config file where we can define a custom loader, but it is only used with a few specific commands.

[brandonpayton]

Sometimes, it's nice to be able to read see everything inline anyway.