update wordpress from version 6.1 to 6.3.1 does not seem to update the wordpress files

[bleissem]

Hello,
when I use wordpress 6.1

for a local test environment

and then update my Dockerfile to wordpress version 6.3.1

build my local docker image again

and check if docker has itself updated after stopping, deleting and starting my docker container then

I'm still seeing the version 6.1. Expected would be to see version 6.3.1 which is not the case.
When I verify that I used correct docker Image with version 6.3.1 for my container that has been started with "docker history"

I can see that in that image version 6.3.1 is being used.

Currently I'm using a docker-compose.yml with a local volume that mounts to /var/www/html

volumes:  
  - ./html:/var/www/html

When I check what the content of the file version.php from the html/wp-includes folder is I see

that this file has not been updated by the docker container that is based on wordpress version 6.3.1.

I would like to know how to properly update the wordpress version by using docker ?

[maiorano84]

Your answer lies in the docker-entrypoint.sh file: https://github.com/docker-library/wordpress/blob/master/latest/php8.2/fpm-alpine/docker-entrypoint.sh#L28

If you want the image to automatically update the system in place, I typically delete wp-admin, wp-includes, index.php, and wp-config.php to trigger a full refresh.

[bleissem]

Hi @maiorano84 ,

thanks for your reply.
I have a question about:

If you want the image to automatically update the system in place, I typically delete wp-admin, wp-includes, index.php, and wp-config.php to trigger a full refresh.

Is deleting those files somewhere documented that this is a correct way of updating wordpress ?

Regards

[maiorano84]

@bleissem

No, that's just how the image works under the hood. It's just that if you're expecting the image itself to upgrade an existing installation through the use of a changed image version, the only way the current entrypoint script will do it is if certain files don't exist at runtime.

The "correct" way depends on what environment you're working in, and whether you're mounting your entire installation as a volume.

In most local installs, the entire WP instance is mounted, so the "correct" method would be to upgrade through the usual avenues in the Admin panel. Deleting the target files and restarting works - and is arguably faster - but it relies on very specific behaviors from the image itself that falls outside of the usual upgrade process.

When using this image as a final build step for Staging / Production, I will leave out these files in my own build to force the upgrade through the entrypoint. This way, we're keeping the Wordpress Core stateless and whatever orchestrator we use (in our case, EKS) can continue to reliably replicate and restart our containers in a repeatable manner. This way, the Wordpress version is now maintained as a part of the image build which would be considered the "correct" method for anybody with a reasonable DevOps and CI/CD setup.

Is it worth mentioning in the docs? Eh, maybe. I don't have a strong opinion about it, I'm just a user. But I never have a problem with maintainers providing more information than less.