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 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
Allows .vue files to be used in package modules as if they were .js
files: they can be added to the 'packageFiles' array in module
definitions, and require()d from JS files.
In the load.php output, each .vue file is transformed to a function that
contains the JS from the <script> tag, then a line that sets
module.exports.template to the contents of the <template> tag (encoded
as a string). The contents of the <style> tag are added to the module's
styles.
Internally, the type of a .vue file is inferred as 'script-vue', and the
file is parsed with VueComponentParser, which extracts the three parts.
After the transformation, the file's type is set to 'script+style', and
files of this type contribute to both getScript() and getStyles().
This change also adds caching to getPackageFiles(), because it now needs
to be called twice (in getScript() and getStyles()).
Change-Id: Ic0a5c771901450a518eb7d24456053956507e1ed
