AbuseFilter needs a class which is almost identical to core's
ActorMigration, so I split out the generic facilities into
ActorMigrationBase, leaving the bits specific to core in ActorMigration.
I changed the way fields and tables are specified so that it's easier to
override in subclasses.
Proper injection of ActorStoreFactory in
ActorMigrationTest::testGetWhere() was necessary to avoid a test failure
due to a teardown issue.
Bug: T278917
Change-Id: I3a6486532f2ef360d1fd01b3a609de71d412f739
All hooks were previously hard deprecated
in 1.35. Affected hooks:
* ArticleRevisionUndeleted - use RevisionUndeleted
* ArticleRollbackComplete - use RollbackComplete
* DiffRevisionTools - use DiffTools
* DiffViewHeader - use DifferenceEngineViewHeader
* HistoryRevisionTools - use HistoryTools
* NewRevisionFromEditComplete - use RevisionFromEditComplete
* PageContentInsertComplete - use PageSaveComplete
* PageContentSaveComplete - use PageSaveComplete
* ParserFetchTemplate - use BeforeParserFetchTemplateRevisionRecord
* RevisionInsertComplete - use RevisionRecordInserted
* TitleMoveComplete - use PageMoveComplete
* TitleMoveCompleting - use PageMoveCompleting
* UndeleteShowRevision - no replacement
Includes a fix for setting the associated rev id
of page protections, which previously was only done
using $nullRevision which was a Revision object created
if any hooks needed it; those hooks were hard deprecated
and so for WMF prod the rev id was not being set.
Bug: T247143
Depends-On: Idfa345193ae99fb2f1c9a8f8d28d8d540a6e3d62
Change-Id: I519167f76a5a3c1f5410415b2721462a3dcc3ec8
Use case: for a list of classes used in a specific context such as
MediaWikiServices, list all files containing these classes, so they can
be processed with command line tools such as grep.
Change-Id: I88dbee72dc5a560624f8cc1da0d905460309f624
* Remove LOCK TABLES. It was probably never necessary, but in any case
we have transactions now.
* Delete updateDoubleWidthSearch.php, it was for upgrading from 1.17 or
earlier, which is no longer supported. Revert the move of various
updateSearchIndex.php functions to Maintenance. Nothing has ever used
these except updateSearchIndex.php and updateDoubleWidthSearch.php.
* Convert the query to use the new Database:select() method.
* Remove migration from searchUpdate.pos to searchUpdate.wiki.pos, which
was put there to support upgrades to 1.16.
Bug: T252853
Change-Id: I19bb44a9a46c2ebdb16a777bb462375278b05b7b
== Adding --skip-message-purge
Follows-up d91c6627a9. Per CR and Phab comments, I don't think we
can (yet) promise a generic "--offline" mode. This seems too easy to
misuse. Both for users of the script, as well as for future development
to the script. It can fall out out of sync with requirements of the
overall system and leaves no natural place to discover what
responsibilities are being deferred and how the operator should fulfill
those duties.
We know LCStoreDB doesn't work offline, but there are likely other
aspects of this that don't yet work offline for some users. It would
require a much more rigorous refactor (and dropping signifant extension
hooks) to make this reliably offline. I'd welcome a standalone script
using only vendor libs, that does nothing other than scan directories
and build JSON/PHP/CDB files, but that's not what it is today.
What we can do is skip the one operation we know requires a live
DB connection, and (my main motivation for this commit) then document
that skipping it, require the user to perform the purge by other means
instead, since the purge itself is not actually optional.
Also, make this not a WMF-specific option in MW core, by committing
the accompanying script needed for this to work. This was previously
in the WikimediaMaintenance extension as "refreshMessageBlobs.php".
== Keeping --offline (as --no-database)
As far as I know, the purge is the only action we ran into that needed
a database connection, and important to note was that it's not optional.
I think for WMF we did not run into any other logic in our configuration
that uses a database, so --skip-message-purge should suffice. However,
I've kept the option for two reasons:
1. To recognise in some way the business need for WMF to use this
script in an offline manner, and thus document that the script
should at least have a way to work offline, even if there may be
site configurations and extensions that make this impossible, from
a core perspective we want to (experimentally) try to support this.
2. There is unimportant setup logic that happens in doMaintenance.php
where the service wiring for LBFactory is activated by default.
This seems avoidable and technical debt, but at least for now
we do need a way to skip that, so this option will continue to
have that effect.
However, I've renamed the option and inverted its promise. This is not
a promise from core *to* the user to offer an offline mode. Rather,
it is a promise *from* the user that they think nothing DB-needy is in
use.
Bug: T268698
Bug: T263872
Change-Id: I7878fdf4a901fb5e75da540293bb9df9fb508c20
- doCategoryPopulation is not needed nor being called anymore. There's
not much use for the maintenance script either.
- doPopulateParentId ditto.
Bug: T272199
Change-Id: Id7fc111b71e8ee9a37a3e2e56849ac5afeea9f9d
Implements HTMLTagMultiselectField, a form field that instantiates
TagMultiselectWidget, the PHP representation of the OOUI's js-based
widget of the same name with the implemented parameters:
* allowArbitrary
* allowedValues
Bug: T278317
Change-Id: I3a6a30506d493be4185f917c577b3837fffd8ae1
Subclass DBAL\Platforms\MySqlPlatform so that we can override
methods cleanly. Move the current MySQL hack from the schema
generator script to this class.
If 'float' is specified in the json spec without any option, the
FLOAT data type will be used. To use DOUBLE PRECISION (aka REAL)
a 'doublePrecision' option has to be specified and set to true.
No support for specifying arbitrary precision since no current
table is using that and the feature is deprecated in MySQL 8 anyway
Due to T270740, the subclassing is not straightforward because
the base DBAL MySqlPlatform class is renamed in DBAL 3.0.0. For
now a compatibility intermediate class is used as in PG subclass
Other changes: Use switch instead of if/else and remove brackets
in instantiating a class without arguments.
Bug: T191231
Change-Id: I9a5087b1e2afc2b63e30d67ea2ca616f047a0258
This script was introduced in 1.16 to fill log_user_text. We don't
support direct upgrade from this version anymore.
Bug: T272199
Change-Id: I2876a07f906f2e88c3408bcb51b9887e7e3cb3dc
This table was introduced in 1.15 that we don't support direct upgrade
from anymore and it should be already pre-filled since then.
Bug: T272199
Change-Id: I2f74243c813b6c15481fffed65ebc82136017f02
This is only needed for upgrading from 1.15 which we don't support direct
upgrade from anymore
Bug: T272199
Change-Id: I0f716140a5abb5230d6ae19c0e67ce3bcd80e402
This is only needed for upgrading from 1.3 which we don't support direct
upgrade from anymore (and I doubt anyone can run 1.3 now)
Bug: T272199
Change-Id: I3e5140c85265a7bfbe912fc0a40ada0eafcfb7c3
This was introduced in version 1.5 which we don't support upgrading from
anymore and it's already removed from update.php checks.
Also dropping its related maintenance script which is not needed
anymore.
Bug: T272199
Change-Id: I5a755fd04f0e69880f27628fd805f865f4bc86bf
- JavaScriptMinifier: The public interface for this internal class is
ResourceLoader::filter which, except for one caller (minify.php)
is indeed consistently used already, no other callers need replacing.
- CSSMin: Idem for minification, however, this class has some other
method as well, which have a number of internal users, but none
outside core. These have all been replaced in this commit.
- Remove pear/net_url2 as own dependency as this was only used by CSSMin
and recently added there. This is now a dependency of wikimedia/minify
instead. This was not part of the public API and no longer mentioned
here in composer.json or RELEASE-NOTES. (It remains pinned in
mediawiki-vendor, however.)
Bug: T273247
Depends-On: Iadff8c2112d5e53bd994ab4882006e8c644a2379
Depends-On: Id3c6dcc0b952a9efe34b3a9ed88b716101a51f87
Depends-On: I589be910f57289fd908b22db87241b0e52da60d4
Change-Id: I8d71fc64aeecdb31db218b02e361ae9bb0d19b48
Mostly copied from UzConverter.
This is a very simple converter, with bidirectional one to one
correspondence: for every Latin letter there is a corresponding
Cyrillic letter and vice versa. There are no digraphs or punctuation
to convert.
The Latin alphabet is the primary one used for this language today,
and will probably remain so for the foreseeable future, so "tly" remains
the usual code, and "tly-cyrl" is added for Cyrillic.
Language name is changed:
* The main language name is now Latin.
* The word "language" ("зывон") is removed.
* The spelling of the word "Talysh" is based on the Pireyko dictionary.
Bug: T258975
Change-Id: I552e07967ea82e03c413a0b10b129a846aa007c7
This new hook provides for the use case in T47096 (allowing the
Translate extension to transclude a page from another language) by
adding a new hook which would let us deprecate and replace two awkward
legacy hooks (one with an embarrassing capitalization issue). The new
hook is a little more tightly scoped in terms of what it allows and
gives access to, and it uses the new RevisionRecord API.
In addition, the new hook uses LinkTarget instead of Title per
current best practices. (PageIdentity is not appropriate for
reasons documented at the hook invocation site.)
The original BeforeParserFetchTemplateAndtitle (sic) hook allowed
redirecting the revision id of a template inclusion, but not the
title. The only known current use is Extension:ApprovedRevs; the
FlaggedRevs extension replaces the entire function using
ParserOptions::setCurrentRevisionRecordCallback().
Extension:Translate would like to redirect the title as well, possibly
recursively (for a limited number of hops) to handle fallback
languages. That is, when invoked on Foo/fr, including Template:Bar
would redirect to Template:Bar/fr -- and, if that doesn't exist, then
Template:Bar/fr would redirect to its fallback language, say
Template:Bar/en. It uses the top-level page title as context to set
the desired page language. This would require 2 invocations of the
hook; we've set the recursion limit to 3 to provide a little bit
of future-proofing.
The hook added in this patch uses RevisionRecord instead of int
$rev_id, and thus can handle the case where the redirect is to a page
which doesn't exist (by setting the RevisionRecord to a
MutableRevisionRecord with the correct title and no main slot content)
in the fallback language case above.
The new hook deprecates BeforeParserFetchTemplateAndtitle and replaces
ParserFetchTemplate as well (deprecated in 1.35). Code search:
https://codesearch.wmcloud.org/search/?q=BeforeParserFetchTemplateAndtitle&i=nope&files=&repos=
Bug: T47096
Change-Id: Ia5b5d339706ce4084c16948300e0e3418b11792e
Soft deprecated since 1.31, no need for hard deprecation
since it is unused and not stable to create
Change-Id: Ie854f422870e1f7666566544d4ed5df9abe240fb
Add an interface to hold cross-wiki assertion and constants.
This also is a good place to document the expectations.
Currently planned to be implemented by PageIdentity, RevisionRecord,
UserIdentity.
Change-Id: I41a7a82a0386a52a765774ade1ab56a26aaf0741
This script takes an offline XML dump file, containing wikitext pages, and
feeds them through the Preprocessor without actually importing any content
into the wiki as revisions or pages.
The documented purpose of the script is to "get statistics" or "fill the cache".
- I was unable to find any stats being emitted.
- I did find that the called Preprocessor method indirectly writes to
"preprocess-hash" cache keys, which have a TTL of 24 hours (e.g. Memcached).
I could not think of a use case for populating Memcached with parse results
for pages that do not exist on a given wiki.
It was created in 2011 with r80466 (ad8b42449d) without a use case described
or referenced. I suspect it may've been used to help inform the development of
a major change to the Preprocessor around that time, but it doesn't appear to
be needed for that any more, and does not appear to have been aimed at general
usage by site operators. If and when something it is needed for new
developments, it can be easily brought back rather than maintained as-is.
Change-Id: I139aa4ee8c2f92a40e94824c709556dda7ec74ff
Follow-up ba6490aa1e.
That patch worked around $executeContext iteration errors due to the
lack of recursion support in doUpdates()/handleUpdateQueue(). Errors
were triggered by MediaWiki::schedulePostSendJobs() enqueueing deferred
updates that invoke JobRunner::run(), which, in turn, invoke doUpdates()
for each job via JobRunner:: doExecuteJob(). The doUpdates() method was
changed to operate on the sub-queue for the in-progress DeferrableUpdate.
Further improve the recursion logic:
* Use classes for the scope stack and scope queues.
* Put *all* updates added during a DeferrableUpdate::doUpdate() call into
the subqueue, regardless of "defer until" stage or whether it implements
MergeableUpdate. Now, doUpdate() can run *everything* it enqueued instead
of a non-obvious subset. Note that the TransactionRoundDefiningUpdate
that invokes JobRunner was already a POSTSEND update before ba6490aa1eb;
the only effect of this change is that MergeableUpdate instances from jobs
will once again run in doExecuteJob().
* Make recursive DeferredUpdates::doUpdate() calls error out immediately
unless the DeferrableUpdate responsible is a TransactionRoundAwareUpdate
with the TRX_ROUND_ABSENT flag. This covers the schedulePostSendJobs()
scenario and only prohibits insane call patterns. Failing early avoids
the risk of handleUpdateQueue() dropping all the updates due to the same
DBTransactionError error in DeferredUpdates::attemptUpdate().
* Avoid recursion loop in tryOpportunisticExecute() when JobQueueDB is in
use and a large number of tasks are pending. This happened due to methods
like onTransactionPreCommitOrIdle() being used within JobQueueDB.
Mark DeferredUpdates::doUpdates()/tryOpportunisticExecute() as @internal
and create a Maintenance::shutdown() method to avoid a direct call in the
doMaintenance.php file.
Bug: T249069
Bug: T268840
Change-Id: Ib369f0e74243a48ababdb9cd83b155c9a0f5e741
Many files were in the autoloader despite having potentially harmful
file-scope code.
* Exclude all CommandLineInc maintenance scripts from the autoloader.
* Introduce "NO_AUTOLOAD" tag which excludes the file containing it
from the autoloader. Use it on CommandLineInc.php and a few
suspicious-looking files without classes in case they are refactored
to add classes in the future.
* Add a test which parses all non-PSR4 class files and confirms that
they do not contain dangerous file-scope code. It's slow (15s) but
its results were enlightening.
* Several maintenance scripts define constants in the file scope,
intending to modify the behaviour of MediaWiki. Either move the
define() to a later setup function, or protect with NO_AUTOLOAD.
* Use require_once consistently with Maintenance.php and
doMaintenance.php, per the original convention which is supposed to
allow one maintenance script to use the class of another maintenance
script. Using require breaks autoloading of these maintenance class
files.
* When Maintenance.php is included, check if MediaWiki has already
started, and if so, return early. Revert the fix for T250003 which
is incompatible with this safety measure. Hopefully it was superseded
by splitting out the class file.
* In runScript.php add a redundant PHP_SAPI check since it does some
things in file-scope code before any other check will be run.
* Change the if(false) class_alias(...) to something more hackish and
more compatible with the new test.
* Some site-related scripts found Maintenance.php in a non-standard way.
Use the standard way.
* fileOpPerfTest.php called error_reporting(). Probably debugging code
left in; removed.
* Moved mediawiki.compress.7z registration from the class file to the
caller.
Change-Id: I1b1be90343a5ab678df6f1b1bdd03319dcf6537f
Some irritating breaking changes, including dropping PHP 7.2 support
and renaming the classes we care about. For now, hack in via || and
some back-compatibility class aliases.
Bug: T270732
Change-Id: I685f099584d2f0e5fa17f1f4275eab5289c7bfee
This patch implements the BanConverter class for Balinese. Its purpose is to transliterate Balinese in Balinese script to Latin script. Latin to Balinese is not currently supported, because (1) the Latin transliteration is not fully one-to-one, (2) I'm not aware of any users who currently need Latin to Balinese.
The converter supports three distinct Latin transliteration variants: ban-dharma, ban-palmleaf, and ban-puri-kauhan-ubud. All three variants have been requested by different Balinese community members working with Balinese palm-leaf manuscripts. ban-puri-kauhan-ubud is the default, as it is the most familiar to lontar scholars, but Balinese Wikisource users will be able to select their preferred variant via a user script.
Conversion is accomplished via ICU Rule-Based Transliterators, bindings for which are available through the Intl extension.
This patchset adds the abstract class LanguageConverterIcu and has BanConverter inherit from it (makes future ICU-based LanguageConverters easier).
Bug: T263082
Change-Id: Ic3a46a215fbf020a022726e6b130b1d25496e284
DEPLOY: Set $wgOldRevisionParserCacheExpireTime = 0 in production first!
Bug: T267832
Depends-On: I3c73f5d9f6a54e2736600e8f9506659a3fb0e7f6
Change-Id: I0fe275b4991f1bf89c7bb587132bc4fb0ea862e2
Extracts a specialized subclass for rendering the current revision
from PoolWorlArticleView, which then no longer knowes about caching.
In the next step, we will add a subclass that implements caching for old
revisions.
Bug: T267832
Change-Id: I56fb365962951e6c723a01cf9243dbc0094b5581
