Why:
- From MediaWiki 1.36 to MediaWiki 1.44 (inclusive),
`PostgresUpdater.php` contains a typo in the instruction to rename
the `sites_group` index to `site_group`.
- This typo means that - on Postgres wikis - the MediaWiki update
script will not currently rename this index as intended, as the index
which the updater is told to rename (i.e., containing the typo)
doesn't exist.
- From MediaWiki 1.42 onwards, this typo indirectly causes `update.php`
on Postgres wikis to throw an error on its first run:
- From MW 1.42 onwards, the update script included an instruction to
drop multiple indexes on the `sites` table, including this index
that was previously intended to be renamed.
- However, as this typo meant that the `sites_group` index was never
renamed on Postgres wikis, the database is unable to find the
renamed index in order to drop it; and consequently throws an
error (reported on Phabricator as T374042).
- This only affects the first run of `update.php` due to the fact
that - when deciding whether to apply the patch containing _all_ of
the index-drops for the `sites` table - the `dropIndex` instruction
only checks for the existence of the `site_type` index (and, if the
`site_type` index doesn't exist, the patch as a whole isn't applied).
However, as - within `patch-sites-drop_indexes.sql` - the statement
to drop the `site_type` index is located _before_ the instruction to
drop the `site_group` index, the `site_type` index will have been
dropped on the first run of `update.php`.
- This also means that - on any future runs of `update.php` - the
indexes listed after (and including) `site_group` in that SQL file
will currently remain un-dropped.
What:
- Fix the typo in the PostgresUpdater index renaming instruction:
`'sites_group, '` -> `'sites_group'`
- Update PostgresUpdater to individually re-attempt to drop the indexes
listed after & including `site_group` in
`patch-sites-drop_indexes.sql`, to ensure that they're dropped on
Postgres wikis that have already (1) upgraded to MW 1.42+, & (2) ran
`update.php`.
(These could theoretically have all been combined within one extra
SQL patch, rather than one for each index; but I thought it might be
best for the updater to check for the existence of each of these
indexes individually before it attempts to drop each one.)
Follows-up 9907b56c9b, 616744db1d
Bug: T374042
Change-Id: Ie6ffa92153e64ca653f726a35a5a6b5d95d093f5
MediaWiki's maintenance scripts are PHP scripts that perform maintenance tasks,
and are designed to be run from the command line.
See also: https://www.mediawiki.org/wiki/Manual:Maintenance_scripts
== Running Maintenance Scripts ==
Maintenance scripts are generally executed using the maintenance runner, calling
''php maintenance/run.php'' followed by the script's name. On most systems, the
shorthand ''maintenance/run'' can also be used. For instance, to run the script
that displays the MediaWiki version, use ''maintenance/run version''.
Maintenance scripts can be called by their simple name, class name, or path.
The simple name corresponds to a file in the maintenance directory:
* ''maintenance/run version'' runs the file ''maintenance/version.php''.
For the class name:
* ''maintenance/run Version'' runs the Version class (using auto-loading from
''./maintenance/version.php'').
For the path:
* ''maintenance/run ./maintenance/version.php'' runs the file
''./maintenance/version.php''.
Note that relative file paths must start with "./". Using this form allows for
the use of tab-completion.
Maintenance scripts defined by extensions may also be called by giving their
full class name or full relative path, such as:
* ''maintenance/run ./extension/AbuseFilter/maintenance/SearchFilters.php''
* ''maintenance/run MediaWiki.Extension.AbuseFilter.Maintenance.SearchFilters''
Note how the dot (".") can be used as a namespace separator instead of the
backslash ("\").
If the extension follows the MediaWiki coding conventions for the location and
namespacing of maintenance scripts, they can be invoked using the name of the
extension, followed by a colon (":") and the name of the script file or class:
* ''maintenance/run AbuseFilter:SearchFilters''
For more details on using the script runner, call ''maintenance/run --help''.
For about an individual script, call ''maintenance/run <script> --help ''.
=== Running Maintenance Scripts before MW 1.40 ===
The maintenance runner described above was introduced in MediaWiki 1.40. In
MediaWiki version 1.39 and earlier, maintenance scripts had to be run as
standalone PHP scripts, by passing the path the the script to the php interpreter.
For instance:
* ''php maintenance/version.php''
This is still possible for most scripts in 1.40, but it will show a deprecation
warning.
== Creating Maintenance Scripts ==
To create a maintenance script, add a PHP file to the maintenance directory that
contains a class that extends the ''Maintenance'' base class and implement
the ''execute()'' method. At the end of the file, add a return statement that
returns the name of the class.
For example, if your class is called ''Frobnify'', place it in a file called
''maintenance/Frobnify.php'' and at the end of the file, put the following
statement:
<pre>
return Frobnify::class;
</pre>
You can now run your script by calling ''maintenance/run Frobnify''.
With this, it will however not be possible to run Frobnify.php as a PHP command
line script. ''php maintenance/Frobnify.php'' will fail with an error.
=== Supporting direct execution of maintenance scripts ===
Since MediaWiki version 1.40, invoking maintenance scripts directly is now
deprecated, and will show a warning even for scripts that support it.
If you need to support direct invocation for your script, this can be
achieved as follows:
At the top of the script file, place the statement:
<pre>
// @codeCoverageIgnoreStart
require_once __DIR__ . '/Maintenance.php';
// @codeCoverageIgnoreEnd
</pre>.
For maintenance scripts defined in extensions, this is slightly more complex:
<pre>
require_once getenv( 'MW_INSTALL_PATH' ) !== false
? getenv( 'MW_INSTALL_PATH' ) . '/maintenance/Maintenance.php'
: __DIR__ . '/../../../maintenance/Maintenance.php';
</pre>
Then, at the bottom of the file, replace the return statement with the
following lines:
<pre>
// @codeCoverageIgnoreStart
$maintClass = Frobnify::class;
require_once RUN_MAINTENANCE_IF_MAIN;
// @codeCoverageIgnoreEnd
</pre>
This will allow your script to be executed directly on the PHP command line.
Note however that it will show a warning.
ffa868bcf1