-
Notifications
You must be signed in to change notification settings - Fork 316
[Playground CLI] explore why plugin files don't exist after mounting #2347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
Here's a recap of everything related to the symlink issue I learned so far.
My next steps are to understand if the mentioned Core and Woo issues are related to what we are experiencing. |
I'm not sure if the current approach of overriding |
Thanks for exploring this @bgrgicak! It seems like we're looking in the right direction but perhaps we're not in the right place yet. In particular, I'm worried about always following the symlink – that would mean we can't do things to the symlink itself, e.g. unlink it, move it around, etc. Perhaps that's not an issue here, since we're not forcing I'd still like to understand the consequences. The tests are passing which is very encouraging. But so they did before this PR. Can we add some tests that would fail without this PR? Also, what are some things that could go wrong if we merge? How could we add them to the test harness?
Which places specifically? If we can pinpoint the root cause we can understand the problem and implement a surgical fix for those data flows.
I wouldn't worry too much about that, that problem just can't be solved. If a sandboxed symlink points to an unsandboxed resource and the user did not allow it, it should break. It's a feature, not a bug.
We already do that for fcntl, poll, and others. I don't see anything inherently wrong with overriding Emscripten functions. |
Thanks for the feedback! Yes, I feel like the exploration is moving in the right direction, but it's not there yet. My main concern is that I still don't fully understand why WooCommerce is deactivated sometimes. I would like to point to a single line that causes the issue. My first step is to wrap the tests in #2338 to ensure this doesn't break any existing behavior. Also, I'm not sure that setting
#2338 will help uncover these places, but for now it looks like |
A POSIX-compliant test suite sounds really good! |
…ollowing-symlink-mounts
…ollowing-symlink-mounts
Thanks @brandonpayton! I will probably need to handover this. If you have time this week let's start collaborating. |
…ollowing-symlink-mounts
….com:WordPress/wordpress-playground into fix/lookup-path-not-following-symlink-mounts
@brandonpayton I updated the PR with my notes and a script that will allow you to recreate it. Please let me know how I can make the handof easier. |
@bgrgicak Thank you! I didn't get a chance to look at this today but will prioritize it tomorrow so we have a chance to talk yet this week. |
@brandonpayton checkout this commit ae7033b. I was able to find which PHP functions don't follow symlinks during plugin activation and cause the issue. |
476e647
to
ae7033b
Compare
@bgrgicak I took a look at this PR and am planning to meet with you tomorrow to discuss. See you then! |
I am able to see when the file lookup starts failing with breakpoints in the faccessat system call JS. It's not clear why yet, and I plan to investigate this more tomorrow. |
The first call to On the second call to This is a good clue. |
This isn't the problem, but there is a typo we can correct as well: |
It looks like this is an issue with secondary PHP instances and When |
A next step is making a good test for this. We can probably test it directly using a primary and secondary PHP instance. |
Motivation for the change, related issues
We got a report that WooCommerce "randomly" deactivates in WordPress Studio.
This PR attempts to find the root cause of the deactivation.
Note Studio doesn't use Playground CLI, but the same issue is also observable in the CLI.
Research
Recreate issue
nvm use 22
sh run-cli.sh
Debugging
file_exists
check during plugin activation in WordPress.sh run-cli.sh | grep "\[DEBUG\]"
. After mounting the symlink,readlink
mounts the symlinked directory. While insidecreateNodeFsMountHandler
, the plugin path exists, but after boot inrunCLI
it doesn't.FS.lookupPath
calls to follow symlinks. The plugin will activate.Notes
trunk
behaviorThis branch is based on add/file-mounting-to-nodefs and fails slightly differently from
trunk
.When I first started testing this issue with commit 92d0ce7, Playground CLI would boot and activate WooCommerce, but deactivate it after a random number of reloads after a WP_Cron request and after some WC-JSON API calls. I wasn't able to fully understand the issue so, I worked on adding mount tests in and resolved some mount issues in the process.
After rebasing this branch onto add/file-mounting-to-nodefs, Playground CLI started failing to boot due to the Plugin activation step failing with Plugin file does not exist.
WordPress symlinked plugins
Following symlinks used to be broken in WordPress and was fixed by Allow symlinked plugins, there is also a closed WooCommerce issue.
When I mounted a
debug.log
file to/wordpress/wp-content/debug.log
, I observed this warning which confirms that PHP is unable to access the symlinked plugin[16-Jul-2025 10:56:23 UTC] PHP Warning: scandir(/wordpress/wp-content/plugins/woocommerce): Failed to open directory: No such file or directory in /wordpress/wp-admin/includes/plugin.php on line 1115
.It seems like Playground isn't able to register the real path for the plugin using
wp_register_plugin_realpath
because the mounted plugin directory isn't recognized as a valid plugin.Other potentially related WooCommerce issues
When I mount a symlink to WooCommerce and start it's onboarding process, the same WC-JSON rest API requests failed every time, but they would succeed after a reload. This might be a completely different issue, but I haven't observed it when testing on a LAMP stack, so I'm mentioning it here.
Other
If you want to mount a WordPress directory into the CLI, there's a bug that will rewrite your WordPress files. [Playground CLI] skip-wordpress-setup overrides the mounted WordPress directory.