When I implemented the ParserOutput merge logic in OutputPage
(I0909ac85c6c785d9089b077a16923c61d6a09996) I realized that
consistent "combine with OR" merge logic for the TOC flag
is obtained only if we invert the flag; that is, the existing
code showed a TOC *if any ParserOutput contained a shown TOC*
otherwise the TOC was hidden.
I'd originally implemented this in
I35e199cca40c0e4359ac493e5806dcf4ae49321c with the opposite sense in
order to avoid having to wait for ParserCache contents to expire:
since the default on most pages was to have the TOC shown anyway, if
"out of date" parser cache entries were missing a HIDE_TOC flag, it
wouldn't be a big deal, whereas if a SHOW_TOC flag were required then
upon deploy all cached pages would lose their TOC rendering.
BUT a better solution is just to let a "parser cache expiration time"
elapse between the time we start generating this flag and the time we
start using it. The existing patch to export this
(I6cf76c870124c162dc1bcbc2f7e9ca0c5fdcd10e) uses
ParserOutput::getTOCHTML() anyway, so we can just wait to switch this
over to use the SHOW_TOC flag
(I10c3d06fb162103c06395bf9d1d27ac3c199d7b6) until the parser cache has
expired.
Anyway, this is a bit of a hassle to switch now, but I think having
consistent merge semantics for ParserOutput flags is worth the
short-term pain.
Bug: T310083
Change-Id: I3b76010f1e2283add629b84bf3824f215f932903
There are two related issues here: first, when parsing non-wikitext
pages for side effects (categories, etc) we want to ensure that any
spurious `===` or `<h2>` on the page don't create nonsense "sections".
We introduce a ParserOption to suppress the ToC in this case; a
follow-up patch will set this parser option from the correct path in
CodeContentHandler and its subclasses. [T307691]
Second, modern skins can generate the ToC on-the-fly outside the
content area, and need to be able to regenerate the ToC from API
output when the page is edited. A ParserOutput flag is added to
mirror the $enoughToc variable from the parser to indicate whether
or not the ToC should be generated and/or updated after edit.
(See I6cf76c870124c162dc1bcbc2f7e9ca0c5fdcd10e for parallel code
to echo this value in ApiParse.)
Bug: T294950
Bug: T307691
Change-Id: I35e199cca40c0e4359ac493e5806dcf4ae49321c
This patch exports the necessary information from the Parser into the
ParserOutput to ensure that the Table of Contents can be properly
language-converted: both ensuring that the target language is correct
(in cases where it differs from the content language) and that various
conversion-suppression mechanisms are functional. When the
ParserCache does not (yet) have the new properties from Parser, the
behavior is unchanged from before (the content language is used, and
its "preferred variant").
This is a follow up to the "quick fix" deployed in
Ic14b3a49a8ee7ed600485d4f8a363a206035a847 to fix an UBN regression.
Parser tests have also been added to verify that ToC conversion
is correctly done (T299973).
Task T303329 has been opened to (eventually) rename the
'core:target-lang' and 'core:target-lang-variant' properties added to
the ParserOutput in this patch.
Bug: T303235
Bug: T295187
Bug: T299973
Followup-To: Ic14b3a49a8ee7ed600485d4f8a363a206035a847
Followup-To: Ib273f88531c340b561072ee9f616aa60725091e6
Change-Id: Ie0f1d7b6daffc8ff47228f6f086a257518f72717
ContentMetadataCollector is a write-only interface defined by Parsoid
that performs the metadata collection functions of ParserOutput. In
order to support asynchronous and out-of-order parses,
ContentMetadataCollector is write-only and merges of fragments are
defined to be independent of merge order.
This provides an initial implementation of ParserOutput::collectMetadata()
which transfers metadata from a ParserOutput to a ContentMetadataCollector.
It is intended that the flags and accumulators in ParserOutput will be
(incrementally) made more regular so that ::collectMetadata() grows
simpler over time.
An optional $strategy argument is added to ::appendExtensionData() and
::appendJsConfigVars() to allow future expansion of merge strategies,
although only `union` is supported for the moment.
The MW_MERGE_STRATEGY_UNION constant will be upstreamed into Parsoid's
ContentMetadataCollector class as MERGE_STRATEGY_UNION; we've added a
prefix to ParserOutput's copy for now to avoid a conflict with the
constant which Parsoid will define.
Bug: T300979
Change-Id: I4e20b84eb590296fb3c011bb4d658d7a65082a11
This is a uniform mechanism to access a number of bespoke boolean
flags in ParserOutput. It allows extensibility in core (by adding new
field names to ParserOutputFlags) without exposing new getter/setter
methods to Parsoid. It replaces the ParserOutput::{get,set}Flag()
interface which (a) doesn't allow access to certain flags, and (b) is
typically called with a string rather than a constant, and (c) has a
very generic name. (Note that Parser::setOutputFlag() already called
these "output flags".)
In the future we might unify the representation so that we store
everything in $mFlags and don't have explicit properties in
ParserOutput, but those representation details should be invisible to
the clients of this API. (We might also use a proper enumeration
for ParserOutputFlags, when PHP supports this.)
There is some overlap with ParserOutput::{get,set}ExtensionData(), but
I've left those methods as-is because (a) they allow for non-boolean
data, unlike the *Flag() methods, and (b) it seems worthwhile to
distingush properties set by extensions from properties used by core.
Code search:
https://codesearch.wmcloud.org/search/?q=%5BOo%5Dut%28put%29%3F%28%5C%28%5C%29%29%3F-%3E%28g%7Cs%29etFlag%5C%28&i=nope&files=&excludeFiles=&repos=
Bug: T292868
Change-Id: I39bc58d207836df6f328c54be9e3330719cebbeb
