Adding Special:Delete and Special:Protect as redirects to the delete and
protect action.
Bug: T295611
Change-Id: Idf076573c0f429171221660145b616ec83516a2a
With recent changes that moves reading the file to Shellbox, it seems
the current memory limit (~300KB) is extremely small and it broke
rendering of basically any DjVu file on the beta cluster, even when Shellbox is
is disabled there.
Until T292322 is resolved, this should stay. If we decide that moving
the file along the wire is better than looking them up in swift, this
should stay forever.
Bug: T275268
Change-Id: I292ee4f0ae79e7bd8afe9578c2ca0c4410c681ca
The goal is to use SettingsBuilder to load settings from JSON files
instead of relying on PHP files that manipulate global variables.
To allow for a smooth transition to the new system, config settings read
from JSON files will be applied to global variables, and it will be
possible to load JSON files programmatically from inside traditional
settings files.
Bug: T294740
Bug: T295500
Bug: T294741
Change-Id: Ibf52c660715fd0e6e67fea5169811ece9ed67cf7
The following User methods, deprecated in 1.35, have been removed:
- ::isIP,
- ::isIPRange,
- ::isValidUserName,
- ::isUsableName,
- ::isCreatableName,
- ::getCanonicalName,
- ::addAutopromoteOnceGroups,
- ::getDefaultOptions,
- ::getDefaultOption,
- ::getOptions,
- ::getBoolOption,
- ::getIntOption,
- ::setOption
- ::listOptionKinds
- ::getOptionKinds,
- ::resetOptions,
- ::getEffectiveGroups,
- ::getAutomaticGroups,
- ::getFormerGroups
User::GETOPTIONS_EXCLUDE_DEFAULTS has been removed, since it is used only in the description of User::getOptions.
Bug: T277511
Depends-On: Ida05c22f81b30d9b46678e8ede3d531c38855d83
Change-Id: I72bbc2336f8ddbc66ce67226cd2d5baaa2f807d8
It has to keep backward compatibility for loading metadata.
Tested locally and works fine.
Bug: T275268
Bug: T192866
Change-Id: Ied61736e329e0e0f37b1db35bd3f7a4b343c01a2
Changes since 2.2.4:
* Fix minify CLI to work from within vendor directory.
* Remove true/false !0/!1 micro optimisation. (T237042)
Depends-On: Id2f2061ac5c7389840b73ad138a91df73a40877f
Change-Id: I1f437781dd8f0cea516693a6e15fe3f95a0aa2ad
Currently for every File page view, if the file is local,
CommonsMetadata extension renders the file page twice -
once to extract the metadata, and once to show the page.
Metadata extraction parse was always uncached, so let's
at least use PoolCounter and ParserCache for this parse.
Bug: T292302
Change-Id: If6e1a1a72d794f4fb87105b7528ea0afe92a585f
Update method name in ContentHandler, soft-deprecate method on Content.
This will require making a semi-backwards-incompatible
change no matter what, we don't really have a great way
of hard-deprecating overriding methods.
Replace all callers of Content::prepareSave in core.
Add tests for ContentHandler::validateSave.
Bug: T287159
Change-Id: I7f23e6e97b1c7d27a6aaefdb88b19b2fc6e8b3a8
It wasn't obvious to me that the mediawiki.org link actually pointed
to specific instructions for resolving the error, as opposed to
just telling the user to search on mediawiki.org. Try to make this
a bit more obvious.
Change-Id: Id9a6cf9ee2520db9d405e17eaf34b10bd72897f3
The new style of checking for the last error during a section of
calls is more robust since it allows nesting of callers. Typically,
an external caller will want to watch a section of code that will
involve zero or more internally watched sections. Errors that are
seen internally (leading to a failing response) should also be
visible externally.
Replace internal BagOStuff clearLastError() calls.
Replace WANObjectCache clearLastError() calls. Such a class should not
clear the error codes since the class is effectively "internal". Callers
that are more meaningfully "external" might want to check the errors.
Cleanup "last" error handling for proxy backends.
Change-Id: I281817a85602967c0ec2bdd23a5d8be101680b64
Slow fatal, before:
> DBTransactionSizeError:
> Transaction spent 3.016772747039795 second(s) in writes,
> exceeding the limit of 3
After:
> DBTransactionSizeError:
> Transaction spent 3.016s in writes, exceeding the 3s limit
Fast debug, before:
> [DBPerformance] Transaction spent 0.015979528427124 second(s) in
> writes, less than the limit of 3
After:
> [DBPerformance] Transaction spent 16ms in writes, under the 3s limit
Test plan:
* Set `$wgMaxUserDBWriteDuration = 3;` in LocalSettings.php.
* Perform a db-writing user action, such as an edit.
* Check mw debug log.
* Set `$wgMaxUserDBWriteDuration = 0.0001;` in LocalSettings.php,
and ensure `$wgShowExceptionDetails = true;` is set as well
(default if using official dev environments, or otherwise
including DevelopmentSettings.php, otherwise check exception log),
or add an artificial delay in DatabaseMysqli::doQuery().
* Perform a user action, and observe the fatal error.
Change-Id: Ice91ad25a836c4d9a824f9c0f6ec8debaad46adc
With a user-friendly error message which uses both technical and
non-technical language, without the irrelevant detail of filebackend
URLs.
Bug: T283045
Change-Id: I8704f405d38acdffae7bd4ea5b91f3f591fc2ebc
