Main Page: Difference between revisions

From MediaWiki-1.39
Jump to navigation Jump to search
(formatting frenzie!)
No edit summary
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 it 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 (for example, <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 “Quick clone workflow.”
  * On sh1re/sh0re we never finished the MediaWiki core patch that deletes <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 normal <code>mw_tags</code>/<code>mw_tag_pages</code> tables.
  * If those tables contain the 4.110 data (they should after your MySQL import), the UI reuses them immediately.
  * There’s nothing special in <code>LocalSettings.php</code>; MediaWiki core creates those tables. Our extension
  simply uses the load balancer to read/write them.


* '''CustomQueryPage''' now ships with a simplified clone path:
   == Next steps if you want to exercise it on mw.eckfordc ==
** ''Special:CustomQuerySettings'' copies the ''mw_tag_pages'' rows from ''ROUTINE_4.110'' to ''ROUTINE_4.111'',
  # Copy <code>extensions-mw1359/CustomQueryPage</code> to the MW 1.39 box.
** clones the ''mw_tags'' row,
  # Ensure <code>mw_tags</code>/<code>mw_tag_pages</code> have 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> and confirm the clone form works end-to-end (new
* On sh1re/sh0re we never finished the MediaWiki core patch that deletes ''mw_logging.log_user*''.
  <code>mw_tags</code> row, ApprovedManuals listing updated).
** We seeded ''mw_customquerypage_settings'' manually instead so Lisa could keep using the UI.
  # Once Lisa confirms the UI covers her release workflow (set tag + clone), document the progressive-release
 
  steps on her admin page.
== 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.
 
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
 
 
  == Routine Clone (eckfordc) ==
  # (One time) Clear Opcache: temporarily add
    <code>if ( function_exists( 'opcache_reset' ) ) { opcache_reset(); }</code>
    to <code>LocalSettings.php</code>, load any page, then remove the snippet.
  # Run the maintenance helper:
    <pre>
    php extensions/CustomQueryPage/maintenance/testClone.php \
        --wiki=eckfordc_mw19424 \
        --source=ROUTINE_4.110 \
        --target=ROUTINE_4.111 \
        --user=Admin
    </pre>
    This clones the tag and prints “Cloned X pages (Y revisions)” or the exact SQL error.
  # Visit [[Special:ApprovedManuals]]; it should now show <code>ROUTINE_4.111</code>.
  # If the clone fails, rerun step 2 and copy the error output so we can patch it.
 
-----------------


   = Recap (Last Week → Now) =
   = Recap (Last Week → Now) =
 
   * Finished the MW 1.35.9 build with the simplified clone workflow so Lisa can re‑tag releases (Set active tag +
   * Finished the MW 1.35.9 '''CustomQueryPage''' build with the simplified clone workflow so Lisa can re-tag
   Clone ROUTINE_x.xxx → ROUTINE_y.yyy).
   approved releases inside MediaWiki.
   * Deployed the same code to eckfordc (1.39) and sh1re/sh0re (1.35.9); all installs now have the expected tables
  ** ''Special:CustomQuerySettings'' now handles both “Set active tag” and “Clone ROUTINE_x.xxx → ROUTINE_y.yyy”.
  (''mw_tags'', ''mw_tag_pages'', <code>mw_customquerypage_settings</code>).
   * Deployed the same bits to eckfordc (MW 1.39) and sh1re/sh0re.
   * On sh1re/sh0re, <code>update.php</code> still complains about dropping <code>mw_logging.log_user*</code>; for
  ** All installations have the expected tables (''mw_tags'', ''mw_tag_pages'', ''mw_customquerypage_settings'').
  now we seeded the settings row manually.
   * ''update.php'' still balks at dropping ``mw_logging.log_user*`` on sh1re/sh0re, so we seeded the settings
  table manually until the patch runs cleanly.


   == Where we landed ==
   == Where we landed ==
   * No human DB access: the release export populates ``mw_tags``/``mw_tag_pages``, and Lisa stays within the
   * No human DB access: the release script populates <code>mw_tags</code>/<code>mw_tag_pages</code>, and Lisa
  Special pages.
  stays within the Special pages.
   * ''Special:CustomQuerySettings'' + ''Special:ApprovedManuals'' confirmed for <code>ROUTINE_4.111</code>; README
   * ''Special:CustomQuerySettings'' and ''Special:ApprovedManuals'' both confirmed for <code>ROUTINE_4.111</code>;
   documents the “Quick clone workflow”.
   README documents the “Quick clone workflow.”
   * Nothing special needed in <code>LocalSettings.php</code>; the extension uses the standard tables via MediaWiki
   * Nothing special required in <code>LocalSettings.php</code>; the extension uses the standard tables via
   services.
   MediaWiki services.


   == Next step: JSON/API practice ==
   == Next step: JSON/API practice ==
   * Since most releases are just re-tagging existing pages, the clone form covers the common path.
   * Since most releases are re‑tags, the clone form covers the common path.
   * For the rare “new” ROUTINE payload, we can define a JSON schema (page_id, rev_id, comment, wikitext, etc.) and
   * For the rare “new” ROUTINE payload, define a JSON schema (page_id, rev_id, comment, wikitext, etc.) and build
   build either
   either a REST endpoint, an Action API module, or a CLI importer to ingest it inside MediaWiki.
  ** a REST endpoint,
  ** an Action API module, or
  ** a CLI maintenance script
  that ingests the data without direct SQL access.


   = Routine Clone (eckfordc) =
   = Routine Clone (eckfordc) =
   # One-time: flush Opcache so PHP reloads the helper script:
   # One-time: flush Opcache so PHP reloads the helper script:
  #::Add this to <code>LocalSettings.php</code>, load any page, then remove it:
   #::<pre>if ( function_exists( 'opcache_reset' ) ) {
   #::<pre>if ( function_exists( 'opcache_reset' ) ) {
       opcache_reset();
       opcache_reset();
