Three new checks are now applied to user signatures in preferences:
* Disallow invalid HTML and lint errors (T140606)
Since 15e0e9bb4b we can rely on Parsoid to check the signature for
lint errors. (The old PHP Parser doesn't have this capability.)
Most importantly, this will disallow unclosed HTML tags. Unclosed
formatting tags like `<i>` (and also wikitext markup like `''`)
could affect the entire page with the bad markup.
New configuration variable $wgSignatureAllowedLintErrors is added
to allow ignoring some errors. The default value ignores the
'obsolete-tag' error (caused by HTML tags like `<font>` and `<tt>`.)
* Require a link to user page, talk page or contributions (T237700)
Various tools don't work correctly when such a link is missing. For
example, Echo notifications are not sent, DiscussionTools will not
allow replying to these comments, English Wikipedia's SineBot treats
these comments as unsigned.
Such requirement has been present for a long time in many Wikimedia
wikis' policies, but it was not enforced by software.
* Disallow "nested" substitution in signature (T230652)
Clever abuse of "subst" markup and tildes allows users to save edits
containing wikitext in which substitution occurs again when the page
is next saved. Disallow this in signatures, at least.
New configuration variable $wgSignatureValidation is added to control
what we do about the result of the validation described above. The
options are:
* 'warning':
Only displays a warning near the field on Special:Preferences if
the current signature is invalid. Signatures can still be changed
regardless of validity and will be used when signing comments.
* 'new':
In addition to the above, if a user tries to change their signature,
the new one must be valid. Existing invalid signatures are still
used when signing comments.
* 'disallow':
In addition to the above, existing invalid signatures are no longer
used when signing comments.
Bug: T140606
Bug: T237700
Bug: T230652
Change-Id: I07c575c2d9d2afe7a89c4847d16ac044417297bf
The future Parsoid parser will not support this, and it appears to be unused.
It could be reimplemented as an extension tag once it is removed from core.
Code search:
https://codesearch.wmflabs.org/search/?q=allowimagetag&i=fosho&files=&repos=
Bug: T254802
Change-Id: I1b532a7a8794766f8df6fdf375a6ffd78fee94e5
If PoolCounter acquisition would block and a stale ParserCache entry is
available, deliver it immediately rather than waiting for the lock. This
should avoid PoolCounter contention on heavily edited pages.
* Add a fastStale pool option to toggle the feature. False by default
but I'll set the default to true in a followup commit.
* Add a $timeout parameter to PoolCounter::acquireForMe() and
acquireForAnyone(). This requires a simultaneous update to the
PoolCounter extension.
* In the Redis implementation, use the requested timeout for blPop()
but use the configured timeout for data structure cleanup and item
expiry.
* Add a boolean $fast parameter to fallback() which tells the subclass
whether it is being called in the fast or slow mode. No extensions
in CodeSearch extend PoolCounterWork directly so this should not
cause a fatal.
* Pass through the $fast parameter in PoolCounterWorkViaCallback
* In PoolWorkArticleView, use the $fast flag to decide whether to check
the ChronologyProtector touched timestamp.
* Add $wgCdnMaxageStale by analogy with $wgCdnMaxageLagged, which
controls the CC:s-maxage when sending a stale ParserOutput.
* Fix the documented type of the timeout. It really should be a float,
but locks.c will treat non-integers as zero.
A simultaneous update to the PoolCounter extension is required.
Bug: T250248
Change-Id: I1f410cd5d83588e584b6d27d2e106465f0fad23e
This data is the same as the 'credits' data that is already compiled,
cached and made available via ExtensionRegistry.
Similar to various other configuration variables previously, the
$wgExtensionCredits variable is now also required to only be used
for providing input to the system (e.g. from LocalSettings.php,
or from legacy extension PHP entry points). It is no longer
supported to use this variable to reliably read out a full view
of all extension credits (specifically those registered via
extension.json).
Doing so had the downside of adding processing cost to every
web request, as well as taking one the single largest portion
of the ExtensionRegistry APCu cache key, which in PHP7+ incurs
a linear cost for every string value, string key, of every
(sub)array in this huge structure; and does to on every request
just in case something reads from $wgExtensionCredits.
The new method to access this information reliably is owned
by SpecialVersion for now (could be moved elsewhere). This
also makes the merging logic more testable and incurs it on-demand
rather than upfront.
Details:
* Move 'type' internally from NOT_ATTRIBS to CREDIT_ATTRIBS.
These two arrays behave identically for most purposes (they are
both used to mean "don't export this as a global attribute").
By placing it in CREDIT_ATTRIBS it becomes complete and makes
it easy to refer to in docs. Previously, extractCredits()
read the 'type' key outside the loop for CREDIT_ATTRIBS.
* Remove redundant code in ApiBase.php, that is now more obviously
redundant. Looks like a left-over or merge conflict mistake
from when ExtensionRegistry was first introduced.
Bug: T187154
Change-Id: I6d66c58fbe57c530f9a43cae504b0d6aa4ffcd0d
Introduces $wgWatchlistExpiryMaxDuration which is used instead of given
expiry if the given exceeds it. This is done in the storage layer. The
reasoning is to control the size of the watchlist_expiry table. Hence,
the max duration does not apply to indefinite expiries (since that would
mean now row in watchlist_expiry).
The frontend is responsible for disallowing expiries greater than the
max, if it choses to do so.
APIs should now pass in $wgWatchlistExpiryMaxDuration as the PARAM_MAX
setting for the 'expiry' type. They should also set PARAM_USE_MAX so
that the maximum value is used if it is exceeded.
Other APIs that watch pages will be updated in separate patches
(see T248512 and T248514).
Bug: T249672
Change-Id: I811c444c36c1da1470f2d6e185404b6121a263eb
* Add HttpRequestFactory::createMultiClient(), which returns a
MultiHttpClient with configured defaults applied. This is similar to
the recently-deprecated Http::createMultiClient().
* Introduce $wgHTTPMaxTimeout and $wgHTTPMaxConnectTimeout which, if set
to a lower value than their defaults of infinity, will limit the
applied HTTP timeouts, whether configured or passed on a per-request
basis. This is based on the frequently correct assumption that ops know
more about timeouts than developers.
* In case developers believe, after becoming aware of this new situation,
that they actually do know more about timeouts than ops, it is possible
to override the configured maximum by passing similarly named options
to HttpRequestFactory::createMultiClient() and
HttpRequestFactory::create().
* Apply modern standards to HttpRequestFactory by injecting a logger and
all configuration parameters used by its backends.
* As in Http, the new createMultiClient() will use a MediaWiki/1.35
User-Agent and the 'http' channel for logging.
* Document that no proxy will be used for createMultiClient().
Proxy config is weird and was previously a good reason to use
MultiHttpClient over HttpRequestFactory.
* Deprecate direct construction of MWHttpRequest without a timeout
parameter
Bug: T245170
Change-Id: I8252f6c854b98059f4916d5460ea71cf4b580149
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
Follows-up 3ac385a0c3. This was generated by the installer at some
point and we've received two user reports of someone being caught by
this. We don't need to support "unlimited" anymore, but at least make it
do something more sensible, like using the default of 2000.
Previously, it was effectively treating the -1 like 0,
which was causing "debug mode"-like behaviour for end users.
Bug: T251789
Change-Id: I483d5312e6fa25a0b00bb6173ed01eeb99ad42aa
This was previously making calls to various methods during the
Setup.php, which apart from being deferrable logic that isn't
needed on most requests, is also risky/complicated because MW
isn't initialised yet at this point.
Bug: T189966
Change-Id: Iaee3f2af8d18bc5095e9297cbe1b6efc627f3977
This allows indirection between the values in $wgSearchType and
$wgSearchTypeAlternatives where the underlying class name
doesn't match the actual class name that subclasses
SearchEngine.
Bug: T250977
Change-Id: Ib9634128f07d428276e80a6f2f492b850eef17e8
* Move 'hashLevels' docs from $wgHashedUploadDirectory to $wgLocalFileRepo.
* Add docs for the 'deletedHashLevels' option.
* Cross-reference between LocalRepo constructor and $wgLocalFileRepo
so that its option docs can be more easily found.
* Remove the TODO for deprecating 'hashLevels' per T199590.
Change-Id: I19c28fd0c2fb937608963fe0643607b07af69c70
I'm not sure what the benefit was of having this service being injectible
via the constructor. I mean, I wish *all* services would be injected. But
there are more services used in this class, and no other is injected.
Also it seems the only test that was ever setting the ParserCache service
to something else was not even using it: As far as I can see the test
case testJobSpecRemovesDuplicates() is not triggering the code that uses
the ParserCache service.
Change-Id: I65f5c654d36ffecfd914e97cd8069eb99f76c5c6
This setting has been effectively constant since 2008. In modern code
we should be using a ParserFactory instead to customize Parser creation
and not calling the Parser constructor directly (T236811).
Because the ParserFactory is cached, which freezes the current value of
the content language and other options, we need to reset the ParserFactory
object when running parser tests (T248977). Thanks to
Peter Ovchyn <peter.ovchyn@speedandfunction.com> for first uncovering this
issue and suggesting a fix in I4203bf7719a8555a09b72cdb5b1ae7a6e1505acf.
Code search:
https://codesearch.wmflabs.org/deployed/?q=wgParserConf&i=nope&files=&repos=https://codesearch.wmflabs.org/deployed/?q=ParserConf&i=nope&files=&repos=
Bug: T248977
Bug: T236811
Depends-On: I97d58750c91b06eeca5d810509becdf53a39cc95
Depends-On: Idf59cd54146d31c1c32883f4318e6a0bf60e1a8a
Change-Id: I787f22ea9bf59a049b13631ba6974866a1300988
According to \Job::factory() it's not possible for any of the
parameters to be optional. The first is always a Title object, the
second is always an array.
For classes implementing GenericParameterJob the $title parameter is
gone and replaced with a 'title' element in the array. Same here:
the array is not optional.
Change-Id: Idb4ae2f5fb500956b156710dcfe623802c274a3e
Adds <link rel="preconnect"> for the first valid foreign or local file
repo, on pages containing images.
This is a hint to the browser that it should open a connection to the
other host (e.g. upload.wikimedia.org), if it doesn't have one
already. Doing so allows the connection setup to happen before page
parsing is complete, and should result in faster image loading,
especially on slow connections.
Bug: T123582
Change-Id: I2dcc14f05012570a3e41ed8c7064969a4cbfb6db
* Document how wgWANObjectCaches and wgMainWANCache are
used / should be used.
Remove outdated mention of event relayers.
* The easiest way I could document the 'other' options that
wgWANObjectCaches entries can have was by saying which keys
can't be set and that aside from these and class/cacheId
they are all passed on.
However, that wasn't (yet) technically right given we do pass
class/cacheId on blindly, which might be unexpected for
subclasses in theory. Explicitly unset those in ServiceWiring
to avoid any chance of confusion. Also simplify that code
slightly overall in terms of var names and var re-use,
and improve error messages a litle bit.
* Test plan for the wanobjectcache-deployment doc ref:
$ php maintenance/mwdocgen.php \
--file includes/DefaultSettings.php,includes/libs/objectcache/
Then open path/to/mediawiki/docs/html/, click on the docs for
DefaultSettings, and find-in-page to "wgMainWANCache".
Change-Id: I1cfc65c2cc4dbceed6b9777c2b808527a58daeb9
Doxygen's @example is intended for referring to a code file that
contains example code, not for embedding examples inside a doc comment.
@code seems like the best option for the latter.
Change-Id: Ia442ef70492bedd95d6c92cfcfb1786ab9d4573d
It has become apparent that $_SERVER['SCRIPT_NAME'] may contain the same
thing as REQUEST_URI, for example in WMF production. PATH_INFO is not
set, so there is no way to split the URL into SCRIPT_NAME and PATH_INFO
components apart from configuration.
* Revert the fix for T34486, which added a route for SCRIPT_NAME to the
PathRouter for the benefit of img_auth.php. In T235357, the route thus
added contained $1, breaking everything.
* Remove calls to WebRequest::getPathInfo() from everywhere other than
index.php. Dynamic modification of $wgArticlePath in order to make
PathRouter work was weird and broken anyway. All that is really needed
is a suffix of REQUEST_URI, so I added a function which provides that.
* Add $wgImgAuthPath, for use as a last resort workaround for T34486.
* Avoid the use of $_SERVER['SCRIPT_NAME'] to detect the currently
running script.
* Deprecated wfGetScriptUrl(), a fairly simple wrapper for SCRIPT_NAME.
Apparently no callers in core or extensions.
Bug: T235357
Change-Id: If2b82759f3f4aecec79d6e2d88cd4330927fdeca
