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
This class implements EnqueueableDataUpdate and can be pushed as a
job if it fails to run via DeferredUpdates.
Unlike a1f7fd3ada, make RefreshSecondaryDataUpdate skip failing
updates in doUpdate(). Instead of throwing the first exception from
any update, log any exceptions that occur and try all the other
updates. The first error will be re-thrown afterwards.
Also, make sure that each DataUpdate still has outer transaction
scope. This property is documented at mediawiki.org and should not
be changed.
Add integration tests for RefreshSecondaryDataUpdateTest.
Bug: T218456
Bug: T206283
Change-Id: I7c6554a4d4cd76dfe7cd2967afe30b3aa1069fcb
This reduces the size of the class map ($wgAutoloadLocalClasses),
and allows new classes and namespaces to be added without modifying
the class or namespace map as long as they conform to PSR-4.
Adding a PSR-4 mapping for the top-level MediaWiki namespace means that
conforming subnamespaces do not need to be listed.
I did not add some odd or broken cases, since I figure it's better to
fix them by moving the files, which can be done in a separate commit.
I removed testPSR4Completeness, since PSR-4 completeness is no longer
required, that's the point.
Bug: T166010
Change-Id: Ie5e50ecb519b99a1197688c046c7be245ce6da1b
This replaces the client-side compiler for 'mediawiki.template.regexp',
with a simple PHP callback.
The regexp temple compiler is not used anywhere after this and will be
removed in a follow-up commit.
Bug: T233676
Change-Id: I1baa1465d88293d03975cadf2efdd57283427722
Follows-up d4045035b0.
This class was added to the MediaWiki\Special namespace, contrary to the
plan in T166010 which reserves that namespace for core special pages.
Instead, use MediaWiki\SpecialPage, following the directory in which it
is located.
Also, fix two bugs which prevented the introduction of a namespaced
class alias.
Bug: T166010
Change-Id: I6e31340aaae32a89beb7e45b79d76a7fea9808d2
