<pre> behaves very similar to <nowiki> in so far that whatever it
contains doesn't get parsed as wikitext. It might contain {{{…}}}
tripple brackets, but these aren't going to be activated as template
parameters.
Bug: T91326
Change-Id: I05c24e369d97c48161c565e2ef30969ec28c6a23
I tried to write a test that can cover this code, but realized it is
unreachable. All parameters with all their properties are already
validated in the first loop.
Bug: T301337
Change-Id: If97adba45beb0ef1303907746715613fca23468e
The return value of ParserOutput::getPageProperty() has transitioned
to returning `null` instead of `false` when the page property is missing.
Bug: T301915
Depends-On: Iaa25c390118d2db2b6578cdd558f2defd5351d15
Change-Id: I1126eab0e882b5bdfecea1ef6e3e27dca7b85115
The return value of ParserOutput::getPageProperty() will transition to
returning `null` instead of `false` when the page property is missing.
Bug: T301915
Change-Id: I71628661b4539a4e35ae32846e719f92bcf782e0
This method is not used anywhere else:
https://codesearch.wmcloud.org/search/?q=getRawParams
I tried to make the code a bit more readable. Notable:
* Make use of the return value we get from the preg_… function.
* {{3,} means "the character '{' 3 or more times". {{{+ does the
same. Note the { doesn't need to be escaped when it's not
followed by a number.
* At the end, it doesn't make any difference when we scan for
optional closing brackets. The moment we find at least 3 we are
done.
The test is intentionally not moved. This is something for a later
patch.
Bug: T301337
Change-Id: I55e31ceecea2ae7c35bcfbc2d641b35f751820db
One method is only public to be able to test it. Others look like
they have been made "protected by default", which is not needed
anywhere.
Change-Id: Ib2231f0b2a879323aa53f8d40a175527c5b131d8
Effectively a no-op. This patch doesn't change what the code does.
Tests are in place to prove this.
As before, the tests are intentionally not moved but left in place.
This is for later patches to clean up.
Change-Id: If130e0d006a36d8c755288f8a4e4e9a4c42a6295
PHP is a little weird in so far that what you get from e.g. `(object)[]`
or json_decode() are not objects but stdClass instances. You can think
of stdClass as a subclass of object, i.e. it's more specific.
Using is_object() means that stuff like ArrayIterator will be accepted,
which is not correct in this context here.
Change-Id: I0bffc54508ac7a27bbb59c3aabb9695158eb96b3
The word "param" is not really that ambiguous in this context. The
only other meaning it could have is "parameter name". Such places
already use $paramName.
This makes the following patches easier to review.
Change-Id: I1e6210d1ca7d58726a0fc3b3396d75e0e28c16d8
No functional change was made to the code. It was only moved from one
place to another. Note there are a lot of tests that cover this code.
The tests haven't been touched on purpose. Splitting these as well
is something for a later patch.
Bug: T260980
Change-Id: I9fa0fa87768f2560b83a1b5f3d39211ea9d6cfad
