I set up a local test instance with RedisLockManager, but some things
seemed more complicated than they needed to be. So:
* Add lockManager option to $wgLocalFileRepo, which becomes the
lockManager of the auto-generated file backend.
* Made srvsByBucket be optional. I made the same change to the identical
code in MemcLockManager and DBLockManager, but I didn't test them.
* Improved doc comments for RedisLockManager::__construct() and
$wgLocalFileRepo.
Change-Id: I8ce430b8e849589d4ea87c90a56ee3659da085a0
$wgLocalHTTPProxy can be used to configure a reverse proxy
for requests to domains in $wgLocalVirtualHosts. The previous
implementation of using it as a proper HTTP proxy is no longer
supported and has been reverted out of REL1_37 (856da72363d1ba8bf).
It sets the hostname of the request as a "Host" header, scheme as
"X-Forwarded-Proto" and then sets the proxy's scheme, host and port as
those of the request.
Bug: T288848
Change-Id: Ibc3616f5ad925d464d937ab15461a88619c8b7a7
This is a fairly low-risk right, I think viewing
deleted content (viewdeleted) or OS logs (viewrestrictedlogs)
should be separate from this. The basic grant already has
other low-risk rights, like patrolmarks or abusefilter-log-detail,
so I think it should be fine to add this too.
Alternatively, we can create a new grant instead.
Bug: T292940
Change-Id: Ied76fe0e6f896e56029fb40f1197e87f3f5ff68a
It's already shipped when $wgParserEnableLegacyMediaDOM is disabled, but
having separate config for it will allow us to leave it enabled should
we re-enable $wgParserEnableLegacyMediaDOM and still have content in
the cache that needs styling.
Bug: T292498
Bug: T51097
Change-Id: I027d3a718b0c1a3eebe4b55983540ad2f28d229a
$wgShellLocale was a flawed solution to the problem of locale
dependence. MediaWiki has its own concept of locale (the Language
hierarchy) and any kind of dependence on the server's libc locale is
incorrect and harmful, leading to bugs. Developers have an expectation
that functions like strtolower() will work in a certain way, and
respecting the locale set in the environment at install time violates
this expectation.
The problems with using C as a locale, which led to $wgShellLocale, are:
* escapeshellarg() will strip non-ASCII characters. This can be worked
around by not using it. The security vulnerability it was trying to
fix can be prevented in another way.
* Shell commands like rsvg will fail to correctly interpret UTF-8
arguments. This is the reason for the putenv(). On Linux, this can
be fixed by using C.UTF-8, which we didn't know at the time. On
Windows, the problem is not relevant (there are unrelated issues
with UTF-8 arguments).
Bug: T291234
Change-Id: Ib5ac0e7bc720dcc094303a358ee1c7bbdcfc6447
If $wgMaxImageArea is false, MediaWiki will no longer check if the image
fits within that area before trying to scale it. Extensions can still
use the BitmapHandlerCheckImageArea hook to override it.
This is primarily useful when using an external scaler like Wikimedia
does with Thumbor, which decides whether it can scale images by using a
timeout rather than based on size.
Codesearch indicates that the only extension checking this setting is
PagedTiffHandler, which will be updated in Iefa67321d07f7.
Bug: T291014
Depends-On: Iefa67321d07f79d982388231e02e87e2f18aed40
Change-Id: Id10173bbddb32bc70e036f426369cfbea52cecf4
Use HTML5 URL fragment encoding (leaving almost all Unicode
characters unescaped) when rendering internal links. Section titles
will still generate an anchor with the old (percent-encoding-style,
with dots instead of percents) fragment encoding, alongside the
HTML5 one, for compatiblity with external links etc.
Follows up I8780bb589002a4 which enabled the HTML5 anchors.
This follow-up was planned for 1.35 but better late than never.
Wikimedia has been using HTML5-first since 1.31 without problems.
Bug: T186267
Bug: T290464
Change-Id: If6696fb33ef95cbd29c944b48588918e8077e9f9
Depends-On: I0c846173c06698eb039ed289ad202fd3539e61a9
The software behind this is abandoned and we are migrating djvu metadata
to json instead.
This doesn't affect production as we already use djvudump
Bug: T275268
Change-Id: If45ae5746ba91ba305f93603dc1e3aafba80a369
As part of our wider work on modernising and making more welcoming the
language we use within and around MediaWiki, now is a good time for us
to rename these configuration variables:
- $wgFileBlacklist is now $wgProhibitedFileExtensions
- $wgMimeTypeBlacklist is now $wgMimeTypeExclusions
- $wgEnableUserEmailBlacklist is now $wgEnableUserEmailMuteList
- $wgShortPagesNamespaceBlacklist is now $wgShortPagesNamespaceExclusions
Bug: T277987
Depends-On: I91e065c58fda144a722a41cf532e717f962d7a64
Change-Id: I558a8b20d67d48edccce0d065aec2d22992e9dda
Per IETF RFC 4329 (http://www.rfc-editor.org/rfc/rfc4329.txt),
application/javascript is nominally now the main MIME type for
JavaScript files. See T250370 for some discussion over whether
we should switch MediaWiki to emitting ResourceLoader and page
objects with application/javascript instead of text/javascript
but that's a different matter.
Change-Id: I16fdf38e2b2fb2698b7683687fbc7aa26d40105a
Currently requests to domains listed in $wgLocalVirtualHosts bypass
use of the standard $wgHttpProxy. With WMF's migration to Kubernetes, we
limit outgoing traffic in a much stricter manner, so even internal
requests will need to go over a proxy (e.g. Envoy).
If the domain passes MWHttpRequest::isLocalURL(), then $wgLocalHTTPProxy
will be used if set, otherwise no proxy will be used (current behavior).
Bug: T288848
Change-Id: Ifd0cbab02fa8f14a82ca34ebc7ad95b2be174434
The $wgLangObjCacheSize configuration variable was added in 2012
with commit 121cf60119. From what I could gather, no-one has ever
needed to change its value. Not for any WMF wikis, not for heavy-duty
special-purpose wikis like translatewiki.net, not for any third-parties
that have public configuration files (e.g. Fandom, WikiApiary, Miraheze),
not for developer environments, and not for test suites.
This follows-up 0484ac9e7a, where the implementation changed
from a FIFO array to use MapCacheLRU (which requires a non-zero size)
and thus introduced conditional complexity and code duplication. This
could be simplified by other means, but it seems like we could just
remove it.
Change-Id: I5143e238857f760f2a2ab6f2e0af174872e9cd43
$wgActions used to map string action names to true,
false, a string, a callable, or an object. Now it can also
be an array (that isn't a callable) corresponding to an
ObjectFactory spec for DI.
This patch converts the revisiondelete and rollback actions to
use DI, with the rest to be converted later. The new structure
of $wgActions is fully backwards-compatible.
We don't yet deprecate Action::factory(), ::getActionName(),
and ::exists(), those will be deprecated in a follow-up.
Additionally, we no longer impose a rule that only some
actions can be overridden on a per-article basis via
Article::getActionOverrides().
Bug: T253078
Change-Id: I0fc3c53d671eced1758458f9a0148180b40c6c9b
Number ranges are common and easily mistaken as telephone numbers by
the data detectors of popular browsers. To link a telephone number,
use the explicit [tel:phonenumber display value] syntax.
If you want to re-enable, set the BrowserFormatDetection configuration
variable to false.
Bug: T256758
Change-Id: I49dff3c084d8c9a66defcdae5a1ffb8f35ba8a93
NOTE: this is a backwards incompatible change which will
need to have corresponding changes implemented in CentralAuth
and probably force-merged.
Depends-On: I4c2170a25ea8b1cf5410a4648ebec66a3ab253f3
Depends-On: I612460ec2c6a038b7155b3f38f3261757ba63b4e
Depends-On: I3b91b333753a877aceb177b7d38f9272a044f055
Depends-On: I9ae86c9a5da66d5857fcea9967012c6bbbfc4d45
Depends-On: I4a08af2227d0dfd833e16469df3f76e397dce669
Change-Id: I67bf4f2442269b8aa1002868ede9a71a5ca43a84
$wgShowSQLErrors and $wgShowDBErrorBacktrace have been
deprecated and immediately made no-op since MW 1.32
Change-Id: I655610ac49cb0a836d0c95aa1e6edc087ebf3f4c
Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59f. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
The old description had some grammatical issues, and did not explain
what it influences or when. Namely, that it considered during manual
purges and overall rebuilds/refreshes. (E.g. it does not cause
update something directly on page views, nor does it kick-off a job
that will upgrade all existing files or something like that.)
Change-Id: Ia2d3f17a9f7c05f816004c619eb9ff1ec45b019b
* Add automatic splitting of large metadata on upload or refresh. If
the reserializeMetadata option is enabled, metadata stored with PHP
serialization will be automatically reserialized to JSON.
* Inject configuration variable $wgUpdateCompatibleMetadata via
LocalRepo instead of accessing it directly.
* In refreshImageMetadata.php and rebuildImages.php, construct a new
LocalRepo with config overrides, instead of overwriting config
globals. Add a helper to RepoGroup to help with this.
* In refreshImageMetadata.php, add new options --convert-to-json and
--split which reserialize metadata and optionally split out large
items to blob storage.
Also, refreshImageMetadata.php was totally broken in the non-force mode
since metadata refresh on page view was disabled in b814245d9f. The
maintenance script was relying on newFileFromRow() magically upgrading
the row, which doesn't happen anymore. So, call maybeUpgradeRow()
directly.
Bug: T275268
Change-Id: I7bf7d9cef71641e287ca4346b568b381f4ada50e
