Main Page

MediaWiki has been installed.

Consult the User's Guide for information on using the wiki software.

Getting started

• Configuration settings list
• MediaWiki FAQ
• MediaWiki release mailing list
• Localise MediaWiki for your language
• Learn how to combat spam on your wiki

Import CustomQueryPage

• CustomQueryPage for mw1359

Installing CustomQueryPage

• Download the bundle: wget https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz
• Extract it into your extensions folder:
  • tar -xzf CustomQueryPage-mw1359.tar.gz -C /srv/mediawiki/extensions
• Edit LocalSettings.php and add wfLoadExtension( 'CustomQueryPage' );
• Run php maintenance/update.php --quick.
• Visit Special:CustomQuerySettings, set the ROUTINE tag (e.g., ROUTINE_4.110), and confirm Special:ApprovedManuals.

Where We Stand

• CustomQueryPage now ships with a simplified clone path:
  • Special:CustomQuerySettings copies the mw_tag_pages rows from ROUTINE_4.110 to ROUTINE_4.111,
  • clones the mw_tags row,
  • and immediately points the listing at the new tag.
  • Success banner fixed; README documents the exact steps (see the new "Quick clone workflow").
• On sh1re/sh0re we never finished the MediaWiki core patch that deletes mw_logging.log_user*.
  • We seeded mw_customquerypage_settings manually instead so Lisa could keep using the UI.

Why mw_tags felt “bypassed” during export

• On dev we inserted the active tag row directly into mw_customquerypage_settings; the clone form still expects

 the regular mw_tags / mw_tag_pages tables.

• • If those tables contain the 4.110 data (they should after your MySQL import), the UI will re-use them.
  • If the environment you tested lacked mw_tags, we need to confirm the table exists and is populated before cloning.
• There’s nothing special to reference in LocalSettings.php; MediaWiki core creates mw_tags / mw_tag_pages

 automatically.

• • Our extension simply reads/writes them via the load balancer.

Next steps if you want to exercise it on mw.eckford.ca

1. Copy extensions-mw1359/CustomQueryPage to the MW 1.39 box.
2. Ensure mw_tags / mw_tag_pages have at least one ROUTINE (e.g., import ROUTINE_4.110).
3. Visit Special:CustomQuerySettings, confirm the clone form works end-to-end:
   • new mw_tags row
   • ApprovedManuals listing updated
4. Once Lisa confirms the UI covers her release work (set tag + clone), we can document the progressive-release workflow on her admin page.

If that 1.39 run reveals that mw_tags truly doesn’t exist in that environment, we’ll know we must create it (or point the extension at your custom release table).

Otherwise, the existing code already ties directly into mw_tags, so maintaining progressive releases is just a matter of Lisa cloning each ROUTINE and then toggling the Approved Manuals view as you outlined.

Yep — here’s that whole block “mw-ified” into clean MediaWiki wikitext (copy/paste ready):

```wiki

Recap (Last Week → Now)

• Finished the MW 1.35.9 CustomQueryPage build with the simplified clone workflow so Lisa can re-tag approved releases inside MediaWiki.
  • Special:CustomQuerySettings now handles both:
    • Set active tag
    • Clone ROUTINE_x.xxx → ROUTINE_y.yyy
• Deployed the same bits to eckfordc (MW 1.39) and sh1re/sh0re.
  • The tables you saw (mw_tags / mw_tag_pages plus mw_customquerypage_settings) match what the extension uses.
• update.php keeps screaming about dropping legacy logging indexes.
  • On dev we skipped the patch and seeded the settings table manually.
  • Production installs just need to run update once so mw_customquerypage_settings exists.

Where we landed

• DB access for humans stays off the table:
  • whoever preps the ROUTINE export runs the existing script/import
  • Lisa only touches the Special pages
• The ROUTINE clone form is working end-to-end:
  • confirmed by the success banner
  • ApprovedManuals shows ROUTINE_4.111
  • the README now documents the exact steps
• No special mention of mw_tags in LocalSettings.php is required.
  • It’s core schema, and the extension already hits it directly.

Next step: JSON/API practice

• Since new ROUTINEs are usually just re-tagging existing pages (rarely brand-new content), the current clone form covers the common path.
• If you want to practice building a JSON/API importer for the rare cases when a ROUTINE bundle comes from outside:
  • define the payload first
  • describe the data coming out of your export process:
    • page_id
    • rev_id
    • deploy_comment
    • wikitext
    • etc.
  • decide whether you want:
    • a REST endpoint
    • an Action API module
    • a CLI maintenance script that reads JSON
  • once we agree on the schema, I can wire the MediaWiki-side code so Lisa (or a bot) can feed in the new release without touching MySQL

```

Next we can also convert the “ROUTINE_x.xxx → ROUTINE_y.yyy” bits into `` style and wrap the “update.php” warning into a warning box format (using templates like `

Note: {{{1}}}

` / `

⚠️

Warning: {{{1}}}

` if our wiki has them).