Add an 'autovalue' parameter property to the TemplateData spec. And
implement it in the validation for the API and in the editor.
Also added tests to make sure all parameter attributes preserve
their values before and after parsing, including the 'autovalue'
parameter.
Bug: 51428
Change-Id: Iffb376a804d39388d2b5b6ea3583ef2a292eea41
Apparently some Blackbery devices just silently chomp content inside HTML4-style
elements, so let's use the HTML5 version (which is meant to be preferred anyway).
Bug: 67084
Change-Id: I7e07fc2193b290a0e5c3912a678f53045ff1de32
This is a status for parameters which are not 'required' but are recommended
to be high value, if not always used, by downstream template users. This
commit does not add GUI-related changes to address this, as the interface
probably needs moving from checkbox- to dropdown-based status setting given
that there are now four, rather than three, mutually-exclusive statuses.
Change-Id: I104976e76d5ad6d586d9c818418ba6e16af53506
Specified as {boolean|InterfaceText}, which means both false and true
must be valid values.
Bug: 53412
Change-Id: I0272c7acc85caed0b73a427e86f851792964214f
For example, in case of failure we were defaulting to an empty
object, even though that is invalid input.
Change-Id: I00b4ce26b04ec408b5e86b9a2242cf942300ad41
* Detail the new property in the spec.
* The property is optional (as all new properties have to be
for backwards compatibility).
* Validate value if present, and for normalisation fill it
with inferred order from the JSON parser. This means the API
output will always contain #paramOrder, however the strict
specification for it is optional and users must still account
for absence of this property.
Bug: 53608
Change-Id: I7bcd7c9146f5ae75c4bad22b0a9cd4400f196c8c
* An empty array for a Set is invalid and the implementation now
enforces this.
* Add new error message for invalid value. When Sets contain a
reference to a key that doesn't exist, it should say that that
reference in the Set is invalid instead of saying that Params
is invalid for not having it.
> { params: {}, sets: [ { params: [ "quux" ] } ] }
- Required property "params.quux" not found.
+ Invalid value for property "sets.0.params[1]".
Also:
* Abstracted handling of $case and the different assertions
on it in a helper function so that we don't have to repeat
it everywhere.
* Use the same hack as in other tests to display the status error
message in the phpunit output (true === isGood ?: getHtml).
Maybe use '' === getHtml instead, though that is also evil
since Status fatals if you call getMessage/getHtml for a good
Status object.
Change-Id: I06a6615f728cd287a4839e09eedc2d0eeb537949
* Fixed 'should be not be' in other 'qqq' messages.
* Fixed absence of ->text() in other wfMessage uses
(defaulted to parse, which was wrong as these are Html::element
uses that take text input, so it was being double escaped).
Bug: 50370
Change-Id: Iba1a10f14e258a588435cd03017177acfb96d0f3
Fallback for user language and content language is easiest to
resolve server-side. Also saves sending a lot of data to the
client that it doesn't need. Similar to how ResourceLoader only
sends 1 set of message values.
Bug: 50431
Bug: 52922
Change-Id: If8317ed6522a05d5a48a210ff43c97277b950a97
The description property is optional and is explicitly set to
null by the parser in normalisation if there is none.
The HTML rendering of parameter descriptions (as oppposed to the
description of the template as a whole) already covered for this.
Used the same logic for the template parameter.
Also fixed:
* Localize the text "no description"
* Use !== null instead of isset() since the property is always
set, we just need to know whether it is null or an object.
Bug: 54422
Change-Id: I86a40dbd1225feb54123e77a856b4ad6d525461b
gzdecode() has been introduced in PHP 5.4 although gzencode() has been
there for a while. Wikimedia is still using PHP 5.3, so the
TemplateDataBlob::newFromDatabase() would trigger a fatal error whenever
it is passed compressed JSON :-(
The test does not fix the root cause (that needs a fallback function in
the TemplateData extension), but it does highlight the issue in PHP 5.3.x.
Updated a @return comment, correcting the class being returned.
bug: 54058
Change-Id: I8357b474165f4317982b9c924cf0afe68650d677
We only have 65535 bytes, let's use them wisely.
Prior to Ib2db241a in core (1.22wmf12) even binary page properties
were sometimes shown as plaintext (e.g. on Special:PagesWithProp).
Thus this introduces a "soft dependency" on that change.
No backwards-incompatible changes were made in public methods.
Added two new ones:
* Add TemplateDataBlob#getJSONForDatabase which returns compressed
JSON, use it where applicable.
* Add TemplateDataBlob::newFromDatabase which accept compressed and
uncompressed JSON, use it where applicable.
Use a long pseudorandom string in the test.
Bug: 51740
Change-Id: Ie66b0dd6b6dab6f8648e78595c41e52d9c704d57
Configuration for phpcs was changed to now require spacing
of ternary to be at the end of the previous line.
Change-Id: I8a358053a9ccf4ec83bfd8db1383fce12d9d9f2f
This might not be necessary on non-MySQL databases, but I'm sure that
at least their limits aren't lower than MySQL's, so let's stay on the
safe side.
Bug: 51740
Change-Id: I9c7115a951f126844bc70755bff12e8cd5fc2be1
The context user language is correctly set to that of the user
who is saving the page.
Parser options are set to the default language during saving and
only changed to the user language when viewing the page with
a uselang that is not the default wiki language.
As a result we were saving the user language (e.g. French) on
en.wikipedia.org as the canonical version on-save and only changing
it to the correct language for non-English viewers.
To test:
* Wiki set to 'en', user preference language to 'nl'
* Save a page with templatedata
* View it logged-out without a uselang query
Was 'nl', is now 'en'.
Bug: 52419
Change-Id: Ic8b5b63450c9f80b85a95d16cc81ce62fc96b77f
This is to help differentiate between <input type="text" /> and
<textarea> fields. We need this for UploadWizard in particular because
we intend to build a form for the Information template on Commons, and
it has both small fields (for which we'll use <input>) and big ones
like description (for which we need <textarea>).
Change-Id: Ib9b381816d18f2723a9f715c54f6a64ff4b69847
For invalid keys, pass property path, not just the latest
child.
Changes error:
- Invalid value for "typo"
+ Invalid value for "params.date.typo"
Also cleaned up the concatenation logic for the others to
be more readable (PHP dots vs. string dots):
- 'params.' . $paramName . '.key'
+ "params.{$paramName}.key"
Change-Id: I666e0b22f4b7bacc5b89b0761c74138732f94d73
InterfaceText now defaults to null instead of {en:""} which
was awkward to deal with in the frontend.
As specified:
- label is InterfaceText
- type is a string and must be a one of the recognized types
Updated example for the hypothetical variant of Template:Unsigned
and removed other no longer needed example.
HTML output has been revised per conversation with Trevor,
James and Timo:
- Not sortable.
- Add label to html output.
- Aliases in the main parameter column (one per line),
but muted in styling.
- Add type to html output.
The css module styles content from the server, not content
generated by javascript. Moved module to position => top to
fix flash of unstyled content.
Change-Id: I16d3f9e460c5513935b9b55fe4cec0092b38e6c2
I ran into countless random exceptions and errors locally due to
cache I built up over time that was no longer valid. Though in
approved commits in the repository there is only 1 version as of
now, I'm sure we will make changes in the future that require a
cache invalidation since getHtml needs to be able to make
assumptions about what properties exist.
Also fixed a bug in the parse() method where the 'deprecated'
property is asserted the wrong way around. Added a test for it.
Change-Id: I5f61d6030578a711909435c8b996373e9aaa5178
* Add unit tests for all types of invalid input we check for.
* Add unit tests for all types of input we expand or otherwise
normalise.
* Implement InterfaceText expansion/normalisation.
* Fix bug that caused a string value in the root description property
to be considered invalid (it only accepted an object, it should
accept both).
Change-Id: I5a15080f1f924451a9dde8af96ea2922011981ec
Registers a parser tag <templatedata> that should have a JSON
blob as content. The blob is then validated and normalised when
MediaWiki parses the page (e.g. during save and preview).
If there are validation errors, the save is aborted from the
extension hook and an error is displayed.
If all goes well, the normalised blob is stored in the database
(which can be retrieved through the API). And an HTML
representation of the template parameters is returned to the
wikitext parser to show where the <templatedata> was in the page.
The blob format is specified in spec.templatedata.json and
is validated in TemplateDataBlob::parse.
Bug: 44444
Change-Id: Icf305892a9512545a63f5a5280cc0d340c61585f
