If you transclude a special page, OutputPage::addWikiText can cause
problems. This prevents that from happening, by using a new object
if currently in a parsing operation.
Bug: 14562
Bug: 65826
Change-Id: I7c38fa9e2fbd270e45f73f522612451e77ab8cbb
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
We previously had addParserOutput(), which added everything and did
some other magic, and addParserOutputNoText() which, as the same says,
added everything but the text.
I renamed addParserOutputNoText() to addParserOutputMetadata() and
created two more functions:
* addParserOutputText(): This is almost identical to adding the raw
HTML, but calls the OutputPageBeforeHTML hook like other
addParserOutput*() methods.
* addParserOutputContent(): Like addParserOutputText(), but also adds
the ResourceLoader modules and variables associated with the parser
output. This is important especially for some extensions like
TemplateData or SyntaxHighlight which add styles to the page to
enhance the display.
Change-Id: Iead541886fd1ccdbdf1cb06af71b34cd04644985
Usually these are API siteinfo requests (api.php?action=query&meta=siteinfo). In that case, this code used to produce a fatal ("Call to a member function getPageLanguage() on a non-object").
Change-Id: Ifb6f99fe554890ff2719220f58d1b6c1a7a95ddc
These skins have been obsolete since 1.16 and aren't supported well at this point.
This deprecates those skins and begins deprecation of the creation of <head> contents
with only chunks of OutputPage stuff. The entire head should be created by OutputPage.
This also deprecates some old methods responsible for returning raw chunks of html for the head:
* getScript
* getHeadItems
Output of HeadItems is also tweaked. Previously there was no newline added
after each item, now there is. Most of the callers of addHeadItem don't use
their own newline and as a result end up on one line.
Change-Id: I13e25cc8d8fc3aa682f23b019a2fda0e809a5f64
We've had the logic for stripping the outer <p/> element in three
separate places. The version in OutputPage was missing the '$' at the
end of the regex, that was most likely a mistake caused by the
duplication.
Also, extend the logic in order not to generate invalid HTML if the
input contains more than one <p/> tag. Added tests for this and the
previous behaviour.
https://www.mail-archive.com/mediawiki-api@lists.wikimedia.org/msg03188.html
Change-Id: I6bb3597898324556df912a23a7ffc9ff250b8f58
Derk-Jan Hartman suggested this to remove a HTML validation error. As he
noted, the HTTP header is also more effective, since it works on
intranets, and is not sensitive to ordering issues within the <head>.
See http://stackoverflow.com/questions/6156639 .
Bug: 62885
Change-Id: I2214abcb1badbbaca48427a31d1218c9db9a6af7
Variants included 'in <version>', 'as of <version>' and just the
version number.
Some @deprecated annotations do not have the version number at all,
I want to hunt them down separately.
Change-Id: I8208c6097098f4735d4f51bc42254675f1f27f6d
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I64e8cfe478cb0ba438f40b0631d6e9049cdab567
Also swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ic36c8c7820a6c2d603f1138130670c6bf6a1ca59
Changes:
* Removed hardcoded logic in OutputPage regarding modules
being "enabled".
Previously we would always output state=loading and use
$wgAllowUserJs (and others) to decide whether to output
state=ready or makeResourceLoaderLink.
Now, we no longer unconditionally output state=loading and
simply always call makeResourceLoaderLink. That method takes
care of checking whether modules are enabled and non-empty
and returns state=ready when that is the case.
This cleans up cases where the duplicated and incomplete logic
in OutputPage thought the module was non-empty but turned out
to be empty and thus would output both state=loading and later
state=ready for the same module.
* Clean up documentation for makeResourceLoaderLink (inconsistent
ordering of type hint and $var, and @return was missing the fact
that the returned html can also contain <link>).
* makeResourceLoaderLink now returns an array of html and module
states. This allows the consumer of this method to combine the
states in 1 larger script tag on top of multiple
makeResourceLoaderLink calls (e.g. one state script followed
by multiple <script src=load.php>).
This isn't to reduce html output, but to make sure we inform
mw.loader about modules before the <script src=load.php>.
If we were to mix/alternate the state script and load.php
requests (which are blocking in html), it is possible for those
scripts to request other modules. We need to prevent duplicate
loading of modules we already know are going to be requested
by the HTML output futher down.
* Removed spurious new line.
Example of change in HTML output:
* The output has been reduced from:
- loader.state( site: loading, user: loading, user.groups: loading )
- loader.load( .. )
- <script src="load.php?modules=site ..">
- loader.state( user: ready, user.groups: ready )
to:
- loader.state( site: loading, user: ready, user.groups: ready )
- loader.load( .. )
- <script src="load.php?modules=site ..">
Change-Id: I91754ce5fae3d05b4bfa7372372eba81ee2fc579
- OutputPage: if $wgCachePages is set to false, then it can be shown
back to the user
- AjaxResponder: don't send back to the user (for consistency with the
other calls to wfDebug(), and this can't be displayed to the user)
Change-Id: I17794016cfaef65ee3df3b82ceb8cb3a32ac7c67
action=render is often used to pull the rendered HTML of an article
for inclusion in a different context. More often than not, the edit
links are not desired in that context.
This reverts commit a04b5d5dcb
and redoes Iab02cbd42f2f93f0f5264a74691ae1b84f296f12.
Bug: 19415
Change-Id: I26213653c017c2e19a6f6799f3ea0676ff8524d1
The OutputPage has variables for modules, moduleScripts, moduleStyles,
moduleMessages and the config vars, but the ParserOutput is missing the
last one.
With ParserOutput::addJsConfigVars it is possible to add scripts and it
config vars at one place and have not use the MakeGlobalVariablesScript
hook or other ways to get the needed javascript variable in the output.
Change-Id: I6ad61cca76805f6b9d76e053c98c7509c323d5da
- The parameter is now a string, making is more understandable than
boolean values
- It takes the same values in both wfDebug() and wfDebugLog() (except
for 'private' which is only used in the latter)
- This adds a new possibility to wfDebugLog() to log the message either
on the specific log or the general one, but not to the debug toolbar
- Old boolean values are still recognised for backward compatibility
- Also send the messages passed to wfDebugLog() to the debug toolbar
when they are written to a specific log and not restricted to logs
- Updated the calls of and wfDebug() and wfDebugLog() with the last
parameter to change it into a string
- Renamed MWDebug::sendWarning() to MWDebug::sendMessage() and added
$group parameter to it; will not break anything since that method
is marked as private
- Changed the call to wfDebug() from MWDebug::sendMessage() to use
wfDebugLog() with 'log' as thrid parameter, so that those messages
can be logged separately from the main log and they don't show up
a second time on the "debug log" tab of the debug toolbar
Change-Id: I1be09d4c1d3408ed5b26a5db02691c17c0ec0926
The method has the following signature:
OutputPage::showErrorPage( $title, $msg, $params = array() )
$msg can be a string or a Message object.
If it's a string, a Message object is built, with $params as parameters.
If it's a Message object, $params is ignored.
The core now triggers a notice in the case a call is made with $msg an instance
of Message object, and a (non-empty array) $params argument is given.
Change-Id: I227a416f088fc1acd6a04345ed0e24d06f967ecc
It is a very advanced user preference with little usage and is often misleading.
Updated Release Note.
Bug: 52809
Change-Id: I43f6205df53c7a38717c60a2d7d144307feb58a4
The Line continuation Coding conventions prefers the closing parenthesis
on the same line than the beginning curly braces. This is done for ifs
and functions.
Also move some boolean operator from the end of a line to the beginning
and changed some indentation to make the condition hopefully better
readable.
Change-Id: Id0437b06bde86eb5a75bc59eefa19e7edb624426
This reverts commit 2248021997.
That revision caused section edit links to be shown on views of old
revisions. See comments there for suggestions on reimplementing it.
Change-Id: Ie65e3de84b44866e4ab1fc222a365cb3a9180ee1
OutputPage's addTemplate() is now a wrapper around QuickTemplate.
This allows more flexible usage of templated HTML, as
required by some third-party extensions.
Change-Id: I943e8e50438c716b7b56d2f908da38a4bf73d9e2
It often happens that wiki sysops want to change it site wide, especially
when they want to change the format (eg, have {{SITENAME}} removed, or
replace the hyphen with a middot).
Bug: 48701
Change-Id: Iaf00fca1e89ae022c348c4fa0de32b998d7921a1
action=render is often used to pull the rendered HTML of an article
for inclusion in a different context. More often than not, the edit
links are not desired in that context.
Bug: 19415
Change-Id: Iab02cbd42f2f93f0f5264a74691ae1b84f296f12
A skin can have a relevant user, then some help links in the sidebar
are shown. When a user want extend this informationen with userjs, he
has to parse the existing items or the title param of the url to get the
name of the user for which this help links are shown. Having the name as
javascript variable makes it easier to add more links in the sidebar.
Change-Id: I17a75902b6e739d5149d332b6a94a6568b79501f
It's elitist mathematical jargon. In all cases dealt with here, it adds
no additional meaning compared to "if", beyond what was already obvious
from context. Thus, its only purpose is to smugly demonstrate that the
author attended their second-year mathematics classes, at the expense of
causing confusion for everyone who doesn't have such a background.
If you really think you need to convey extra information beyond what
"if" gives you, the English language contains plenty of devices for doing
so, without resorting to neologisms.
Change-Id: Iae21095d02ec2935c10e94f532235c2671c115b1
Currently, if an extension doesn't want a TOC, it has to remove it manually.
This change wraps the TOC in markers that make it easy to remove it in ParserOutput
on demand without fragmenting the parser cache with stuff like "use/not use TOC".
Change-Id: I2889bcb9eb999c9049601e92440132118e1a8a41
The function is more difficult to read than it need be by dint of some things
two names. I can't be the only one who finds 'wgCurRevisionId' => $latestRevID
ugly, right? Anyhow, lots of JS code depends on the JS variable names, whereas
the PHP variables exist only in the scope of that method, so it's clear that
it's the PHP names that should be brought in line.
Change-Id: Ibddd5d2fc8d75e0ade18ff3433714d52605f2911
Varnish seems to be returning the cached version of pages for users
after they have logged in over https, but access an http page. This
seems to occure because only the forceHTTPS cookie is sent on the
request, but varnish doesn't vary the cache based on that cookie.
Bug: 54513
Change-Id: Ia97ed80622191669ee5ca37af809d307bbdb61ae
mw.config provides wgCurRevisionId, which has the latest
revision number. This adds wgRevisionId, which indicates
the revision number currently being viewed. This is useful
when looking at old revisions.
Bug: 51594
Change-Id: Ie0d00f3a9a8af8533ab28204b5bb483a0092c710
It's a relic of simpler times, no longer used by any core skin. The
'mediawiki.legacy.commonPrint' module can be used instead.
(SkinTemplate-based skins do it automatically.)
* The 'mediawiki.legacy.wikiprintable' module has been removed.
* The skins/common/wikiprintable.css file has been deleted.
* Skin#commonPrintStylesheet has been deprecated; its return value is
ignored.
Dependency: I96e66ff8905416bea906d40cdd72ba646399191b
Change-Id: Icbcebc8f539f7786d037b717d262684e9931aca6
Also removed some unnecessary ones. I think I've caught them all.
The spaceless version already appears in core ~300 times (after
accounting for false positives when grepping). Some consistency would
be nice.
Change-Id: I607655b5f4366e66dc78730d5fd2f57ed8776cae