The publishing docs tell operators to run `wp sirius export` and `wp sirius status`, and the export plugin registers both — but a stack built from docker/ had no wp-cli at all, so those pages described a tool nobody running the bundled image actually had. Pinned to a version and checked against its SHA-256 rather than piped from a URL. It is the only thing the build downloads, which is exactly why it is the only thing that has to prove what it is.
6.8 KiB
6.8 KiB
Changelog
0.1.0 — unreleased
First cut. Sirius Press installs, signs people in with a wallet, and publishes static copies of its pages to a BCNR name.
Accounts
- Sign in by signing a challenge with a Bitcoin Cash key. The address is recovered from the signature, so nothing has to be typed but the signature itself.
- Three ways to produce one: a wallet the browser already exposes (Theseus), a recovery phrase used once in the page and wiped, or a signature pasted in from any BIP-137 wallet. The last works with JavaScript disabled.
- One-step registration — the signature is the confirmation, so there is no email round trip and no pending state.
- Password sign-in stays on by default and can be turned off once every account has a wallet. The screen that turns it off refuses to do so while it would lock out the person asking.
- No password reset, and the "lost password" page explains why rather than pretending otherwise.
/sirius-press/v1/confirmlets any plugin demand a fresh signature before something irreversible.
Publishing
- Publishing a post exports it, the home page and its archives to the name's storage on Sia, signed BNS-SITE1.
- Two signing modes: manual, where the browser signs and the server stores nothing, and automatic, where an encrypted phrase lets cron publish alone. Manual is the default.
- Unchanged pages are hashed and skipped rather than re-uploaded.
- Unpublishing a post removes its file from the mirror.
wp sirius exportandwp sirius statusfor the command line.
Compatibility
- Every account carries an unroutable
.invalidplaceholderuser_email, so the thousands of ecosystem reads of that field keep returning a string. - Mail to those placeholders is captured into an in-app inbox. Mail to real addresses is passed through untouched, so SMTP works normally.
- Shims for WooCommerce, Contact Form 7 and core's admin-email machinery.
Core
- One change, 75 lines, in
wp-admin/install.php: the setup wizard asks for a wallet address instead of an email address, and the address is optional. - WordPress is vendored at
wordpress/as a git subtree, already patched. Upstream releases arrive throughgit subtree mergeagainstsirius-press/wordpress-upstream, a branch of pristine imports, so a release that touches code near the fork's change is three-way merged rather than re-derived by hand.tools/update-wordpress.sh <version>runs the whole thing. patches/is now generated from the tree bytools/refresh-patches.sh(with--checkfor CI) and exists to answer "what does this fork change in core?" without reading a 3,800-file log. It is documentation, not the build mechanism.
Packaging
install.shfor a fresh Ubuntu VPS; Docker stack with MariaDB, PHP-FPM and nginx. Core lives in the image, so rebuilding is a real upgrade.tools/build.sh --zipfor shared hosting.tools/update-wordpress.shto move onto a new upstream release.tools/publish-release.shto ship to both mirrors.
Fixed while testing against a live instance
- Registration and wallet-linking accepted a signature over the wrong text. Public-key recovery always succeeds — it returns a different key rather than failing — so a mismatched signature silently bound an account to an address nobody could sign for. Both paths now require the claimed address and compare it to the recovered one. Sign-in was never exposed to this, because a wrong address simply matches no account.
- URL rewriting mangled links on any site whose URL carries a port: the protocol-relative pass matched inside absolute URLs and doubled the scheme, and a host-only match left the port stranded. Both covered by tests now.
- Translations loaded on
plugins_loaded, which WordPress 6.7+ warns about on every request. Moved toinit. - The Publishing screen now refuses to be quiet about plain permalinks, which would collapse an entire site onto one exported file.
- Removed an
is_email()filter that rested on a false premise: WordPress validates syntax, not whether a domain can exist, so.invalidaddresses already pass and the filter never fired. The documentation said otherwise and has been corrected.
Fixed after opening it in a browser
- Wallet sign-in did not work in a browser at all. WordPress marks its
username and password inputs
required; the wallet path leaves both empty on purpose, so the form refused to submit a valid signature and pointed a validation bubble at a field the visitor is not meant to fill in. - The
hiddenattribute was being overridden by WordPress's own button styles, so controls this plugin ships hidden were visible regardless — offering a browser wallet that is not there, and showing a JavaScript-only button to visitors without JavaScript.
WordPress 7.1.2
Taken through tools/update-wordpress.sh and merged cleanly; upstream did not
touch the one file this fork patches. Two bugs in the update tool surfaced
doing it: a Windows path-subtraction that produced an absolute --prefix, and
git-subtree's refusal to run in a repository with any uncommitted file. The
merge now runs in a scratch worktree and a failed run can be retried.
Fixed after deploying to a real VPS
- Static export could never work in the bundled Docker stack. The exporter
fetches each page over HTTP, and a container cannot reach the host's own
published port on most Docker hosts — every export died with a cURL
timeout while the site itself was plainly up.
SIRIUS_PRESS_LOOPBACK_URLnow points the exporter at the nginx service on the compose network, with the site's realHostheader so the rendered page is unchanged and the internal address never reaches the output. The stack sets it by default.
Fixed while building a real site on it
- The image had no wp-cli.
docs/publishing.mddocumentswp sirius exportandwp sirius status, and the export plugin registers both — on a stack built fromdocker/, neither existed. wp-cli is now in the image, pinned to a version and checked against its SHA-256; it is the only thing the build fetches, which is why it is the only thing that has to prove what it is.
Known gaps
- No byte has yet been written to the real gateway under a registered name.
The signing is verified against a transcription of the gateway's own
verifier, and the live instance reads the correct on-chain owner from
navigate.st, but the upload itself is untested. - Manual-mode publishing (browser signs and uploads) has not been clicked through; the server-signing path has.
- Publishing is verified against a transcription of the gateway's own
verification logic, not against
navigate.stwith a registered name. - Seven of the ten rows in the plugin compatibility matrix are reasoned rather than tested; the three named in the ship criteria were installed and run.