mediawiki いつの間にか更新されている件
mediawiki は、Wikiアプリの中でも重厚なシステムです。
PHPとRDBMがキーコンポーネントとなっていることと、プロジェクトそのもののCI/CDサイクルとの関係で数年放置すると手が付けられない状況になりがちです。
- FreeBSD-ports/pkg では、2026年1月の段階ですでに 1.39 が obsolete になっていて、途中バージョンを経ることも面倒な感じでした（飛ばすと面倒）
- 1.43 に一気に上げたことで、トラブル対処することになったので記録します。
mediawiki 1.39->1.43
$ php ./maintenance/run.php ./maintenance/update --quick
error のスクリーンショットを撮るのを失念しましたが、SQLで失敗しているのがログに残りました。
Jan 22 13:08:39 pgsql postgres[75614]: [8-3] 2026-01-22 13:08:39.023 JST [75614] STATEMENT: ALTER /* Wikimedia\Rdbms\Database::sourceFile( -usr-local-www-mediawiki-maintenance-postgres-archives-patch-l10n_cache-pk.sql ) */ TABLE l10n_cache
Jan 22 13:08:39 pgsql postgres[75614]: [8-4] ADD PRIMARY KEY (lc_lang, lc_key)
-
li0n_cache へのインデックスを張るのに失敗とかで、そもそもキャッシュだろうから内容はどうでも良さそうでスキーマを残して全消ししました(DELETE)
-
pagelinks migration での DROP 文問題： そもそもINDEXが「存在する」前提で落としてくるのでそこで止まります。⇨ バッチ処理のSQLファイル について
”DROP INDEX foo IF EXISTS＂ に書き換えておきます
patch-pagelinks-drop-pl_title.sql
-- This file is automatically generated using maintenance/generateSchemaChangeSql.php.
-- Source: maintenance/abstractSchemaChanges/patch-pagelinks-drop-pl_title.json
-- Do not modify this file directly.
-- See https://www.mediawiki.org/wiki/Manual:Schema_changes
DROP INDEX pl_namespace; ← ここ
DROP INDEX pl_backlinks_namespace; ← ここ
ALTER TABLE pagelinks
DROP CONSTRAINT pagelinks_pkey;
ALTER TABLE pagelinks
DROP pl_namespace;
ALTER TABLE pagelinks
DROP pl_title;
ALTER TABLE pagelinks
ALTER pl_target_id
SET
NOT NULL;
ALTER TABLE pagelinks
ADD PRIMARY KEY (pl_from, pl_target_id);
このSQL文修正で update も終わるようになります。
1.43->1.44
ここからは特に問題なく、例の update のみです。
1.44->1.45
- UPDATE 時に カテゴリ関係のテーブルがうまく処理できませんでした
- 1.40から順に経由すれば良かったのですが、飛ばしたことできちんと変更・または作られていなかった可能性があります
以下の問題を解決することになります。
- カテゴリをまとめたテーブル catgorylinks に cl_namespace というカラムがないこと
- mediawiki の名前空間に category というキーがあり すでに 14 というIDを振られているのですが、何故かその14という数字がそのまま振られて処理されようとしていた（まさかのマジックナンバーうめこみ？）
テーブルにカラムを足してみた。
wikidb=# SET search_path = mediawiki;
SET
wikidb=# \d categorylinks
Table "mediawiki.categorylinks"
Column | Type | Collation | Nullable | Default
-------------------+--------------------------+-----------+----------+--------------
cl_from | integer | | not null | 0
cl_sortkey | text | | not null | ''::text
cl_timestamp | timestamp with time zone | | not null |
cl_sortkey_prefix | text | | not null | ''::text
cl_type | text | | not null | 'page'::text
cl_collation_id | smallint | | not null | 0
cl_target_id | bigint | | not null |
Indexes:
"categorylinks_pkey" PRIMARY KEY, btree (cl_from, cl_target_id)
"cl_sortkey_id" btree (cl_target_id, cl_type, cl_sortkey, cl_from)
"cl_timestamp_id" btree (cl_target_id, cl_timestamp)
wikidb=#ALTER TABLE categorylinks ADD COLUMN cl_namespace int;
ALTER TABLE
wikidb=# \d categorylinks
Table "mediawiki.categorylinks"
Column | Type | Collation | Nullable | Default
-------------------+--------------------------+-----------+----------+--------------
cl_from | integer | | not null | 0
cl_sortkey | text | | not null | ''::text
cl_timestamp | timestamp with time zone | | not null |
cl_sortkey_prefix | text | | not null | ''::text
cl_type | text | | not null | 'page'::text
cl_collation_id | smallint | | not null | 0
cl_target_id | bigint | | not null |
cl_namespace | integer | | |
Indexes:
"categorylinks_pkey" PRIMARY KEY, btree (cl_from, cl_target_id)
"cl_sortkey_id" btree (cl_target_id, cl_type, cl_sortkey, cl_from)
"cl_timestamp_id" btree (cl_target_id, cl_timestamp)
include/linker/LinksMigration.php で見かけた数字14を書き換えます。
--- ./LinksMigration.php.old 2025-12-10 20:19.45.00000000 +0900
+++ ./LinksMigration.php 2026-01-22 13:57:04.123996000 +0900
@@ -45,7 +45,7 @@ class LinksMigration {
'categorylinks' => [
'config' => -1,
'page_id' => 'cl_from',
- 'ns' => 14,
+ 'ns' => 'cl_namespace',
'title' => 'cl_to',
'target_id' => 'cl_target_id',
'deprecated_configs' => [],
- これは完全に野良パッチです。 gerrit.wikimedia.org から git で拾ったら修正がされているかもしれません（未確認）
まとめ
- 都度の更新（バージョンとばし）を手動で行なっているので、手作り感あふれる構成に慣れてはきましたがレガシーPHPアプリっぽいところの「一発もの」パッチがどんな状況でも動くかっていう話は難しいんだと思います
- あと、Mediawikiのバックエンド、postgresql よりは、mysql/mariadb にした方が苦労はしないと思います。 別なシステムでSQLite3も使ってますが、採用数が少ないとちょっとしたことで苦労します
- 昔は不要だった composer この数年の更新では必須のツールになってますというところが、化石級のPHPレガシーと違うところです。