The word "param" is not really that ambiguous in this context. The
only other meaning it could have is "parameter name". Such places
already use $paramName.
This makes the following patches easier to review.
Change-Id: I1e6210d1ca7d58726a0fc3b3396d75e0e28c16d8
No functional change was made to the code. It was only moved from one
place to another. Note there are a lot of tests that cover this code.
The tests haven't been touched on purpose. Splitting these as well
is something for a later patch.
Bug: T260980
Change-Id: I9fa0fa87768f2560b83a1b5f3d39211ea9d6cfad
PLURAL magic word expects formatted numbers, so just format them
in the code already, as is common practice.
Change-Id: I813c45f8959d9d013a6176e999622c81f7e86042
Parameter names in a template can be numeric. While it makes a lot of
sense to force a specific format in the TemplateData JSON (i.e. only
strings), it's inconvenient and confusing if numbers are rejected for
being "invalid".
Effects of this patch:
* The incoming JSON is allowed to contain numbers in the aliases
array.
* However, the API normalizes these and forces all aliases to be
strings, as it was always documented.
* The editor component accepts anything in the aliases array, but
forces all aliases to be strings. Again, as documented.
* Note that it was never possible to use numeric keys in the `params`
list. This patch is only about aliases.
At the moment this is a somewhat "hidden" feature. We might or might
not update the documentation to officially allow numeric aliases.
Bug: T298795
Change-Id: I32ea296b4520e7f21b03a1f6390db4f43b613bdd
This is not new. This was always documented to not accept anything
but strings.
Let's apply the same fix to aliases while we are here.
Bug: T297386
Change-Id: I57e18779f28802816d5adb66cc4067df4e58b26e
The $this->data property stores whatever json_decode() returned,
which could be anything. The validation happens later.
Change-Id: I0d04831b8253005734c1c6c97b48061be35e5d88
"Almost" because I found at least one that appears to be
unreachable (the very first check for null). But changing this
code is out of scope of this patch.
This also updates some of the error messages to explain the
location of the error better. It appears like the incomplete
paths are copy-paste mistakes.
I also found one duplicate test case and removed it.
Change-Id: Ic0ee9d04f5cd1060ade385ef308e70d221dd2f18
At the moment, when the user clicks the "Status" column to
sort by status, the statuses are ordered alphabetically,
which gives widely varying results depending on the language.
But there is an inherent order for these, even hard-coded in
the code: When a parameter is deprecated, nothing else matters.
Otherwise it's required → suggested → optional. Doesn't it
make much more sense to order the column this way? Especially
because there are never more than these 4 hard-coded values.
This is one of the (few remaining) issues mentioned on
https://de.wikipedia.org/wiki/Vorlage:TemplateData#Vorlagendokumentationsseite_verbessern_%E2%80%93_MediaWiki_ungen%C3%BCgend
This patch also makes it so that a CSS class name is always
added to all status fields, not only to the required ones.
This allows for per-wiki or per-user styling.
Change-Id: Id3f1ffafe09a3817972a4ee4bd4a3ded7be6f039
This is all unused, e.g. because it just repeats a default
value. All verified by my PHPStorm IDE.
Change-Id: I69665e07ca2d04016dc16e93290ef276f6b2cd95
All API modules that are a submodule of the action=query API do
this already. What this method does is to forward all additional
information from the "generator" module to the module that uses
the generator as input. Without this line only the list of pages
is forwarded, but all metadata is lost.
The thing is: The templatedata API is not an action=query API,
but a separate action. But it's largly compatible. It might
even be possible to turn it into an action=query API, but this
is beyond our capacity at the moment.
Bug: T274907
Change-Id: I3c3c684109688c112ec15424119d4d30430ffd86
Parameters may include a `suggestedvalues` property, which is rendered
in the UI for some parameter types.
TemplateData editor UI elements are implemented behind the
TemplateDataSuggestedValuesEditor feature flag.
Bug: T271897
Change-Id: I14012c79b3fa0d48c58fd8999584cc03ec03575e
I tested this locally, and indeed: Try to edit for example your
own page http://en.wikipedia.org/wiki/Special:MyPage/common.js
Try to paste and save this:
var notWikitext = '<templatedata>{</templatedata>';
The page fails to save. (You might not see the error message
because of T258790#6751678.)
But this is not even wikitext. The <templatedata> string is
meaningless and does not trigger any TemplateData code when
the page is parsed and saved. Still there is an additional (!)
parser run that processes every page with the wikitext parser,
no matter what the actual content model is.
This does not only cause strange stack traces (see T272231),
it's most probably a massive performance bottleneck. Luckily
the majority of pages on the Wikimedia cluster is wikitext
anyway.
Bug: T272231
Change-Id: I2efcadc9bae6ecb37314f6d45c0c520abfbb85a0
Example:
On
https://en.wikipedia.beta.wmflabs.org/wiki/Template:Anschutz
the two parameters "state" and "capitalization_test" don't have
a label in the <templatedata> JSON structure. Instead the
internal parameter name is shown. But it's capitalized for an
unknown reason. I guess this is done to make the table look
"nice". But it causes confusion – see the ticket.
This capitalization is there since the very first commits from
2013, see I16d3f9e.
Compare with VisualEditor: Edit the template on
https://en.wikipedia.beta.wmflabs.org/wiki/Conflict-title-0.8542952978413387-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n
or use the old wikitext editor and TemplateWizard to insert
the template. In both cases the parameter names are not
capitalized.
Another argument why this capitalization is misplaced: When
there is no <templatedata> JSON blob, the TemplateData editor
auto-detects the parameters and semi-automatically creates a
minimal JSON blob. This is the moment where labels should be
created and stored so the user can edit them. But this doesn't
happen (for good reasons).
The user can't do anything about the current capitalization.
The only way to change it is to add a label that does nothing
but repeat the parameter name, just to undo the capitalization.
That should not be the way this works, I would like to argue.
Bug: T174771
Change-Id: Ia8133d3f0d6b79fe89c63bb0392a334c0a185a65
This will give results whenever template data is requested e.g. by
VisualEditor or the TemplateWizard.
Bug: T259705
Change-Id: I2a9e864b94b6f8f49ca3adaa46502627ab6b3322
We got the info we wanted, the statistics gathering is now just
causing extra ParserCache lookups.
This reverts commit dd81de53d7.
This reverts commit 9a85a1b67e.
Bug: T266200
Change-Id: I830797e287118fbde07e0e22e1304b30ee9f67e5
Switching ParserCache to JSON serialization requires
extensions to stop writing non-JSON-serializable objects
into ParserOutput::setExtensionData.
This should be deployed at least 1 train after dependencies.
Bug: T266252
Change-Id: I24dfbcff47b6a317d9928fda8c70da64f2d6bc82
This should help us decide whether it would be OK to
rely on the ParserCache to store parsed TemplateData.
This patch should be reverted once we have collected
the desired data.
Bug: T266200
Change-Id: I0631806145d46e4a5e7c177797b8fdfe7a152076
Transitioning of ParserCache to JSON serialization will add
a requirement that all the extension data is JSON-serializable.
This is the first step in transition - making it forward-compatible.
Bug: T266252
Change-Id: If1c9d9bb5b0039df80a9d9b30c247206d8844c0a
This null was being forced to string by PHP before strict typing in I9a20335
This is a rare error as self-closing tag is not allowed as far as
I can see and will emit proper syntax error after this change; but
it should not raise fatal exception
Bug: T263605
Change-Id: I1d9f674fb92d1f1cf70b57e820f8fc3312be9cc8
This fixes a series of issues:
* The JS implementation had a trim() in one place that was
missing in PHP.
* The actual parameter name in the paramNames/$params array was
trimmed, but the "normalized" name (this is only for duplicate
detection) was not trimmed.
* It was possible for an empty parameter to show up.
This resulted in very strange behavior, e.g. {{{ 1}}}{{{1 }}}
was detected as "1" and "10" (?), i.e. it would try to renumber
the duplicate in a strange way (string "1" plus a counter that
starts with 0).
Change-Id: I0a6371f3633b03b5b21809ecd06ea4c72d7d914d
These are not really variables. They are never modified, and not
meant to be modified. Using "static" was a common workaround
when we had no private constants in PHP.
Change-Id: Ie1234ce8833986431be95f8537282fa174978063
Html::open/closeElement are hard to read and possibly error
prone. We can easily avoid it in this case here.
Change-Id: I2251cb63e58bc132ced0bb684e3f0e3be35ab1aa
No subclass is directly using these. They don't need to be
protected. There are getters, if needed.
Change-Id: I27dcb8bee37b9559242451774c52240b490a18af
In detail:
* Callers don't need to know that the return value can be a
TemplateDataCompressedBlob. All relevant stuff is declared in
the base class.
* It's not relevant which internal method returned the status.
It's just the status of the object after it was constructed.
* "stdClass" is more specific. "object" includes more stuff
which can't be returned here.
* Avoid duplication and use @inheritDoc instead.
Change-Id: I68878a5b26ecd566fbea88b513ee697b45769659
In detail:
* Mark both as protected and make them call each other.
* Avoid duplication.
* Remove unused "null" default value.
Change-Id: I272a68bb3cc0c544ef306b16c2998458c2eb1a2d
Notes:
* In PHP, when a function parameter does have a strict type,
all it does is forcefully casting the value to this type. It
doesn't cause warnings.
* Violating a strict return type causes a warning.
* I'm intentionally not touching places where the result from
json_decode() is passed through. In theory this could be
anything. Let's update these later, after more refactoring
is done.
Change-Id: I9a203356f70cf9edd434f7dc4ca130c2b7605ab4
This fixes parts of a TODO in the code. Specifically:
* When an InterfaceText is an object, it can not be any object,
but must be an stdClass.
* It can't be empty.
* Language codes must be non-empty strings.
* Values must be strings.
I'm intentionally not adding more validation for the language
codes, as this needs discussion (what values should be allowed?),
and can potentially break existing pages.
Same for empty strings. This can easily happen when users
manually create a <templatedata> tag and copy-paste pieces that
are meant to be filled in later. Empty strings are not really
invalid (again, this needs discussion), but might be something a
client want's to ignore.
Change-Id: I0facaa08cffe5a5a038423a58d55bc90a40b2d75
Both styles create the exact same object. Casting an array to an
object creates an stdClass object as well. The main benefit of this
syntax is that there is much less repetition. Everything is one
token instead of individual lines, where each line might contain a
typo.
Change-Id: I8fb09e9d33e5a1d91d4b32a71f658b31c629987b
In detail:
* Don't pass the Parser by reference. Hook handlers don't need to
replace the object with another one, and shouldn't.
* Use __CLASS__ instead of repeating the class name.
* Returning true from a hook is meaningless and indistinguishable
from the default.
Change-Id: Iac60f7f4946eb78cfb3b579fcdb1cab8bdcac7cd
This is used by the includeMissingTitles option of API action=templatedata.
Parameter syntax existing within nowiki tags or comments will not be valid
for the template.
Bug: T237195
Change-Id: Ibbfa3e21488f2a37fc494862e929baf50607d4c9
Removing the sorting arrows from tables that have one row or less in
templates. By using variable $sorting that changes according to the
coung of elements in the array $data->params, to determine whether the
table should have "sortable" class or not.
Bug: T126150
Change-Id: I414c2375d4eb4da5d78f92f6b4e99b55e314ce4d
Additional changes:
* Removed phan-taint-check-plugin from extra, now inherited from mediawiki-phan-config.
Change-Id: I1f52b9bd1dbbdf15359d16efd5fc35eaf8b8ea76
The <templatedata> extension tag wants to render itself into HTML
before an OutputPage has been set up. Unfortunately, this meant that
we needed to hack in a call to OutputPage::setupOOUI() with default
theme and directionality, regardless of whether those were correct.
Slightly improve matters by using the directionality of the user
language object, but this codepath really needs to be rethought.
Follow up to Ie3f37b8b972dc6e89e3cd334672954d3632c1b20; see also
the discussion in T101666.
Change-Id: I6ae99ea6bd8b6ee21b8ed8b06dc4e9e324050ab7
This adds a missing call to OutputPage::setupOOUI(), to fix a code path
where `<templatedata>` is expanded via API call (eg, during Parsoid
rendering) and an OOUI theme has not been set up. This hacky workaround
is pretty bogus, since the output will not have the proper user skin
or directionality, but it avoids a crash (and duplicates the previous
behavior, without using the deprecated method).
Change-Id: Ie3f37b8b972dc6e89e3cd334672954d3632c1b20
Follows-up 956367fb90.
* Fix typo.
* Remove <del>footgun</del><ins>dangerous return value</ins>
from this unabortable hook.
* Document the weird PageProps workaround.
This should be fixed in core.
Change-Id: I6b22e9c2112039e5703e6a62252f1909b15c8887
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: I8846de470461b4887dbc1e33653c8cdec8839366
* This hook supports functionality that Parsoid/JS used the MW API for.
Parsoid's html2wt code requests templatedata for titles one
at a time currently and so this hook also supports lookups one
title at a time.
This initial implementation is good enough for initial Parsoid/PHP
deployment.
* As part of later performance optimization, we should figure out if
we want to fetch templatedata for all templates in batch mode and
work out the details (selser doesn't touch all templates, for one).
The hook does accept an array of titles, but it looks them up
serially in a simple for-loop.
Separately, we need to resolve if this is better architected as
a lookup service vs. a hook as it is now (see discussion on gerrit).
* Tested locally on my local wiki.
Bug: T238954
Change-Id: I01fb6a9f334ca37a703be497524180f87fb8bbf7
This change avoids the flash of missing sorting buttons while loading,
but only with I0b446d18f47428d8c0c4aed78b75de16fe106218 in MediaWiki
core included in MediaWiki 1.33 or higher.
Depends-On: I0b446d18f47428d8c0c4aed78b75de16fe106218
Change-Id: I2c3eeb3a83822798ae0c46fcfea071df706798d7
Ib40d23da made it possible for $data->paramOrder to be unset.
ApiTemplateData needs to check for that before passing it to
ApiResult::setIndexedTagName().
Bug: T213953
Change-Id: I7647ddfc47426c7b6be8ddcd84472371eec07d72
When normalising a TemplateData blob for API consumers, we previously
automatically generated the 'paramOrder' with the order of the keys
as they were specified in the JSON blob (which, unlike in JS, is
known to be reliable in PHP).
While this was useful to some extent, it made it mandatory for
Parsoid and VisualEditor to always re-order properties during
edits to match the specified order.
In order to allow the order to remain flexible/unspecified, the
original Specification made paramOrder optional, but during the
implementation I gave it a default, which kind of defeated that
intention. This patch fixes that.
Bug: T138200
Change-Id: Ib40d23dac7e75274083f95a25c5aa1c22dfffb22
