Hook in to specific point in entrypoint script

[ivandotv]

I need to do some other stuff in the container before the php-fpm is started, but after entrypoint.sh file provisions wordpress.
In between those two steps, I want to add some plugins (via wp-cli).
So it would be nice if we could hook in to the setup process.

Just before exec "$@" we could have code that checks if there is a script in predetermined location,
and if there is, it executes it.

[yosifkit]

It could work currently, if you name your script "apache2-something" and run the container with docker run [options] wordpress apache2-something. Then you just need to end your script with exec php-fpm.

[ivandotv]

True, hadn't thought of that. But wouldn't that mess up later calls to those services, for whatever reason?

[yosifkit]

I'm not sure what "later calls" you are referring to. As long as your script is idempotent, then a docker restart would be fine, since the entrypoint.sh would see the full /var/www/html and skip most initialization and check for an sql server and then your script would be called, followed by starting the service.

[ivandotv]

Thanks for the info.
What about the idea of the script to hook in.

[yosifkit]

As far as a place to hook scripts, this was previously proposed in #124. I am still unconvinced of the usefulness. Any required themes (or plugins) could easily be placed in /usr/src/wordpress/wp-content/themes/ in a dependent dockerfile FROM wordpress or even mounted in at runtime -v /local/custom-theme/:/var/www/html/wp-content/themes/my-custom-theme/.

[ivandotv]

Some good points were made in that issue, in favor of additional script.
I would also add continuous integration, as one of the reasons.

• Basically setting up wordpress files just isn't enough, there is always more work to be done to get the container in usable state for development or deployment.
• And I would always prefer to work with official image.

[SamMorrowDrums]

This is a really important issue.

For anyone who wants to create a deployable image with this + db backup (anywhere), it is not practical to externally download all plugins etc. and then mount them.

[SamMorrowDrums]

I should clarify, I'm already extending the image and the only step I'm having difficulty with, is a sensible way to run my own wp-cli commands as part of the initial setup. I guess I need to just inject my script into the process, but it'd be great to have some advice on this.

[yosifkit]

@SamMorrowDrums I'm still in favor of just chaining your own script with the current entrypoint by taking advantage of line 4 that matches any executable that starts with apache2.

$ # make sure my script ends with exec apache2-foreground
$ # put the script in the PATH to make it run without a full path to the file
$ docker run -d -v /path/to/my-script.sh:/usr/local/bin/apache2-special.sh ... wordpress "apache2-special.sh"`

[SamMorrowDrums]

@yosifkit I do see where you are coming from - a very WP specific issue though, is that as the wp-cli is the main nice way to install modules, but needs to be run in an active container once, to get things set up I think it's pointlessly confusing.

Surely it's not a lot to ask that an optional run-once.sh that gets called in the if block (where the final wordpress setup occurs) - given that it's purpose is to bootstrap the wp install anyway.

It would make a huge difference to usability, and while I can see the principled point about the parent image - all I want is to be able to add a manifest of plugins that will be installed and enabled on the image first start. Wordpress is very hard to use in a docker automatic deployment workflow without being able to do this.

I have tried other means of obtaining plugins, but they are not really right. wp-cli is the right way to go, and you don't need to add it to the image, just provide a super easy spot to incorporate a shell script.

[SamMorrowDrums]

The above might have been a bit dense. I'm just trying to say that some kind of event where Wordpress has been set up - now hand off to the user of this image (just once, for init), would be incredibly useful. There must be a way to handle that sensibly, in a way that is acceptable to all parties.

[tianon]

@SamMorrowDrums interesting idea -- you're thinking something like this added to wp-config.sample.php by default?

if (file_exists('/some-well-known-docker-specific/path.php')) {
	require '/some-well-known-docker-specific/path.php';
}

[tianon]

(probably actually require_once to ensure that if WordPress decides to load wp-config.php more than once, we only run it once -- not sure what WordPress behavior is WRT loading wp-config.php, but IIRC poorly-behaved plugins used to do really hacky things in that regard 😇)

[SamMorrowDrums]

That sounds like an excellent avenue to pursue! Would really be powerful to configure in that way.

…

On Sat, 10 Dec 2016, 18:30 Tianon Gravi, ***@***.***> wrote: (probably actually require_once to ensure that if WordPress decides to load wp-config.php more than once, we only run it once -- not sure what WordPress behavior is WRT loading wp-config.php, but IIRC poorly-behaved plugins used to do really hacky things in that regard 😇) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AElqXoTBTcR8CGsDAl0G4Or9SUj9UoL1ks5rGu_ggaJpZM4IgbZD> .