Download the PHP package lch/docker-wordpress without Composer
On this page you can find all versions of the php package lch/docker-wordpress. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download lch/docker-wordpress
More information about lch/docker-wordpress
Files in lch/docker-wordpress
Package docker-wordpress
Short Description Ready-To-Start LAMP stack with Wordpress, WP-CLI and PHPMyAdmin
License MIT
Homepage https://github.com/compagnie-hyperactive/docker-boilerplate-wordpress
Informations about the package docker-wordpress
Docker WordPress Boilerplate (Apache, PHP-FPM, MariaDB, WP-CLI, phpMyAdmin)
A ready-to-start Docker boilerplate for WordPress projects with:
- Apache 2.4 + PHP-FPM
- MariaDB
- WP-CLI
- phpMyAdmin
- Task automation with
just
Quick Start
Create a new project from this template:
Without a version constraint, Composer installs the latest stable release.
If you want HEAD of main, use:
Then go into your project directory and update .env.
Prerequisites
- Docker + Docker Compose plugin (
docker composecommand) just(task runner)composer(only needed if you bootstrap withcomposer create-project)envsubst
Install just
Use your preferred package manager:
If your distro package is unavailable/outdated, use cargo install just.
Install envsubst
On macOS:
On most Linux distros, envsubst is provided by gettext.
Configuration (.env)
Set all values before first initialization.
Directories
WORDPRESS_HOST_RELATIVE_APP_PATH: host path mounted to/var/www/html(default./)LOGS_DIR: Apache logs directory on host
Runtime
PHP_VERSION: PHP version used to build the PHP containerMARIADB_VERSION: MariaDB image tagTIMEZONE: container timezone
Host Mapping
HOST_USER: your host usernameHOST_UID: your host UID (used for file ownership mapping)HOST_GID: your host GID
WordPress
PROJECT_NAME: WordPress site titleADMIN_USER: initial admin usernameADMIN_EMAIL: initial admin emailADMIN_PASSWORD: initial admin password (keep quotes if needed)BO_URL: back-office path slug used for authenticated warmup requests (for examplewp-admin); set it without leading/trailing slashWP_CLI_CACHE_DIR: WP-CLI cache pathDIVI_USERNAME: Elegant Themes username (used byjust set-divi-api-key)DIVI_API_KEY: Elegant Themes API key (used byjust set-divi-api-key)THEME_UPDATE_RECHECK_PASSES: number of HTTP warmup passes beforejust update-themes(default5)PLUGIN_UPDATE_RECHECK_PASSES: number of HTTP warmup passes beforejust update-plugins(default5)UPDATE_WARMUP_PASSES: fallback warmup pass count if specific vars above are not set (default5)UPDATE_WARMUP_SLEEP_SECONDS: delay between warmup passes (default2)
GitHub (used by just install-and-version)
GITHUB_NAME: GitHub owner/orgPROJECT_REPO: GitHub repository name
Database
MYSQL_HOST: DB host (mysqlby default, must match compose service name)MYSQL_DATABASE: DB nameMYSQL_DATABASE_PREFIX: WordPress table prefixMYSQL_USER: DB userMYSQL_PASSWORD: DB passwordMYSQL_HOST_PORT: host port mapped to DBMYSQL_PORT: DB port inside container (default3306)
Ports
APPLICATION_WEB_PORT: Apache exposed port (default80)PHP_MY_ADMIN_PORT: phpMyAdmin exposed port (default81)
Usage
List available recipes:
Initial project setup
This recipe:
- builds/starts containers
- waits for DB readiness
- generates
wp-cli.ymlanddeploy.phpfrom.disttemplates - installs/configures WordPress
- installs a default plugin set
Day-to-day commands
Maintenance commands
set-divi-api-key writes Divi update credentials to the WordPress option et_automatic_updates_options using WP-CLI.
warmup-updates emulates authenticated back-office page loads (/${BO_URL}/) + front-office hits + cron triggers to refresh update metadata (same effect as manual BO/FO navigation).
update-themes and update-plugins call this warmup automatically before applying updates (THEME_UPDATE_RECHECK_PASSES / PLUGIN_UPDATE_RECHECK_PASSES).
Core recipes can execute optional hooks when present:
update-themes-pre-hookupdate-themes-post-hookupdate-plugins-pre-hookupdate-plugins-post-hookerase-allis a destructive test helper: it stops/removes the compose stack, removes compose volumes, and deletes${GITHUB_NAME}/${PROJECT_REPO}on GitHub. It asks for an inlineYESconfirmation before running.
Private Just overlays
The root justfile can optionally import extra local files:
justfile.localjustfile.privatejustfile.user
Role of this feature:
- keep personal/team-specific recipes out of the shared
justfile - avoid committing private automation (local credentials, shortcuts, machine-specific tasks)
- extend project commands without changing versioned project files
- inject project-specific update logic (for example Divi/Elegant Themes fallbacks) via the optional hook recipes listed above
These files are ignored by git via justfile.*.
Example:
Repository bootstrap helper
install-and-version assumes you are authenticated with GitHub CLI (gh auth login), bootstraps WordPress/GitHub/Git on first run, and skips GitHub bootstrap if the local git repo is already initialized.
Tools (tools/)
The tools/ directory contains helper scripts that are not part of the main just workflow.
check_wordpress_state.py
This script compares a local WordPress instance against production and returns a non-zero exit code only when a blocking mismatch is detected.
What it checks:
- admin login through the hidden back-office slug (
/${BO_URL}/) and final access to/wp-admin/ - page-by-page comparison between production and local URLs
<title>equality- first
<h1>equality - visible text similarity
- HTML similarity after basic normalization (URLs, scripts, styles)
Files:
tools/check_wordpress_state.py: executable Python scripttools/check_wordpress_state.example.json: sample JSON configuration
Recommended workflow:
- Make sure the local stack is up and the site is reachable.
- Run the checker in the mode that matches your migration/update context.
- Review the
SUMMARYblock first, then inspect page-level details only if the summary isWARNorFAIL. - If needed, rerun with explicit paths for the pages that matter most to the project.
Basic usage:
Usage with a project .env:
Usage with a JSON config file:
Configuration sources are resolved in this order: CLI options, JSON config, environment variables, then script defaults.
Supported environment variables:
PROD_SITE_URLLOCAL_BASE_URLAPPLICATION_WEB_PORTBO_URLADMIN_USERADMIN_PASSWORDCHECK_TIMEOUTCHECK_USER_AGENTCHECK_MODECHECK_MIN_HTML_SIMILARITYCHECK_MIN_TEXT_SIMILARITY
Important behavior:
- if
--local-baseis omitted, the script buildshttp://localhost:<port>from--local-portorAPPLICATION_WEB_PORT - if no paths are provided, it falls back to the hard-coded defaults in the script; these sample paths are project-specific and should usually be overridden
strictmode is the default: HTML similarity is enforced in addition to title/H1/text checksvisual-ishmode ignores low HTML similarity when visible text still matches closely
Recommended modes:
strict: use for classic updates where you expect the DOM to stay close to productionvisual-ish: use for builders/framework migrations such as Divi 4 -> Divi 5, where rendered content may stay stable while DOM structure changes heavily
Examples:
Output format:
ADMIN_LOGIN: login URL used, final URL reached, login cookie status, page titlePAGE_COMPARE: one block per checked path with status and similarity metricsSUMMARY: final status and per-check recap
How to read the metrics:
html_similarity: structure-oriented comparison after removing scripts/styles and normalizing base URLstext_similarity: visible-text comparison after stripping markup- low
html_similaritywith hightext_similarityusually means markup drift, not content drift - title/H1 mismatches are treated as blocking because they usually indicate a real page-level regression
Status semantics:
OK: page/admin check is within the configured expectationsWARN: content still matches closely enough, but a non-blocking threshold was crossedFAIL: admin access is broken, HTTP fetch failed, or a blocking mismatch (for example title/H1) was detected
Exit codes:
0: all checks passed, or only non-blocking warnings were found1: at least one blocking failure was found
Access URLs
- WordPress:
http://localhost:${APPLICATION_WEB_PORT}(defaulthttp://localhost) - phpMyAdmin:
http://localhost:${PHP_MY_ADMIN_PORT}(defaulthttp://localhost:81)
Reset From Scratch
-
Stop containers:
- Remove WordPress files and DB data using the paths configured in
.env. - Re-run initialization:
For full test reset (including remote GitHub repo deletion), use:
Notes
- WP-CLI commands should generally be run as
www-datainside the PHP container. configure-wordpressconsumes template files (wp-cli.yml.dist,deploy.php.dist) by generating runtime files and removing.distfiles.