update-page with mode='append' writes the new content after everything already on the page, including the category links most articles end with. The appended section lands below the categories, so the page source stops following the convention that categories close an article.
Reproduction
Against a local MediaWiki 1.43.6. Page before:
A short article about widgets.
== History ==
Widgets were invented in 1899.
[[Category:Widgets]]
[[Category:Inventions]]
Append with source "\n\n== Manufacturing ==\n\nWidgets are pressed from sheet metal.\n". Page after:
A short article about widgets.
== History ==
Widgets were invented in 1899.
[[Category:Widgets]]
[[Category:Inventions]]
== Manufacturing ==
Widgets are pressed from sheet metal.
The categories now sit in the middle of the source, and each further append leaves them further from the end.
What this does and does not break
The rendered page is unaffected — MediaWiki hoists category links out of the flow into the footer wherever they appear in the source. The cost lands on the wikitext: an editor opening the source finds the article's closing block stranded mid-page, and repeated appends widen the gap.
Not introduced by #533
buildEditParams maps mode='append' to the API's appendtext and mode='prepend' to prependtext (src/tools/update-page.ts:69-70). Before #533 the same job went through section='new'. MediaWiki places both identically: section=new§iontitle=Manufacturing against an identical seed page produced byte-identical wikitext to the append above, categories and all. The placement is MediaWiki's, and neither path ever avoided it.
What changed is exposure. #533 made append the documented route to a new section: the tool description now says "adding a new section means appending a source that begins with a heading" (src/tools/update-page.ts:86), the source parameter documents the leading-newline form (src/tools/update-page.ts:28), and a call still sending section='new' is redirected to it (src/tools/update-page.ts:20-21). The server now steers callers into this placement.
mode='prepend' has the mirror problem
Same wiki, page before:
{{Short description|A mechanical part}}
{{About|the machine part|the band|Widget (band)}}
{{Infobox device
| name = Widget
| type = Mechanical
}}
'''Widget''' is a mechanical part.Prepend with "A new lead sentence added by prepend.\n\n". Page after:
A new lead sentence added by prepend.
{{Short description|A mechanical part}}
{{About|the machine part|the band|Widget (band)}}
{{Infobox device
| name = Widget
| type = Mechanical
}}
'''Widget''' is a mechanical part.Prose lands above the short description, hatnote and infobox, which by convention open the article. This is the lesser case — nothing steers callers to prepend — but a fix should consider both ends.
Options
Document the limitation. State in the update-page description that appended content lands after any trailing categories, and that a caller who cares should splice the text itself. Costs nothing and leaves the caller to notice.
Place appended content above a trailing category block. This needs the page tail, which is what appendtext exists to avoid: the server would have to read the page and write back with text instead of appendtext, giving up the constant-size request that makes append worth using on a large page. A section-scoped read bounds that cost — action=parse§ion=N&prop=wikitext returns the trailing category lines along with the section — but something still has to identify which section holds them.
The tail is also not only categories. Language links, {{DEFAULTSORT:}}, stub templates and navboxes sit in the same closing block by convention, so a rule recognising only [[Category:...]] would still misplace content on many articles.
AI-authored — Claude Code, Opus 5 1M (ultracode); noticed while reviewing PR #533 and written up at @alistair3149's request; not human-reviewed; every file:line and behavioural claim above was verified against master at 8fa0cff, with the MediaWiki behaviour reproduced against a local MediaWiki 1.43.6 rather than cited.
update-pagewithmode='append'writes the new content after everything already on the page, including the category links most articles end with. The appended section lands below the categories, so the page source stops following the convention that categories close an article.Reproduction
Against a local MediaWiki 1.43.6. Page before:
Append with source
"\n\n== Manufacturing ==\n\nWidgets are pressed from sheet metal.\n". Page after:The categories now sit in the middle of the source, and each further append leaves them further from the end.
What this does and does not break
The rendered page is unaffected — MediaWiki hoists category links out of the flow into the footer wherever they appear in the source. The cost lands on the wikitext: an editor opening the source finds the article's closing block stranded mid-page, and repeated appends widen the gap.
Not introduced by #533
buildEditParamsmapsmode='append'to the API'sappendtextandmode='prepend'toprependtext(src/tools/update-page.ts:69-70). Before #533 the same job went throughsection='new'. MediaWiki places both identically:section=new§iontitle=Manufacturingagainst an identical seed page produced byte-identical wikitext to the append above, categories and all. The placement is MediaWiki's, and neither path ever avoided it.What changed is exposure. #533 made append the documented route to a new section: the tool description now says "adding a new section means appending a source that begins with a heading" (src/tools/update-page.ts:86), the
sourceparameter documents the leading-newline form (src/tools/update-page.ts:28), and a call still sendingsection='new'is redirected to it (src/tools/update-page.ts:20-21). The server now steers callers into this placement.mode='prepend'has the mirror problemSame wiki, page before:
{{Short description|A mechanical part}} {{About|the machine part|the band|Widget (band)}} {{Infobox device | name = Widget | type = Mechanical }} '''Widget''' is a mechanical part.Prepend with
"A new lead sentence added by prepend.\n\n". Page after:A new lead sentence added by prepend. {{Short description|A mechanical part}} {{About|the machine part|the band|Widget (band)}} {{Infobox device | name = Widget | type = Mechanical }} '''Widget''' is a mechanical part.Prose lands above the short description, hatnote and infobox, which by convention open the article. This is the lesser case — nothing steers callers to prepend — but a fix should consider both ends.
Options
Document the limitation. State in the
update-pagedescription that appended content lands after any trailing categories, and that a caller who cares should splice the text itself. Costs nothing and leaves the caller to notice.Place appended content above a trailing category block. This needs the page tail, which is what
appendtextexists to avoid: the server would have to read the page and write back withtextinstead ofappendtext, giving up the constant-size request that makes append worth using on a large page. A section-scoped read bounds that cost —action=parse§ion=N&prop=wikitextreturns the trailing category lines along with the section — but something still has to identify which section holds them.The tail is also not only categories. Language links,
{{DEFAULTSORT:}}, stub templates and navboxes sit in the same closing block by convention, so a rule recognising only[[Category:...]]would still misplace content on many articles.