Main Page: Difference between revisions

From MediaWiki-1.39
Jump to navigation Jump to search
No edit summary
(That’s the entire page, stitched together and formatted for the client. No guessing, no duplicates—just one cohesive document you can hand over today.)
Line 1: Line 1:
<strong>MediaWiki has been installed.</strong>
  <strong>MediaWiki has been installed.</strong>


Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.
  Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User’s Guide] for information on
  using the wiki software.


== Getting started ==
  == Getting started ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
  * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
  * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
  * [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
  list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]
  * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for
  your language]
  * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your
  wiki]


== Import CustomQueryPage ==
  == Import CustomQueryPage ==
* [https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz CustomQueryPage for mw1359]
  * [https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz CustomQueryPage for mw1359]


=== Installing CustomQueryPage ===
  === Installing CustomQueryPage ===
* Download the bundle: <code>wget https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz</code>
  # Download the bundle: <code>wget https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz</code>
* Extract it into your extensions folder:
  # Extract into your extensions folder: <code>tar -xzf CustomQueryPage-mw1359.tar.gz -C /srv/mediawiki/
** <code>tar -xzf CustomQueryPage-mw1359.tar.gz -C /srv/mediawiki/extensions</code>
  extensions</code>
* Edit <code>LocalSettings.php</code> and add <code>wfLoadExtension( 'CustomQueryPage' );</code>
  # Edit <code>LocalSettings.php</code> and add <code>wfLoadExtension( 'CustomQueryPage' );</code>
* 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 includes the simplified clone path:
  ** ''Special:CustomQuerySettings'' copies the ''mw_tag_pages'' rows from <code>ROUTINE_4.110</code> to
  <code>ROUTINE_4.111</code>, clones the ''mw_tags'' row, and immediately points the listing at the new tag. The
  success banner is fixed and README documents the “Quick clone workflow.”
  * On sh1re/sh0re we still need to finish the MediaWiki patch that drops <code>mw_logging.log_user*</code>, so we
  seeded <code>mw_customquerypage_settings</code> manually to keep the UI working.


= Where We Stand =
  == Why mw_tags felt “bypassed” ==
  * On dev we inserted the active tag row directly into <code>mw_customquerypage_settings</code>; the clone form
  still expects the standard <code>mw_tags</code>/<code>mw_tag_pages</code> tables.
  * If those tables contain the 4.110 data (they should after your import), the UI reuses them immediately.
  * Nothing special is required in <code>LocalSettings.php</code>; our extension simply uses the core tables via
  the MediaWiki load balancer.


* '''CustomQueryPage''' now ships with a simplified clone path:
  == Next steps on mw.eckfordc (MW 1.39) ==
** ''Special:CustomQuerySettings'' copies the ''mw_tag_pages'' rows from ''ROUTINE_4.110'' to ''ROUTINE_4.111'',
  # Copy <code>extensions-mw1359/CustomQueryPage</code> onto the host.
** clones the ''mw_tags'' row,
  # Ensure <code>mw_tags</code>/<code>mw_tag_pages</code> include at least one ROUTINE (for example, import
** and immediately points the listing at the new tag.
  <code>ROUTINE_4.110</code>).
** Success banner fixed; README documents the exact steps (see the new ''"Quick clone workflow"'').
  # Visit <code>Special:CustomQuerySettings</code>, run the clone form end to end, and confirm the changed
* On sh1re/sh0re we never finished the MediaWiki core patch that deletes ''mw_logging.log_user*''.
  listing.
** We seeded ''mw_customquerypage_settings'' manually instead so Lisa could keep using the UI.
  # Once Lisa confirms the UI workflow, document the promotion steps on her admin page.


== Why mw_tags felt “bypassed” during export ==
  = Recap (Last Week → Now) =
  * Finished the MW 1.35.9 build with the simplified clone workflow (Set active tag + Clone ROUTINE_x.xxx →
  ROUTINE_y.yyy).
  * Deployed the same code to eckfordc (1.39) and sh1re/sh0re (1.35.9); all installs now have ''mw_tags'',
  ''mw_tag_pages'', and <code>mw_customquerypage_settings</code>.
  * On sh1re/sh0re, <code>update.php</code> still balks at dropping <code>mw_logging.log_user*</code>; we seeded
  the settings row manually until the patch runs cleanly.


* On dev we inserted the active tag row directly into ''mw_customquerypage_settings''; the clone form still expects
  == Where we landed ==
   the regular ''mw_tags'' / ''mw_tag_pages'' tables.
   * No human DB access – the release script populates ``mw_tags``/``mw_tag_pages``, and Lisa works entirely
** If those tables contain the ''4.110'' data (they should after your MySQL import), the UI will re-use them.
  through the Special pages.
** If the environment you tested lacked ''mw_tags'', we need to confirm the table exists and is populated before cloning.
  * ''Special:CustomQuerySettings'' + ''Special:ApprovedManuals'' both confirmed for <code>ROUTINE_4.111</code>;
