This streamlines the code of the helper method a bit, mostly by
avoiding duplication.
What actually happens is the exact same as before, with one
exception: When a test case doesn't have an expected "output",
the default (mostly empty) output does not run through the
roundtrip test. While doing this is not wrong, it doesn't tell
us anything about the specific test case.
Change-Id: I4a3d8a22c3dd6a9c5c3766195e5aef3cf37a6441
"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
I find this good practice. It makes the tests more robust (e.g.
changes to a text don't make the test fail) and is potentially
faster, as no localization needs to be loaded.
Change-Id: I6c6342c80a40ab7260c35e7f1e3052aa4a9b9358
This test was reported as being slow (approx. 0.1s, but still).
This new implementation is 10 times faster, while still
fulfilling the requirements. While the new algorithm is more
predictable (every chunk is guaranteed to contain every
character exactly onece), it's obviously still good enough.
Neither the exact length of the generated string nor the exact
length of the gzipped string matter. PHP's random number
generator might be different – possibly generating a string
that compresses different. Newer versions of the gzip library
possibly save an extra byte. Who knows. This test shouldn't
care, as long as the gzipped string is long enough.
Compatibility with PHP 7.1 can be dropped as it is not
supported any more since MediaWiki 1.34, as far as I can tell.
Change-Id: I8d63390c9f4baa6084f932fa34068f606696cafc
Two main mistakes:
* The {...foo} syntax is for a variable number of parameters.
But this is not the case here.
* Optional parameters should be marked as such via [foo].
Change-Id: I0c26ea44fab6094616443ce8fae4fd47c61fd7c4
assertEquals() does have weird effects, like not reporting a
method that is expected to return null but returns an empty
string, and such. While it's usually not a problem, I learned
to avoid it.
Change-Id: I4f27ed5b200278021e051f1ab4d272f48e0bf344
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
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
… instead of 0. Conditionally add a dash in front as well to
avoid confusing results like '1' + sequence number = '12'.
Change-Id: I345704b00ba3812c4905f85e35cf21a6dfd05437
I looks like the Model.params data structure is build in a way
that it allows mismatching parameter "keys" and "names". E.g.
{
"a": { "name": "a" },
"a0": { "name": "a" },
}
There are comments in the code that suggest this is
intentional.
I found code that confused these two values and tries to use
the name as a key, for example. This fails, messes up the
paramOrder, and such.
This should not have much, if any effect for users because
users are blocked from doing this anyway, e.g. buttons get
disabled.
Change-Id: I2067024ad8d5b8e985a4f162cf6875f523777a6c
Example:
On
https://en.wikipedia.beta.wmflabs.org/wiki/Template:Anschutz
the two parameters "state" and "capitalization_test" don't have
a label in the <templatedata> JSON structure. Instead the
internal parameter name is shown. But it's capitalized for an
unknown reason. I guess this is done to make the table look
"nice". But it causes confusion – see the ticket.
This capitalization is there since the very first commits from
2013, see I16d3f9e.
Compare with VisualEditor: Edit the template on
https://en.wikipedia.beta.wmflabs.org/wiki/Conflict-title-0.8542952978413387-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n
or use the old wikitext editor and TemplateWizard to insert
the template. In both cases the parameter names are not
capitalized.
Another argument why this capitalization is misplaced: When
there is no <templatedata> JSON blob, the TemplateData editor
auto-detects the parameters and semi-automatically creates a
minimal JSON blob. This is the moment where labels should be
created and stored so the user can edit them. But this doesn't
happen (for good reasons).
The user can't do anything about the current capitalization.
The only way to change it is to add a label that does nothing
but repeat the parameter name, just to undo the capitalization.
That should not be the way this works, I would like to argue.
Bug: T174771
Change-Id: Ia8133d3f0d6b79fe89c63bb0392a334c0a185a65
Transitioning of ParserCache to JSON serialization will add
a requirement that all the extension data is JSON-serializable.
This is the first step in transition - making it forward-compatible.
Bug: T266252
Change-Id: If1c9d9bb5b0039df80a9d9b30c247206d8844c0a
This fixes a series of issues:
* The JS implementation had a trim() in one place that was
missing in PHP.
* The actual parameter name in the paramNames/$params array was
trimmed, but the "normalized" name (this is only for duplicate
detection) was not trimmed.
* It was possible for an empty parameter to show up.
This resulted in very strange behavior, e.g. {{{ 1}}}{{{1 }}}
was detected as "1" and "10" (?), i.e. it would try to renumber
the duplicate in a strange way (string "1" plus a counter that
starts with 0).
Change-Id: I0a6371f3633b03b5b21809ecd06ea4c72d7d914d
This fixes parts of a TODO in the code. Specifically:
* When an InterfaceText is an object, it can not be any object,
but must be an stdClass.
* It can't be empty.
* Language codes must be non-empty strings.
* Values must be strings.
I'm intentionally not adding more validation for the language
codes, as this needs discussion (what values should be allowed?),
and can potentially break existing pages.
Same for empty strings. This can easily happen when users
manually create a <templatedata> tag and copy-paste pieces that
are meant to be filled in later. Empty strings are not really
invalid (again, this needs discussion), but might be something a
client want's to ignore.
Change-Id: I0facaa08cffe5a5a038423a58d55bc90a40b2d75
This is used by the includeMissingTitles option of API action=templatedata.
Parameter syntax existing within nowiki tags or comments will not be valid
for the template.
Bug: T237195
Change-Id: Ibbfa3e21488f2a37fc494862e929baf50607d4c9
Removing the sorting arrows from tables that have one row or less in
templates. By using variable $sorting that changes according to the
coung of elements in the array $data->params, to determine whether the
table should have "sortable" class or not.
Bug: T126150
Change-Id: I414c2375d4eb4da5d78f92f6b4e99b55e314ce4d
When normalising a TemplateData blob for API consumers, we previously
automatically generated the 'paramOrder' with the order of the keys
as they were specified in the JSON blob (which, unlike in JS, is
known to be reliable in PHP).
While this was useful to some extent, it made it mandatory for
Parsoid and VisualEditor to always re-order properties during
edits to match the specified order.
In order to allow the order to remain flexible/unspecified, the
original Specification made paramOrder optional, but during the
implementation I gave it a default, which kind of defeated that
intention. This patch fixes that.
Bug: T138200
Change-Id: Ib40d23dac7e75274083f95a25c5aa1c22dfffb22
Three-braces-and-a-bang can be a table starting construct in templates.
This also fixes an overlooked bug in which the test wasn't checking
array element key names.
Bug: T157029
Change-Id: I69ed4fc9fe3bb126b7b39abea0f58ad56adf3885
Parameter names can be constructed with parser functions, so
we should not include these as raw parameter names. There
might be more characters to add here.
Bug: T203605
Change-Id: If57a9ed7edf1e881cd121d9a1bcb2e7455c04ec9
When extracting raw parameters from wikitext, ignore those that
only differ from already-found ones by spaces, underscores, or
hyphens.
Bug: T193265
Change-Id: I012e06bf4353eaaf0613124d7d6b88f3444d248a
