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
