Main Page: Difference between revisions

From MediaWiki-1.39
Jump to navigation Jump to search
(Formatting courtesy of ChatGPT 4o)
(add templates)
Line 20: Line 20:
* Run <code>php maintenance/update.php --quick</code>.
* Run <code>php maintenance/update.php --quick</code>.
* Visit <code>Special:CustomQuerySettings</code>, set the ROUTINE tag (e.g., <code>ROUTINE_4.110</code>), and confirm <code>Special:ApprovedManuals</code>.
* Visit <code>Special:CustomQuerySettings</code>, set the ROUTINE tag (e.g., <code>ROUTINE_4.110</code>), and confirm <code>Special:ApprovedManuals</code>.
= 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 ==
# Copy ''extensions-mw1359/CustomQueryPage'' to the MW 1.39 box.
# Ensure ''mw_tags'' / ''mw_tag_pages'' have at least one ROUTINE (e.g., import ''ROUTINE_4.110'').
# Visit ''Special:CustomQuerySettings'', confirm the clone form works end-to-end:
#* new ''mw_tags'' row
#* ApprovedManuals listing updated
# 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 `<code>` style and wrap the “update.php” warning into a warning box format (using templates like `{{Note}}` / `{{Warning}}` if our wiki has them).


= Quick Start: ROUTINE Management =
= Quick Start: ROUTINE Management =
Line 118: Line 38:
* Go to: <code>Special:CustomQuerySettings</code>
* Go to: <code>Special:CustomQuerySettings</code>
* Two options:
* Two options:
** **Set Active Tag** — type <code>ROUTINE_4.111</code>, then Save.
** '''Set Active Tag''' — type <code>ROUTINE_4.111</code>, then Save.
** **Clone ROUTINE → New ROUTINE**:
** '''Clone ROUTINE → New ROUTINE''':
*** From: <code>ROUTINE_4.110</code>
*** From: <code>ROUTINE_4.110</code>
*** To: <code>ROUTINE_4.111</code>
*** To: <code>ROUTINE_4.111</code>
Line 142: Line 62:
** Maintenance script that reads JSON
** Maintenance script that reads JSON


Once defined, we’ll wire MediaWiki to import it directly into <code>mw_tags</code> / <code>mw_tag_pages</code>
Once defined, MediaWiki can import directly into <code>mw_tags</code> / <code>mw_tag_pages</code>.
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.}}
{{Warning|Avoid touching the database manually if you want to adopt the JSON route. The importer will safely handle all insertions.}}

Revision as of 20:12, 21 January 2026

MediaWiki has been installed.

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

Getting started

Import CustomQueryPage

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.

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, MediaWiki can import directly into mw_tags / mw_tag_pages.

⚠️

Warning: Avoid touching the database manually if you want to adopt the JSON route. The importer will safely handle all insertions.