Line 161: Line 83:
   </pre>
   </pre>
   # Visit [[Special:ApprovedManuals]]; it should now show <code>ROUTINE_4.111</code>.
   # Visit [[Special:ApprovedManuals]]; it should now show <code>ROUTINE_4.111</code>.
   # If the clone fails, rerun step 2 and capture the error text so we can patch it.
   # If the clone fails, rerun step 2 and capture the error text so we can patch it.

Revision as of 19:08, 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 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 (for example, 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 “Quick clone workflow.”
 * On sh1re/sh0re we never finished the MediaWiki core patch that deletes 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 normal mw_tags/mw_tag_pages tables.
 * If those tables contain the 4.110 data (they should after your MySQL import), the UI reuses them immediately.
 * There’s nothing special in LocalSettings.php; MediaWiki core creates those tables. Our extension
 simply uses the load balancer to read/write them.

 == Next steps if you want to exercise it on mw.eckfordc ==
 # Copy extensions-mw1359/CustomQueryPage to the MW 1.39 box.
 # Ensure mw_tags/mw_tag_pages have at least one ROUTINE (for example, import
 ROUTINE_4.110).
 # Visit Special:CustomQuerySettings and confirm the clone form works end-to-end (new
 mw_tags row, ApprovedManuals listing updated).
 # Once Lisa confirms the UI covers her release workflow (set tag + clone), document the progressive-release
 steps on her admin page.

 = Recap (Last Week → Now) =
 * Finished the MW 1.35.9 build with the simplified clone workflow so Lisa can re‑tag releases (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 the expected tables
 (mw_tags, mw_tag_pages, mw_customquerypage_settings).
 * On sh1re/sh0re, update.php still complains about dropping mw_logging.log_user*; for
 now we seeded the settings row manually.

 == Where we landed ==
 * No human DB access: the release script populates mw_tags/mw_tag_pages, and Lisa
 stays within the Special pages.
 * Special:CustomQuerySettings and Special:ApprovedManuals both confirmed for ROUTINE_4.111;
 README documents the “Quick clone workflow.”
 * Nothing special 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, comment, wikitext, etc.) and build
 either a REST endpoint, an Action API module, or a CLI importer to ingest it inside MediaWiki.

 = Routine Clone (eckfordc) =
 # One-time: flush Opcache so PHP reloads the helper script:

#::

if ( function_exists( 'opcache_reset' ) ) {
      opcache_reset();
  }
 # Run the maintenance helper:

#::

php extensions/CustomQueryPage/maintenance/testClone.php \
      --wiki=eckfordc_mw19424 \
      --source=ROUTINE_4.110 \
      --target=ROUTINE_4.111 \
      --user=Admin
  
 # Visit Special:ApprovedManuals; it should now show ROUTINE_4.111.
 # If the clone fails, rerun step 2 and capture the error text so we can patch it.
Retrieved from "https://mw.eckford.ca:443/index.php?title=Main_Page&oldid=35"