Main Page: Difference between revisions
Jump to navigation
Jump to search
(Undo revision 16 by 198.16.202.243 (talk)) Tag: Undo |
(Add Where we stand) |
||
| 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>. | ||
Absolutely — here it is converted into **clean MediaWiki wikitext** (copy/paste ready): | |||
```wiki | |||
= 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. | |||
``` | |||
Revision as of 13:40, 21 January 2026
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
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.phpand addwfLoadExtension( 'CustomQueryPage' ); - Run
php maintenance/update.php --quick. - Visit
Special:CustomQuerySettings, set the ROUTINE tag (e.g.,ROUTINE_4.110), and confirmSpecial:ApprovedManuals.
Absolutely — here it is converted into **clean MediaWiki wikitext** (copy/paste ready):
```wiki
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. ```