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.