Add a new hook, 'RejectParserCacheValue', which allows extensions to reject an
otherwise-successful parser cache lookup. The intent is to allow extensions to
manage the eviction of archaic HTML output from the cache.
Change-Id: I660679a48c46608f859bd52b31d6a888aabcc9ac
Some code paths abuse wfForeignMemcKey() for this purpose. This is semantically
incorrect and seems fragile. Also the empty second argument (for db-prefix) is
either misused or akwardly set to the empty string.
It also creates a namespace conflict between arbitrary application keys (from
the software) and any database names (from users). This commit reduces the
conflict surface down to a single key (namely, "global").
Also added unit tests to assert the implicit restrictions and
assumptions between these cache key functions are valid.
Change-Id: Ia0953b51005fe3de3b881dd1bd64c9d3c85e8c66
This is in preparation for fixing T67402, which requires adding
logic inside this condition block. However the to-be-added code
will influences whether or not a redirect should be made.
In case a redirect is not made, it has to fall through to the next
'elseif' handler in MediaWiki::performRequest(), which is not possible
from inside the 'if' block.
Hence, move it out in a separate block and use a boolean return value
to communicate whether the case has been handled.
This also allows us to unit test this thing. Which is desperately
needed. Albeit ugly as it requires lots of mocking.
Change-Id: If3157f2ff1fd3ab2ca20a5d1f550d864ea62c493
'isParserCachedUsed' implies that the parser cache usage has already occurred,
and obscures the true purpose of this method, which is to determine whether or
not the requested page *should* be looked up in the parser cache.
Only usage in extensions is in TextExtracts, which I changed to be both
backward- and forward-compatible in If5d5da8eab13.
Change-Id: I7de67937f0e57b1dffb466319192e4d400b867de
Since jquery.mwExtension is deprecated, fix the undeclared dependency by making
the module not depend on $.ucFirst rather than by declaring the dependency.
Change-Id: I32b57662464e7dde0f61d6875196764fb61dcfba
Canonical URLs allow webmasters to indicate the preferred URL form for
accessing some content that can be reached via a multitude of URL patterns.
It is usually (but not always) distinct from the request URL, which may
feature things like aliases and session-specific query parameters.
We currently derive canonical URLs from request URLs, which is backwards:
it is the web application, not the client, that ought to know the canonical
way to refer to some content.
This patch ensures MediaWiki derives a clean canonical URL for all wiki
pages from the request context's title object and action.
For some assurance that this is the correct approach, see:
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
This Google blog post identifies Wikia as exemplary in its usage of canonical
URLs. Wikia disregards things like the requested revision ID (oldid=NNN) when
constructing the canonical URL. See, for example:
http://fallout.wikia.com/wiki/Aqua_Pura_delivery_program?oldid=2171222
Wikia goes as far as canonicalizing the action=history to the page view URL.
I think that this is incorrect, because the history and info actions are not
views of the page content, but rather its associated metadata.
This affects all requests where "setArticleRelated" is true. This is typically
all urls that show content (title query, curid, oldid, diff), and all actions
thereof (edit, delete, purge, info, history etc.). It does not apply to
File pages and Special pages.
Bug: T67402
Change-Id: I1549ca056637981a0d751020c634b9fab387f7bc
Reject any edits that attempt to change the content model of a page if
$wgContentHandlerUseDB is false.
Change-Id: Ic2e0ed8f74c3a54864793a457a452f72fe637f73
TinyRGB is an ICC profile released by Facebook under CC0.
It is designed to be fully compatible with sRGB.
It offers the vast advantages of being much smaller than sRGB,
as well as being free as in freedom (the sRGB profile found in the
majority of JPGs is copyrighted).
This change aims to provide the ability to swap sRGB for TinyRGB at
the time thumbnails are generated.
JPGs that use another ICC profile than sRGB or no profile at all are
unaffected.
Bug: T100976
Change-Id: I2ae35ddad4e8a82db8b9541974367dc76c884e7a
Codesniffer says that the `var` keyword must not be used to declare a
property and that visibility must be declared on class properties.
Change-Id: I28240aa0f394588b1df315621dbcd260c51430c1
MediaWiki Codesniffer warns that "Silencing errors is discouraged".
Assuming this was done with good reason, this patch surrounds the
offending line with comments asking codesniffer to ignore the line.
Ironically, silencing errors about silencing errors.
Change-Id: Ib811b03b0a53735ce0da38bc8861ff38f9d1a666
Removes dependency on the generic jquery.mwExtension module I
wrote in 2011 which has rotten and contains largely unused utilities.
Change-Id: Id7025dc2be958840735f4a9a5b020bd876011740
LinkBatch::add already handle the underscore/space part, that means it
is not need to do it on the caller side when adding user names to
LinkBatch
Change-Id: I09e80712903a539164141cc0a88d321203114677
Each user in the file history trigger an own query to get the state of
the user page, talk page and gender information. Use a LinkBatch to
combine all of these queries to two (one for pages, one for gender).
Change-Id: Ic1973c1ccfa17002b343d8c0d110a7c1d20b0460