Skip to content

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

Closed
kryton opened this issue Aug 6, 2014 · 14 comments
Closed

add a VOLUME to wp-content/ #6

kryton opened this issue Aug 6, 2014 · 14 comments

Comments

@kryton
Copy link

kryton commented Aug 6, 2014

not sure what your feelings are about this, but it would be handy to have this exposed.

  1. wp-content/uploads is where images and other user-uploaded content gets put, so you need a way to back it up
  2. it allows people to easily add/update themes/plugins
@yosifkit
Copy link
Member

yosifkit commented Aug 7, 2014

This sounds like a great idea, but would it make more sense to do the whole /var/www/html?

@kryton
Copy link
Author

kryton commented Aug 7, 2014

my personal preference is just the user-generated stuff, so as to discourage people from 'tweaking' the FS directly.
I think it might also make upgrades a bit harder as /var/www/html is where the code is

@tianon
Copy link
Member

tianon commented Aug 7, 2014

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, wp-config.php is in the root, and it's technically completely supposed to be user-supplied code, so this would let people use --volumes-from to tweak their Wordpress global configuration without any extra hoops to jump through.

@aoberoi
Copy link

aoberoi commented Sep 8, 2014

👍 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 wp-config.php, but that is generated/managed by the docker-entrypoint.sh script in this project (which I think is a good idea) so it starts to look less like a user-generated piece.

@hamiltop
Copy link

I would say plugins should be taken into account as well.

@md5
Copy link
Contributor

md5 commented Oct 17, 2014

I would actually go the other way on this and remove the existing VOLUME /var/www/html from this definition (cf. docker-library/php#15).

It's trivial to create a derived image from this one that adds the VOLUME declaration or to simply run or create the container with a -v /var/www/html/wp-content. It is not so trivial to undo this VOLUME declaration. The way the entrypoint is written will accommodate both those who want /var/www/html or any subdirectory to be a volume and those who don't, regardless of whether this Dockerfile declares those volumes, because it will "install" Wordpress into /var/www/html the first time the container is run.

I've used a similar technique in synctree/docker-mediawiki, but since I didn't declare /var/www/html to be a volume, I was free to "pre-install" MediaWiki into /var/www/html in a (private) derived image and add on local modifications. Making /var/www/html or anything else a volume by default makes this more difficult by requiring all intialization logic to live in the entrypoint.

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 wp-content or even all of /var/www/html if they so choose. I'd be happy to provide a PR for the docs to help out here if someone is willing to remove the existing VOLUME declaration 😉

@md5
Copy link
Contributor

md5 commented Oct 17, 2014

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:

Step 0 : FROM wordpress
 ---> 4c68cd64d24a
Step 1 : WORKDIR /
 ---> Running in b0d519e11389
 ---> 1c7d687f5c67
Removing intermediate container b0d519e11389
Step 2 : RUN rm -fr /var/www/html && cp -pr /usr/src/wordpress /var/www/html
 ---> Running in 1469241e02f8
rm: cannot remove `/var/www/html': Device or resource busy
2014/10/16 21:53:08 The command [/bin/sh -c rm -fr /var/www/html && cp -pr /usr/src/wordpress /var/www/html] returned a non-zero code: 1

@daghack
Copy link
Contributor

daghack commented Oct 17, 2014

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 FROM wordpress and is not necessarily something that we want to require in the official image.

@ethervoid
Copy link

👍

There is a discussion about this in the docker main project moby/moby#8803

@yosifkit
Copy link
Member

Closing as we currently have VOLUME /var/www/html which covers this and if there is desire to remove the volume, then a new discussion can be opened for that.

@agherzan
Copy link

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.

@gymnae
Copy link

gymnae commented Jun 13, 2017

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?

@surtic86
Copy link

Still a Problem or is there any other easy fix?

@tianon
Copy link
Member

tianon commented Jan 12, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests