Download plugins/themes at build time.

[jmatsushita]

Hi there,

In order to diminish initial startup time in a development environment, I've been finding myself wanting to include the download of plugins (haven't needed themes but maybe there would be a similar need) at container build time. This has led me to this issue https://github.com/wp-cli/wp-cli/issues/2189 which seems stalled, but was looking at the possibility to have a wp command to download plugins only.

This means that adding new plugins or theme would require a docker-compose up --build or docker-compose build but then after that, each start of the container would only download/install plugins or themes that are missing, which should significantly increase startup time both in development and in production. The same could be done with the wordpress core download.

Expanding on this idea, it would be good practice to set the version of plugins allowing enlighter@3.7 syntax in the plugin list (which I guess is already achievable with the lengthier [enlighter]https://downloads.wordpress.org/plugin/enlighter.3.7.zip ). Maybe in a local development context a environment variable AUTO_UPDATE could automatically fetch the latest version, but deactivating it in production would guarantee that only the plugins that have been included at build time are available?

I realize this changes a bit the philosophy of the repo, but I thought I'd clarify my need and see if you're interested to get contributions that would go in this direction.

Cheers!

Jun

[dsifford]

Hi there,

we already have a caching mechanism set up for both plugins and themes. You can see that here. Is this not working as intended?

I should note, this mechanism will never work if you are using docker-compose down in any form. You must use docker-compose stop.

[jmatsushita]

Sorry I think caching is probably not the right term. I meant that the plugins would be downloaded at build time, so that at run time only missing plugins would be downloaded.

I've implemented this by creating a setup.sh file with the same init() and Environment than run.sh but whose main() runs install_plugins which is implemented like this:

# Install based on $PLUGINS in parallel threads
install_plugins() {
    (

        # Obtain keys of plugins to install, ignoring ADDed ones
        mapfile -t plugin_keys < <(comm -23 \
            <(echo "${!plugin_deps[@]}" | tr ' ' '\n' | sort -u) \
            <(check_volumes -p))

        for key in ${plugin_keys[*]}
        do
            printf "Installing $key\n"
            if [ "${plugin_deps[$key]}" = "$key" ]; then
              curl -s -O https://downloads.wordpress.org/plugin/${key}.zip;
            else
              curl -s -o ${key}.zip ${plugin_deps[$key]};
            fi
            unzip ${key}.zip -d wp-content/plugins/ > /dev/null
            rm ${key}.zip;
        done

    ) &
    wait
}

This is then ran as the last RUN command in my docker file. Then when the run.sh entry point kicks in, most plugins are already in the image. This considerably speeds up the startup of the container. This means also that the container, when used in a production environment could (with a AUTO_UPDATE flag) bypass the check_plugins() function to keep the plugins as they have been set at build time (hence the digression on how to pin versions, which is a good practice when deploying in prod).

Hope this is clearer.

Jun

[MariusStuparu]

Hey @jmatsushita this sounds very interesting. Can you post all the affected files somewhere?

[dsifford]

Sorry I think caching is probably not the right term. I meant that the plugins would be downloaded at build time, so that at run time only missing plugins would be downloaded.

This is what currently happens. Is this not happening for you?

[dsifford]

If you're referring to putting plugin and wordpress setup INTO the build of the actual image outside of the run.sh script, that is not something we are going to support because it will require people to build their own dockerfiles and will prevent them from pulling from the docker registry.

[dsifford]

I'm closing this as wontfix because what you're suggesting is fundamentally infeasible for this project.