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
PLURAL magic word expects formatted numbers, so just format them
in the code already, as is common practice.
Change-Id: I813c45f8959d9d013a6176e999622c81f7e86042
Parameter names in a template can be numeric. While it makes a lot of
sense to force a specific format in the TemplateData JSON (i.e. only
strings), it's inconvenient and confusing if numbers are rejected for
being "invalid".
Effects of this patch:
* The incoming JSON is allowed to contain numbers in the aliases
array.
* However, the API normalizes these and forces all aliases to be
strings, as it was always documented.
* The editor component accepts anything in the aliases array, but
forces all aliases to be strings. Again, as documented.
* Note that it was never possible to use numeric keys in the `params`
list. This patch is only about aliases.
At the moment this is a somewhat "hidden" feature. We might or might
not update the documentation to officially allow numeric aliases.
Bug: T298795
Change-Id: I32ea296b4520e7f21b03a1f6390db4f43b613bdd
This is not new. This was always documented to not accept anything
but strings.
Let's apply the same fix to aliases while we are here.
Bug: T297386
Change-Id: I57e18779f28802816d5adb66cc4067df4e58b26e
The $this->data property stores whatever json_decode() returned,
which could be anything. The validation happens later.
Change-Id: I0d04831b8253005734c1c6c97b48061be35e5d88
"Almost" because I found at least one that appears to be
unreachable (the very first check for null). But changing this
code is out of scope of this patch.
This also updates some of the error messages to explain the
location of the error better. It appears like the incomplete
paths are copy-paste mistakes.
I also found one duplicate test case and removed it.
Change-Id: Ic0ee9d04f5cd1060ade385ef308e70d221dd2f18
At the moment, when the user clicks the "Status" column to
sort by status, the statuses are ordered alphabetically,
which gives widely varying results depending on the language.
But there is an inherent order for these, even hard-coded in
the code: When a parameter is deprecated, nothing else matters.
Otherwise it's required → suggested → optional. Doesn't it
make much more sense to order the column this way? Especially
because there are never more than these 4 hard-coded values.
This is one of the (few remaining) issues mentioned on
https://de.wikipedia.org/wiki/Vorlage:TemplateData#Vorlagendokumentationsseite_verbessern_%E2%80%93_MediaWiki_ungen%C3%BCgend
This patch also makes it so that a CSS class name is always
added to all status fields, not only to the required ones.
This allows for per-wiki or per-user styling.
Change-Id: Id3f1ffafe09a3817972a4ee4bd4a3ded7be6f039
This is all unused, e.g. because it just repeats a default
value. All verified by my PHPStorm IDE.
Change-Id: I69665e07ca2d04016dc16e93290ef276f6b2cd95
All API modules that are a submodule of the action=query API do
this already. What this method does is to forward all additional
information from the "generator" module to the module that uses
the generator as input. Without this line only the list of pages
is forwarded, but all metadata is lost.
The thing is: The templatedata API is not an action=query API,
but a separate action. But it's largly compatible. It might
even be possible to turn it into an action=query API, but this
is beyond our capacity at the moment.
Bug: T274907
Change-Id: I3c3c684109688c112ec15424119d4d30430ffd86
Parameters may include a `suggestedvalues` property, which is rendered
in the UI for some parameter types.
TemplateData editor UI elements are implemented behind the
TemplateDataSuggestedValuesEditor feature flag.
Bug: T271897
Change-Id: I14012c79b3fa0d48c58fd8999584cc03ec03575e
