Follow-up to commit fea5c2f, which changed from using `BETWEEN` to
expression builder and broke this.
Change-Id: If2686bb547420fa2f12b41adcff69db5611e6428
When there are more files as the batch size,
the script loops as the where condition is not changed.
Bug: T401088
Change-Id: Ic52ea24de0bd68db9e7d84e2f1b1067b20c2836d
(cherry picked from commit 9a162bff8add74a1b797cf0769b8601d440cc231)
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
The convert from raw sql to expression in 81c6df6a46
has a error for the touched condition.
Switch the conditions and use RawSQLExpression to use the raw sql.
Follow-Up: Ieb229d8088cb1ff3f03e44f7ac99eb612f48bc7b
Change-Id: I8fbe0ec44d1a43795a3e4c94f910e09878eebde6
(cherry picked from commit f11b59de58bcb241fa337bbcdd276d25bc94e462)
When MovePage::move() returns an error, doMove() should return false
instead of carrying on with move log adjustment.
Bug: T394556
Change-Id: I0864bd491d59fff42a062d7e5db957e46852761a
This patch was applied to release branches for MW 1.42 in April 2024, and
since ported to MW 1.43 and then MW 1.44 as well. This one-of-a-kind hot
patch will finally discontinue once this lands in the master branch as
part of MW 1.45+ releases.
A small handful of phan fixes make this pass so it can land; the rest
(including fixes rather than suppressions of events here) will happen in
later patches.
Bug: T328921
Bug: T359868
Change-Id: Ica2c11a6243795437ec652923e42ef3bd74a5fd8
These .htaccess files are intended to prohibit all web access. But if
the user sets "Satisfy Any" on a parent directory, in conjunction with
any permissive require directive like "Require all granted", access will
be allowed despite "Require all denied" in .htaccess.
So, override Satisfy so that the "Require all denied" will reliably take
effect.
Note that "Satisfy All" is the default. This only affects non-default
installations.
Change-Id: Ia5862fb69e439b7ea2ed7af011e1ebf8f1b1f6d6
(cherry picked from commit a50d2e69f8ce9e5720b05615d04c35cc9008b6ae)
When scripting, folks generally check the exit code of a program to be
zero if it is successful, and non-zero if it isn't. Since importImages
can be used in third-party scripts to automate wiki imports, it is
paramount that import failures are detected.
However, since it doesn't exit with a failure code (i.e. a non-zero
exit code) when a file fails to import or when there are no files
found, it is much more difficult to detect import failures.
Therefore, we exit with a non-zero return code to make import failures
much more easier to detect for scripts.
Bug: T388296
Change-Id: I5d9ede123355d63267793133287253a86faecda5
(cherry picked from commit 5a7c5491775ebf97f60fc7067d3d41c609358534)
Correct the join conditions used to find the current edit count for
a batch of users. Follows up b98f33c where the incorrect join order and
conditions were introduced as part of migration to QueryBuilder syntax.
Change-Id: I1841bb074b0f2be31e60a3cce3d62eb1b5999ad0
(cherry picked from commit 834891e01afa19cc1ecd973c04a453a9abb2d484)
This reverts commit 4563e41f20.
Reason for revert: The expected DatabaseSqlite is not directly used here, it is still DBConnRef and the patch does not work as is.
Bug: T386891
Change-Id: I83b1e299b698c004dcacb9aa90901dfe28097403
(cherry picked from commit 7fdc51ed4d27ba6211215c6198b7e448de799cde)
Why:
- TextPassDumper may spawn PHP subprocesses via proc_open() when invoked
with --spawn.
- The script uses pclose() to try and close these, which is incorrect,
because the resource returned by proc_open() should be closed via
proc_close().[1]
- This causes a TypeError on PHP 8.1 and newer.
What:
- Use proc_close() to close the resource instead of pclose().
Test Plan:
- Run `php maintenance/dumpBackup.php --current --stub | php maintenance/dumpTextPass.php --spawn`
on a local test wiki using PHP 8.1 or newer. It should succeed.
[1] https://www.php.net/manual/en/function.proc-open.php
Bug: T382484
Change-Id: I66cd733cdbc1b8bc1470c14851a0700401c36d1e
(cherry picked from commit 8b9c3ab08eddc86032166f5b9dc208e51c2aaebb)
- Make si_page primary key
- Allow si_title to be larger
- Switch from utf8 to utf8mb4
- Remove default of empty string for titles
Sqlite is not migrated, as it has it's own overrides
Postgres is migrated, but is not in actual use
This is mostly from I273e3a7715abf97d2889904642c7c375e76de4f6
Bug: T249976
Bug: T231827
Change-Id: I12adff3e6ca6a9986ff207bef16272195c3a6a48
(cherry picked from commit a2ba7ee14d6b38a5e89bcc63c3bd0ca8b5107702)
This does not include use of MediaWiki\Maintenance\Maintenance,
assuming the maintenance scripts going into the same namespace
Change-Id: I488f95b537ce86eb5e463be7bce3653610dd13d9
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
Why:
* Maintenance scripts in core have low test coverage
* This can cause issues such as the findDeprecated.php maintenance
script not working, as described in T374832
* Testing the broken script after fixing it will avoid the script
breaking again.
What:
* Fix the findDeprecated.php maintenance script to actually
show when code is hard-deprecated.
* Modify the script to allow mocking of the MediaWiki install
path in PHPUnit tests
* Create FindDeprecatedTest which tests that the script produces
an expected output, without being specific about how the
code finds the methods (to allow the method to be changed
as discussed in T243403)
** To do this, create a folder in the data folder for the PHPUnit
tests that has a mock file structure allowing the test to
use a fixed list of soft and hard deprecated methods.
Bug: T374832
Bug: T371167
Change-Id: Ic4933cef95ef1af7fa3939625ac1747106c71230
A constant is not a variable. The type is hard-coded via the value
and can never change. While the extra @var probably doesn't hurt much,
it's redundant and error-prone and can't provide any additional
information.
Change-Id: Iee1f36a1905d9b9c6b26d0684b7848571f0c1733
Why:
* Maintenance scripts in core are mostly untested
* Increasing this test coverage, especially for more critical
scripts, will help avoid bugs and regressions.
What:
* Add tests for renameUsersMatchingPattern.php
* Expand tests for renameUser.php
* Add TestSelectQueryBuilder::assertFieldValues, which is used
to assert against the result of ::fetchFieldValues.
Bug: T371167
Change-Id: I0470c53df7f31ae4891c33aeb5ba6e308bdcdac6
For a private function the $fname does not need to be optional,
it should be easy to pass it always.
Change-Id: Ifcddcd2479ae6f8bbf68210441c61ee7a45e1489
Remove unused $db parameter and make the $cluster required. Update
the checkStorage.php callers to provide the cluster.
Use the getTable() method in trackBlobs.php to avoid duplication.
Mark this method as @internal to the class and /storage scripts.
Change-Id: I888040a536a60e22e780900a59e4c34b6c468cdf
The variables on the converter are not usable outside of the class,
so making the public ones also private.
Change-Id: I6087dcdac761916359009548beb5210671a32ee5
