-
Notifications
You must be signed in to change notification settings - Fork 1.1k
add a VOLUME to wp-content/ #6
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
Comments
This sounds like a great idea, but would it make more sense to do the whole |
my personal preference is just the user-generated stuff, so as to discourage people from 'tweaking' the FS directly. |
Well, the justification here would really be that technically, all of Wordpress is the "user-specified" bit. Wordpress upstream prefers that Wordpress itself do auto-updates, for example. Also, |
👍 to kryton's original feature request. if the original code remains clean an unadulterated, the official updates to wordpress should apply without an issue. the exception of course is |
I would say plugins should be taken into account as well. |
I would actually go the other way on this and remove the existing It's trivial to create a derived image from this one that adds the VOLUME declaration or to simply I've used a similar technique in synctree/docker-mediawiki, but since I didn't declare If the VOLUME declarations are removed from this image, it's just a matter of updating the docs to show users how to properly initialize a data volume container and mount it into the Wordpress image for |
Here's an example of what I mean: FROM wordpress
WORKDIR /
RUN rm -fr /var/www/html && cp -pr /usr/src/wordpress /var/www/html
WORKDIR /var/www/html
ADD my_local_stuff /var/www/html And this is what happens if you do that:
|
I actually agree with @md5 here - this is something that can trivially be done when you run the container, or by making your own image |
👍 There is a discussion about this in the docker main project moby/moby#8803 |
Closing as we currently have |
I'm not sure why was this dropped and why don't we consider at least documenting this mount. The whole idea of a docker container is to be able to update a component at the image level. If I persist that component in the docker container, why should I use docker in the first place? If I don't mount /var/www/html and update the container, I will lose all my data that does not reside in the database (ex plugins, themes, uploads etc). So the problem @kryton raised is crucial and actually I have no idea how user would use this image otherwise. |
I just ran into this with an upgrade of Wordpress. I can either demount my volume container to upgrade to the new version, but doing so lose plugins and themes, or link an ftp container to my wordpress container. The problematic file wp-content and the folder wp-content need to be user mounted and persistently stored, the rest should be "docker like" and not persistently stored. How could this be achieved? |
Still a Problem or is there any other easy fix? |
The "easy" fix to what's described here is to add your own volume for
"wp-content" (specifically, "/var/www/html/wp-content"), add appropriate
environment variables for database linking, and ignore the "/var/www/html"
volume entirely (let it get re-filled fresh every time you recreate your
container).
|
not sure what your feelings are about this, but it would be handy to have this exposed.
The text was updated successfully, but these errors were encountered: