Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: Ibd54adb359d2993663db6453e83245d1335ccf63
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I813e0d8fb266474eab5ad59ba33f6cd089099212
Also replace some expensive HTML formatting with something much more
straightforward. The upstream methods also give very good debug
output.
Change-Id: Ie8cca306e0cd6293877b2d54178d7b4f0690b11a
This pulls the dependency out of __construct() up into the static
newFromJSON() method.
I'm also replacing the "ContentLanguage" service, which is a Language
object, with the plain language code. Features from the Language
class are never needed.
Change-Id: Ic4892cd22d83ff557af37e36e62e2af14bc58a99
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: I8e049e495a0d0f3a0e1ee02a8252354b12604bf9
* deprecated means "please do not use this".
* required means "you must use this".
* suggested means "it's a good idea to use this".
* optional means "you typically don't need this".
There is no combination that makes any sense. They are really
exclusive to each other.
Still we have to keep the three checkboxes for backwards
compatibility reasons. It was always possible (and will probably
continue to be possible) to have more than one of the three fields
enabled. While users like VisualEditor will make a good guess (e.g.
ignore the rest when "deprecated" is checked) I really think we
should not attempt to hide (and auto-fix) it in this dialog. That's
why the proposed code continues to show the old checkboxes when
more than one is checked.
Bug: T202851
Change-Id: I994268d658602761b180f489bedb50b91fe0c419
This is not really anything new. Most code already followed these
sniffs. This patch just fixes the remaining exceptions. Also:
* Remove PHPDoc blocks that don't add anything but just repeat the
strict types.
* Remove @file comments in favor of class-level comments.
* Add strict types where possible, most notably some `void`.
Change-Id: Iff6872dff68170b0fc4e82ac2ba3cad385e8773e
So far we show nothing but the index in the "paramOrder" array. This
is especially useless when a parameter is missing. The index just
points to the end of the array then.
Same when an unknown parameter appears. What the user needs is not
the index but the name of the unknown parameter.
I played around with a few formats. As suggested in this patch:
Required property "paramOrder[ "foo" ]" not found.
Invalid value for property "paramOrder[ "foo" ]".
A possible alternative is:
Required property "paramOrder[0] ("foo")" not found.
Invalid value for property "paramOrder[0] ("foo")".
Bug: T340377
Change-Id: I1dbef1b6e585d5b972a0c9a373a040aee6027cf3
These aren't sentences but lists of aliases as well as suggested
values. They are rendered as <code>, visualized as light gray boxes.
We don't need them to respect some language-specific word separation
to be able to read them like a sentence.
https://translatewiki.net/wiki/MediaWiki:Word-separator/qqq
explains how the message should be used.
Bug: T340378
Change-Id: Ia082b5ccb211524262f0c535bb178ee7ec3c20eb
We need to disable this so that we can update the message box in core
to use codex components.
Once I16d8f53b9a83a468acdb3803044f6c4e9d5dfeeb has been merged
the test will be restored using the new message box markup.
Bug: T326587
Change-Id: I3959c8f8d4c7bbe019f5e3b356649b5b7dc88907
Note this will make the templatedata API temporarily fail for
templates that are affected by this, until their documentation is
fixed. I think we have two ways to proceed here:
1. Thanks to Ie572809 we can change the API module to not do the
validation again. This allows us to make the validation more strict,
but the API module will continue to deliver the same data as before
until the parser cache is invalidated.
2. We accept it and merge this patch as it is. The problem is
extremely rare and easy to fix.
Bug: T333826
Change-Id: I16c7cc2328c47dde196e2dc07edb2eace33a624f
This makes it possible to use these steps independent from each
other. For example, a future patch can get rid of the re-validation
that's done over and over again when the API is called.
A significant change is that this gets rid of an expensive deep
clone. It was necessary before exactly because validation and
normalization was intertwined. Normalized properties would mess with
the later inheritance.
Strictly splitting validation and normalization (and executing them
in this order) solved this. The only downside of this is that
inherited properties are validated twice. But this is much less of a
problem, compared to the deep clone, I would like to argue.
This was always covered by tests. You can still see the tests fail
when you flip the execution order of inheritance and parameter
validation.
Bug: T301337
Change-Id: Ie5728094f9ed813f53b709d8b5283c4b99dc7d63
This button, similar to an edit-section link, will launch the editor
and immediately open the TemplateDataGenerator UI.
Bug: T316759
Depends-On: Idb5e3c51a22361e0d9916d3c31444daeff310ed2
Change-Id: Ieb575c499c16d87c28972a55662ef0bd9cb72c06
Some time ago there was a little bit of custom CSS applied to the HTML
table rendering. This is broken since patch I74214ea from 2016. This
patch renamed all CSS classes but forgot to update the PHP code
accordingly.
I decided to not change the HTML rendering because these class names
might already be used in custom per-wiki or per-user CSS. Instead I
partly revert I74214ea.
Unfortunately, some of the styles are quite dramatic, don't look good
or just don't work. I decided to remove some. The argument is that
the HTML rendering looks the same for 6 years now. I don't see a good
reason to change it now.
In detail:
* Suggested values are not aliases and should not be rendered in
gray.
* The message "no description" is rendered in gray and italics. But
this was applied to the wrong DOM element and made everything else
gray and italic as well.
* The color #777 is not readable, violating WCAG rules. While it's ok
to dim aliases and such, it must be at least #555 or darker.
* The "nowrap" destroys the table the moment one of the parameters
does have a longer name or alias. Let the browser handle this, as
it did for 6 years now.
* Same for rendering aliases as individual, indented blocks. This
makes the table unnecessarily big when there are many aliases, and
just doesn't look right. Again, let's stick to what we had for
6 years.
Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
The idea is to make it a little easier to follow what's going on
here.
This also improves an error message when tests fail.
Change-Id: If35be8aefab5a1568d53a9ecdc4313a66f71317b
<pre> behaves very similar to <nowiki> in so far that whatever it
contains doesn't get parsed as wikitext. It might contain {{{…}}}
tripple brackets, but these aren't going to be activated as template
parameters.
Bug: T91326
Change-Id: I05c24e369d97c48161c565e2ef30969ec28c6a23
This method is not used anywhere else:
https://codesearch.wmcloud.org/search/?q=getRawParams
I tried to make the code a bit more readable. Notable:
* Make use of the return value we get from the preg_… function.
* {{3,} means "the character '{' 3 or more times". {{{+ does the
same. Note the { doesn't need to be escaped when it's not
followed by a number.
* At the end, it doesn't make any difference when we scan for
optional closing brackets. The moment we find at least 3 we are
done.
The test is intentionally not moved. This is something for a later
patch.
Bug: T301337
Change-Id: I55e31ceecea2ae7c35bcfbc2d641b35f751820db
One method is only public to be able to test it. Others look like
they have been made "protected by default", which is not needed
anywhere.
Change-Id: Ib2231f0b2a879323aa53f8d40a175527c5b131d8
Effectively a no-op. This patch doesn't change what the code does.
Tests are in place to prove this.
As before, the tests are intentionally not moved but left in place.
This is for later patches to clean up.
Change-Id: If130e0d006a36d8c755288f8a4e4e9a4c42a6295
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
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
