Added to the release notes as a breaking change,
no deprecation period because there are no known
uses anywhere on codesearch
Bug: T248215
Change-Id: If7368ffdd09ab69f7a40501ef9d8a90660db7f58
Following soft deprecation in 1.31, hard deprecation
in 1.35, and removal of remaining deprecated uses,
the entire Revision class, and the tests for it, can
now be removed. This will be followed by a patch to
clean up old references in comments - this is just
dealing with the code.
There were some other tests in RevisionDbTest.php
for Title::getNextRevisionID and Title::getRelativeRevisionID,
which could have been kept, but since those methods are
tested separately in TitleTest, no need to keep these, so
just remove the entire file.
Also remove the RevisionTestModifyableContent and
RevisionTestModifyableContentHandler classes that were
only loaded for use in RevisionDbTest - not sure how
the stable interface policy applies to classes that
are only loaded within tests, so mention that in the
release notes as a breaking change.
Bug: T247143
Change-Id: I05a297d28b85c7413384979f5c908be318098d9d
Some MediaHandler subclasses were setting custom properties on the File
object in order to cache file-associated state. So:
* Add File::getHandlerState() and File::setHandlerState().
* Put them in an interface, which will be used in a subsequent commit in
MediaHandler::getSizeAndMetadata().
* Use them in DjvuHandler.
* Provide a trivial implementation of the interface, for use in testing
and in the subsequent commit.
Change-Id: Ic365384ff13f7898c1203da38c4405abf03d7563
This patch injects services into WikiImporter. It also adds
a WikiImporterFactory service for creating WikiImporter
instances.
Change-Id: I2966297e5728fca1ae8280361f1008cef6c6041b
Basic handler for JPEG2000 files. Both jp2 and jpx are supported by
php's image functions.
No support for:
- metadata
- lossy vs lossless thumbnail
- bucketing
- thumbor
Bug: T161934
Change-Id: I1a72d4dfb034f3ae24661db515cf03b35ec18fa2
These are rows in page_table that have 'page_latest' entry with
corresponding 'rev_id' but no associated 'rev_page' entry in revision
table. Such rows create ghost pages because their 'page_latest' rev is
actually missing or moved to a different page now (which possess the -
associated 'rev_page' on revision table now).
https://en.wikipedia.org/wiki/Module:Jct/city/Chinissai
(page_id=41871839) is an example of such pages. Its page_latest rev is
819371998. But this revision has been moved to another page now
(page_id= 56252475), rendering the former inaccessible.
fb58d39 will prevent this going forward (for scribunto content), but we
need to clear the extant pages for module namespace and others caused
by something else.
Bug: T263340
Change-Id: I51abc295e37030ab181d4380f62c30d7998f1b9e
SearchResultPageIdentity and SearchResultPageIdentityValue were
introduced as placeholders for PageIdentity and PageIdentityValue.
They were marked @unstable, and should be unused now. So we can delete
them.
Depends-On: I7a1dfc26d0985e645c785297c849e4c2854c034b
Depends-On: I7e4f6099083ec0eed8878a67ed1b2ee30b5fe43e
Change-Id: I07d6eb019d4570f293ca12035092705b447aa458
SearchResultPageIdentity and SearchResultPageIdentityValue were
introduced as placeholders for PageIdentity and PageIdentityValues.
They can now become aliases.
Bug: T282091
Depends-On: I9b1ab02e0acf12ace107361ea2c443aa543c4880
Depends-On: Ie405ea9539cd18e15b0abb6db6df64ec0135825d
Change-Id: I6eb55c78a0a72be66814f8bc854ba663e7c6f62b
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
And use it in core
Avoid direct use of super global $_FILES
This can breaks all FauxRequest relaying on $_FILES
in tests or production code via FauxRequest::getUpload.
Falls back to $_FILES for the moment
Bug: T48163
Change-Id: I7392acc9bb682ec6b7025dbed0734c142f45c91a
- 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
CacheTime::mUsedOptions and ParserOutput::mAccessedOptions
do exactly the same thing and has to be merged into a single property.
This patch adds forward-compatibility and needs to be deployed
at least one train before the patch which actually merges the properties.
Change-Id: Ic9d71a443994e2545ebf2a826b9155c82961cb88
When making primitive tests for HookRunner in
I8d0a34e185aad79a391acdd47e506c8911c75257 I've
notived that coverage was not 100% and found that
this hook interface was forgotten.
Change-Id: Ic877fd1f2bbac5a1af708f283e9e0b7a49f89d88
To accommodate PG-unique timestamp format, if there's a
timestamp field in a column, and there's a default value,
the given timestamp will be converted to PG-compatible format
in the final schema output.
SQLite and MySQL use the same format.
Bug: T191231
Change-Id: If344395615087c360597a5b3d66ea03e930b7d9b
Replace existing class with static ::search method
with a service under MediaWiki\User\ and with
dependencies injected
Similar to the creation of the SpecialPageFactory
service, rename the old file to UserNamePrefixSearch_deprecated
so that UserNamePrefixSearch.php can be used for
the service.
Follow-up patches will:
* Inject and use the new service
* Update the release notes
* Replace the use of the UserFactory with UserNameUtils
Change-Id: Ib78b9bdc96c935d75bd03a8af789b8b359c58b07
The NonSerializableTrait prevents object serialization via php's native
serialization mechanism. Most objects are not safe to serialize, and
NonSerializableTrait provides a covenient and uniform way to protect
against serialization attempts.
This patch applies the NonSerializableTrait to some key classes in
MediaWiki.
Bug: T187731
Bug: T259181
Change-Id: I0c3b558d97e3415413bbaa3d98f6ebd5312c4a67
* Makes ParserCache take the root of the key
as a constructor argument
* Introduces a ParserCacheFactory
Next steps:
- convert FlaggedRevs to using this.
- cleanup
This assumes that we wouldn't want to differentiate
the parser cache settings per use-case, as it is now
for default vs flaggedrevs caches. There are only two settings:
$wgParserCacheType - name of the BagOStuff to use
$wgParserCacheExpireTime - the expiration time.
I think if we wanted to have different settings for different
caches, we could add that as a next step.
Bug: T263583
Change-Id: I188772da541a95c95a5ecece7c7dd748395506c2
This allows bad actor IDs to be overwritten with some default. This
solves the problem of rows in tables like ipblocks, logging, or
revision not being found due to a failing join against the actor table.
Bug: T261325
Change-Id: Ibc554d0b6f52e7b30cdde5138ac165774831ec36
The tag is added to reverted edits as described in T254074.
Functionality:
* Adding the mw-reverted tag to reverted edits (duh)
* Limiting the maximum depth of the update through a config variable
(mitigation #2 from T259014).
* Only applying the reverted tag after the edit has been somehow
approved. Only the patrol subsystem currently implements this, but
there's a hook that extensions can use (mitigation #4 from T259014, more
explanation in T259103).
* When performing the delayed update, it is checked whether the reverted
edit was reverted itself. If so, the update is ignored. This is
probably the only way to make the feature work due to the lack of an
explicit "disapproval" mechanism other than reverting.
* The update is also ignored if the revert is marked as deleted.
Technical design:
* The update code is in RevertedTagUpdate.php, which is a deferrable
update, but is not used as such. It's separated to allow for better DI,
testing and better code reusability in the future.
* The update is queued / ran using the Job subsystem. The relevant job
is in RevertedTagUpdateJob.php
* PageUpdater determines whether the edit is approved or not and passes
that to the DerivedPageDataUpdater.
* The BeforeRevertedTagUpdate hook lets extensions decide whether the
update should be ran right away or await approval.
* DerivedPageDataUpdater checks whether the edit is a revert and if so
either enqueues the job (if it's auto-approved) or caches the EditResult
for later use (if it needs approval).
* RevertedTagUpdateManager allows for easy re-enqueueing of the update
for extensions. Thus, it has a very minimal interface.
Other notes:
* The unit testing setup for RevertedTagUpdate is a bit complicated,
but it was the only way I could make this class testable while using
the static ChangeTags class.
Bug: T254074
Depends-On: I86d0e660f0acd51a7351396c5c82a400d3963b94
Change-Id: I70d5b29fec6b6058613f7ac2fb49f9fad9dc8da4
In the past, $wgVersion was the global container used to keep
track of the version of MediaWiki. It was recently moved to a
constant (MW_VERSION).
Sometimes, it's difficult to know the current version of a MW
install unless checked via Special:Version (on the web interface).
This script is to make a quick command line based version checker
of MediaWiki so when someone is working on a patch and wants to
quickly know which version of MW that master is on (as this is
changing from time to time and no quick way to know if by developers).
It's a very simple script and to run it on your command line, do:
`php maintenance/version.php`
and you'll get a response with the MW version number and other info.
Also, it attempts to check that if the version is an LTS and appends
it to the version number and also build date which is the latest commit
tracked by git.
Change-Id: I547f3e7328cf3f18b9d414619b757efc81e63081
This is useful in testing environments where we want to spin up new mediawiki
instances and configure them programatically.
Change-Id: Ice94b67cb8775786a754de51010e78211954b2b0
The method UserEditTracker::getUserEditCount (as well as the old User class
logic it replaced) calculates the user's edit count and writes it to the
database if it was not computed yet. However, it attempts this write even if
MediaWiki is in read-only mode, causing errors as this method is frequently
called on read requests as well.
As a fix, move the edit count initialization to the job queue, which will avoid
trying to open a source DB connection (and thus cause a read-only error) on
installs that do not use the DB-based job queue. This change requires a
workaround in UserGroupManagerTest.
Bug: T259719
Change-Id: I6d1c8e9038ae1f98f47bdb2495aecc21654b24c0
Add 'ready.config.json' to resource
Add 'collapsible', 'sortable' field to be possible override via hook.
In order to override setting, new hook ResourceLoaderPageReadyConfigHook has been introduced.
A new config field for search will follow.
Bug: T250851
Change-Id: I041d4a4b9114f1190f28e0283d96cd33b81f9850
This causes RevisionStore to use FallbackContent instances to represent
content for which no content handler is defined.
This may happen when loading revisions using a model that was defined
by an extension that has since been uninstalled.
Bug: T220594
Bug: T220793
Bug: T228921
Change-Id: I5cc9e61223ab22406091479617b077512aa6ae2d
This maintenance script was obsolete in two ways:
* it tries to parse docs/hooks.txt, which no longer lists hooks.
* it searches for calls to Hooks::run, which has been replaced by
HookRunner.
The purpose of the script, namely listing hooks defined in core,
is covered by the fact that HookRunner implements all hook
interfaces.
Bug: T257804
Change-Id: I6313fe2f4366e09f0408d4d698cf92e8ff792a47
The script is broken in 1.35, since it operates on the rev_content_model
and ar_content_model fields which have been removed.
Bug: T258139
Change-Id: I172c83931a322a908ea8445c883b9333268ceac8
This introduces an ApiWatchlistTrait that refactors out common code
across APIs that allow you to watch pages. Some methods have been
migrated from ApiBase and changed completely, but codesearch suggests
they aren't being used outside the API modules in this patch.
Bug: T248512
Bug: T248514
Change-Id: Ia18627b9824dca81f44f0571e8420d89b7626cf6
These are easy to move. They contain regular, testable, source code,
are loaded only via the autoloader, and have no references to their
file paths from anywhere else in or outside of core (as far as
Codesearch can see).
Change-Id: Ibe94e541637bb273bd11dba6c2bc5b59f601dd19
Follows-up f5aaf75ad1, which introduced the new Hook interfaces,
with some under includes/language/Hook/ and others under languages/Hook/.
Unify under the former.
Bug: T225756
Change-Id: I887f5037771d96f455cc4d0c8aafe185186b917d
Follows-up 61e0908fa2 (I0e4d77de0), which introduced these new classes
in the old languages/ directory instead of under includes/language.
Bug: T226833
Bug: T225756
Change-Id: Ib19db32303c9e2275a0007a3583820c6b1d5529c
The new SkinMustache class is based on the emerging class in Vector.
Having this in core, will allow Vector to make use of this class
immediately and provide a minimal generic mechanism going forward
for rendering skins using Mustache. For now, I've fleshed out the minimum
possible data in getTemplateData which are based on existing functions in
Vector.
The Skin class now takes a generic options parameter which allows
registration of a skin using the SkinMustache class with a templateDirectory
option pointing to the associated template. A `styles` option can be passed
to define stylesheets that should be associated with the skin.
The SkinApi and SkinFallback classes are reduced significantly.
There are no known uses of SkinApiTemplate and it is thus removed.
SkinFallbackTemplate is removed and its functions copied across to
SkinFallback
End user changes:
* The fallback skin no longer prints the confusing warning message if the default
skin is setup incorrectly. Previously viewing the fallback skin with useskin
indicated that wgDefaultSkin was not set correctly which was misleading and confusing.
* Factory functions now receive skin options as a second parameter and the service as a
first - this is due to how ObjectFactory handles the extraArgs key for 'factory' key
- placing it at the beginning.
Bug: T254048
Change-Id: Ibbabd1d0f26efebf8f8ff068966685dc2191c527
There's already a thing called magic words, and this is not it. These
things are called variables. There are many usages of this term in the
source. The term was introduced by Lee in 2002: originally
OutputPage::replaceVariables() contained only this functionality.
I introduced the term "magic word", meaning a localizable keyword.
Localizable keywords are an abstraction not limited to this use case.
"Magic variables" is a neologism, but I suppose it is permissible, since
it disambiguates. Whereas calling a variable a magic word conflates rather
than disambiguates.
Fix terminology in magicword.md and update the examples.
Change-Id: I621c888e3790a145ca9978f6b30ff1a8f685b64c
BaseTemplate should not handle anything but rendering.
In order to allow replacing it with another renderer,
such as Mustache or Vue, its hooks should be moved to
the Skin class instead.
BaseTemplateAfterPortlet is soft deprecated to allow
filtering, preventing the hook from running twice.
Both BaseTemplate::getAfterPortlet and ::renderAfterPortlet
have been deprecated as well, with both now calling
Skin::getAfterPortlet after running the
BaseTemplateAfterPortlet hook.
Bug: T253797
Change-Id: I438daa79d3d97e2518e6258c3213a805bd1f30e8
This was introduced in r75446 based on r75429. This is not a
benchmark of MW code, but rather a static comparison of how
PHP performs. I'm not sure that's useful to keep long-term.
For what it's worth, anecdotally it seems on PHP 7.2, the caching
might actually be slowing it down. I speculate this might be due
to the simpler variant being easier to optimise, but it hardly
matters as this function now has a very different implementation,
and if something were to call this so often that its runtime
is significant, the caller should probably just avoid doing that
in the first place. Lexical caching tends to be easier to reason
about in the long run, compared to static/unreleased/uncontrolled
caches.
> Running PHP version 7.2.30 (x86_64) on Linux 4.19 (Debian 9 Stretch)
> BenchWfIsWindows::wfIsWindows()
> count: 100
> rate: 208464.4/s
> total: 0.48ms
> mean: 0.00ms
> max: 0.01ms
> stddev: 0.00ms
>
> BenchWfIsWindows::wfIsWindowsCached()
> count: 100
> rate: 163266.0/s
> total: 0.61ms
> mean: 0.01ms
> max: 0.05ms
> stddev: 0.01ms
Change-Id: Iedd273705b88268f1f4d2632913983cbd1028649
Currently, MimeAnalyzer builds the internal mappings of MIME types <=> file
extensions by concatenating several string buffers in mime.type format into a
giant string, and then parsing it. The mapping of MIME types to internal
media types is built up in a similar way, except we use a dubious homegrown
format with undocumented conventions. It's a mess, and an expensive one --
~1.5% of api.php CPU time on the WMF cluster is spent building these buffers
and parsing them. Converting the mappings to PHP associative arrays makes
them much cheaper to load and easier to maintain.
Doing this without breaking compatibility with existing behaviors requires
some delicate footwork. The current mime.types buffer is made up of the
following fragments, in order:
1) MimeAnalyzer::$wellKnownTypes
2) If $wgMimeTypeFile == 'includes/mime.types' (sic!):
the contents of includes/libs/mime/mime.types.
If $wgMimeTypeFile is another file path (e.g., '/etc/mime.types'):
the contents of that file.
If !wg$MimeTypeFile, this fragment is blank.
3) MimeAnalyzer::$extraTypes (populated by extensions via hook).
The mime.info buffer is built up in the exact same way, except it's
MimeAnalyzer::$wellKnownInfo, $wgMimeInfoFile, and MimeAnalyzer::$extraInfo.
What this means in effect is that some built-in MediaWiki MIME mappings are
"baked in" (anything in MimeAnalyzer::$wellKnown*), and others can be
overridden (anything in includes/libs/mime/mime.*).
To avoid breaking backward compatibility, we have to preserve the
distinction. Thus this change has two MIME mappings, encapsulated in two
classes: 'MimeMapMinimal', which contains just the baked-in mappings, and
'MimeMap' which contains both the baked-in and overridable mappings. We also
have to keep the code for parsing mime.types and the ad-hoc mime.info format,
at least for now.
In a FUTURE change (i.e., not here), I think we can:
* Deprecate $wgMimeTypeFile in favor of a new config var,
$wgExtraMimeTypeFile. $wgMimeTypeFile is evil because if you are using to
add support for additional MIME types, you can end up unwittingly dropping
support for other types that exist in MediaWiki's mime.types but not your
file. The new $wgExtraMimeTypeFile would only be used to add new MIME
mappings on top of the standard MimeMappings, which was probably the
original intent for $wgMimeTypeFile.
* Deprecate $wgMimeInfoFile. I don't think we need to provide a replacement,
because extensions can use the hook, and I doubt anyone is using the config
var. But if we wanted to provide an alternative, we could have a
$wgExtraMimeInfoMap that has an array of extra mappings.
* Deprecate MimeAnalyzer::addExtraTypes and MimeAnalyzer::addExtraInfo, and
provide alternative interfaces that take structured input instead of string
blobs.
I tested this by dumping the internal state of MimeAnalyzer before and after
this CL using the script in Ib856a69fe, using both default and custom values
for $wgMimeInfo(File|Type).
Bug: T252228
Change-Id: I9b2979d3c9c0dee96bb19e0290f680724e718891
Historically skins like MobileFrontend and WhoIsWatching rely on
the SkinTemplateOutputPageBeforeExec hook.
I want to deprecate this and allow direct manipulation of the footer
prior to rendering.
The new hook is named SkinGetFooterLinks.
The existing getFooterLinks method is modified. Given this is a new
function, is protected and final and currently has no usages, this
can be done safely.
MobileFrontend: Id83ef2f2cba1dce940f89125b5cd26a29421ee48
Usage in Vector: I4e89beb96f6401ed7e51bafdf0aac408f5a2c42f
Bug: T251817
Change-Id: Id258b1ec2ae7008fc4d586d0647a5131ec889fe6
There are almost no CDB files left in MediaWiki, and that ones
that remain (commonpasswords.cdb and LCStore support) are
sufficiently large, automated or rarely changed that one wouldn't
be expected to debug them regularly enough to warrant a whole
interactive REPL script dedicated to it.
Note that one can still read these with relative ease using
the eval.php REPL, e.g. using Cdb\Reader::open() and then
calling get($key), firstkey(), or nextkey() etc.
And as of I858dbd5746, a simplified version of this CLI
exists in the wikimedia/cdb library as well.
Change-Id: I20654b91cf15cad512cedeab659ab0dcce5d85f0
Follows-up f5aaf75ad1.
* Improve some docs for these hooks.
* Add type hints.
* Add them as a subgroup within the ResourceLoader docgroup
for easy navigation.
Bug: T246855
Change-Id: I52f31e2b63dcf265b27e68ba8fd4f885d82088ac
Originally submitted as commit 2cdeb26d0c.
This patch is fully backwards compatible. The Maintenance.php entry
point is now a true entry point (i.e. no classes defined), and it requires
all the *Maintenance classes.
Bug: T246780
Change-Id: I75b22f54b19fe560ab71349189598245af1c5693
Add hook interfaces which were generated by a script which parses
hooks.txt and identifies caller namespaces and directories.
Hook interfaces are mostly placed in a Hook/ subdirectory
relative to the caller location. When there are callers in multiple
directories, a "primary" caller was manually selected. The exceptions to
this are:
* The source root, maintenance and tests, which use includes/Hook. Test
hooks need to be autoloadable in a non-test request so that
implementing test interfaces in a generic handler will not fail.
* resources uses includes/resourceloader/Hook
* The following third-level subdirectories had their hooks placed in
the parent ../Hook:
* includes/filerepo/file
* includes/search/searchwidgets
* includes/specials/forms
* includes/specials/helpers
* includes/specials/pagers
Parameters marked as legacy references in hooks.txt are passed
by value in the interfaces.
Bug: T240307
Change-Id: I6efe2e7dd1f0c6a3d0f4d100a4c34e41f8428720
This script scans for content blobs that can't be loaded due to
database corruption, and can change their entry in the content table
to an address starting with "bad:". Such addresses cause the content
to be read as empty, with no log entry. This is useful to avoid
errors and log spam due to known bad revisions.
The script is designed to scan a limited number of revisions from a
given start date. The assumption is that database corruption is
generally caused by an intermedia bug or system failure which will
affect many revisions over a short period of time.
Bug: T205936
Change-Id: I6f513133e90701bee89d63efa618afc3f91c2d2b
This class was last used in ~2008 as @tstarling was developing the
original wikitext Parser. It has since code-rotted and wouldn't work
as a drop in for the Parser class any more anyway. We'll probably
(re)invent something similar when we eventually switch Message
rendering from the legacy parser to Parsoid, but this existing code
isn't a good starting point for that; we'll need to tackle T236812
(splitting Parser into a base class) first.
Last meaningful change to ParserDiffTest:
350b498b9f
Code search:
https://codesearch.wmflabs.org/search/?q=ParserDiffTest&i=nope&files=&repos=
Bug: T236811
Change-Id: I98f1ef8ad296791a810bd8b10343f8640fd23c5e
Broken:
ArgumentCountError from line 43 of /home/developer/mediawiki/workdir/
extensions/Translate/ffs/MediaWikiExtensions.php: Too few arguments to
function PremadeMediawikiExtensionGroups::__construct(), 0 passed in
/home/developer/mediawiki/workdir/maintenance/language/checkLanguage.inc
on line 609 and exactly 2 expected
No point fixing this, checks are done on translatewiki.net side.
Change-Id: I9f39684c2ef8479ea35ad1d60e3f1f86d88a8067
This is a re-submit of 35da1bbd7c, which was accidentally merged before
CR (and reverted with aa4da3c2e8).
The purge() method handles purging of both file cache and CDN, using
a PRESEND deferred update. This avoids code duplication and missing
file cache purge calls.
Also:
* Migrate HTMLCacheUpdate callers to just directly using HTMLCacheUpdateJob
* Add HtmlFileCacheUpdate class and defer such updates just like with CDN
* Simplify HTMLCacheUpdate constructor parameters
* Remove BacklinkCache::clear() calls which do nothing since the backlink
query does not actually happen until the job runs
Bug: T230025
Change-Id: Ic1005e70e2c22d5bd1ca36dcdb618108ebe290f3
This allows them to be more easily reused by other Parser implementations
(ie, Parsoid), and helps keep Parser.php compact.
Bug: T236813
Change-Id: I68fb1e786374e445b7df047934c532d7e10b8e94
I confirmed that the LoadExtensionSchemaUpdates hook no longer runs
after the parent patch to fix T249584 is merged, in either sql.php or
patchSql.php.
Note that sql.php is not just a "debugging script", it's intended for
use in production, and was used in production, hence T249565.
Bug: T249565
Bug: T157651
Change-Id: Ia4d99e00e6455eec9cf0fa486ec5e4b83c9cf25d
It's dangerously broken.
This is supposed to be a read-only ad-hoc debugging script but in actually
triggers 'LoadExtensionSchemaUpdates', which is effectively update.php, but
without any of the safe guards, and at a time where you least expect write
queries to happen, let alone administrative queries that drop tables and
run other schema migrations.
Bug: T157651
Change-Id: I8d18a7f5b1731333aa40a9d04dafdb7176cf1d52
Add two methods to remove expired watchlist items:
1. A job that's triggered on about 10% of page edits; and
2. A new maintenance script.
Bug: T244804
Change-Id: Ica8ab92837c38fa4d484726c94d5181c08387e28
For back-compat, keep 'user.tokens' as deprecated alias to 'user.options'
for one release cycle (to be removed in MW 1.36).
== user.options ==
As before, 'user.options' arrives immediately on every page view,
embedded in the HTML. It has an async dependency on 'user.defaults',
which is not downloaded until there is a known demand on
'user.options'. Once that arrives, the implementation closure
of 'user.options' will execute, and the module becomes 'ready'.
== user.options "empty" ==
Before this change, UserOptionsModule used isKnownEmpty to consider the
module "empty" for logged-out users (as well as for logged-in users that
haven't yet set any preferences).
This was a mistake. It is invalid in ResourceLoader to mark a module as
"empty" if that module has dependencies (see also T191596 and c3f200849).
This broke the state machine. The impact was minimal given that it is unlikely
for features to read keys from mw.user.options for logged-out users, which
if attempted would have simply returned null for all keys.
== New HTML ==
The user.options module is always embedded (never empty), and always
has a dependency on user.defaults.
== Cached HTML ==
The cached HTML for anons sets user.options's state to ready without
waiting for any dependency. Per the above, this was already causing
subtle bugs with mw.user.options.get() likely returning null for anons,
which was fairly innocent. For tokens a bottom value of null would be
problematic as the default for tokens must be "+\" instead. To make
sure that is available for cached page views, set this directly
in mediawiki.base.js. The cached HTML does contain an implement call for
'user.tokens' that contains the same defaults, but new code will not
be asking for or waiting for user.tokens, so that is unused.
Bug: T235457
Change-Id: I51e01d6fa604578cd2906337bde5a4760633c027
In order to test functionality dependant on sending emails
Emailer should be introduced as service
Bug: T247229
Change-Id: I4fcceb7860a9a4dda091fb4cffcd2f6950fffaf8
