To follow Message. This is approved as part of RFC T166010.
Also namespace it but doing it properly with PSR-4 would require
namespacing every class under language/ and that will take some time.
Bug: T321882
Change-Id: I195cf4c67bd51410556c2dd1e33cc9c1033d5d18
There are many, many more. I touch only a few where I'm sure it's
never anything but an array of strings.
Change-Id: I8b798f2e9d48f07a241b95ce0ace8fa9d981695d
This addresses the common case patched by
I530d71d0f9279b40a263cd62467d3ef8c76975c3,
If6267f3389b166043fc94d7f952bc54122b1a378 and probably
the code in Article.php from I44045b3b9e78e7ab793da3f37e3c0dbc91cd7d39
by ensuring that "injectTOC" in the options passed to
ParserOutput::getText() defaults to the correct value based on the skin
being used by OutputPage.
Bug: T317333
Change-Id: Ica30569efbb5730eff5b807e8fc34beb2e13e74f
Map values can include JsonUnserializable objects, and strict
(reference) equality comparison of these objects is not going to
reflect value equality. Serialize the values and compare strings
instead; this case should be hit very infrequently given that
rewriting the same extension data key is discouraged.
Bug: T312588
Change-Id: I942e7fa662b2f1a5e32fd55ef65eaa10a22afcfb
The PHP `isset(...)` construct covers a multitude of possible "wrong
types" for the left hand side of an array access, but it still crashes
(with "Cannot use object of type stdClass as array") if the left hand
side is an object.
Bug: T312242
Change-Id: I35026c573fb941004764d46d5652ebcddc559c03
When JSON support was introduced into ParserCache in 1.36, it was
controlled by a feature flag, $wgParserCacheUseJson. The feature flag
was "born deprecated" in 1.36. It can now be removed.
This means that ParserCache will always store entries as JSON.
Support for reading old non-JSON entries remains intact.
This is needed when updating wikis from a version older than 1.36
to the current version.
Change-Id: Id04e42bfb458d98414bac50e0d6c505e8878e5c0
Follow-up to I9d1f0f6bab1305552a0350667d6142a24bc04049. That patch was
not collecting data at all (not even overwriting them over and over
again) - the assignment operation was, in practice, a NOP. This patch
fixes this.
Bug: T303014
Bug: T303015
Change-Id: I7d09b532f3270edf4327c16e032d665353d992f6
NOTE: This changes the HTML returned by the endpoint!
It will now include the id="mwXYZ" attributes needed to
later map to data-parsoid entries.
Bug: T268205
Change-Id: I0a29434b996cc289eb67083e62bd6f1ad750cb4d
Remove the code that outputs self-closing <mw:editsection ... /> tags
in Parser, previously used for transcluded sections.
Remove the ability to handle them in ParserOutput. We don't need
backwards-compatibility with cached content, because that feature did
not work correctly for several years: Remex-Tidy always expanded them
to normal open and close tags.
Remove handling for this case in skin code (and fix documentation).
These are backwards-compatible changes.
Depends-On: Idbf0b95a3c0b04caa056b71dd08f46659920114a
Bug: T306299
Change-Id: I3fac0f34d134d8eec46c7eefa3ad2b67abb957da
Previously:
* It was unclear that generate-html is an optional optimization
* Most of MediaWiki core was doing $parserOutput->setText('') if
html wasn't generated. However this is wrong and will cause
$parserOutput->hasText() to return true and also potentially cause
cache pollution if a content handler both does that and supports
parser cache (Like MassMessage; see T299896)
* The default value of mText in the constructor was '', and most
of the time MW used that default. This doesn't seem right. If
setText() is never called, the ParserOutput should not be considered
to have text
* It was impossible to set mText to null, as $parserOutput->setText(null)
was a no-op. Docs implied you were supposed to do this, so it was very
confusing.
This patch clarifies docs, changes the default value for ParserOutput::$mText
from '' to null, and makes $parserOutput->setText(null) do what you
expect it to. The last two are arguably breaking changes, although
the previous behaviours were unexpected, mostly undocumented and
based on a code search do not appear to be relied on.
It seems like the main reason this only broke MassMessage is most
content handlers either don't support generateHtml, or they don't
support parser cache.
Bug: T306591
Change-Id: I49cdf21411c6b02ac9a221a13393bebe17c7871e
Depends-On: I68ad491735b2df13951399312a4f9c37b63a08fa
Part 1, proof of concept. Hundreds of files left to go. These changes
brought to you in large part by vim macros.
Bug: T305805
Change-Id: I44789091e9f6394c800a11b29f22528c8dcacf71
As part of the project of enforcing uniform semantics for
combining ParserOutput objects (T300979) use standard boolean flags
for the 'index' and 'noindex' index policy metadata.
The forward-compatibility "1.39_wmf.7-ParserCache-*" serialization
test cases have been renamed to "1.39-ParserCache-*" in this commit;
backward compatibility with the prior representation of index policy
will continue to be tested via the "1.38-ParserCache-*" cases.
Bug: T300979
Change-Id: I683e5ae054a0425b03c60a4af8c845b576414c1d
Instead of ParserOutput::$mIndexPolicy, a future MW version
(I683e5ae054a0425b03c60a4af8c845b576414c1d) will use two boolean fields
ParserOutput::$mIndexSet and ::$mNoIndexSet. For parser cache migration
purposes, ensure that core can deserialize the new version so that
rollback are safe.
Add serialization test cases with the new boolean fields as
"1.39_wmf.7-ParserOutput-*"; compatibility with the existing
"mIndexPolicy" serialization will continue to be tested with the
"1.38-ParserOutput-*" cases.
Change-Id: I5e4fc68cea18b31ecb028b3867537dcbd86b93cd
A number of exceptions assume that the ParserAfterParse hook is called
exactly once per top-level page, and use that hook to "finalize"
various write-once properties in ParserOutput, including jsconfigvars.
Unfortunately, ParserAfterParse can't be supported properly in Parsoid
(T303630), which results in legacy extensions using this hook
overwriting extensiondata and jsconfigvars multiple times.
Instead of throwing an exception, restore the previous Parsoid
behavior where the last write wins. This doesn't fix the root cause,
but at least it doesn't regress. Eventually we'll have to deprecate
the ParserAfterParse hook, and when we do so we can add deprecation
warnings to these code paths in ParserOutput::collectMetadata() as
well and eventually remove them.
Noting uses ParserOutput::collectMetadata() except Parsoid at the
moment.
Bug: T303014
Bug: T303015
Change-Id: I9d1f0f6bab1305552a0350667d6142a24bc04049
This allows Parsoid to properly merge jsconfigvars via the external API
(ie, when Parsoid is run in 'standalone mode') when an extension uses
the new-in-1.38 ParserOutput::appendJsConfigVar() method.
Change-Id: I974d9ecfb4ca8b22361d25c4c70fc5e55c39d5ed
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
This reverts commit 0fdd607a84.
This attempt to fix T295187 caused other issues (T303235). A proper
fix is in Ie0f1d7b6daffc8ff47228f6f086a257518f72717.
Bug: T303235
Change-Id: Ib273f88531c340b561072ee9f616aa60725091e6
Content language of specific pages can be changed manually or by the Translate extension.
Bug: T295187
Change-Id: I714711201ba71a2234d625c2e71505973655f36e
This has core implement an abstract interface defined by Parsoid in order
to allow Parsoid to record metadata in ParserOutput without introducing
a cyclic dependency.
Bug: T287216
Followup-To: Ia02c6774c87b13d1ae5a8ed1e55cdd8c88c19b9e
Depends-On: Ie0e358a4910c1946eb4added76318fcacf9308df
Change-Id: I15c0e81185b9957fe097c82e6609a200742ee7d1
The old ParserOutput::getProperty() method returned `false` when a property
was missing. This requires callers to use the `?:` syntax to supply default
values, which then causes any falsey value to be treated as missing.
So, for example, setting the defaultsort to '0' will cause the default
sort to be ignored.
Modern php convention is to use `null` for missing values, and the `??`
syntax is a better/more restrictive alternative to `?:`.
We renamed `ParserOutput::getProperty()` to `::getPageProperty()` in
1.38 (Ie963eea5aa0f0e984ced7c4dfa0fd65d57313cfa/T287216) but kept the
return value convention. Before this actually makes it into a 1.38
release, take the opportunity to fix the return value for the new
`ParserOutput::getPageProperty()` method to return `null` when the
property is missing.
We need to do some temporary workarounds to the places we'd
already swapped over to use the new `::getPageProperty()` method
to allow them to handle either `false` or `null` as a return value;
we'll clean that up once this is merged.
Code search:
https://codesearch.wmcloud.org/deployed/?q=-%3EgetPageProperty%5C%28|T301915&i=nope&files=&excludeFiles=&repos=
Bug: T301915
Depends-On: I3f11ce604970e47b41fc1c123792df8c3045626f
Depends-On: Ie7533f49fe4cad01ebfda29760d23c61e9867b10
Depends-On: Ic5c09f5caa4c897bc553c614fbae9cee159566a2
Depends-On: I0278b2eafd90e77e4fee41c45a1165fb79ddf47e
Depends-On: I383abb6b7dc5e96c0061af13957609f6e31a1065
Depends-On: I79f9f4078e415284af29b15047bafd1c823d7f5b
Depends-On: I02276c48c49f5d2d241a69eb0a6cdf439b572d8b
Depends-On: I71628661b4539a4e35ae32846e719f92bcf782e0
Depends-On: I7e215cb43de0ce150a6bcc00f92481dcdcfed383
Change-Id: Iaa25c390118d2db2b6578cdd558f2defd5351d15
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
Just added the low-hanging fruit: the methods where the return type was
obvious from local inspection.
Change-Id: If6aabfc8f0dacb156167745808fd5c57cdb3eb23
