-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Exclude existing "pluggable" content in case it's been updated #507
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
Exclude existing "pluggable" content in case it's been updated #507
Conversation
If any directories like "wp-content/plugins/akismet" already exist, they're likely from a previous install where only "wp-content" was persisted and are likely to be already updated, so we should leave them alone.
Changes: - docker-library/wordpress@5a7623d: Merge pull request docker-library/wordpress#507 from infosiftr/exclude-extra-content - docker-library/wordpress@5a0d85b: Exclude existing "pluggable" content in case it's been updated
Could this be done optionally, please? This fix blocks my workaround for undesired VOLUME in Dockerfile. Of course, ideally, I'm dreaming of a separate container/tag w/o VOLUME, but I understand it may require lots of additional work during new version preparations. Thanks |
Can you provide a minimal set of steps to reproduce your failure?
|
@tianon I'm trying to achieve the below workflow (we are still working on it, so it's not in prod yet):
So I was expecting docker-entrypoint.sh is to copy everything from /usr/src/wordpress/ to /var/www/html (including "pluggable" content) on each container start. Like it's doing now when "/var/www/html" is empty Also, as I said earlier, the best case for us is to have only "uploads" directory as a volume |
That should work fine -- what I'd suggest is having a persistent volume / bind mount for the wp:
image: our-wordpress-image
tmpfs:
- /var/www/html
volumes:
- uploads:/var/www/html/wp-content/uploads |
@tianon thanks a lot for quick action and solution. It looks pretty nice :) |
Another solution you might find interesting would be to change Apache's |
Hello, We are building a Wordpress plugin containing ACF schema, from another application. Since this PR, the plugin is not updated anymore as we are doing :
The plugin is never updated in our image at redeploy... |
I'm sorry your deployments broke; can you provide a minimal set of deployment steps to reproduce your failure? If we can understand what you're trying to accomplish and how you're trying to accomplish it currently, we're more likely to be able to help. |
Hello @tianon,
Now, as the plugin is existing of course, it's not updated anymore in the volume. I've tried your solution based on tmpfs to not save a volume. This work, but it adds a new problem : if I want to use this volume for the CLI image. For example :
It will break. (and it is normal as the volume is just tmpfs volume). This change is definitively a breaking change. I imagine there is a lot of other users struggling to know why they deployment broke recently. It would be very good to trigger this behavior only with a context variable. For example, checking if a variable like |
If any directories like "wp-content/plugins/akismet" already exist, they're likely from a previous install where only "wp-content" was persisted and are likely to be already updated, so we should leave them alone.
Closes #506