This is the second patch of a series of patches to remove
ParserOutput::getText() calls from core. This series of patches should
be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e.
This patch replaces the calls to getText where the legacy parser is
called directly by creating a pipeline and invoking it on the generated.
These should probably eventually use the Content framework to generate
output instead of using Parser directly (T371008), which will also allow
them to transparently support Parsoid.
Bug: T293512
Change-Id: I45951a49e57a8031887ee6e4546335141d231c18
This is the first patch of a series of patches to remove
ParserOutput::getText() calls from core. This series of patches should
be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e.
This first patch replaces the calls to getText to calls to
ParserOutput::getRawText when the pipeline has no reason to be executed.
Bug: T293512
Change-Id: I0ad53cd074ca9cf13e96e6b08179e13aeea180f4
The main benefit is that this syntax avoids repeating the variable
name. It does the same as before.
Change-Id: I2040be889c749f4e2416ca9948ba261345858af2
get_debug_type() does the same thing but better (spelling type names
in the same way as in type declarations, and including names of
object classes and resource types). It was added in PHP 8, but the
symfony/polyfill-php80 package provides it while we still support 7.4.
Also remove uses of get_class() and get_resource_type() where the new
method already provides the same information.
For reference:
https://www.php.net/manual/en/function.get-debug-type.phphttps://www.php.net/manual/en/function.gettype.php
In this commit I'm only changing code where it looks like the result
is used only for some king of debug, log, or test output. This
probably won't break anything important, but I'm not sure whether
anything might depend on the exact values.
Change-Id: I7c1f0a8f669228643e86f8e511c0e26a2edb2948
This code was partially copied into MassMessage and will hopefully
enable more places that accept arbitrary wikitext to check lint errors.
It also hides the internal details of checking with the Linter
extension's configuration in one place until it can be refactored into
something more acceptable (T360809).
Bug: T368690
Change-Id: Iaeb3ccbd61a2a8cb0d8b3dc8b06a3a10bc8fa653
A single test function can have multiple @dataProviders. No problem.
A @dataProvider can also be used by multiple test functions. No
problem. No need to duplicate such large pieces of code when it's
identical anyway.
Change-Id: I5aea36304ec2d1666ff2334ba883df07a70c15c5
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
Git blame on wfDeprecated() is 7 years old.
Unique name, no sign of it in CodeSearch for MediaWiki & services
at WMF. Couple of CodeSearch hits using the "Everything" filter.
Bug: T362636
Change-Id: I8961ebb3a72b328e839659aeeee3e73512a88dee
I realized that even though we have a lot of ParserCache serialization
tests, and we have unit tests for JsonCodec, we don't have any tests
which bring these together and include JsonDeserializable data inside
ParserOutput objects.
Change-Id: I9dfe1050c18010d1447e77e0670e9e601449b110
This is to make it clearer that they're related to converting serialized
content back into JSON, rather than stating that things are not
representable in JSON.
Change-Id: Ic440ac2d05b5ac238a1c0e4821d3f2d858bc3d76
The validate* maintenance scripts for CacheTime, ParserOutput, and
MessageValue didn't handle 1.xx_wmf* versions correctly, sorting them
*after* the final released 1.xx version. Further, failing immediately
when a mismatch is found in the validate* scripts can mislead maintainers
into thinking only a single mismatch is present.
Change-Id: I4c7bc281c7398d889652a6a1bd9c511d31ffca39
PHPUnit 10 requires test data providers to be static. This patch doesn't
completely do the job, as some providers currently call the non-static
method `$this->markTestSkippedIfPhp()`, but it gets us closer to PHPUnit 10
compatibility.
This also lets us simplify the validateParserCacheSerializationTestData
maintenance script and make it slightly more generic.
Change-Id: Ie3696bfaa29aca9da45f54239126222e8c847ea9
I don't think these do anything with the documentation generators
we currently use. Especially not in tests. How are tests part of a
"package" when the code is not?
Note how most of these are simply identical to the namespace. They
are most probably auto-generated by some IDEs but don't actually
mean anything.
Change-Id: I771b5f2041a8e3b077865c79cbebddbe028543d1
With the precise expiration computation for magic words like
{{CURRENTYEAR}} there's the potential for all the pages which
use (say) {{CURRENTYEAR}} to expire at the exact same time,
causing a cache stampede.
I9acb42b0d9ff67798a1624cbf9c7cac99c8fbe2f added code to "randomly"
stagger the cache expiration:
$ttl += ( $deadlineUnix % self::DEADLINE_TTL_STAGGER_MAX );
However, this "stagger" was not actually random, since it is
based on the computed deadline. So all of the pages which use
{{CURRENTYEAR}} will all compute the same `$deadlineUnix` (midnight
of January 1st of the next year) and thus compute the same "stagger".
Change $deadlineUnix to $tsUnix so that the stagger is based on when
this particular page is being parsed, which should actually have
the desired effect of spreading out the possible cache stampede.
Followup-To: I9acb42b0d9ff67798a1624cbf9c7cac99c8fbe2f
Change-Id: I95272e301c00e4646dd29ca22abc26c6cbe9028e
Legacy parser can now output headings using a more accessible markup,
which is also identical to the markup used by the Parsoid parser.
Changes to client-side JS and CSS necessary to support the new markup
have already been merged in earlier commits.
includes/skins/Skin.php
includes/ServiceWiring.php
* Define a new skin option, 'supportsMwHeading', which can be used
to toggle the new markup per-skin.
* Update the built-in fallback skin to enable it. This affects the
output in parser tests.
docs/config-schema.yaml
includes/config-schema.php
includes/config-vars.php
includes/MainConfigNames.php
includes/MainConfigSchema.php
* Add a new configuration setting, 'ParserEnableLegacyHeadingDOM',
which can be used to toggle the new markup per-site.
includes/OutputTransform/Stages/HandleSectionLinks.php
* Output new heading HTML for skins that enabled the option.
tests/*
* Duplicate parser tests that cover heading generation to cover both
new and old markup. Update other parser tests to use new markup.
* Add some unit and integration tests for the behavior of the skin
option and some parser tests for edge cases of the new markup.
Bug: T13555
Change-Id: I1180169a8e83af834c2984ba16089e6277f2a8dd
A number of tests have hardcoded expections that pass only in WMF CI
where Quibble has LocalSettings.php with $wgScript and $wgArticlePath
set a certain way.
We could fix these by adding setMwGlobals() in their tests, as we
often do, but these are so often forgotten that I'd rather we just
add them to TestSetup.php so that it is simply impossible to write a
test that that passes locally for you (if you have the same config)
but not for someone else.
There is a larger project in there somewhere about expanding this
slowly such that we basically only pluck DB-settings and extension
enablement from LocalSettings and otherwise run the tests with the
default settings in PHPUnit. Pretty much by definition, any (other)
setting you have in LocalSettings is irrelevant because it either:
1. has no effect on the test (majority, harmless either way),
2. has a custom default via TestSetup.php (which has precedence over
LocalSettings.php),
3. is relevant to the code being tested and the test case correctly
calls setMwGlobals() to ensure a consistent value during test.
4. is relevant to the tested code but has no override, thus only
passes if you happen to have the "right" value set for it
(undesirable).
Case 4 is already categorically impossible for the most common config
settings that influence random code because we give them a value
in TestSetup.php. This patch expands that to include $wgScript
and $wgArticlePath. Perhaps in the future we can think about a way
to do this automatically by either re-applying MainConfigSchema
(sans db settings) or by only selectively applying LocalSettings.php
in the first place.
This patch follows-up I072ddf89562fe, which added a test case in
WikitextContentHandlerIntegrationTest.php that assumed "/index.php"
as the value of $wgScript. This passes in WMF CI since Quibble uses
that value, but the tests failed in most local development installs
since those tend to use "/w" instead.
Rather than one-off fixing that one test with overrideConfigValues(),
switch to a more general fixture, since the precise values don't
matter for this test.
Bug: T349087
Bug: T277470
Change-Id: If4304b7ca4a838bd892d4516a0b5c6dfbc30986e
This is a non-default option that will add a <div> wrapper around
section contents to allow client-side collapsing. This is intended
for use by MobileFrontEnd, but could eventually be enabled for
desktop read views as well.
Since this parser option is in the "cache-varying options" set, any
caller who sets this option will fork the cache for that page, which
is reasonable as the parser options sets a ParserOutput property.
In the future our caching strategy will get smarter and we'll add
code which avoids the cache split and just transfers the appropriate
values from ParserOptions to ParserOutput flags after the cached
output is retrieved.
Bug: T359001
Change-Id: Ie93959a056ed15a728404eb293e4bb6eeaeb15c0
According to the dictionary, "per" (or more conventionally "as per")
means "according to". Refer OED "per" sense II.3.a. For example:
"No value was passed, so return null, as per default".
In this sentence, we are not specifying the default, we are referring
to the default. This correct usage of "per default" was used nowhere
in MediaWiki core as far as I can see.
Instead we have "per default" being used to mean "by default", that is,
giving the value to use when no explicit value was specified.
In OED, the phrase "by default" is blessed with its own section just
for computing usage:
"P.1.e. Computing. As an option or setting adopted automatically by a
computer program whenever an alternative is not specified by the user
or programmer. Cf. sense I.7a."
There are highly similar pre-computing usages of the same phrase,
whereas the phrase "per default" is not mentioned.
As a matter of style, I think "per default" should not be used even
when it is strictly correct, since the common incorrect usage makes it
ambiguous and misleading.
Change-Id: Ibcccc65ead864d082677b472b34ff32ff41c60ae
This will split the cache for now, but pages are generally either
always rendered with suppressed edit links or always rendered without
suppressed edit links. Previously, ParserCache would report the page
as "not safe to cache" and always bypass the cache when
suppressSectionEditLinks was set. This isn't a problem since no one
uses this parser option yet in production, although the original
motivation was to replace the mutation of the $options array
done by the Translate extension in the ParserOutputPostCacheTransform
hook here:
5eff51db88/src/PageTranslation/Hooks.php (197)
See 770d2bf040 for more information.
Change-Id: I88e33248c1e40a8aa694974b2a1f94e36d8c7ed6
Before this method name gets baked forever into the 1.42 release, rename
the ParserOutput::setIndexedPageProperty() and ::setUnindexedPageProperty()
methods to ::setNumericPageProperty() and ::setUnsortedPageProperty() to
try to address some confusion about whether the *presence* of the page
property is still indexed (it is!), in contrast to whether there's an
additional "sort key" associated with the *value* assigned to the page
property.
This naming is compatible with the feature request in T357783 to have
the sort key and property value specified independently. The new
method signature in that case would be:
...setSortedPageProperty( string $name, string $value, int|float $sortKey )
Although PHP 8.0 will throw a TypeError if a non-numeric type is coerced
to numeric using `0 + ...`, use an explicit is_numeric check to obtain
the same behavior in PHP 7.x.
Change-Id: Ia94c192c429d0482c58467bed787fd2e0aca052f
Remove dead code left over from the removal of the
BeforeParserFetchTemplateAndtitle (sic) hook in
20c5632c4e.
While we're at it, add test cases for statelessFetchTemplate and
improve coverage.
Followup-To: Ifecd4108eb02ebccc0c7bc4ec432036da08ffe53
Followup-To: Idf1fd12cc61ca30867dc9f8aeb1701fe035fc5ff
Change-Id: I135f5234e7be015a2781d6cb8d23b3143b618c5a
Deprecate non-string values to ::setPageProperty(), which introduce easy
traps for programmers to fall into. Instead if page properties are intended
to be indexed, use the new ::setIndexedPageProperty() instead. Also add
::setUnindexedPageProperty() for symmetry, with a tighter string type on
the value.
Bug: T305158
Bug: T350224
Change-Id: I8a39a7c90341dfee932aa819c9a0a637a8782f69
This is a follow-up to: I0b683461212a357c7eb09ddec59c87539e323c65
and I40a8372a76f33c5f62ea73bb1180dd7c47412c89 which explicitly for
backward compatibility reasons supports IBufferingStatsdDataFactory.
Now that we've fully switched to StatsFactory together with the
`copyToStatsdAt()` method, we're fine to fully remove this `instanceof`
logic.
Bug: T356815
Change-Id: I164d82904b6d3fb575cb973c14f9454569bf09ac
This is just a cleanup change. The exception should never happen,
but if it does, this can be reverted.
Change-Id: I26a7c4105d39d83015c09b779a2de3fd1ddacec1
Call the suppression function in the data provider as that function is
called there. Also escape \ for the P to avoid \P
PHP Deprecated: CacheTime::setCacheTime called with -1 as an argument
[Called from
MediaWiki\Tests\Parser\ParserOutputTest::provideMergeInternalMetaDataFrom
in /workspace/src/tests/phpunit/includes/parser/ParserOutputTest.php at
line 1028] in /workspace/src/includes/debug/MWDebug.php on line 379
PHP Warning: preg_match(): Compilation failed: unknown property after
\P or \p at offset 19 in /workspace/src/includes/debug/MWDebug.php on
line 370
PHP Deprecated: Use of MediaWiki\Parser\ParserOutput::setTOCHTML was
deprecated in MediaWiki 1.40. [Called from
MediaWiki\Tests\Parser\ParserCacheSerializationTestCases::getParserOutputTestCases
in /workspace/src/tests/phpunit/includes/parser/ParserCacheSerializationTestCases.php
at line 236] in /workspace/src/includes/debug/MWDebug.php on line 379
Bug: T355952
Follow-Up: Ifed584aac7947c47fd494a66564a3bd367f83c49
Change-Id: I7d6075b2c2b3d53db47e37040394bd013cece8a6
ParserOutput::getText() is not a simple getter, but does
transformations on the "text" of the ParserOutput; the simple getter
is named ::getRawText().
To maintain consistency, rename ParserOutput::setText() to
::setRawText() and the property name ParserOutput::$mText to
::$mRawText so future readers are not confused.
The JSON property name as it appears in the serialized ParserCache
is left as 'Text' so that we don't have any forward- or backward-
rollback issues.
Change-Id: I3ef34814ab9473cc70d0a6806e8c5a4a02b73491
This will allow the Translate extension to set this parser option
in the ArticleParserOptions hook, instead of mutating $options passed
to ParserOutput::getText() in the ParserOutputPostCacheTransform hook.
It ought to also help to handle the many places which call:
... = $parserOutput->getText( [
'enableSectionEditLinks' => false,
] );
by allowing them to set the appropriate ParserOption instead
of passing arguments to ::getText().
Bug: T350626
Change-Id: I719c115194059060f7f888608417a194ac80cc92
This avoids confusion with the "render timestamp" held by the cache,
and is consistent with ::get*RevisionId() etc.
The old ::getTimestamp() and ::setTimestamp() methods have been
deprecated.
Change-Id: Idb5e687709c98086c5d3075d31885c58a0723197
