The following sniffs are failing and were disabled:
* MediaWiki.Files.ClassMatchesFilename.NotMatch
Change-Id: Ia5b694aa005b6e67796fac2d954220e32393fddb
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.FunctionComment.Missing.Public
* MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.NewLineComment
Change-Id: I79fb2bf4782b14ba671c15e304f110183adabdf1
If the TemplateData blob failed validation, then OOUI would be enabled
in the ParserOutput even though it wouldn't be used.
Also fix casing of the Status::getHTML() function call.
Change-Id: I1c1cc8ffd46deecd12a07bb13730a073a3363019
On pages like https://www.mediawiki.org/wiki/Template:Unsigned, the
parameter documentation first renders without these styles because
the module is loaded asynchronously with JavaScript.
Change-Id: I2fdb961e0bd8efb1aa3c3e825d58d1071f20a3ec
> The module 'ext.visualEditor.mediawiki' must not have target 'mobile' because
> its dependency 'jquery.uls.data' does not have it
This happens when TemplateData is loaded before VisualEditor.
Both extensions provide jquery.uls.data when ULS is not installed.
The first one wins.
Change-Id: I9d24da71bb960b88cfd891ac8523bc2ec97551e1
Fix onResourceLoaderRegisterModules() to
check if the jquery.uls.data module is already
loaded in the ResourceLoader.
Modify comment to indicate that VE also
loads this module.
Bug: T85733
Change-Id: Idd459555312879a85a0a56fba651f609b4f9a52a
Change the ui/data behavior to work with oojs and event emitters,
and replace the gui from jquery ui to oojs-ui.
Changes made:
* Recreate the templatedata editor with oojs and ooui.
* Create a standalone templatedata model with internal validation.
* Allow the user to insert language-specific strings:
* Allow adding arbitrary languages and values
* Normalize output between language object and 'simple' string
* Add new language code by searching for its name or code
* Import parameters from template code
* If the template is in subpage and there is no code in the
current page, the code will request the contents of the parent
page.
Change-Id: I985ea03dfee58984ec22ec9a157a00968bfca878
This adds a TemplateData manager to the edit page in the Template
namespace.
If a <templatedata> tag already exists, the tool will parse it and
display it in a visual interface that the user can then manipulate in
their own language. If there is no <templatedata> tag, the dialog will
appear empty and allow users to add and tweak their desired template
parameter data.
The tool also allows rudimentary parameter import, which picks up the
parameters from a current template into the GUI to make the user's life
easier when producing TemplateData.
The template documentation editor feature is off by default. To enable it
use $wgTemplateDataUseGUI = true in LocalSettings.
Bug: 50436
Change-Id: I863a8199c0b08cc52b320ed00dcba912dd2aeefc
This message is output' within the page. A single line in red text was
easily lost on a longer page. This also makes it consistent with other
errors from mediawiki.
Change-Id: I71b8be492d4f9f2ecdecc66a88e17490fbf62112
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
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
* 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