* There’s nothing special to reference in ''LocalSettings.php''; MediaWiki core creates ''mw_tags'' / ''mw_tag_pages''
  README documents the “Quick clone workflow.”
   automatically.
  * Nothing extra is required in <code>LocalSettings.php</code>; the extension uses the standard tables via
** Our extension simply reads/writes them via the load balancer.
   MediaWiki services.


== Next steps if you want to exercise it on mw.eckford.ca ==
  == Next step: JSON/API practice ==
  * Since most releases are re-tags, the clone form covers the common path.
  * For the rare “new” ROUTINE payload, define a JSON schema (page_id, rev_id, deployment comment, wikitext, etc.)
  and decide whether you want a REST endpoint, an Action API module, or a CLI importer so everything stays inside
  MediaWiki.


# Copy ''extensions-mw1359/CustomQueryPage'' to the MW 1.39 box.
  = Routine Workflow (ship today) =
# 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
  == 1. Seed the ROUTINE data ==
(or point the extension at your custom release table).
  * Import the raw rows (''mw_tags'' + ''mw_tag_pages'') via the export/import script.
  * After import, run <code>php maintenance/update.php --quick</code> if <code>mw_customquerypage_settings</code>
  does not exist yet.


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.
  == 2. Use the Special page ==
  * Log in as a sysop and open [[Special:CustomQuerySettings]].
  * Top form (Set active tag): type the ROUTINE you want live (for example, <code>ROUTINE_4.111</code>) and click
  '''Save tag''' if the rows already exist.
  * Clone form: source <code>ROUTINE_4.110</code>, target <code>ROUTINE_4.111</code>, optional note. Submit once
  to duplicate the tag entirely inside MediaWiki (no DB work).


Yep — here’s that whole block “mw-ified” into clean MediaWiki wikitext (copy/paste ready):
  == 3. Verify ==
  * Visit [[Special:ApprovedManuals]]; it now lists the pages tagged with <code>ROUTINE_4.111</code>.
  * Lisa reviews/publishes directly from there—no database access required.


