Each of these scripts had a class name that was not referenced outside
of the script file itself, and are safe to rename as a result.
Change-Id: Id605aca11db51ee433baeaa998a0e33184c930ca
Old bugs and such may have left the archive table with multiple rows
using the same ar_rev_id, or rows that also exist in the revision table.
These need to be cleaned up for MCR.
The maintenance script added here will delete rows that appear to be
duplicates of the same change, and will assign new IDs to rows that do
not appear to be duplicates.
Bug: T193180
Change-Id: I39b0825c9469e074ded3df33a4f06a1ef0edb494
Adds a maintenance script to populate the field, has that be
automatically run during update.php, and drops the no-longer-needed
default value on the column (where possible: mssql has some sort of
constraint thing going on that I have no idea how it works).
Bug: T59176
Change-Id: I971edf013a1a39466aca3b6e34c915cb24fd3aa7
The web installer loads extensions during
Installer::includeExtensions(), but then
DatabaseUpdater::loadExtensions() reloads them again. Use a constant
(MW_EXTENSIONS_LOADED) to indicate that we shouldn't load them again.
Also fix a minor issue in loadExtensions() that would accidentally
register a bogus yet harmless hook called 'wgHooks'.
Change-Id: Id72fc0ceea15ccea52b1709bef51918ce64f8b40
This should have been done long ago. Now it is being done.
This also changes ar_text_id to NOT NULL, since it should never be null
anymore, and DEFAULT 0 in preparation for MCR stopping writing it.
Bug: T33223
Change-Id: I18f1c740b7537c7dc3cfeba9b241d0a9f31caa34
Revisions deleted before MediaWiki 1.5 do not have a value in this
field. This is going to be a problem for migration to the MCR schema, so
provide a maintenance script to clean this up.
Then, for good measure, change the schema to make the field
non-nullable.
Bug: T182678
Change-Id: Ie2e11f12a30f379db32c3e074658012c6f93adb0
Per documentation on IDatabase, $conds must be a string or an array.
Passing false for conds is confusing, since it's unclear whether this
should match everything or nothing.
Bug: T188314
Change-Id: I8be1ac4cbdaafc41aadc2a658be8a99b754b0268
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This really should have been done a very long time ago.
This adds a maintenance script to migrate rows with ar_text_id null to
modern storage, either the text table or ExternalStore.
Bug: T36925
Change-Id: I5608c6b6d3ecad516b785e13d668427c1b762e41
We already had modifyExtensionField(), but to do a table modification
you still had to do
$updater->addExtensionUpdate( [ 'modifyTable', ... ] );
Change-Id: I20368bf3c007a01718513a435de24907dc0aaf81
This works by using the new table introduced with T156318.
The only thing that differs from normal Special:Contribs is we are
showing the IP address next to each entry. This is it how it is
displayed if you request to see newbie contributions:
https://en.wikipedia.org/wiki/Special:Contributions?contribs=newbie
For the time being, Special:DeletedContributions does not support
IP ranges. Various other irrelevant links such as Uploads and Logs
are also hidden.
Refer to P4725 for a way to automate creation of edits by random
IPs in your dev environment.
IP::isValidBlock() has been deprecated with this dependent change:
https://gerrit.wikimedia.org/r/#/c/373165/
Bug: T163562
Change-Id: Ice1bdae3d16cf365da14c6df0e8d91d2b914e064
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
The addition of a pp_sortkey field in T60032 necessitates an update
to old entries in the page_props table that don't have a pp_sortkey.
The script uses the pp_value as the sort key if it's numeric.
The script extends LoggedUpdateMaintenance so it only runs once.
Added the script to MysqlUpdater so that it automatically runs.
Bug: T66949
Change-Id: Id482dc73ec1963010324e51fe9273a72dd31a7f7
This introduces the function modifyTable to the DatabaseUpdater class
which will allow to alter multiple columns on the same table in a single
sql patch file. In favor of this new function, usage of
MssqlUpdater::updateSchema for mssql patches is discouraged for the
future.
Also fix T70786, which is about update rows being inserted regardless
whether applying the patch was successful or not (no retry on failure).
Now update rows only get inserted if applying the patch was successful.
Bug: T70786
Change-Id: Id2a1583cd9efa5ef271ae67238119bc24b76a3c6
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Nothing ever looks at these rows, and if you have update.php in a Cron
job or a Git hook or something, they can accumulate in huge numbers.
Also remove a test which verified that the rows get inserted.
If you reached this place while trying to find out what the weird
"updatelist-1.28.0-14628929450" rows in your database are, rest
assured they are useless. If they're causing disk space problems,
you can delete them:
DELETE FROM updatelog WHERE ul_key LIKE 'updatelist-%';
Change-Id: If94f243810e82ea3724cbd47b301bb96ba9a49d9
As an alternative to using magic links, PMID was added to the default
interwiki list.
RFC already existed, but the URL in the default list was pointing to
rfc-editor.org, not the tools.ietf.org view like the RFC magic link or
Wikimedia interwiki map are.
Updating the default lists in maintenance/interwiki* only affects new
installations, so a post-database update maintenance script adds and
updates the two interwiki prefixes.
Bug: T147536
Change-Id: I5a2c2c9b0f989da62a4395c9516d880c7d923444
A "currently-existing category" is defined as a category that either
contains any pages or has a description page. Thus:
* Category::initialize() now schedules an update to insert a row if the
title exits but the row is missing.
* Category::refreshCounts() now removes the row if the title doesn't
exist and the category is empty.
* WikiPage::onArticleCreate() loads the Category object, to trigger
bullet #1.
* WikiPage::updateCategoryCounts() refreshes the counts if it results in
the row showing 0 pages, to trigger bullet #2.
* LinksDeletionUpdate refreshes the counts if the row shows 0 pages, to
trigger bullet #2.
A maintenance script is provided to update the category table for this
new definition.
Bug: T28411
Bug: T50824
Change-Id: I0f0adf124c181ae5d3c7c95b3b5fb275a725794c
Each update should manage its own transactions, which is necessary
when batching is needed. Previously, maintenance updates would try
to nest begin() and an exception would halt update.php.
Bug: T89363
Change-Id: Iaadf847dcef46654e25f89680072dccd4cb5998e
MediaWiki:Foo.json and User:Foo/bar.json pages now have a default
content model of JSON, but existing pages using those names will be set
to defaults of wikitext.
The content models of those pages are now set to "json", unless it has
invalid syntax, in which case it will be set to "wikitext".
For convenience, the script is automatically run as part of update.php.
Bug: T108663
Change-Id: I1412937ccea8e65dba58580beec79cbf2286ae01
The web updater reads LocalSettings.php in function scope to figure out
what extensions have been loaded. This doesn't work for extensions being
loaded through the ExtensionRegistry since they're only added to a
queue.
This adds the ability for the installer to read and get information from
the current extension load queue. LocalSettings.php is still read for
extensions that have not been converted yet.
Other uses of Installer::getExistingLocalSettings() were audited and
determined to be safe with regards to extension usage.
Extensions that register hooks using explicit globals
($GLOBALS['wgHooks']['FooBar']) are still broken.
Bug: T100414
Change-Id: Icc574a38a7947a1e3aff8622a4889e9dcfd7a4b2
