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
