Repository navigation
chore: repair the settings load order WikvenSiteUrl needs - #624
Merged
Merged
Conversation
SiteConfig::lint() reads a site's WikvenSiteUrl through SiteUrl, and ran twenty lines above the require_once that loads it, so any site that actually set the value fataled at LocalSettings time. CI never saw it: the path is behind `$siteUrl !== ''` and no test site set one, so the setting was broken on its only non-default path with every check green. docs/.wikven.yaml now names the documentation site's own URL, which puts that path in every bake CI runs and fills $wgCanonicalServer besides. Deliberately not a fix: the defect was introduced by #621 and #621 has not been released, so nobody running 1.0.0 ever had it. Typed as a chore so release-please keeps it out of 1.1.0's notes, where a "Bugfixes" line would describe a bug no released version carried. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn
lens0021
enabled auto-merge (squash)
September 2, 2026 18:24
This was referenced Sep 3, 2026
lens0021
added a commit
that referenced
this pull request
Sep 3, 2026
Follows #621, #624, #623 and #630. Three files, no code. ## What it does A static export has no way to put a head tag that is about the site rather than a page, and proving control of a site to a search engine is exactly that. WikiSEO is the widely used extension for it. The key is a public token — it grants nothing but the claim, and the search engine publishes it back to anyone who asks for the site's tag. **The pin is REL1_46's head, not the `v2.7.0` tag.** The tag is mis-stamped: | ref | manifest version | requires | | --- | --- | --- | | `v2.7.0` tag | **2.6.6** | MediaWiki >= 1.39 | | `REL1_46` branch | 2.7.0 | MediaWiki >= 1.42 | | `master` | 2.7.0 | MediaWiki >= 1.42 | The tag's name promises code it does not hold. `REL1_46` carries the same code as master and follows the release branch of the image's MediaWiki, which is how Translate, UniversalLanguageSelector and MobileFrontend are already pinned. `updatecli/updatecli.d/mediawiki-extensions.yaml` gains a source and target so the pin does not go stale. ## Why it needed #630 first WikiSEO does not only emit the verification tag. Diffing the head against the same fixture without it: ``` + <meta property="og:title" content="…"> + <meta property="og:url" content="…"> + <meta property="og:type" content="website"> + <meta property="article:modified_time" content="…"> + <meta property="article:published_time" content="…"> ``` `article:modified_time` and `article:published_time` come out as the frozen `page_touched`, so they are stable across bakes — a fixed value rather than a drifting one, same as the sitemap's omitted modification time. `og:url` was the blocker, and it was ours, not WikiSEO's: ```php $url = $this->outputPage->getTitle()->getFullURL(); // this build answered "./index.html" $url = WikiSEO::protocolizeUrl( $url, ... ); // -> "http:index.html" ``` There is no switch that turns the OpenGraph output off — `MetadataGenerators` **replaces** the built-in list when non-empty, but `Twitter extends OpenGraph`, so the only list that drops `og:url` is `[SchemaOrg]`, which throws away the useful tags with it. #630 fixed the cause instead. ## Verification Built with the released binary against a fixture that fetches the extension for real: - the verification tag lands on every page; - **`og:url` is an absolute URL on all 219 pages that carry one**, and a skin preview copy names the page it duplicates rather than itself; - WikiSEO appears on the generated Licenses page by itself (GPL-2.0-or-later), with no extra work; - two bakes of one source are byte-identical, so nothing here breaks #411. The smoke bake now fails on a non-absolute `og:url`. Every check was green while the preview shipped the broken one, which is the same gap that let a fataling setting through in #621 — and this assertion is the end-to-end proof of #630, which could not carry it: without WikiSEO installed no page has an `og:url` to assert on. ## After this merges Register the site in Google Search Console and submit `sitemap.xml`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn Co-authored-by: Claude <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out of #623, which now stacks on this.
The defect
SiteConfig::lint()reads a site'sWikvenSiteUrlthroughSiteUrl, and ran twenty lines above therequire_oncethat loads it. Any site that actually set the value fataled atLocalSettingstime:CI never saw it. The path is behind
$siteUrl !== ''and no test site set one, so the only setting #621 added was broken on its only non-default path with all 26 checks green.docs/.wikven.yamlnow names the documentation site's own URL. That is what stops this recurring: the path is in every bake CI runs, and it fills$wgCanonicalServerbesides, so an absolute URL MediaWiki or an extension builds names the right host instead oflocalhost.Why this is a chore and not a fix
The defect was introduced by #621, and #621 has not been released — it is sitting in the pending 1.1.0 (#618). Nobody running 1.0.0 ever had this bug.
.release-please-config.jsonshowsfixunder a visible "Bugfixes" section, so typing this as a fix would put a line in 1.1.0's notes describing a defect no released version carried.choreis hidden, which is the right answer for repairing unreleased work. The commit message says the same, so the reasoning survives the squash.Checked locally
Built with the released binary over this working tree:
WikvenSiteUrl— reproduced the fatal, then confirmed the build completes and writes its pages.$wgCanonicalServercomes out ashttps://chaotic-ground.github.iowhereWikvenSiteUrlishttps://chaotic-ground.github.io/wikven/— the host half, path left to wikven.phpcs(60 files),mago format --check,mago lint,yamllintall clean.phpcsnow runs here, which it did not for the three lint failures earlier in this stack:phpcsstandards/phpcsextrawas installed but its sniff path was not registered, so everyUniversal.*reference errored out. Registeringinstalled_pathsfixed it.🤖 Generated with Claude Code
https://claude.ai/code/session_019ghEx26MRm9V5CnCLrdUQn
Generated by Claude Code