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
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
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
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
* 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
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
This resolves two issues:
* Database inefficiency (T52512).
* Doc pages showing on Special:PageWithProp.
It also makes progress on (but doesn't fully resolve) T54448,
by not outputting encouraging accidental use of "/doc" by
displaying descriptions and parameter documentations for them
below the suggestions in VisualEditor.
Bug: T52512
Bug: T54448
Change-Id: I99323d7adc5fc072a85ff1d3595f805f537bbb43
