Avoid polluting the parser cache with skin-dependent output from
Skin::doEditSectionLink() by introducing getRawText(), which provides
access to the uncooked text. Use this in
WikitextContent::fillParserOutput() which is the primary offender
judging by the debug logs (see referenced bug).
Bug: T124356
Change-Id: Ia9e1e4a6dc3a26f88eeebc64eed023ff20c53d58
Remove ParserOutput::getSecondaryDataUpdates and
ParserOutput::addSecondaryDataUpdate
Deprecated since 1.25, slated for removal in 1.26 but not done.
Change-Id: Id5e41003fe47b55f493f636c69c9b31932cde9b8
This change only improves documentation, it does not touch code.
For reference:
* CoreParserFunctions::displaytitle generates HTML, with &, < and so on
property escaped. OutputPage::setPageTitle() treats the input as wikitext,
which works for both plain text and HTML.
* Wikibase calls ParserOutput::setDisplayTitle() with HTML including <span>
structures.
In the API action=query&prop=pageprops returns HTML. There doesn't seem to
be a good place to document that fact, though.
Change-Id: I043b26b82f066abe2830a81d3bc073543b3748d8
This change adds the possibility to enable OOUI out of the parser,
which enabled parser tag functions to easily enable OOUI, if they
need it, for every page view out of the function that handles the
parser tag.
Bug: T106949
Change-Id: If1e139d4f07be98e418e11470794ea42e8a9b2eb
This might work in specific cases, depending on the string we're
quoting, but is never correct. The instance in SpecialAllMessages.php
was resulting in incorrect behavior (and log spam, T103879).
Searched for this regex: preg_quote\((?:\([^)]+?\)|[^,()])+?\)
Change-Id: Icc88775970f4927ddf953e5ad7c5c19d59491573
This is a hard deprecation, with getSecondaryDataUpdates returning an
empty array and addSecondaryDataUpdate throwing an exception. This seems
prudent since there are no known users of these methods, and they
interfere with the parser cache:
DataUpdates are basically jobs, they need access to services to
function. That makes them inherently non-serializable. This interferes
with the function of the parser cache, which serializes ParserOutput
objects in order to persist them.
This could be solved by splitting DataUpdates into DataUpdateDefinitions
and DataUpdateHandlers, similar to how JobSpecification works with
wgJobClasses. That however seems pointless and overkill, since
ParserOutput already has a mechanism for storing arbitrary data,
including any info needed by an UpdateJob: the setExtensionData method.
After this change, the preferred method to introduce custom data updates
is to store any relevant data using setExtensionData and
implement Content::getSecondaryDataUpdates() if possible. If not,
use the 'SecondaryDataUpdates' hook to construct the necessary update
objects from the info stored using setExtensionData.
Change-Id: I0f6f49e61fa3d8904e55f42c99f342a3dc357495
* Use special prioritized refreshLinksJobs instead, which triggers when
transcluded pages are changed
* Also added a triggerOpportunisticLinksUpdate() method to handle
dynamic transcludes
bug: T89389
Change-Id: Iea952d4d2e660b7957eafb5f73fc87fab347dbe7
* Use special prioritized refreshLinksJobs instead, which triggers when
transcluded pages are changed
* Also added a triggerOpportunisticLinksUpdate() method to handle
dynamic transcludes
bug: T89389
Change-Id: I8e5a6ddb643c12e0fb5c1c68bc83f912944e6e8d
This demonstrates how we can transition from extensions putting
things into the global scope ($wgTrackingCategories) to instead
storing them in the extension registry. This will increase the
overall performance of the extension registry since it no
longer needs to do an array_merge with $wgTrackingCategories.
For extensions already converted to using the registry
no change is needed as the schema is still the same.
Change-Id: Ie0df4c20b123dac784a1c02eb991edc609a911b6
My previous patch broke this: ApiStashEdit would stash ParserOutput
with no custom DataUpdates, but calling getSecondaryDataUpdates still
failed after unserialization. This patch should fix that.
Bug: T86305
Change-Id: Ic114e521c5dfd0d3c028ea7d16e93eace758deef
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Page status indicators are icons (or short text snippets) usually
displayed in the top-right corner of the page, outside of the main
content. Basically, <indicator name="foo">[[File:Foo.svg|20px]]</indicator>
may be used on a page to place the icon in the indicator area. They
are also known as top icons, page icons, heading icons or title icons.
I found the discussion on bug 23796 highly illuminating. I suggest
that everyone read it before suggesting different design choices.
I spent some time with a thesaurus pondering the name. "Emblems" and
"badges" were also considered, but the former has a much more limited
meaning and the latter is already taken by Wikidata, with a similar
but subtly different feature set. I am not aware of any naming
conflicts ;) besides new talk page message "indicator" (used by core
and Echo in some documents) and OOjs UI indicators (tiny icons like
the arrow on a dropdown form element), which shouldn't be confusing.
Potential use cases include:
* "Lock" indicators for page protection levels
* Featured/good article indicators
* Redirect shortcuts display ("WP:VPT")
* Links to help/manual for special pages
* Coordinates?… or globe icon for inline pop-up maps
Design features:
* Skin-customizable. Skins can fully control where and how indicators
are shown, or may just do <?php echo $this->getIndicators(); ?> to
output the default structure. By default they are not shown at all.
* Extension-customizable. Extensions can call ParserOutput::addIndicator()
to insert an indicator from one of the numerous parser hooks.
* Wiki-customizable. In addition to just using the parser functions,
on-wiki styles and scripts can use the provided classes and ids
(.mw-indicator, #mw-indicator-<name>) to customize their display.
Design limitations:
* Every indicator must have a unique identifier (name). It's not
possible to create arrays, or to have several indicators with the
same name. In case of duplicates, the latest occurrence of the
parser function wins.
* Indicators are displayed ordered by their names (and not occurrence
order). This ensures consistency across pages and provides a simple
means of ordering or grouping them.
* Indicators are not stored, tracked or accessible outside of
ParserOutput (in particular they're not in the page_props table).
They are intended to merely reflect the content or metadata that is
already present on the page, and not be data themselves. If you ever
think you need to list pages with a given status indicator, instead
figure out what it means and use the appropriate tracking category,
special page report, already existing page_prop, or other means.
Corresponding patch in Vector: I90a8ae15ac8275d084ea5f47b6b2684d5e6c7412.
I'll implement support in the other three skins included in the tarball
and document it on mediawiki.org after this is merged.
Bug: 23796
Change-Id: I2389ff9a5332a2b1d033eb75f0946e5241cfaaf4
addTrackingCategory is more in line with ParserOutput's functionality
(addLink, addCategory etc), and tracking categories are useful even for
content types which do not use the parser at all. There is no reason to
require the caller to obtain a Parser object just to be able to add
tracking categories.
Change-Id: I89d9ea1db3a4e6486e77eee940bd438f7753b776
As of <https://github.com/facebook/hhvm/commit/0f98cab>, it is possible to
call getrusage( [ int $who = 0 ] ) with $who = 2 to request resource usage
info for the current thread (RUSAGE_THERAD), rather than the calling process
(RUSAGE_SELF). (Earlier versions of HHVM return RUSAGE_SELF data unless $who
is 1.)
PHP5 code can assume that each request is handled in a dedicated subprocess,
but the same is not true of HHVM, which is multi-threaded. Therefore, to get
resource usage data for the current request context, it is necessary to ask
for RUSAGE_THREAD rather than RUSAGE_SELF.
To do this, introduce a new global function in Profiler.php: wfGetRusage().
It is defined there and not in GlobalFunctions.php so that it can be used early
in WebStart.php.
Bug: 70227
Change-Id: Ibe9598ecdfc0f6c434f8b3c7a94f06a7b2fcca23
In Parser.php an array was built and then the elements of that array
were used, replaced this by local vars.
In ParserOutput.php also use local vars to make the code more readable.
Also inlined a private callback by using an anonymous function.
Change-Id: I1c31c9e4855f93a8fb65e1c21faba46fcdcb1f4b
Special page transclusion returns an OutputPage, whose metadata is
copied into the ParserOutput, and then later back into an OutputPage.
The "preventClickjacking" flag should be part of that metadata.
Bug: 65778
Change-Id: I17d2720fb94bb383a92059e5adbf6c16ee3e9ef4
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I8ebfbcea0e2ae2670553822acedde49c1aa7e98d
I would love to make this getter return null instead of false,
similar to getExtensionData() in the same class. A property that's
not set should be null. Not a boolean. This makes it impossible to
have boolean properties. But I can't change this because it's used
in extensions with "!== false" and such.
Change-Id: I2bc0bed1c58435d791f7a055bac2763a3411bb6f
Remaining are the classes containing underscores and possibly a few other
issues that will be addressed soonish.
Change-Id: Icf56374c71afc134420ebbcfecf12dcb29dc9564
This adds the pp_sortkey column to the page_props table.
pp_sortkeys allows for top-k queries for pages, e.g.
the 100 pages with the most language links, etc. It is also
possible to query for exact values.
For now, pp_sortkey will contain pp_value's numeric value if
the value was set to a float, int or boolean.
Associated tasks:
* create a maintenance script for populating pp_sortkey. Tricky,
because when reading from the database, all values are strings.
* create an API module for querying pages by property value.
bug: 58032
Change-Id: I217c42656fb877ff35a36eb446a22bdaf119faac
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I49f8f48b521878de7abd9cc40efdeff6cf9a37e0
The OutputPage has variables for modules, moduleScripts, moduleStyles,
moduleMessages and the config vars, but the ParserOutput is missing the
last one.
With ParserOutput::addJsConfigVars it is possible to add scripts and it
config vars at one place and have not use the MakeGlobalVariablesScript
hook or other ways to get the needed javascript variable in the output.
Change-Id: I6ad61cca76805f6b9d76e053c98c7509c323d5da
