Main Page: Difference between revisions

From MediaWiki-1.39
Jump to navigation Jump to search
(formatting frenzie!)
 
(57 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<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.
{{Info|Updated March 16, 2026.}}
 
= ROUTINE troubleshooting notes =
 
These notes are for checking or changing the active ROUTINE in the Manual Procedures workflow.
 
== Normal workflow ==
 
# Log in.
# Open '''Approved manuals'''.
# Note the ROUTINE shown at the top of the page.
# Open '''ROUTINE tags'''.
 
=== To activate or roll back to an existing ROUTINE ===
 
Use the '''top ROUTINE field'''.
 
Enter the exact existing ROUTINE value you want to use, for example:
 
<code>ROUTINE_4.110</code>
 
Then click '''Activate tag'''.
 
This can be used to:
 
* activate the current working ROUTINE
* return to a previous ROUTINE
* confirm that an existing ROUTINE bundle still works
 
'''Do not''' use '''Clone ROUTINE release''' for rollback.
 
=== To create the next ROUTINE ===
 
First make sure the current ROUTINE is correct in the '''top ROUTINE field'''. 
If needed, enter the current ROUTINE there and click '''Activate tag''' first.
 
Then use '''Clone ROUTINE release'''.
 
Enter:
 
* '''Source ROUTINE''': the current active release, for example <code>ROUTINE_4.110</code>
* '''New ROUTINE''': the new release, for example <code>ROUTINE_4.111</code>
 
Then submit the form.
 
This should:
 
* create the new ROUTINE tag
* copy the current bundle into the new ROUTINE
* activate the new ROUTINE automatically
 
== What to check immediately after ==
 
After activating or cloning:
 
# Stay on the page and note the message shown at the top.
# Open '''Approved manuals''' again.
# Confirm whether the ROUTINE heading changed.
# Confirm whether the manual list changed as expected.
 
== Important ==
 
* '''Activate tag''' uses an existing ROUTINE.
* '''Clone ROUTINE release''' creates a new ROUTINE from an existing one.
* '''Rollback''' means activating an existing ROUTINE in the top field.
* Enter the ROUTINE exactly as written, for example <code>ROUTINE_4.110</code>.
* Changing approved document revisions does '''not''' by itself create a new ROUTINE label.
* A new ROUTINE appears only after it is cloned or otherwise created in the ROUTINE tables.
 
= Emergency fallback test in LocalSettings.php =
 
Use this only if the normal ROUTINE activation path is not working and you need to test whether the wiki is falling back to configuration.
 
== Method 1: Change the fallback ROUTINE in <code>LocalSettings.php</code> ==
 
Edit this line in <code>LocalSettings.php</code>:
 
<syntaxhighlight lang="php">
$wgCustomQueryPageDefaultTag = 'ROUTINE_4.111';
</syntaxhighlight>
 
Then:
 
# Save the file.
# Reload [[Special:RoutineTags]].
# Reload [[Special:ApprovedManuals]].
 
If nothing changes:
 
# Do a hard refresh in the browser.
# If it is still unchanged, ask the sysadmin to restart PHP or the container.
# Reload both special pages again.
 
Expected result:
 
* If the page starts showing <code>ROUTINE_4.111</code>, the extension is reading the fallback value from configuration.
* If it still shows <code>ROUTINE_4.110</code>, this change did not affect the current read path.
 
== Method 2: Quick page check ==
 
After Method 1, check both pages, not just one:
 
* [[Special:RoutineTags]]
* [[Special:ApprovedManuals]]
 
Things to confirm:
 
* Does [[Special:RoutineTags]] show <code>ROUTINE_4.111</code> as the visible current or default tag?
* Does the heading on [[Special:ApprovedManuals]] change to the new ROUTINE?
* Does the document list appear to match the intended release?
 
== Method 3: See documentation ==
 
Use the ROUTINE workflow and recovery notes for deeper troubleshooting.
 
Known points:
 
* ROUTINE labels are stored in <code>mw_tags</code>.
* ROUTINE membership is stored in <code>mw_tag_pages</code>.
* The current approved set is stored in <code>mw_approved_revs</code>.
* The active selected ROUTINE is stored in <code>mw_customquerypage_settings</code>.
* Activating a ROUTINE rebuilds <code>mw_approved_revs</code>.
* Rollback is done by reactivating the previous ROUTINE.
 
If the manual <code>LocalSettings.php</code> edit and page refresh do not restore expected behaviour, continue with the documented extension workflow and technical recovery notes.
 
---
= DEBUG STEPS =
 
== In a nutshell ==
 
* What ROUTINE is showing on Approved manuals?
 
* What ROUTINE tag displays on the ROUTINE tags page?
 
* What exact message appeared after clicking the button?
 
== Tech Fixes ==
 
Please let me know if this is fixed or if you need another step. Based on what's happening, I can probably help :)
 
-----------------------------------------------------------


== Getting started ==
{{Info| Released Vesion 1.0 is available as Latest Version released Feb 26, 2026}}
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
[[:File:CustomQueryPage-latest.tgz|CustomQueryPage – latest deployment bundle]]
* [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://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 ==
File:CustomQueryPage-latest.tgz
* [https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz CustomQueryPage for mw1359]


=== Installing CustomQueryPage ===
'''Data model summary:''' <code>page_latest</code> tracks the most recent edit, <code>mw_approved_revs</code> identifies the revision currently approved for display, and each ROUTINE snapshot in <code>mw_tag_pages</code> records which revision belongs to that release.
* Download the bundle: <code>wget https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz</code>
* Extract it into your extensions folder:
** <code>tar -xzf CustomQueryPage-mw1359.tar.gz -C /srv/mediawiki/extensions</code>
* Edit <code>LocalSettings.php</code> and add <code>wfLoadExtension( 'CustomQueryPage' );</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>.


---------------------------------------------------------


= Where We Stand =
The following information can be used as an installation guide. Only download files tagged latest


* '''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 ==
= OBSOLETE Pre-release =
<strong>MediaWiki has been installed.</strong>
{{Notice
| event_name  = Wiki launch
| date        = February 12th
| location    = Lisa's Desk
| description = Count down to the retirement of the efs3 server!
}}
{{{Hatnote|content is content}}}


* On dev we inserted the active tag row directly into ''mw_customquerypage_settings''; the clone form still expects
== Import CustomQueryPage ==
  the regular ''mw_tags'' / ''mw_tag_pages'' tables.
This install is originally intended for the ROUTINE Manuals publication workflow. That's all it does now, but hey, it's a good place to keep notes too. Did you know for MediaWiki you create a page by writing the name in the address bar? How tricky is that?
** 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 ==
== NOTE ==
See procedure for rollback to reset to a previous version. Set tag ONLY.  


# Copy ''extensions-mw1359/CustomQueryPage'' to the MW 1.39 box.
== Let's Get Started ==
# 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
* [https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz CustomQueryPage for mw1359]
(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
[[:File:CustomQueryPage-latest.tgz|CustomQueryPage – latest deployment bundle]]
= 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.
=== Installing CustomQueryPage ===
** ''Special:CustomQuerySettings'' now handles both:
* Download the bundle: <code>wget https://mw.eckford.ca/downloads/CustomQueryPage-mw1359.tar.gz</code>
*** ''Set active tag''
* Extract it into your extensions folder:
*** ''Clone ROUTINE_x.xxx → ROUTINE_y.yyy''
** <code>tar -xzf CustomQueryPage-mw1359.tar.gz -C /srv/mediawiki/extensions</code>
* Deployed the same bits to ''eckfordc'' (MW 1.39) and ''sh1re/sh0re''.
* Edit <code>LocalSettings.php</code> and add <code>wfLoadExtension( 'CustomQueryPage' );</code>
** The tables you saw (''mw_tags'' / ''mw_tag_pages'' plus ''mw_customquerypage_settings'') match what the extension uses.
* Run <code>php maintenance/update.php --quick</code>.
* ''update.php'' keeps screaming about dropping legacy logging indexes.
* Visit <code>Special:CustomQuerySettings</code>, set the ROUTINE tag (e.g., <code>ROUTINE_4.110</code>), and confirm <code>Special:ApprovedManuals</code>.
** 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 ==
= Quick Start: ROUTINE Management =


* DB access for humans stays off the table:
=== 1. Seed the ROUTINE in the DB ===
** whoever preps the ROUTINE export runs the existing script/import
Before first run of the UI, make sure the database has ROUTINE data.
** 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 ==
* Use the import script or manual SQL method.
* Required tables:
** <code>mw_tags</code> — one row per ROUTINE (e.g., <code>ROUTINE_4.111</code>).
** <code>mw_tag_pages</code> — one row per approved page.
* If needed, run: <code>php maintenance/update.php --quick</code>
{{Note|Note: Only run <code>update.php</code> if <code>mw_customquerypage_settings</code> does not exist yet, or if you are intentionally applying the CustomQueryPage schema changes in a controlled maintenance window.}}


* Since new ROUTINEs are usually just re-tagging existing pages (rarely brand-new content), the current clone form covers the common path.
=== 2. Use the Special Page to Switch or Clone ===
* 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


Please note that the Revision is part of this query and display. Any documents that have been approved since the last release should have a new revision and this new revision should be included in the ROUTINE_tag


  == Routine Clone (eckfordc) ==
* Go to: <code>Special:CustomQuerySettings</code>
  # (One time) Clear Opcache: temporarily add
* Two options:
    <code>if ( function_exists( 'opcache_reset' ) ) { opcache_reset(); }</code>
** '''Set Active Tag''' — type <code>ROUTINE_4.111</code>, then Save.
    to <code>LocalSettings.php</code>, load any page, then remove the snippet.
** '''Clone ROUTINE → New ROUTINE''':
  # Run the maintenance helper:
*** From: <code>ROUTINE_4.110</code>
    <pre>
*** To: <code>ROUTINE_4.111</code>
    php extensions/CustomQueryPage/maintenance/testClone.php \
*** Submit → this copies rows and updates the active tag.
        --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.


-----------------
=== 3. Verify the Result ===


  = Recap (Last Week → Now) =
* Visit: <code>Special:ApprovedManuals</code>
* Confirm the listing shows <code>ROUTINE_4.111</code>
* Lisa can now publish or review the approved manuals.
* No DB access required.


  * Finished the MW 1.35.9 '''CustomQueryPage''' build with the simplified clone workflow so Lisa can re-tag
= Optional: JSON/API Importer =
  approved releases inside MediaWiki.
  ** ''Special:CustomQuerySettings'' now handles both “Set active tag” and “Clone ROUTINE_x.xxx → ROUTINE_y.yyy”.
  * Deployed the same bits to eckfordc (MW 1.39) and sh1re/sh0re.
  ** All installations have the expected tables (''mw_tags'', ''mw_tag_pages'', ''mw_customquerypage_settings'').
  * ''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 ==
If you're ready to skip the SQL import:
  * No human DB access: the release export populates ``mw_tags``/``mw_tag_pages``, and Lisa stays within the
  Special pages.
  * ''Special:CustomQuerySettings'' + ''Special:ApprovedManuals'' confirmed for <code>ROUTINE_4.111</code>; README
  documents the “Quick clone workflow”.
  * Nothing special needed in <code>LocalSettings.php</code>; the extension uses the standard tables via MediaWiki
  services.


  == Next step: JSON/API practice ==
* Define a JSON payload that includes:
  * Since most releases are just re-tagging existing pages, the clone form covers the common path.
** <code>page_id</code>, <code>rev_id</code>, <code>deploy_comment</code>, <code>wikitext</code>, etc.
  * For the rare “new” ROUTINE payload, we can define a JSON schema (page_id, rev_id, comment, wikitext, etc.) and
* Build a:
  build either
** REST endpoint, or
  ** a REST endpoint,
** Action API module, or
  ** an Action API module, or
** Maintenance script that reads JSON
  ** a CLI maintenance script
  that ingests the data without direct SQL access.


  = Routine Clone (eckfordc) =
Once defined, MediaWiki can import directly into <code>mw_tags</code> / <code>mw_tag_pages</code>.


  # One-time: flush Opcache so PHP reloads the helper script:
{{Warning|Avoid touching the database manually if you want to adopt the JSON route. The importer will safely handle all insertions.}}
  #::Add this to <code>LocalSettings.php</code>, load any page, then remove it:
  #::<pre>if ( function_exists( 'opcache_reset' ) ) {
      opcache_reset();
  }</pre>
  # 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>
  # 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.

Latest revision as of 08:49, 17 March 2026

Info: Updated March 16, 2026.


ROUTINE troubleshooting notes

These notes are for checking or changing the active ROUTINE in the Manual Procedures workflow.

Normal workflow

  1. Log in.
  2. Open Approved manuals.
  3. Note the ROUTINE shown at the top of the page.
  4. Open ROUTINE tags.

To activate or roll back to an existing ROUTINE

Use the top ROUTINE field.

Enter the exact existing ROUTINE value you want to use, for example:

ROUTINE_4.110

Then click Activate tag.

This can be used to:

  • activate the current working ROUTINE
  • return to a previous ROUTINE
  • confirm that an existing ROUTINE bundle still works

Do not use Clone ROUTINE release for rollback.

To create the next ROUTINE

First make sure the current ROUTINE is correct in the top ROUTINE field. If needed, enter the current ROUTINE there and click Activate tag first.

Then use Clone ROUTINE release.

Enter:

  • Source ROUTINE: the current active release, for example ROUTINE_4.110
  • New ROUTINE: the new release, for example ROUTINE_4.111

Then submit the form.

This should:

  • create the new ROUTINE tag
  • copy the current bundle into the new ROUTINE
  • activate the new ROUTINE automatically

What to check immediately after

After activating or cloning:

  1. Stay on the page and note the message shown at the top.
  2. Open Approved manuals again.
  3. Confirm whether the ROUTINE heading changed.
  4. Confirm whether the manual list changed as expected.

Important

  • Activate tag uses an existing ROUTINE.
  • Clone ROUTINE release creates a new ROUTINE from an existing one.
  • Rollback means activating an existing ROUTINE in the top field.
  • Enter the ROUTINE exactly as written, for example ROUTINE_4.110.
  • Changing approved document revisions does not by itself create a new ROUTINE label.
  • A new ROUTINE appears only after it is cloned or otherwise created in the ROUTINE tables.

Emergency fallback test in LocalSettings.php

Use this only if the normal ROUTINE activation path is not working and you need to test whether the wiki is falling back to configuration.

Method 1: Change the fallback ROUTINE in LocalSettings.php

Edit this line in LocalSettings.php:

<syntaxhighlight lang="php"> $wgCustomQueryPageDefaultTag = 'ROUTINE_4.111'; </syntaxhighlight>

Then:

  1. Save the file.
  2. Reload Special:RoutineTags.
  3. Reload Special:ApprovedManuals.

If nothing changes:

  1. Do a hard refresh in the browser.
  2. If it is still unchanged, ask the sysadmin to restart PHP or the container.
  3. Reload both special pages again.

Expected result:

  • If the page starts showing ROUTINE_4.111, the extension is reading the fallback value from configuration.
  • If it still shows ROUTINE_4.110, this change did not affect the current read path.

Method 2: Quick page check

After Method 1, check both pages, not just one:

Things to confirm:

  • Does Special:RoutineTags show ROUTINE_4.111 as the visible current or default tag?
  • Does the heading on Special:ApprovedManuals change to the new ROUTINE?
  • Does the document list appear to match the intended release?

Method 3: See documentation

Use the ROUTINE workflow and recovery notes for deeper troubleshooting.

Known points:

  • ROUTINE labels are stored in mw_tags.
  • ROUTINE membership is stored in mw_tag_pages.
  • The current approved set is stored in mw_approved_revs.
  • The active selected ROUTINE is stored in mw_customquerypage_settings.
  • Activating a ROUTINE rebuilds mw_approved_revs.
  • Rollback is done by reactivating the previous ROUTINE.

If the manual LocalSettings.php edit and page refresh do not restore expected behaviour, continue with the documented extension workflow and technical recovery notes.

---

DEBUG STEPS

In a nutshell

  • What ROUTINE is showing on Approved manuals?
  • What ROUTINE tag displays on the ROUTINE tags page?
  • What exact message appeared after clicking the button?

Tech Fixes

Please let me know if this is fixed or if you need another step. Based on what's happening, I can probably help :)


Info: Released Vesion 1.0 is available as Latest Version released Feb 26, 2026

CustomQueryPage – latest deployment bundle

File:CustomQueryPage-latest.tgz

Data model summary: page_latest tracks the most recent edit, mw_approved_revs identifies the revision currently approved for display, and each ROUTINE snapshot in mw_tag_pages records which revision belongs to that release.


The following information can be used as an installation guide. Only download files tagged latest


OBSOLETE Pre-release

MediaWiki has been installed.

   Upcoming Event: Wiki launch 
Scheduled for: February 12th at Lisa's Desk

Count down to the retirement of the efs3 server!

content is content

Import CustomQueryPage

This install is originally intended for the ROUTINE Manuals publication workflow. That's all it does now, but hey, it's a good place to keep notes too. Did you know for MediaWiki you create a page by writing the name in the address bar? How tricky is that?

NOTE

See procedure for rollback to reset to a previous version. Set tag ONLY.

Let's Get Started


CustomQueryPage – latest deployment bundle

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 first run of 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: Note: Only run update.php if mw_customquerypage_settings does not exist yet, or if you are intentionally applying the CustomQueryPage schema changes in a controlled maintenance window.


2. Use the Special Page to Switch or Clone

Please note that the Revision is part of this query and display. Any documents that have been approved since the last release should have a new revision and this new revision should be included in the ROUTINE_tag

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