Remove VOLUME

[davidbarratt]

Docker does not provide a way to remove the VOLUME in docker-compose.yml or by extending this image in a Dockerfile. Because of this, the VOLUME should be removed so others can add it if they want.

[pnloyd]

I ran into this same problem, as a workaround just changed WORKDIR to something else (I used '/var/www/public'. docker-entrypoint.sh will copy/setup wordpress into PWD so your good to go!

[donnykurnia]

Or, make the VOLUME as ONBUILD

[donnykurnia]

@pnloyd you will also need to override the DocumentRoot in /etc/apache2/sites-available/000-default.conf

[pnloyd]

@donnykurnia actually using nginx on top of the wordpress fpm image.

[mikew]

Just to give examples why this VOLUME is annoying:

• Makes developing themes with docker-compose difficult, since docker-compose preserves volumes, if you docker-compose build && docker-compose up you'll still be using the old theme files, you must docker-compose rm -v before.
• Same with plugins
• Adding themes / plugins in Dockerfile gets hairy, because the VOLUME comes before any chown commands the person extending the image would write. This means chown doesn't take.

I just spent hours trying to figure out issues with my config to discover this VOLUME instruction is at the root of it all. This also explains all those nameless volumes that keep popping up.

This VOLUME is rather unexpected and unhelpful; if this isn't going to be removed, can we at least get an explanation why it's there?

[tianon]

My comment from #246 (comment) today is relevant:

WordPress expects to self-update (and IMO anyone who doesn't allow it to do so these days is asking for trouble), so we simply recommend that users instead make the entire install a directory and be done with it. If you'd like a fresh install from an image to include pre-installed themes or plugins, simply add them to the source directory in /usr/src/wordpress (which is what gets copied into /var/www/html at runtime).

Applying a VOLUME in this way is consistent with how other official images handle their explicitly mutable state.

This definitely could do with some better documentation, which is over at https://github.com/docker-library/docs/blob/master/wordpress/content.md if anyone wanted to take a stab at writing something.

Thanks @tianon, I appreciate the quick response. I wasn't expecting that. The idea of considering the entire install as mutable state makes sense to me, and now I have some thoughts on how to experiment with VOLUME to get a better understanding of how all this works ( as this is pushing the bounds of my Docker knowledge ). If I can get to a useful understanding, I'll see if I can figure out how to contribute some documentation.

[davidbarratt]

@tianon You don't need to make it a volume to auto-update it. In fact, it can prevent it. I could always let WordPress auto-update within the container, there isn't anything stopping that. However, if I were to disable auto updates and do a docker pull I would not get the latest version (as expected). Also, what if the user would rather just make their plugins and theme directory a volume (since that's the only thing they care about persisting)? There isn't a way for the user to cusotmize this at all, because VOLUME forces a volume to be created. :(

[davidbarratt]

@tianon TBF, I would be fine with the VOLUME if there was an easy way to override it, but afaik there isn't. :(

[davidbarratt]

@tianon IMHO, since volumes have to be named anyways (otherwise most users will get a bunch of unexpected duplicates), I think they should be runtime only (i.e. docker or docker-compose, but not Dockerfile)

[donnykurnia]

The problem with VOLUME in wordpress Dockerfile, there is no easy way to override this if we want to make a new image using this image as a base. So, making an alternative image that set VOLUME as ONBUILD could be a compromise. Those who want to use wordpress image as a base image can use the onbuild image instead. The VOLUME will be executed after the additional commands in child image have all been executed.

[jzaefferer]

WordPress expects to self-update (and IMO anyone who doesn't allow it to do so these days is asking for trouble), so we simply recommend that users instead make the entire install a directory and be done with it. If you'd like a fresh install from an image to include pre-installed themes or plugins, simply add them to the source directory in /usr/src/wordpress (which is what gets copied into /var/www/html at runtime).

Applying a VOLUME in this way is consistent with how other official images handle their explicitly mutable state.

Thank you, that was very helpful. I went a step further, copying files (mostly themes) to a separate folder, and symlinking those into /usr/src/wordpress/wp-content/themes. The symlink is then copied, while my theme files stay outside the volume, so that I can update the image to deploy theme changes.

I'm not quite done testing this, but if it indeed works I'd be happy to extend the docs accordingly.

[jzaefferer]

For anyone else trying to update files from the image, within the /var/www/html volume: https://gist.github.com/jzaefferer/9a47b2d0af58c43deb189267f5a963a6

The custom entrypoint (apache2-init.sh) uses wp-cli to install the theme and eventually calls apache2-foreground