Don't enforce 'inline' as the default format if none is specified.
Instead preserve the unspecified value as 'null'. This allows
third-party tools to provide a better default experience when changing
existing content (e.g. by using smart detection to follow the format
already used).
Bug: T128337
Change-Id: I911c7999e3731c0125fc058118f8d7287d8f88f4
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
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
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
These wiktext-isms from the Status object make the tests rather
obfuscated and hard to read/maintain.
Change-Id: I6438c33229ac013489893f8a2241510d9b5a7765
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
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
Status::getHtml now wraps the html in <p> tags, unwrapping
them for now, classic parseinline style..
Change-Id: Ic9b651cbd76752346ea7cbf230af49f09ef3ec12
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
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
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
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
Previously we only compared output, we now evaluate
status as well.
For example test {} => {} was misleading since the reason
it roundtripped was because it is *invalid* and we replace
invalid blobs with an empty object in blob storage.
But in the API this'll never get used because getStatus
will have a fatal error in it. Which overrides the data.
The tests were previously looking in the data whilst ignoring
the return status.
Change-Id: I9809f126c1615c9bc9c28ce2d8bb7953058cbf6e
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
