Updating wordpress image does not actually update wordpress

[bdew]

The image copies wordpress files to the data volume when it's first run, but it will not overwrite them when it's updated. So the container will keep running the old version of WP.

Moreover since the mount point of the volume is owned by root, wordpress will not try to update itself either.

[scarby]

Surely this is a huge antipattern? Why would i store application code in a datavolume?

Surely the application code should be pre-baked into your container and only altered when your container is updated

[matteo-bombelli]

@scarby @jonknapp

I know that wordpress doesn't support fully the patterns for actual standard web applications, but normally needs a lot of updates, due to the big attention it gets by consumers and not so gently people.

Updates are greatly performed by the application itself, there should be no necessity to rebuild the entire docker image every time wp gets an update. This way produces a lot of wasting in computational power, developers/it time and bandwidth.

If it is important to embrace the data separated from application core pattern it should be consider to set as data volume only wp-upload folder, the others folder are "related to app", but this is not good for developing and all the other stuff (installing themes and plugins)...

to me the best of both world is:

1. create two different folders, "wp" and "wp-data" outside the htdocs folder
2. install wp in htdocs folder (unpack wp and set up wp-config with the right values)
3. move wp files from htdocs to wp folder (volume 1)
4. move wp-upload contents folder from wp folder to wp-data (volume 2)
5. mount "wp" folder contents into htdocs folder
6. mount "wp-data" folder contents into htdocs"/wp-uploads" folder (that should remain there)
7. the htdocs folder contains the right wp

this way it is easy manage to scale the "storage" efficiently (volume 2) and give the ablity to manage core application logic (volume 1) while preserving its state through reboots, portability etc...

I'm using this way of working on different php applications in vm environments and gives great results, and i should really like this on "portable containers".

And please make the wp-config file editable: wordpress now is more like a framework than an app.

Thank you to all for your work

PS please use "mount" and not "ln" : seems stupid but solves a lot of problems...

[naggie]

I've also discovered this the hard way. I've been experimenting, and so far I have made the following observations:

1. Mapping out /var/www/html/wp-content as a named volume and re-creating the container appears to allow a wordpress upgrade. Updating the container conventionally does not, somehow.
2. ...probably only sometimes -- it would probably cause issues if a database schema update happens. For that, a URL can be visited or wp core update-db can be used: https://codex.wordpress.org/Updating_WordPress
   http://wp-cli.org/commands/core/update-db/
3. This won't solve @matteo-bombelli 's wp-config.php issue, however the official docker ghost image has fixed a similar problem using symlinks.

Plan:

1. Make a new image based on this one with a fixed source.
2. Run wp-update on image boot.

I will try this. I'm leaving the idea here in case anyone knows of any problems that I might encounter.

I wonder if the reason the docker image is this way is due to plugins -- wordpress upgrades could potentially be broken by some plugins preventing an generalised upgrade procedure. I hope not -- I'd rather stick to idiomatic docker which this image is not.

[tianon]

Sorry for the long delay here.

To clarify, the primary reason the image works the way it does today is that WordPress itself does expect to be able to update itself (and in fact they highly recommend it). They also work very hard to backport security fixes to an insane number of older releases, and to ensure any updates will not break people's environments (looking at https://wordpress.org/download/releases/, you have to go back as far as 3.6 to find a release branch that wasn't updated in 2018, which is pretty impressive).

As I've noted over in #204 (comment), WORDPRESS_CONFIG_EXTRA can be used (as of #142) to disable the auto-update functionality, and I've seen reports that folks have successfully managed to get this working reasonably in a "Docker-centric manner" (ie, updates to the image result in updates to the running software) by disabling updates and only bind-mounting wp-content (instead of the entire WordPress directory), which should work reasonably well.

Given that, I'm going to close. To reiterate, folks looking to circumvent the WordPress-recommended auto-update behavior and instead manage their own WordPress version updates via Docker image replacement should do something similar to the following:

1. only persist /var/www/html/wp-content (instead of all of /var/www/html), which will force the image to re-initialize the rest of /var/www/html on every fresh container startup

2. disable auto-updates via WORDPRESS_CONFIG_EXTRA (https://codex.wordpress.org/Configuring_Automatic_Background_Updates#Constant_to_Disable_All_Updates)

[lonix1]

For the record, I think the required code in the docker stack file is:

environment:
  WORDPRESS_CONFIG_EXTRA: |
    define('AUTOMATIC_UPDATER_DISABLED', true);

[lonix1]

@tianon Your instructions are for those who want to avoid the auto update behavior altogether.

Suppose I want auto updates, but I want to backup only my custom files? So if I spin up a new container, and attach my volume, I want the container to recreate everything from scratch, EXCEPT for my custom data.

In that case do I use the same approach - use a volume wordpress_data:/var/www/html/wp-content/ (instead of all of /var/www/html)?