```wiki
  (Once the data is in place, you either run the import script or use the clone form. When a JSON/API importer is
= Recap (Last Week → Now) =
  ready, it replaces step 1; steps 2 and 3 stay the same.)


* Finished the MW 1.35.9 ''CustomQueryPage'' build with the simplified clone workflow so Lisa can re-tag approved releases inside MediaWiki.
  == Maintenance helper (eckfordc, MW 1.39) ==
** ''Special:CustomQuerySettings'' now handles both:
  # Flush Opcache once so PHP rereads the helper:
*** ''Set active tag''
  #::<pre>if ( function_exists( 'opcache_reset' ) ) {
*** ''Clone ROUTINE_x.xxx → ROUTINE_y.yyy''
      opcache_reset();
* Deployed the same bits to ''eckfordc'' (MW 1.39) and ''sh1re/sh0re''.
   }</pre>
** The tables you saw (''mw_tags'' / ''mw_tag_pages'' plus ''mw_customquerypage_settings'') match what the extension uses.
   # Run the clone from the server:
* ''update.php'' keeps screaming about dropping legacy logging indexes.
   #::<pre>php extensions/CustomQueryPage/maintenance/testClone.php \
** On dev we skipped the patch and seeded the settings table manually.
      --wiki=eckfordc_mw19424 \
** Production installs just need to run update once so ''mw_customquerypage_settings'' exists.
      --source=ROUTINE_4.110 \
 
       --target=ROUTINE_4.111 \
== Where we landed ==
       --user=Admin
 
   </pre>
* DB access for humans stays off the table:
   # Check [[Special:ApprovedManuals]]; if the script prints an error, copy the message verbatim so we can patch
** whoever preps the ROUTINE export runs the existing script/import
   it.
** 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).
 
<pre>
 
/*------------------------------------------------
|                                                |
|   GARBAGE BELOW                                |
|                                                |
|    not happy                                  |
|                                                |
|----------------------------------------------*/
 
</pre>
 
> Here’s the end-to-end process using what we already shipped, so you can rehearse it before touching the JSON/
   API work:
 
  1. Seed the ROUTINE in the DB (once per release)
 
  - You still need the raw data (page/revision/tag rows) staged somewhere. Today that comes from the export/import
   script—either the manual SQL process or whatever automation you have.
  - Import creates/updates:
      - mw_tags: one row per ROUTINE (tag_id = 'ROUTINE_4.111', comment/deploy note, etc.).
      - mw_tag_pages: one row per approved page (tag_id, tag_page, tag_rev).
  - After import, run php maintenance/update.php --quick if the customquerypage_settings table doesn’t exist yet
  (once per wiki).
 
  2. Use the Special page to switch or clone
 
  - Log in as a sysop on the wiki.
  - Go to Special:CustomQuerySettings.
       - The top form shows the currently active ROUTINE (pulled from mw_customquerypage_settings). Type
  ROUTINE_4.111 and Save if you just want to point the listing at an existing tag.
       - The Clone form lets Lisa duplicate one ROUTINE to another inside MediaWiki itself (no new import).
   Set “Source ROUTINE” to the tag you already have (e.g., ROUTINE_4.110) and “New ROUTINE” to the next one
  (ROUTINE_4.111). Submit; the extension copies the mw_tags and mw_tag_pages rows and switches the active tag
  automatically.
 
  3. Verify
 
   - Visit Special:ApprovedManuals. It now lists the pages tagged with ROUTINE_4.111.
  - Lisa reviews or publishes from there; no DB access required.
 
  So to “create” ROUTINE_4.111 today you either (a) run the existing import script to load a fresh ROUTINE, or (b)
  use the clone form to copy an older tag to the new name. Once the data is in place, Special:ApprovedManuals /
   Special:CustomQuerySettings handle everything else.
 
  When you’re ready to build the JSON/API importer, we’ll replace step 1 (manual DB import) with a MediaWiki
  maintenance/API module that reads your JSON bundle and inserts the mw_tags/mw_tag_pages rows. But the rest of
  the process stays the same, and Lisa keeps working entirely through the Special pages.

Revision as of 19:47, 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
 * [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing
 list]
 * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for
 your language]
 * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam 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 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 includes the 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. The
 success banner is fixed and README documents the “Quick clone workflow.”
 * On sh1re/sh0re we still need to finish the MediaWiki patch that drops mw_logging.log_user*, so we
 seeded mw_customquerypage_settings manually to keep the UI working.

 == Why mw_tags felt “bypassed” ==
 * On dev we inserted the active tag row directly into mw_customquerypage_settings; the clone form
 still expects the standard mw_tags/mw_tag_pages tables.
 * If those tables contain the 4.110 data (they should after your import), the UI reuses them immediately.
 * Nothing special is required in LocalSettings.php; our extension simply uses the core tables via
 the MediaWiki load balancer.

 == Next steps on mw.eckfordc (MW 1.39) ==
 # Copy extensions-mw1359/CustomQueryPage onto the host.
 # Ensure mw_tags/mw_tag_pages include at least one ROUTINE (for example, import
 ROUTINE_4.110).
 # Visit Special:CustomQuerySettings, run the clone form end to end, and confirm the changed
 listing.
 # Once Lisa confirms the UI workflow, document the promotion steps on her admin page.

 = Recap (Last Week → Now) =
 * Finished the MW 1.35.9 build with the simplified clone workflow (Set active tag + Clone ROUTINE_x.xxx →
 ROUTINE_y.yyy).
 * Deployed the same code to eckfordc (1.39) and sh1re/sh0re (1.35.9); all installs now have mw_tags,
 mw_tag_pages, and mw_customquerypage_settings.
 * On sh1re/sh0re, update.php still balks at dropping mw_logging.log_user*; we seeded
 the settings row manually until the patch runs cleanly.

 == Where we landed ==
 * No human DB access – the release script populates ``mw_tags``/``mw_tag_pages``, and Lisa works entirely
 through the Special pages.
 * Special:CustomQuerySettings + Special:ApprovedManuals both confirmed for ROUTINE_4.111;
 README documents the “Quick clone workflow.”
 * Nothing extra is required in LocalSettings.php; the extension uses the standard tables via
 MediaWiki services.

 == Next step: JSON/API practice ==
 * Since most releases are re-tags, the clone form covers the common path.
 * For the rare “new” ROUTINE payload, define a JSON schema (page_id, rev_id, deployment comment, wikitext, etc.)
 and decide whether you want a REST endpoint, an Action API module, or a CLI importer so everything stays inside
 MediaWiki.

 = Routine Workflow (ship today) =

 == 1. Seed the ROUTINE data ==
 * Import the raw rows (mw_tags + mw_tag_pages) via the export/import script.
 * After import, run php maintenance/update.php --quick if mw_customquerypage_settings
 does not exist yet.

 == 2. Use the Special page ==
 * Log in as a sysop and open Special:CustomQuerySettings.
 * Top form (Set active tag): type the ROUTINE you want live (for example, ROUTINE_4.111) and click
 Save tag if the rows already exist.
 * Clone form: source ROUTINE_4.110, target ROUTINE_4.111, optional note. Submit once
 to duplicate the tag entirely inside MediaWiki (no DB work).

 == 3. Verify ==
 * Visit Special:ApprovedManuals; it now lists the pages tagged with ROUTINE_4.111.
 * Lisa reviews/publishes directly from there—no database access required.

 (Once the data is in place, you either run the import script or use the clone form. When a JSON/API importer is
 ready, it replaces step 1; steps 2 and 3 stay the same.)

 == Maintenance helper (eckfordc, MW 1.39) ==
 # Flush Opcache once so PHP rereads the helper:

#::

if ( function_exists( 'opcache_reset' ) ) {
      opcache_reset();
  }
 # Run the clone from the server:

#::

php extensions/CustomQueryPage/maintenance/testClone.php \
      --wiki=eckfordc_mw19424 \
      --source=ROUTINE_4.110 \
      --target=ROUTINE_4.111 \
      --user=Admin
  
 # Check Special:ApprovedManuals; if the script prints an error, copy the message verbatim so we can patch
 it.
Retrieved from "https://mw.eckford.ca:443/index.php?title=Main_Page&oldid=38"