Deployed to a real VPS for the first time. The stack came up, the patched
wizard served, the plugins activated and the 40-check auth suite passed over
the public internet — and then every single export failed:
cURL error 28: Failed to connect to <public ip> port 8081 after 10001 ms
Not a bug in the export. A container cannot reach the host's own published
port on most Docker hosts; there is simply no route back in. The exporter
renders each page by asking the site for it over HTTP, so the one thing it
depends on is the one thing a container cannot do. This would have hit every
user of the documented install path on their first publish, and the error
says nothing about the cause.
SIRIUS_PRESS_LOOPBACK_URL gives the exporter a second address — in the
bundled stack, the nginx service on the compose network — while the request
still carries the site's real Host header. That matters twice: WordPress
renders exactly the page a visitor gets rather than redirecting to a
canonical URL the container cannot follow, and the internal hostname never
appears in the exported HTML. Verified on the VPS: the page builds, the
content is right, no absolute self-links, no `//web/` leaking out.
Also documents the question underneath it — what WP_HOME should be when the
site's public address is a BCNR name. Not the name: whatever the server is
actually reachable at. The exported links are document-relative, so they work
under the name regardless.
The docs said nobody had clicked the buttons in a browser. Somebody has now,
and it cost two bugs, so testing.md gains a section saying to do it after
touching the auth assets — the HTTP suites cannot see that class of failure.
Also sharpens the honest gap: the Docker stack has not been run anywhere, not
just 'not on a clean Ubuntu box'.
The first real upstream release since the subtree landed, and the point of
the whole arrangement. It merged cleanly: 7.1.2 changes about.php,
template.php and version.php, none of which this fork touches, so the patched
installer came through byte-identical and there was nothing to resolve.
Getting there needed two fixes to the tool, both of which only a real release
could have found — the earlier same-version run was a no-op that exercised
none of this.
**The prefix was an absolute path.** `${here#"$repo"/}` assumes the two
strings share a spelling, and on Windows they do not: --show-toplevel answers
"D:/Dev/…" while $PWD is "/d/Dev/…", so the subtraction left the path
untouched and `git subtree merge --prefix` was handed something absolute. The
same bug was fixed in refresh-patches.sh a few commits ago; this is the other
copy of it. Both now ask git via `rev-parse --show-prefix`.
**git-subtree refuses to run in a dirty repository** — any modification
anywhere, not just under the subtree. In a monorepo shared with other work
that is the normal state, so the tool was unusable exactly where it lives.
The merge now happens in a scratch worktree, which is clean by construction,
and comes back as one ordinary merge commit that touches only wordpress/ and
so does not care what else is modified.
Also: a failed run no longer refuses to retry. The import onto the upstream
branch is idempotent now, and the failure message distinguishes "upstream and
the fork changed the same lines" from "the merge could not start", instead of
blaming a conflict for both.
Two bugs, both invisible to every test written so far, because those tests
post to wp-login.php over HTTP and a browser does not.
**The submit was blocked.** WordPress marks its username and password inputs
`required`. The wallet path deliberately leaves both empty — the signature is
the credential — so `form.requestSubmit()` ran constraint validation, refused,
and pointed a "Please fill out this field" bubble at an input the visitor is
not supposed to touch, with a valid signature already sitting in the form.
Nothing happened and nothing explained why. The wallet submit now turns
validation off for that submission only; password sign-in keeps it.
**`hidden` did not hide.** The attribute works through a UA rule that any
author rule with a `display` outranks, and WordPress ships exactly such a
rule — `.wp-core-ui .button { display: inline-block }`. So the two buttons
this plugin ships hidden were on screen regardless. That inverted the whole
progressive-enhancement story: "Use the browser wallet" was offered on every
browser including those without one, and a visitor with JavaScript disabled
would have been shown a sign-in button that could never do anything, instead
of the paste-a-signature box that works without scripts.
Found by opening the login page in a browser and clicking the button, which
is the one thing 178 passing checks had not done.
Cloning the forge repo on Windows and running the suite there turned up two
things a checkout inside the monorepo could never show, because this working
copy has core.autocrlf=false.
Git on Windows defaults to autocrlf=true, so a fresh clone gets CRLF. For
most files that is cosmetic. For shell scripts it is not: install.sh copied
from such a clone onto a server fails with `bash: \r: command not found`,
which tells the person almost nothing about what is wrong. And a
CRLF-rewritten .patch file is no longer the bytes `patch` was given.
.gitattributes now pins eol=lf for the scripts, the container inputs and the
source, and marks *.patch as binary so nothing rewrites it at all.
tools/refresh-patches.sh --check also compares with --strip-trailing-cr, so
a clone made before this landed reports honestly instead of claiming the
patch record has drifted when it has not. A check that cries wolf is a check
somebody switches off.
install.sh was still sourcing tools/wordpress.lock and copying WP_VERSION,
WP_URL and WP_SHA256 into the generated .env. Nothing reads them any more —
core is vendored and baked into the image — and a config file full of
settings that do nothing invites someone to edit one and wonder why it had
no effect.
Someone who clones from code.silentmode.st and starts working will otherwise
find out the hard way: push-split.sh force-pushes master, so their branch
does not survive the next mirror push. Better to say it on the page that
tells people how to take an upstream release, since that is exactly the work
that would be lost.
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.
The one change Sirius Press has to make inside WordPress itself. The
installer runs before plugins load and refuses to finish without an email
address, so a site with no mail identity cannot be installed at all.
- "Your Email" becomes "Your wallet address", and it is optional. The
installer has nothing to verify a signature against yet — the site does
not exist — so an address typed here is taken on trust and can be
replaced from the profile screen afterwards, where it CAN be proved.
- The two is_email() gates become one address check.
- wp_install() still receives an email string, because its signature and
everything downstream expects one. It gets a permanently unroutable
.invalid placeholder.
Kept as a commit on top of the vendored subtree rather than applied at build
time, so `git subtree merge` three-way merges it against each upstream
release and says so when a hunk stops fitting. patches/ keeps the same diff
in readable form for anyone auditing what this fork changes in core.
75 lines, one file. Everything else Sirius Press does is a plugin.
Running the fork against a live WordPress found a real hole in registration,
and it is the kind that only shows up when you actually try it.
ECDSA public-key recovery always succeeds. Given any well-formed signature
and any digest it returns a key — just not the signer's, unless the digest is
the one that was signed. The auth flow leaned on that as if a wrong message
would fail. It does not; it quietly yields a stranger's address.
At sign-in this was harmless, because the wrong address matches no account
and the attempt fails. Registration and wallet-linking were another matter:
both took the recovered address and bound it to an account, so a signature
over slightly different text — a challenge copied without its blank line, a
wallet that rewrote the text, a login signature replayed at the registration
form — created an account keyed to an address nobody could sign for. The
person would see "success" and discover the truth the next time they tried to
get in. Wallet-linking was worse still: it would move an existing account onto
a dead address and lock its owner out of their own site.
Both paths now require the address the signer claims and compare it to the
recovered one, which is what verification actually means. Sign-in accepts the
claim when the page sends it and uses it to turn "no account uses that wallet"
into the more useful "that signature is not over the text we asked for".
Also from running it:
URL rewriting mangled every link on a site whose URL carries a port. The
protocol-relative pass matched inside absolute URLs and gave each one a second
scheme, and matching the host without its port left the port stranded as
`//host:8760:8760/`. Local and staging installs would have exported a site of
broken links.
Plain permalinks silently collapse an entire site onto one exported file,
because every post's URL is `/?p=N` and its path is `/`. The queue looks
healthy the whole time. The Publishing screen now says so.
Translations loaded on `plugins_loaded`, which WordPress 6.7 warns about on
every request — the kind of noise that trains people to stop reading logs.
And one deletion: an `is_email()` filter written on the assumption that
WordPress rejects `.invalid` addresses. It does not — `is_email()` validates
syntax, not whether a domain could exist — so the filter never fired. A filter
that appears to relax a rule but does not is worse than no filter, because
someone later reasons from it. The documentation made the same claim and has
been corrected.
Verification added rather than asserted: tests/live.mjs drives a real instance
over HTTP (40 checks), and tests/mock-gateway.mjs answers uploads with the
signature check transcribed from the gateway's own source, so the publishing
path can be exercised without a registered name.
WordPress makes two assumptions this project cannot accept: that identity
comes from an email address, and that a site lives at one server. Both are
things somebody else can take away — a mailbox is rented from a provider who
can close it or be compelled to open it, and a server is one seizure from
being gone.
Sirius Press replaces the first and hedges the second.
Signing in means signing a challenge with the key that controls a CashAddress.
The address is recovered from the signature, so nothing is typed but the
signature itself, and the result is an ordinary WordPress session cookie —
roles, capabilities, nonces and the REST API never learn the login was
different. Three ways to produce one: a wallet the browser already exposes, a
phrase used once in the page and wiped, or a signature pasted in from any
BIP-137 wallet, which needs no JavaScript and lets the key stay on a machine
that never touches the web.
There is no password reset, and the recovery page says so plainly rather than
offering a form that cannot work. A reset mechanism is by construction a way
to take an account from its owner, and it is always easier to attack than the
cryptography it bypasses.
Publishing a post also exports it as static HTML to the name's storage on Sia,
signed by the key that owns the name, so the site keeps answering when the
server does not.
Email as a feature is untouched. wp_mail() still works, SMTP still sends, and
contact forms still deliver to addresses real people typed. Only mail to the
site's own unroutable placeholder addresses is diverted to an in-app inbox.
The objection was to email as identity, not to email.
Core is pinned and patched rather than vendored. WordPress 7.1.1 is 149 MB and
5,008 files; the fork's entire core diff is 75 lines in wp-admin/install.php.
Carrying the former to express the latter would bury the patch where nobody
reviews it and make every clone of the monorepo pay for it. Upstream releases
still merge through tools/update-wordpress.sh, which reapplies the series and
says exactly which hunk needs a human.
The cryptography is implemented twice — PHP on the server, JavaScript in the
page — because the server must verify and the browser must sign. Both are
pinned against libauth, the library the Sirius portal wallet and the BNS
gateway already use, so a disagreement of one byte fails the test suite rather
than presenting as a rejected login at three in the morning.
132 checks, no framework, about a second.
