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
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
Page status indicators are icons (or short text snippets) usually
displayed in the top-right corner of the page, outside of the main
content. Basically, <indicator name="foo">[[File:Foo.svg|20px]]</indicator>
may be used on a page to place the icon in the indicator area. They
are also known as top icons, page icons, heading icons or title icons.
I found the discussion on bug 23796 highly illuminating. I suggest
that everyone read it before suggesting different design choices.
I spent some time with a thesaurus pondering the name. "Emblems" and
"badges" were also considered, but the former has a much more limited
meaning and the latter is already taken by Wikidata, with a similar
but subtly different feature set. I am not aware of any naming
conflicts ;) besides new talk page message "indicator" (used by core
and Echo in some documents) and OOjs UI indicators (tiny icons like
the arrow on a dropdown form element), which shouldn't be confusing.
Potential use cases include:
* "Lock" indicators for page protection levels
* Featured/good article indicators
* Redirect shortcuts display ("WP:VPT")
* Links to help/manual for special pages
* Coordinates?… or globe icon for inline pop-up maps
Design features:
* Skin-customizable. Skins can fully control where and how indicators
are shown, or may just do <?php echo $this->getIndicators(); ?> to
output the default structure. By default they are not shown at all.
* Extension-customizable. Extensions can call ParserOutput::addIndicator()
to insert an indicator from one of the numerous parser hooks.
* Wiki-customizable. In addition to just using the parser functions,
on-wiki styles and scripts can use the provided classes and ids
(.mw-indicator, #mw-indicator-<name>) to customize their display.
Design limitations:
* Every indicator must have a unique identifier (name). It's not
possible to create arrays, or to have several indicators with the
same name. In case of duplicates, the latest occurrence of the
parser function wins.
* Indicators are displayed ordered by their names (and not occurrence
order). This ensures consistency across pages and provides a simple
means of ordering or grouping them.
* Indicators are not stored, tracked or accessible outside of
ParserOutput (in particular they're not in the page_props table).
They are intended to merely reflect the content or metadata that is
already present on the page, and not be data themselves. If you ever
think you need to list pages with a given status indicator, instead
figure out what it means and use the appropriate tracking category,
special page report, already existing page_prop, or other means.
Corresponding patch in Vector: I90a8ae15ac8275d084ea5f47b6b2684d5e6c7412.
I'll implement support in the other three skins included in the tarball
and document it on mediawiki.org after this is merged.
Bug: 23796
Change-Id: I2389ff9a5332a2b1d033eb75f0946e5241cfaaf4
The existing API help, formatted as basically a plain-text document
embedded in XML and with a little bolding and a few links
syntax-highlighted in after the fact, works ok for experienced programmers
but isn't at all newbie-friendly. Further, all the help is hard-coded in
English, which isn't very friendly to non-English speakers.
So let's rewrite it. The help text is now obtained from i18n messages
and output in HTML, with the default display consisting of help for a
single module with links to help for other modules. This, of course,
necessitates deprecating many of the existing help-related methods and
hooks and replacing them with new ones, but backwards compatibility is
maintained for almost everything.
At the same time, action=paraminfo also needs to support the
'description' and other help-related fields being output in wikitext or
HTML, and I11cb063d (to access all modules via the 'modules' parameter
instead of having 'modules', 'formatmodules', 'querymodules', and so on)
is folded in.
And we also add Special:ApiHelp. When directly accessed, it simply
redirects to api.php with appropriate parameters. But it's also
transcludable to allow up-to-date API help text to be included within
the on-wiki documentation.
Note this patch doesn't actually add i18n messages for any API modules
besides ApiMain and ApiHelp. That will come in a followup patch, but for
the moment the backwards-compatibility code handles them nicely.
While we're messing with the documentation, we may as well add the
"internal" flag requested in bug 62905 (although the 'includeinternal'
parameter it also requests doesn't make much sense anymore) and a
"deprecated" flag that's needed by several modules now.
Bug: 30936
Bug: 38126
Bug: 42343
Bug: 45641
Bug: 62905
Bug: 63211
Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
Improves the "Sections are not supported by <PAGE>" error message when
it fails. Also add phpdoc comment
Bug: 68416
Change-Id: Iaa5d3a1f33b8a9c48263c2ce27cd3b4fe98fbf01
Simply clicking "Show preview" on the edit page triggered a deprecation
warning.
Also removed the wfDeprecated() call from the method, which is still used
in a few WMF-deployed extensions without a corresponding open change.
Follows-up e8f1fede77.
Change-Id: I2cfdc84b92cf13478b9f462028d525e4ec14fdf2
action=parse&prop=modules now provides the ResourceLoader modules used
on the page (included in the ParserOutput object). This is intended to
be used by the live preview functionality.
Bug: 24134
Change-Id: Ib5032e4eeaf6bb97dac965c580a5107437c7bbd4
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
