The two methodes are deprecated since
I0ab14ca936eec1eead91d4eb0970f898628c8388 included in REL1_42.
Depends-On: Ic3343446b1a41760eb1b8fd1e9ad557abac89639
Depends-On: Iae5cf4c0a0d8fdac7e291fdeb0e7f4e4a78a1d58
Depends-On: I226b259e361d3d27ec89975353fdf6396ba60ccb
Depends-On: Ib405ad79b3c348bed51a8938a6a8f73bd35267d2
Depends-On: I41d1516e185ceb5c49b38361360a3adad1a333de
Change-Id: I5452a46ee5fd85efb3835a108c947950945e91f3
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Idc09b4f3e1ffa40f234b34cd8c0c515bd58ce67b
* This patch improves the performance of an
ext:Gadgets regular expression which helps parse
out sections of the gadgets definition page.
Bug: T363773
Change-Id: Ic9e1a181b261ae4d25e9ce2f91ad12f92e9855d9
The reason for this hook is not the validation itself, because that
is already done by `GadgetDefinitionContent->isValid` which is part
of the core Content interface, already enforced by ContentHandler.
Instead, the hook was here to provide the custom interface message
GadgetDefinitionValidator, because the core Content interface is
limited to boolean isValid(), which provides a very generic error
message.
However, nowadays ContentHandler exposes this mechanism directly
such that we can directly attach a custom message to it without
needing to wait for the stack to reach the EditPage and then override
it after the fact from a global hook.
Also:
* Simplify validation logic towards "is" checks with only an
expected description.
* Move schema.json file to top-level file.
It has been unused for as long as it has been in the repo, despite
appearing (due to its placement) to be used as part of the source.
It was added, I believe, with the intent to be used by the validator,
but it isn't. It also isn't validated or checked for correctness
by anything right now.
For now, keep it as informal schema in the top-level location for
easy discovery where perhaps others can find a use for it.
SD0001 mentions gadget developers may want to start using it for
Git-maintained gadgets to help with validation in their IDE, after
Gadgets 2.0 is launched.
Test Plan:
* Set `$wgGadgetsRepo = 'json+definition';`
* Create `MediaWiki:Gadgets/example.json`
* Attempt to save "x" in settings.namespaces item.
* Attempt to save "x.zip" in module.pages item.
* Fails with this patch, similar as on master.
Bug: T31272
Change-Id: I61bc3e40348a0aeb3bd3fa9ca86ccb7b93304095
For each item, either display human-readable and translated text,
or display a technical non-translatable identifier as `<code>`,
with optional localised text in the title attribute.
* Re-format "rights" as a sentence instead of a bullet list. It was
the only one using a bullet list, which made it feel a bit long.
* Re-format "actions" as `<code>` since they are not localised.
* Re-format "contentModels" as `<code>`, and add the localised display
name in a title attribute, same as we do with "rights" already.
ContentHandler::getLocalizedName() is also used already on
Special:ChangeContentModel.
* Fix "contentModels" to set `needLineBreakAfter = true`, otherwise
if a gadget also sets "supportsUrlLoad", then that sentence is
appended to the previous line.
Update phrasing and sorting to be consistent everywhere, and adopt
native PHP types where possible.
In most cases, I made things alphabetical, with the exception of
Special:Gadgets user interface output, and Gadget class methods,
which both follow the order of most recently added feature last
(rights, skins, actions, namespaces, contentmodels, categories).
Highlights:
* Fix namespace IDs type. These can be strings when they are parsed
from the gadget definition text, not always integers.
* Add explicit default for 'category'. In theory not needed because
MediaWikiGadgetsDefinitionRepo has a `$section = '';` default, and
MediaWikiGadgetsJsonRepo uses GadgetDefinitionContentHandler where
`category: ''` is part of both the initial page content, as well
as merged via getDefaultMetadata.
This default benefits simpler test cases, and static analysis,
since the Gadget class constructor does not (yet) require it.
Without this, getCategory() could TypeError due to returning null.
Bug: T63007
Change-Id: I3b2c72a6424d520431d03761d23a5a222518ce3d
Adds a "categories" option to the gadget definition, which takes a
list of category names. Enabled gadgets will only load when the
viewed page is in one of the required categories.
Bug: T204201
Bug: T63007
Change-Id: I0ced9507bdab6cacd0baf2a331859099f35b73e5
This is the most minimal patch possible to fix the regression. More
can be done in later patches.
Bug: T359290
Change-Id: I9351bdbc2f985e72fb253e424cd7523b73820dcd
MultiGadgetRepo is a wrapper around two or more GadgetRepos so that
they can be used at the same, facilitating migration from one repo to
another.
If a gadget appears in both repos, the definition in the first repo
takes precedence, and a warning is shown on Special:Gadgets.
This can be enabled to wrap GadgetDefinitionNamespaceRepo and
MediaWikiGadgetsDefinitionRepo by setting $wgGadgetsRepo to
'json+definition'. In this configuration, once a new JSON definition
exists for the same name, it is used instead of the old one, and the
old one can then safely be removed at a later time in the safe
knowledge that it is no longer used.
Adapted from If3cc5e22e9812d0fd1a9e8e269ea74a7f667dadd
Bug: T140323
Co-authored-by: Kunal Mehta <legoktm@debian.org>
Change-Id: Ibad53629e63ec8713d7a3b84a19838b94600588e
== What ==
* Remove the empty Gadget and Gadget_definition namespaces.
* Remove the "gadgets-definition-edit" user right.
* Remove need for custom namespace permissions that previously
had to extend editsitejs to apply to NS_GADGET.
== Why ==
Simplify the (unused) "GadgetDefinitionNamespaceRepo" backend for
Gadgets 2.0 by making it less radically different from the status quo.
The experimental 2.0 branch will now make use of the "gadget definition"
content model via "MediaWiki:Gadgets/<id>.json" pages, instead of
through a dedicated namespace.
When I first worked the Gadgets 2.0 branch, content models
were not a thing in MediaWiki, and interface-admin wasn't a thing yet
either. Now that we have per-page permissions and per-page content
models, we don't really need a separate namespace.
This follows the principle of least surprise, and fits well with other
interface admin and site configuration tools such as:
- Citoid, MediaWiki:Citoid-template-type-map.json,
- VisualEditor, MediaWiki:Visualeditor-template-tools-definition.json,
- AbuseFilter, MediaWiki:BlockedExternalDomains.json,
- the upcoming "Community Config" initiative.
If/when we develop the SpecialPage GUI for editing gadget definitions,
this can save its data to these pages the same as it would in
any other namespace. Similar to how Special:BlockedExternalDomains
operates on MediaWiki:BlockedExternalDomains.json.
See also bf1d6b3e93 (I6ffd5e9467), which recently removed the
gadgets-edit user right in favour of the editsite{css,js,json} rights.
Change-Id: I5b04ab251552e839087d0a8a6923d205adc7f771
This makes way for "MediaWiki:Gadgets/<id>.json" to be used free of
any confusion or misinterpretation about the subpage being a
translation of "MediaWiki:Gadgets".
Change-Id: Icb68ce6c26a83d7201a97a5406f8752b3c5b0855
This already returns safe Message objects, which allow Special:Gadgets
to localise it accordingly.
Avoid formatting the list ahead of time with a hardcoded user language,
and instead use Message::listParam() so that the caller controls
the Language object. This makes it safe to use in jobs, CLI, tests,
load.php and elsewhere instead of previously where RequestContext would
cause an exception or use something the caller doesn't control.
Bug: T298334
Change-Id: I77dd3c7fef86b4c8c41837bfb276b019f30baeb0
* Validate that pages have .js, .css or .json suffixes.
* Validate that namespaces are integers, disallowing doubles.
* Validate that type is either general or styles.
* Validate that targets are either desktop or mobile.
* Fix validation of skins: stop allowing `true` as it isn't actually
allowed - it causes an exception in Gadget::isSkinSupported().
Bug: T298334
Change-Id: Ic59c20172f496d281acd59419f5c760ad29ce317
The column user_properties.up_value is a text based type in all rdbms.
postgres does not autoconvert strings to numbers, so SUM( up_value )
gives an error when running on postgres.
The use of SUM( up_value ) is also problematic on mariadb/sqlite, as
up_value can be set to any number via the Action API's options module.
This value goes into the sum and produce a wrong result. Using a
non-number value allows to remove the value from the sum and that also
produce a wrong result.
Change the query to exclude the rows which disables a gadget and just
count the "active" ones. Typically there are only rows to disable a
gadget, when the gadget is marked as default, but default gadget are
displayed with the message 'gadgetusage-default' and does not needs to
be counted. In case a gadget was default in the past, there could always
such rows, so be safe and exclude them. That means it is safe to only
count for "active" gadget option usage.
This also allows to remove the up_value condition on the join to
querycachetwo as only rows to enable a gadget are now selected and get
joined to find the active users.
For the join condition use an assoc array, as for database condition the
database class is quoting the value of that array, if that is a string.
In postgres the " is used to quote columns or tables, but not values,
that gives a query error on postgres about the condition.
fixed when using the array style and not "raw" sql.
Define the condition only once as it should be the same for both
queries. Use the new IDatabase::expr function to write that sql piece.
Change-Id: I8dfc3fd5adc4c4bdabceaab20c4b37ffd48e6bee
This requires 1.42 for some new names
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Iacbea33299995c537a7ef77b524614ad02c6a559
