This has a number of implications:
* A deprecation warning is automatically generated if the value is used.
* action=paraminfo can list it in a machine-readable manner.
* It is automatically flagged in the help when message-per-value mode is
used.
* In values lists in the help, it's specially marked (currently
strike-through).
* ApiSandbox will mark it in the widgets (currently strike-through).
Deprecation of submodules is not automatically detected here, that's
left for a later patch.
Bug: T123931
Change-Id: Idad6377063e457f9352a99df5c7cc15b1563579e
Now that ParserOptions->isSafeToCache() exists, use it where necessary.
This also moves the use inside the makeParserOptions() method so other
callers can pick it up as well.
Then pass the flag as $forceParse into WikiPage::getParserOutput()
instead of duplicating the logic in several cases, and generally clean
up the logic in the module to let WikiPage decide when to use the cache
in more cases.
Change-Id: I0079e10a40997e4a3b59ac21ef6c92246a147736
Follows up Iaa85ac49.
This also ensures that the Skin correctly refers back to the constructed
OutputPage even when 'useskin' isn't specified.
Change-Id: I983e907c05acd753733e88904953f355e26f393d
Required for Idc41934eb89.
* If 'useskin' is set, run ParserOutput through OutputPage (with proper
Skin set up). Specifically call addParserOutputMetadata().
Then use OutputPage isntead of ParserOutput to retrieve that subset
of meta data. Such as modules, lang links and config vars.
* Deprecate 'effectivelanglinks' in favour of 'useskin'.
* Simplify 'headhtml' support and re-use this new code.
Change-Id: Iaa85ac49f6e0cbdf7f1bb0f50a8f7730d119f0a2
This will allow CSS to target just the parser output, without also
accidentally targeting the edit form, diff tables, and so on.
Bug: T37247
Change-Id: If4eb5bf71f94fa366ec4eddb6964e8f4df6b824a
Depends-On: I330c6aa4aaee045614b1801ed34bc9e03be69650
Depends-On: I52a518fa44e017841fe78474012cd69823e0a41d
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
Passing in the 'parsewarnings' property will return warnings related
to parsing content.
Bug: T92634
Change-Id: I7e54765ee9a24ffb78e7763f73a520151023baf6
We already throw around some exceptions that are localized
(ErrorPageError and its subclasses, MalformedTitleException), but
there's no standard way to recognize them. Let's change that.
Then let's use them in the API to be able to have internationalized
errors when such exceptions are caught, instead of wrapping the
English-language version.
Change-Id: Iac7c90f92a889f8de9dae373547c07b884addaea
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
For example file pages from foreign repos, MediaWiki-namespace messages
that haven't been locally customized, and titles manipulated with the
'TitleIsAlwaysKnown' hook.
This allows clients to be able to display such titles as bluelinks
rather than redlinks.
This also has ApiPageSet populate LinkCache to make later checks of
->exists() and ->isKnown() more efficient.
Bug: T141963
Change-Id: Idbdfd2896c0ce9425ededd7cb4b60eda89ba7ef5
Prevents leaking page contents for extensions that deny read rights
to certain pages via a userCan hook, but still allow the user to
have read rights in general.
Issue originally reported by Tobias
Bug: T115333
Change-Id: I19f5c2583393794cff802a70af7ccf43c2fed85c
This code has been rotting for a while. It is important missing stylesheets
and critical inline scripts. Consuming these items is quite risky.
One can't safely use it to update an existing document (as some parts are
duplicative or conflicting). One also can't use it to build a new document as
several critical pieces are missing.
* Since ResourceLoader was introduced in 2011, buildCssLinksArray() doesn't have any stylesheets.
For most pages, this will produce an empty array for headitems.
Mark it as deprecated since in favour of 'prop=headhtml' or 'prop=modules'.
Change-Id: I6084e4454e245f59bf3c82d6db830977725f71e5
No uses of 'modulemessages', getModuleMessages() or addModuleMessages()
anywhere in Wikimedia Git.
Change-Id: I59420880f3545d1aabf9bcbea1e34b1475697d26
$context->getOutput() returns an OutputPage tied to the main
RequestContext at the root of the chain, not to the modified context
we're actually using.
Bug: T139565
Change-Id: Ie086d7f2ad3f7b5f50e3a2f83b1680e760b85e5e
This allows extensions (e.g. TemplateSandbox in I77a9aa5a) to better
interact with the ApiParse and ApiExpandTemplates modules.
Change-Id: I72d5cf8e0b86e4250af1459219dc3b42d7adbbb8
Some were being logged, and some weren't. Let's log them all
automatically when PARAM_DEPRECATED is processed, instead of requiring
each module to manually log them.
Bug: T117569
Change-Id: Ia38aeeccd0b9857b12b28914f509284483fbcca8
In the interest of not blocking other work, I4b0e55fe worked around an
issue locally in ApiParse while filing T110269 for the larger task that
would be needed to properly fix the problem.
This adds a @todo comment referring to that task to make the situation a
bit more clear, since I4b0e55fe was merged too hastily to get the
comment included there.
Change-Id: I5be690aa5316cba1d498358635d497aa465a9972
* Rename disablepp to disablelimitreport, since it does not disable the
preprocessor (which is what PP stands for in "NewPP").
* Introduce new option "disabletidy" for T89331
* Suppress the use of the parser cache when options are specified that
affect the output but are not in ParserOptions::optionsHash(). This
was already broken, but the damage was fairly limited since the
options rarely caused user-visible changes. It would break very badly
if I use the disabletidy option for what I am intending.
Change-Id: I4b0e55fe34e237a68450f583bf59bab7dd703a29
Deprecate 'generatexml=' by adding 'prop=parsetree' to revisions,
deletedrevisions and action=parse.
'generatexml' of action=expandtemplates is already deprecated and
replaced by 'prop=parsetree'.
Reason: Api parameter to control the output of a module usually gets
added as type to prop=, not added as new parameter. New parameter
usually used as input parameter for the module.
For revisions and deletedrevisions this allows to get the parsetree
without getting the whole content (makes the result smaller, when just
one is needed)
Change-Id: I7403110d7bd07e9eb2a10e1b398d97f0f40298be
Adds the 'modules', 'jsconfigvars', and 'encodedjsconfigvars' props
to action=expandtemplates, that output the modules and Javascript
configuration variables added to ResourceLoader by extensions and
parser functions, in the same way action=parse does.
This is needed by Parsoid to correctly include all modules used by
parser functions.
Based on I5c3ccb25385e57633639bb0c7e6f562eb58b05a2 by @Jackmcbarn.
Bug: T69540
Change-Id: Iaf58c66c987a318c0dd1ee2b81774106c40e7561
New types 'text' and 'password' for where a <textarea> or
<input type="password"> would be preferred over <input type="text">.
Some timestamp parameters get actually tagged as 'timestamp'.
'submodule' types change the 'submodules' output property from a boolean
to an object indicating the mapping from values to module paths. And
they get an indication of the submodule parameter prefix (e.g.
generator's "g"), if applicable. "generator" actually gets reported as a
submodule type, using this new mechanism.
action=paraminfo will now indicate ApiBase::PARAM_RANGE_ENFORCE status,
and return better-formatted defaults for timestamps and booleans.
Change-Id: Ic862d6f8fe13f7eb6b4298683514d33af5823e47
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
Because the $pageObj state is what actually ends up getting used.
If $pageObj thinks an old rev is the latest one, then we are in
trouble, even if $rev knows what's really going on.
Bug: T95466
Change-Id: I4d6ba4f18adaaad052d3bee1a575ba034aaf112b
When live previewing a 'new' section, we want to automatically add the
edit summary/sectiontitle as an H2 element, as the Edit Page and API
do as well.
Bug: T84877
Change-Id: I40925c16284bb97a4d491e12a8e7878b9d1b4810
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
