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
