Adding format data, which defines the preferred source format
to use when using templates.
Possible formats:
* Inline - all parameters in a single line
* Block - each parameter is in its own line
Bug: T64147
Change-Id: Id856c4a38890526060d0619432f06174d66f7792
Following up on I2bc79421be330, the condition was always true in
case the first one wasn't. This is just a beautification fixup.
Change-Id: I7463207f02de2116b96173d88199d46ce70ca174
Make sure that paramOrder is initialized as an array even if the
params property of the TemplateData object is empty.
Bug: T91470
Change-Id: I2bc79421be33053e7e21170528fbbd1c01eaf4bb
If no parameters are defined in the TemplateData, have the table
display a specific message noting that.
Bug: T53429
Change-Id: I3c9ae31ef9eafab7f94325fcd58e14a3e45c9818
Have the parameter order in the display table appear according to
the paramOrder setting. If the setting isn't explicitly set in the
TemplateData string, the parameters will be in order of appearance.
Change-Id: Ibbd5a7b28f722c51788b9ed0f5ac577902ce4b7a
Timo Tijhof's initial commit b7080c5f90
inexplicably caused the "mw-templatedata-doc-muted" class to be added
to the description field only when $paramObj->deprecated was false.
Bug: T69794
Change-Id: Iad86f5dbc48046faa09f39c339fce95db3331208
This will make the display table sortable; table which appears when
<templatedata> tag is used on a page.
Bug: 50435
Change-Id: If72a44eab3229139791ea2d06ef6a74e2ce2e0c9
Add "maps" as an allowed root value to template data JSON.
Maps allow applications to map equivalencies between their
application-specific parameters and valid template parameters.
Each Map has arbitrary keys (from the consuming application) that
are mapped to one or more template parameters.
* Added root.maps to TemplateDataBlob
* Validates that values are strings or arrays
* Validates that values are valid params
* Added templatedata-invalid-param to i18n/en.json
* Richer error message for when invalid value is a param
* Fixed existing tests to work with new "maps" property
* Added two new tests for maps
* Test for invalid value (!string or !array)
* Test for invalid parameter
* Added specification for root.maps property and Map object
Change-Id: I3bf5e002ad6c1632e02c4c2e393b244c51f77177
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
