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
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
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
Three-braces-and-a-bang can be a table starting construct in templates.
This also fixes an overlooked bug in which the test wasn't checking
array element key names.
Bug: T157029
Change-Id: I69ed4fc9fe3bb126b7b39abea0f58ad56adf3885
VisualEditorPluginModules loads whenever VE loads, so create a minimal
loader page to check if we are in the template namespace before loading
the rest of the TemplateData init code.
Bug: T208765
Change-Id: Id127eb4a2472a6ce9da7672f9237b182cf6be2eb
