README

Bootstrap for WordPress project using Composer.

1. Requirements
2. Installation
3. Configuration
4. Development

Requirements

• koodimonni/composer-dropin-installer
• container (podman, docker)

Installation

Before reinventing the wheel, just check out our skeleton section for inspiration. Otherwise, follow reading :-)

Composer

Before installing the package you need to define the dropin paths in your composer.json. If you installed the package too early, just delete it from vendor folder. This will re-trigger the dropin-process.

The configuration in your composer.json should look something like this:

{
    "extra": {
        "config": {
            "allow-plugins": {
                "koodimonni/composer-dropin-installer": true
            }
        },
        "dropin-paths": {
            "public/": [
                "package:3p5/bootstrap:public/index.php,public/bootstrap.php,public/wp-config.php,public/wp-config-sample.php"
            ]
        }
    }
}

Now you can install the package from composer repository. For plugin/theme development, add --dev as argument.

composer require 3p5/bootstrap

Container

To auto-generate wp-config.php you need to add following to your entrypoint.sh:

if [ "$WP_ENV" != 'production' ]; then
    su -s /bin/sh - www-data -c '
        cd /srv/app;
        composer install --prefer-dist --no-progress --no-interaction;
        yarn install
    '
fi

if [ ! -f "public/content/wp-config.php" ]; then
    echo "Creating wp-config.php & generating salts"
    su -s /bin/sh - www-data -c '
        cd /srv/app;
        cp -a public/wp-config-sample.php public/content/wp-config.php;
        wp config shuffle-salts --config-file=public/wp-config.php
    '
fi

setfacl -R -m u:www-data:rwX -m u:"$(whoami)":rwX public/content
setfacl -dR -m u:www-data:rwX -m u:"$(whoami)":rwX public/content

BTW: For critical infrastructure it's not a bad idea to re-generate salts after each deployment. But to be honest, for that it's a worse idea relying on WordPress :-)

Configuration

Environments

It's possible using system environments and/or container secrets. For secrets, just suffix the environment variable with _FILE and the path to the file, e.g.:

DB_PASSWORD_FILE=/run/secrets/db_password

A full list of all environment variables is not available yet, please check src/Service/Configuration.php.

Trusted proxies

If you're using this application behind a reverse proxy (e.g. traefik), you need to set the trusted proxies to the CIDR of your proxy network. Otherwise you'll not get correct request scheme or client's real ip.

To set the trusted proxy, do something like this:

TRUSTED_PROXIES="172.0.0.0/24, 10.0.0.0/8, ..."

For testing, you can also set a wildcard (*).

Development

We're using some kind of git flow, so for merge requests please create a new branch from develop.

For consistency and security reasons, please run everything inside the container. Most tools are already pre-built in the dev-container.

1. podman compose up -d
2. podman exec -it -u www-data bootstrap_app_1 sh

WP-CLI

You can also use WP-CLI, switch to container and check following ./vendor/bin/wp --path=cms/ --url=https://localhost help

Permissions

If you're using podman in rootless mode (recommend), you'll for sure get permission issues while starting the container and also maybe while git interaction on host system. To fix permissions, you need to change the owner to your shadowed group id. Run following command with your specific gid (you can simply check inside your container):

sudo chown -R :${GID:-100081} .

To revert back, run following:

sudo chown -R ${USER}:${USER} .

PS: You should also be able to use podman unshare. Also, some IDEs support some automatic permission fixing while development. If you've found a better solution, feel free to improve this documentation :-)