env: Update docker volumes during wp-env start #24778
Conversation
noahtallen added [Type] Build Tooling 
Size Change: +3.33 kB (0%) Total Size: 1.17 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Im not exactly sure the best way to test this, but running the wp-env start --update on this branch seems to still work as expected. The code seems to make sense in regard to removing the volumes, pulling the new ones, and adding the required commandOptions where necessary.
| const directoryHash = path.basename( workDirectoryPath ); | ||
| // Note: when the base docker image is updated, we want that operation to | ||
| // also update WordPress. Since we store wordpress/tests-wordpress files |
There was a problem hiding this comment.
Non-blocking
Since we store wordpress/tests-wordpress files as docker volumes, simply updating the image will not change those files
To clarify my understanding, the volumes aren't updated because we've cached them. I guess the caching makes sense because volumes are meant to be stateful, and we shouldn't be updating them regularly because data would be blown away.
Does that mean running --update should now clean all of our WordPress data?
There was a problem hiding this comment.
No, the database is stored in a separate volume, so no data should be wiped!
I'm not entirely sure why we have volumes for the wordpress directories. I think it might be performance? @noisysocks would know more
There was a problem hiding this comment.
Everything looks good to me. Would you be able to elaborate on how I could set up an environment that tests that an outdated plugin is updated?
I'd imagine I manually upload an outdated plugin, but I'm not sure how to roll back the WordPress image version as well.
+1 if everything looks good in testing
Co-authored-by: Addison Stavlo <Stavz01@gmail.com>
I'm not sure. You would have to have a dev environment for something which existed before the latest WordPress environment, that is still running WordPress 5.4, and does not specify a core source. So that excludes gutenberg (which maps its own core source), but might include a different plugin dev environment |
Yes, for example you can find older releases of Gutenberg by browsing through history here. As for the WordPress image, based on the instructions here you can specify an exact version in |
Unfortunately, this will not work. That will cause WordPress to be downloaded as a standalone source via github or a git file, but it does not affect the underlying docker image at all. So if you create an instance with an image for the first time, it will use the updated version of that image even if the wordpress version from the source is older. |
What's the point of having the older source if it's not used then? 🤔 |
All of the docker services need to be based on some image, and for wp-env we use the official WordPress image. That happens to include the latest version of WP, so you can use wp-env out of the box just fine without specifying a core source. Once you specify a core source, it is mounted directly as its own volume, which then takes the place of whatever the image is including by itself. This specific PR is just solving the issue of the docker image itself being out of date and not updating to the latest version. I think it would be more effort to try to use a different image conditionally if you have specified your own wordpress source than it is worth :) No one has really tried to make that happen, though |
I'm in the same situation as Addison. Running To keep the conversation moving forward, it seems like the potential risks of merging this PR are limited because we're only replacing WordPress volumes. (Does that sound right @noahtallen ?) Do we see value in exploring exactly how to test a PR like this? If not, and if my understanding of the risk is correct, then I'm comfortable proceeding. |
One thing to verify would be to test that your data isn't deleted when running I think this is safe to merge though 👍 It is easy to fix issues that arise, and wp-env isn't a tool for production environment. |
Thanks! I'm pretty sure I checked this when you responded here #24778 (comment), but I'll double-check now to be sure 🙂 |
Confirmed that data isn't deleted. I also smoke tested the WordPress environment (edit post, edit site, frontend) and everything looks like it works as expected. |
This was true on my end as well. 👍 |
Description
Since WordPress 5.5 was recently released, I noticed that some of my 3rd party plugins which rely on the base WordPress image were not updating to the latest version. Even after pulling the image updates, WordPress did not update.
This adds two things to the
wp-env start --updateprocess:$hash_wordpressand$hash_tests-wordpressvolumes. These cache the wordpress files, so these volumes need to be removed for the next step.Step 1 is necessary because without it, the container will not see that any wordpress files have changed even after pulling and rebuilding the images.
How has this been tested?
Locally in wp-env with a 3rd party plugin which was out of date.
Screenshots
Types of changes
Enhancement
Checklist: