Wordpress: add a VOLUME to wp-content/

[kryton]

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]

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

[kryton]

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]

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]

:+1: 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]

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

[md5]

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 :wink:

[md5]

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]

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]

:+1:

There is a discussion about this in the docker main project https://github.com/docker/docker/pull/8803

[yosifkit]

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]

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]

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]

Still a Problem or is there any other easy fix?

[tianon]

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).