961cb108ca
The subtree is in place, so everything that used to fetch and patch core at
build time now just copies it.
tools/build.sh copies wordpress/ — no download, no checksum step,
because there is nothing to fetch and nothing to
trust that is not already in the repository
docker/Dockerfile COPY wordpress/ instead of curl + sha256 + patch;
the build args and the `patch` package are gone
docker-compose.yml no WP_VERSION / WP_URL / WP_SHA256 to keep in step
tools/update-wordpress.sh is rewritten around what the subtree makes
possible. It imports the pristine release onto sirius-press/wordpress-upstream
and then `git subtree merge`s that branch, which three-way merges upstream
against the fork's own commit. A patch either applies with fuzz and hopes or
fails and leaves you re-deriving the change by hand; a merge conflict is
resolved once, in the file, and the next release merges against the
resolution.
patches/ survives as documentation rather than mechanism, and is now
generated: tools/refresh-patches.sh diffs the subtree against the pristine
import and rewrites the directory, with --check for CI. It answers the
question anyone auditing a fork asks first — what exactly did you change
inside WordPress? — in a minute, which `git log wordpress/` cannot, because
that log is mostly upstream imports. Generated documentation stays true; a
hand-maintained record of a core diff drifts, and a stale one is worse than
none because people trust it.
One test change worth noting: the syntax sweep no longer walks all of
wordpress/. It lints the fork's own PHP plus every core file patches/ says
the fork touches, which keeps the suite at seven seconds instead of a minute
while still covering the only core file that can break.
37 lines
1.6 KiB
Text
37 lines
1.6 KiB
Text
# Sirius Press — copy to .env and edit before the first `docker compose up`.
|
|
#
|
|
# install.sh writes this file for you with generated passwords. Doing it by
|
|
# hand is fine too; just do not leave the passwords below as they are.
|
|
|
|
# --- database ---------------------------------------------------------------
|
|
# These are read once, when MariaDB initialises its data directory. Changing
|
|
# them later does not change the database — it just stops the app connecting.
|
|
DB_NAME=wordpress
|
|
DB_USER=wordpress
|
|
DB_PASSWORD=change-me
|
|
DB_ROOT_PASSWORD=change-me-too
|
|
|
|
# --- the site ---------------------------------------------------------------
|
|
# The URL visitors reach this instance on. Set it once the name's `p` or `ip`
|
|
# record points here; leaving it blank lets WordPress guess from the request,
|
|
# which is fine for a first run on an IP address.
|
|
SITE_URL=
|
|
|
|
# Port nginx publishes on the host. Put 8080 here if something else already
|
|
# owns 80 and you are running a reverse proxy in front.
|
|
HTTP_PORT=80
|
|
|
|
WP_DEBUG=false
|
|
|
|
# --- the publishing key ------------------------------------------------------
|
|
# What the site's recovery phrase is encrypted with at rest. Generated on first
|
|
# start if left blank, and then kept in the config volume.
|
|
#
|
|
# Worth setting explicitly and keeping a copy somewhere safe: if this value is
|
|
# lost, the stored phrase cannot be decrypted and has to be entered again.
|
|
# It is not the phrase itself and is useless without the database.
|
|
SIRIUS_PRESS_KEY=
|
|
|
|
# WordPress itself is vendored in the repository (wordpress/) and baked into
|
|
# the image, so there is no version or checksum to configure here. See
|
|
# docs/upstream-merges.md for how a new upstream release gets in.
|