== History of WikiPage::triggerOpportunisticLinksUpdate ==
* 2007 (r19095; T10575; b3a8d488a8)
Introduces the "cascading protection" feature.
This commit added code to Article.php, in a conditional branch
where we encountered a ParserCache "miss" and thus have done a
fresh parse. The code in question would query which templates
we ended up using, and if that differed from what the database
said (e.g. stored during the last actual edit or links update),
then a new LinksUpdate is ad-hoc constructed and executed.
I could not find it anywhere explicitly spelled out, but my best
guess is that the reason for this is to make sure that if the page
in question contains wikitext that trancludes a different page based
on the current date and time (such as how most Wikipedia main pages
transclude news information and "Did you know" information based on
dated subpages that are prepared in advance), then we don't just
want to re-render the page after a day has passed, we also want to
re-do the links update to ensure the search index, category links,
and "WhatLinksHere" is correct, and thus by extent, to make sure
that cascading protection from the main page does in fact apply
to the "current" set of subpages and templates actually in-use.
* 2007 (r19227; 0c0c0eff81)
This adds an optimisation to the added logic that limits it to
pages that satisfy `mTitle->areRestrictionsCascading()`.
Thus for most articles, which aren't protected at all, we don't
run LinksUpdate mid-request after a cache miss page view.
Because of this commit, the pre-2007 status quo remained unaltered
and has remains unaltered to this very day: We don't re-index
categories and WhatLinksHere etc, unless an article edit or
propagating template edit takes place.
* 2009 (r52888; 1353a8ba29)
Introduces the PoolCounter feature.
The logic in question moves to Article::doCascadeProtectionUpdates().
* 2015 (Iea952d4d2e66; df5ef8b5d7).
The logic in question is changed, motivated by wanting to avoid
DB writes during page views.
* Instead of executing LinksUpdate mid-request, we now queue a
RefreshLinksJob on the JobQueue, and utilize a newly added
`prioritize => true` parameter.
This commit also introduces a new feature, which is to queue
RefreshLinksJob also for pages that do not have cascading
protection, but that do satisfy a new boolean method
called `$parserOutput->hasDynamicContent()`, which is set when
the Parser encounters TTL-reducing magic words and functions
such as {{CURRENTDAY}} and {{#time}}. For this new case, however,
the `prioritize` parameter is not set, and this feature is disabled
in WMF production (and other farms that enable wgMiserMode).
This commit also renamed doCascadeProtectionUpdates()
to triggerOpportunisticLinksUpdate().
This commit also removed various documentation comments, which
I've partly restored in this patch, the patch you're looking at
now.
== Actual changes ==
* Rename hasDynamicContent() to hasReducedExpiry() and keep the
previous method as a non-deprecated wrapper.
This change is motivated by T280605, in which I intent to make use
of a Parser hook that reduces the cache expiry. There are numerous
extensions in WMF production that already do this, and thus the
assumption that these have "dynamic content" is already false in
some cases. I'm not yet sure how or if to refactor this so to allow
reducing of the TTL *without* causing this side-effect, but as a
first step we can make the method more obvious in its impact
and behaviour.
I've also updated two of the callers that I think will benefit from
this more explicit name and (current) implementation detail.
Bug: T280605
Change-Id: I85bdff7f86911f8ea5b866e3639f08ddd3f3bf6f
The following methods no longer support Revision parameters:
- CategoryMembershipChange::__construct
- ContentHandler::getUndoContent
- DerivedPageDataUpdater::prepareUpdate
- DifferenceEngine::getRevisionHeader
The following methods were removed entirely:
- Title::countAuthorsBetween
The following methods return arrays that formerly include
a 'revision' key that would emit deprecation warnings when
accessed and return a Revision object. The Revision object
has been removed from the arrays, and the 'revision-record'
key should be used to get the relevant RevisionRecord instead:
- PageUpdater::doModify
- PageUpdater::doCreate
- Parser::statelessFetchTemplate
The ParserOptions `templateCallback` option is a callback
that is called in Parser::fetchTemplateAndTitle() and should
return an array - the 'revision' key to that array used to
be a Revision object and was used if no 'revision-record'
was returned - it is now ignored.
Bug: T247143
Change-Id: I163ada88d649c75697aff4fa31a3a3c0bdef78b7
All hooks were previously hard deprecated
in 1.35. Affected hooks:
* ArticleRevisionUndeleted - use RevisionUndeleted
* ArticleRollbackComplete - use RollbackComplete
* DiffRevisionTools - use DiffTools
* DiffViewHeader - use DifferenceEngineViewHeader
* HistoryRevisionTools - use HistoryTools
* NewRevisionFromEditComplete - use RevisionFromEditComplete
* PageContentInsertComplete - use PageSaveComplete
* PageContentSaveComplete - use PageSaveComplete
* ParserFetchTemplate - use BeforeParserFetchTemplateRevisionRecord
* RevisionInsertComplete - use RevisionRecordInserted
* TitleMoveComplete - use PageMoveComplete
* TitleMoveCompleting - use PageMoveCompleting
* UndeleteShowRevision - no replacement
Includes a fix for setting the associated rev id
of page protections, which previously was only done
using $nullRevision which was a Revision object created
if any hooks needed it; those hooks were hard deprecated
and so for WMF prod the rev id was not being set.
Bug: T247143
Depends-On: Idfa345193ae99fb2f1c9a8f8d28d8d540a6e3d62
Change-Id: I519167f76a5a3c1f5410415b2721462a3dcc3ec8
Typehinting parameters that take the return value of these methods
with Language is not safe as they may return global $wgLang which
may or may not be instance of Language.
Bug: T278429
Change-Id: Ia5a71e4c39124f4427bd816e6e19207bb371cc6b
Initializing the preprocessor in the constructor allows better
dependency injection, and removes code complexity caused by
lazy initialization. Any use of the parser is going to end
up creating the preprocessor in any case, so deferring the
initialization doesn't save any performance. (Best performance
is given by not creating the Parser in the first place if it
is not needed, which is what DI allows.)
Old code tried to unbreak cyclic dependencies by setting the
preprocessor to null. This is somewhat of a lost cause,
since there are a number of other cyclic dependencies
involving the parser, including StripState, LinkHolders,
etc. The code complexity is not worth it, given how
ineffective it is in any case.
This is part of T275160 in so far as it allows
Parser::getPreprocessor() to be a simple getter, and thus
(once this patch is merged) we can safely replace any
direct access to Parser::$mPreprocessor with a call to
Parser::getPreprocessor().
Bug: T275160
Change-Id: I38c6fe7d5a97badffdbf34d8b9d725756ed86514
This property was deprecated in 1.35.
Code search:
https://codesearch.wmcloud.org/search/?q=mTagHooks&i=nope&files=&excludeFiles=&repos=
Dependencies below are for WMF-deployed code. Other uses in
non-WMF-deployed code have been patched in:
* I435b0d1ccae9d9bf6fff85dc3e79d3c4b447eb37
* I85ef0e6ce3f0c818df85809d39259d13b56d966c
* Idab6c9475f78ff4040061f2f317560bbe41666d8
Bug: T275160
Depends-On: Ic5445471d770e396421a4fb2bcfbe1490a77e1bf
Depends-On: Ib708e3f84aa871de84aa56561c875f4a85bb000c
Change-Id: I42e23b101e870b66d169cbb731a0359e90f46265
This has effectively been the case since 1.35; this just cleans up the
remaining code which assumed it still needed to explicitly call
Parser::firstCallInit() on a newly-constructed Parser.
Bug: T250444
Change-Id: I340947c721172f12ff413322b4283627c0b0b3a4
A number of different argument variants were deprecated in 1.34,
and direct calls to the Parser constructor were deprecated at the
same time (a ParserFactory should be used instead). These were
hard-deprecated in 1.35. They should be safe to remove now.
Code search:
https://codesearch.wmcloud.org/deployed/?q=new%20Parser%5C%28&i=nope&files=%5C.php%24&excludeFiles=&repos=
Bug: T236811
Change-Id: I58f7b3ba1b1d62851b2db71197a8d9129e8d473d
Choosing a particular encoding of HTML entities is logically a task
of the Remex formatter (which serializes HTML). Move it out of the
Parser so that it is part of the serialization specification.
This is a follow up to Ic8965e81882d7cf024bdced437f684064a30ac86.
Change-Id: If45907baf24d60987b39cd1f7709c5f7caf19f37
- When assigning multiple variables, use multiple statements
- Separate function calls with multiple variables over multiple
lines to make them easier to follow
- Reduce indentation via an early `continue` statement
Should be a no-op
Change-Id: Ib1d625a356cd914db2da29f8178a0568eb6e2aba
This also means we don't need to take special care for French spacing in
attributes, since it's no longer applied there.
Adds a test that captures this change.
Note that the test "Nowiki and french spacing" wonders whether this
escaping should be applied to nowiki content.
Bug: T255007
Change-Id: Ic8965e81882d7cf024bdced437f684064a30ac86
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
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
Make the caching logic use getWithSetCallback() and simplify
the code given that there is only one Preprocessor subclass.
Also, keep the cached values JSON serializable but rely on
the serialization in BagOStuff instead for simplicity.
Add related class constants for injecting preprocessor flags.
Bug: T254608
Change-Id: I72f9f0c0bc352ed5120469090c71294ff0c24999
Currently MediaWiki turns `[[test, abc]]` to `[[test, abc|test]]`
while saving the page but that comma isn't in use in Persian
so this patch makes MediaWiki to treat Arabic comma the same way
as regular comma.
Change-Id: Ib8051023abc25b7c4f97a3f50246f35650057ec9
Document and enforce the correct type for the first argument to
a Parser tag hook, which will be `null` if the tag is self-closed.
Mark the methods in CoreTagHooks @internal. They are apparently
unused outside MediaWiki core:
https://codesearch.wmcloud.org/search/?q=CoreTagHooks&i=nope&files=&repos=
Add coverage test cases to ensure that all tag hooks properly handle
the `null` value of the first argument; prior to this patch the
`<html>` tag emitted a broken strip tag in this case. The other hooks
passed the null to other callees in violation of their type
signatures, but eventually every other hook managed to safely cast the
null to the empty string without throwing an exception or emitting a
warning. For those, this patch does not change existing behavior---it
just makes the cast to the empty string much more obvious to the
reader.
Change-Id: I69fde6c06eabb2db27bb1cc23d2cb19b99273391
This issue type was globally suppressed in
I849ac4f120fd15b483e8939d4db45c98dc351259 to make reviewer easier.
This adds inline suppressions or @suppress directives on function
docs for false positives, mostly restoring those removed in
I849ac4f120fd15b483e8939d4db45c98dc351259
Bug: T231311
Change-Id: I1b1d814bd907e9d49fcc39f777982936574fc7c6
Taint check checks for possible security issues by tracking html
escaping and more by using phan.
This slows done the phan-job a bit and requires more ram
Keep the DoubleEscaped issues out to make reviewer easier
Adds suppression for false positives
Adds taint-annotation to help taint-check
Removes suppression for code phan now understand better by the tracking
of keys in taint-check
Fix some small issues by adding int cast or htmlspecialchars calls
Bug: T216348
Bug: T268920
Change-Id: I849ac4f120fd15b483e8939d4db45c98dc351259
Emit deprecation notices in the constructor
if falling back to $wgUser, and fix core
calls
Bug: T246861
Depends-On: I51117931d527a3bdda468b48de577a7faafbcd69
Change-Id: Ibd0a8ffd0494c17a378cc43e6b6164166130adf4
For example, documenting the method getUser() with "get the User
object" does not add any information that's not already there.
But I have to read the text first to understand that it doesn't
document anything that's not already obvious from the code.
Some of this is from a time when we had a PHPCS sniff that was
complaining when a line like `@param User $user` doesn't end
with some descriptive text. Some users started adding text like
`@param User $user The User` back then. Let's please remove
this.
Change-Id: I0ea8d051bc732466c73940de9259f87ffb86ce7a
This reverts commit a4dc6d82af.
I've reverted the merged patch since I didn't do enough testing
on serialized/reserialized ParserOutput and CacheTime. Now I'm
confident serialization/deserialization works.
Changes since original reverted version:
- Use __get/__set instead of DeprecationHelper in order to
avoid $deprecateProperties array to be serialized.
- Add test for old format serialization new format deserialization.
Change-Id: Ic911c2724ad709931d3316e609781fb89b5b7b28
This reverts commit 799c10b7eb.
Reason for revert: Didn't test how this would work with deserializing stored ParserOutput.
Change-Id: I4221bc26282f3b4bd044f0ab50d00e77eb57ede0
* In preparation for ParserCache/Parsoid integration, it's nice to
do some cleanups. Will untie our hands a bit more.
* Verified no usages in extensions deployed at wikimedia, other then
Flow, fixed in the dependent patch.
Change-Id: Idd78413a36887e2ff5c902d410e55691cafb736b
