Add a WordPress-compatible image without WordPress itself

[tesujimath]

I am using composer to manage WordPress and plugins. I really need a container just like these official WordPress images, but without WordPress itself. The underlying PHP images are insufficient, since they do not contain the required PHP extensions and supporting libraries and tools.

That is, I see value in building these WordPress images in two stages. Only the second stage would actually fetch and unpack the WordPress tarball itself, based on FROM stage1. The first stage would contain everything up until that point. People like me could use the stage 1 images.

Is there general interest in such a facility?

[tesujimath]

My trial is here:

• https://github.com/tesujimath/docker-wordpress-husk
• https://cloud.docker.com/repository/registry-1.docker.io/tesujimath/wordpress-husk

[tianon]

Interesting idea! How much of a space savings are we talking here? (ie, what's the value of du -hs /usr/src/wordpress?)

[tesujimath]

Well, with the wordpress:php7.1-fpm-alpine image, this:

/usr/src # du -shx *
11.7M	php.tar.xz
4.0K	php.tar.xz.asc
44.9M	wordpress

[tianon]

So we're talking ~45MB savings -- not too shabby!

[tesujimath]

So, I've made some progress with this idea, although I have in fact moved away from using composer.

I made my own wordpress container, from my wordpress-husk. I have found it's easiest just to download and install WordPress within the docker-entrypoint, and mount my own wp-config.php into the container. This gives me complete flexibility over my directory structure, etc.

The point for this issue is, installing WordPress itself is pretty easy, once you have a suitable container as a basis, containing a carefully designed PHP installation. Splitting the image would provide great flexibility, allowing addressing of #271, #283, #409, for example.

[bjorn-ali-goransson]

But wordpress isn't installed into the image itself. Only downloaded (as a zip).

It checks for the existence of index.php and wp-includes/version.php at startup, and only then it unzips the bundled zip package. This is done at startup.

If you wanna roll your own installation, just touch those files to bypass the unpacking phase. It still doesn't seem worth it to move to a custom, unmaintained image just for the sake of this file.

[tesujimath]

@bjorn-ali-goransson Upon reflection, I am inclined to agree with you. I have deprecated my husk experiment. Thanks for your input.

That just leaves the potential space saving of doing the wordpress download at runtime, rather than using the pre-downloaded copy baked into the image at /usr/src. That's a space optimisation which someone else can decide whether they care about.

[bjorn-ali-goransson]

Glad to be of help 😊

On another note, why would you need a wordpress docker image optimized (or rather tested) for a specific wordpress version, without having wordpress bundled? Are you using roots or something?

[tesujimath]

Er, I don't think I understand the question. I'm not using roots (whatever that is), and I don't care about a specific WordPress version.

[bjorn-ali-goransson]

How come you don't care about the Wordpress version? What's your MO?

[tesujimath]

New enough is good enough. I'll be upgrading to latest regularly. So a container with a not-quite up-to-date version is just fine, for the few minutes before it gets upgraded. ;-)

[bjorn-ali-goransson]

Yeah, I've thought about this as well. The thing is that you're probably only supposed to choose the image version as a WP baseline, and keep doing security updates automatically through within WP.

So you're not in any way locked in a particular version just because you happened to start the container with one.

BUT when doing feature (major core) updates, those would be best to do by updating the docker image tag reference.

I think this is the way to completely disable major updates through the web UI:

add_filter( 'allow_major_auto_core_updates', '__return_true' ); // Enable major updates

Source: Configuring Automatic Background Updates

What's your view on that?

[tesujimath]

I do all updates manually. And I take a backup before doing any.

Perhaps if I had a lot of sites to maintain, this would matter to me. But I don't, so it doesn't.

[bjorn-ali-goransson]

You do security updates manually?

[tesujimath]

If you mean, updating from WP 5.0.1 to 5.0.2, then yes. Same with plugin updates.

But I only maintain a single wordpress site, so you can regard me as an amateur if you like ;-)

[bjorn-ali-goransson]

Well this is bad practice. This docker image is for best (or at least, good) practice. They can't cater for that.

Now, perhaps you're only managing your own website - but if it's someone elses, it's plain out irresponsible.

Schedule daily backups and reenable automatic updates. I've seen enough websites being taken over which could have been prevented by allowing automatic updates. Sure it's a scary concept, it's actually a security risk by itself, but Wordpress is horribly coded, and needs patching regularly.

Remember this one? https://www.bleepingcomputer.com/news/security/wordpress-511-fixes-xss-vulnerability-leading-to-website-takeovers/

[tianon]

(Closing given #418 (comment) ❤️)