88 lines
3.6 KiB
Markdown
88 lines
3.6 KiB
Markdown
# The demo WordPress
|
|
|
|
A clean install with **no Avada and no plugins**, so the theme has to stand on
|
|
its own. The `wp-migrate` rig is the opposite — the production tree, kept as the
|
|
reference to compare against — and is never touched from here.
|
|
|
|
cd local
|
|
docker compose up -d # http://localhost:8090/
|
|
|
|
Docroot is the project's own `../site`, so a `npm run build` lands in the running
|
|
theme with no copy step and no restart.
|
|
|
|
## Logging in
|
|
|
|
http://localhost:8090/wp-admin/ admin / tlig
|
|
|
|
Throwaway credentials for a throwaway local install. Nothing here is ever
|
|
deployed, and the database lives in a named volume, not in the repo.
|
|
|
|
## wp-cli
|
|
|
|
The `cli` service is behind a Compose profile so it never starts with the site.
|
|
Run it one command at a time:
|
|
|
|
docker compose --profile cli run --rm cli wp user list
|
|
docker compose --profile cli run --rm cli wp plugin list
|
|
docker compose --profile cli run --rm cli wp post list --post_type=page
|
|
|
|
Adding a user, for instance:
|
|
|
|
docker compose --profile cli run --rm cli \
|
|
wp user create editor editor@example.org --role=editor --user_pass=tlig
|
|
|
|
It talks to MySQL directly — it does not go through Apache — so it works even
|
|
when the site itself is down. It shares the same `../site` mount and the same
|
|
`wp-config.php` as the web container, so the two can never disagree about which
|
|
database they are looking at.
|
|
|
|
## Resetting
|
|
|
|
docker compose down -v # -v also drops the database volume
|
|
|
|
`site/` survives, because it is the repo's own tree. Re-running `wp core install`
|
|
gives a fresh site against the same files.
|
|
|
|
## Offline by design
|
|
|
|
`wp-config.php` sets `WP_HTTP_BLOCK_EXTERNAL`: the rig boots with no network and
|
|
never reports this install to WordPress.org. Blocking the request does not stop
|
|
WordPress making it, though — the update checks still ran, each got a `WP_Error`
|
|
back, and under `WP_DEBUG` each printed a warning *before* the headers, so every
|
|
redirect and cookie after it failed too. The message it printed ("could not
|
|
establish a secure connection") was misleading: nothing was wrong with TLS, the
|
|
request was refused locally.
|
|
|
|
`site/wp-content/mu-plugins/tlig-offline.php` stops the checks at the source
|
|
instead of letting them fail. Keep it; without it the admin fills with warnings.
|
|
|
|
## The menus
|
|
|
|
`site/wp-content/import/` holds the fifteen desktop menu trees lifted from the
|
|
live site — 748 items, structure and labels only, with UberMenu's 149-key
|
|
settings blob reduced to the eight fields the audit shows are ever used. Re-run
|
|
it after changing `menus.json`; it replaces each tree rather than doubling it:
|
|
|
|
docker compose --profile cli run --rm cli \
|
|
wp eval-file wp-content/import/import-menus.php
|
|
|
|
It takes a couple of minutes — `wp_update_nav_menu_item` is not fast — and
|
|
finishes with a count of menus, items and images.
|
|
|
|
`?lang=el` picks the language (WPML is not installed; `inc/demo-languages.php`
|
|
stands in for it). `?open=3` holds the third panel open and `?open=all` drops
|
|
every panel into the flow — the second is the argument in one picture: seven
|
|
panels of seven heights, all from one 328px file.
|
|
|
|
## Regenerating the parchment
|
|
|
|
python3 tools/cut-parchment.py && npm run build
|
|
|
|
It reads `papyrus_submenu_450_cnd.png` from the production tree, so that path
|
|
has to exist. The tile is the master whole — 1200x450, WebP at quality 90 —
|
|
because every narrower cut has to manufacture junctions the artwork does not
|
|
have, and the corners showed it badly. The script's header records what was
|
|
tried; its output prints the four corner junctions (the master's own, so a
|
|
regression check rather than a correction) and how many vertical repeats each
|
|
panel height needs.
|