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.

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).

Quick Start: ROUTINE Management

1. Seed the ROUTINE in the DB

Before Lisa touches the UI, make sure the database has ROUTINE data.

• Use the import script or manual SQL method.
• Required tables:
  • mw_tags — one row per ROUTINE (e.g., ROUTINE_4.111).
  • mw_tag_pages — one row per approved page.
• If needed, run: php maintenance/update.php --quick

Note: Only run update.php if mw_customquerypage_settings doesn't exist yet.

2. Use the Special Page to Switch or Clone

• Go to: Special:CustomQuerySettings
• Two options:
  • **Set Active Tag** — type ROUTINE_4.111, then Save.
  • **Clone ROUTINE → New ROUTINE**:
    • From: ROUTINE_4.110
    • To: ROUTINE_4.111
    • Submit → this copies rows and updates the active tag.

3. Verify the Result

• Visit: Special:ApprovedManuals
• Confirm the listing shows ROUTINE_4.111
• Lisa can now publish or review the approved manuals.
• No DB access required.

Optional: JSON/API Importer

If you're ready to skip the SQL import:

• Define a JSON payload that includes:
  • page_id, rev_id, deploy_comment, wikitext, etc.
• Build a:
  • REST endpoint, or
  • Action API module, or
  • Maintenance script that reads JSON

Once defined, we’ll wire MediaWiki to import it directly into mw_tags / mw_tag_pages. Lisa keeps working via Special pages — nothing changes for her.

⚠️

Warning: Avoid touching the DB manually if you want to adopt the JSON route. The importer will handle safe insertion.