Official-images: WordPress 5.0.1 with security patch

[limestreet]

May I know when will be updated WordPress image in Docker Hub? As there is version 5.0.1 released 4 days ago with security patch. Link to official note: https://wordpress.org/news/2018/12/wordpress-5-0-1-security-release/
Here is the appropriate commit: https://github.com/docker-library/wordpress/commit/1c5c9ca909e1cd58714eb351922c80ceb2f30d9e

[gwynnarth]

Also waiting. Especially in case of security updates such big lag makes me want to explore other options than using official image from Docker Hub.

[tianon]

Updating your image will not update your blog -- the WordPress image will only do an initial install. We recommend that especially for security updates like this, you allow WordPress's automatic updates to do their thing as they're designed to do for exactly this purpose (which is why the image is designed to work this way in the first place).

[tianon]

If you'd like to help get this change released faster, clone https://github.com/docker-library/wordpress locally, run ./generate-stackbrew-library.sh, and make a PR to this repository updating library/wordpress with the file contents.

[limestreet]

Thanks for explanation @tianon
in my environment I use official WordPress image as a base to my build. I install all the dependencies (themes and plugins in custom directories - outside wp-content) through composer to keep exact versions and they are stored into docker image with read-only permissions and define('DISALLOW_FILE_MODS', true) flag. This is to keep builds immutable and for improved security. The only mounted and writable directory is wp-content (without themes and plugins).
If I find a while I'll try to prepare PR.
So as a base and to track WP versions I use official WP docker image. It has many good sane defaults :)
P.S. Today should be released WP 5.0.2

Thank you :)

[gwynnarth]

Hi @tianon,

Our use case is a bit different from what I think you assume.

Since Docker containers should be volatile and stateless, I think it's not entirely justified to talk about "initial install" at all - of course you need to install Wordpress database tables but that's a one-time operation. In our case, specifically, we run our custom image based on official WP image just as @limestreet and have the same approach as he has described (which leads me to believe that we're not doing anything unusual...).

Key point is that we have multiple container instances running behind a load balancer (database and wp-content are of course separate and shared between them) and we specifically have to disable any automatic updates to ensure immutability: since Wordpress updates may involve changes to database scheme, we cannot allow this to happen uncontrollably, otherwise we might have different versions of Wordpress running in parallel. Old version might not be compatible with the new database or might break something again that a database migration was supposed to fix. In general, bad stuff can happen that we'd like to avoid.

To update we bump up the version of base wordpress image, rebuild and redeploy, which replaces all containers with a new version. Clean and simple. But the caveat is that we depend on the base image to be available in a new version. This has not been a problem until now as the updates were quite quick.

I wonder how many people use this Docker image in a similar fashion... I suspect the percentage would be significant. I realize that Wordpress automatic updates SHOULD be the answer here, but unfortunately we cannot let it happen.

[yosifkit]

Sorry for the delay all.

@tianon is responding on vacation and I have been a bit swamped with other work. Thanks @limestreet for the PR, running tests on it now.