Benefits:
* Full per-language icons support. Icons that differ for each language
(such as the 'Bold' icon) will now always display correctly
according to user interface language, even on old browsers.
* MediaWiki UI icons support. When the 'mediawiki.ui.icon' module is
loaded, you can use syntaxes such as below to display any OOUI icons
(from the packs that were loaded) without involving OOUI itself.
<div class="mw-ui-icon mw-ui-icon-before mw-ui-icon-check">OK</div>
<div class="mw-ui-icon mw-ui-icon-after mw-ui-icon-check">OK</div>
<div class="mw-ui-icon mw-ui-icon-element mw-ui-icon-check">OK</div>
Summary of changes:
* Resources.php:
* Remove icons CSS files. Include image data JSON files instead.
* Split the images from 'oojs-ui.styles' module to separate ones.
* OutputPage: Update enableOOUI() method for newly split modules.
* ResourceLoaderImageModule: Make it possible to load image data from
a JSON file.
* update-oojs-ui.sh: Copy source files rather than distribution for
icon packs.
This is not an improvement when it comes to code quality, though :(
Issues include some nasty code duplication, using "source code" (image
definitions) from OOUI rather than just distribution files, and hacky
methods to load image data from JSON files live.
Bug: T92551
Change-Id: Id369ecaec7048dcf68ba1e4df748362760533782
Changing 'window.jQuery && jQuery.ready()' to 'if ( window.jQuery )
jQuery.ready()' means no *<![CDATA[*/ /*]]>* is required (because we
got rid of the ampersands). It's also more readable and more consistent
with if(window.mw).
Change-Id: I28262efb978c085e732b40f9dc5ddb1bda5c4376
Someone could theoretically try to hide malicious code in their user
common.js and then trick an admin into previewing it by asking for help.
Bug: T85855
Change-Id: I5a7a75306695859df5d848f6105b81bea0098f0a
The patch did not improve performance. I'd like to think that the increased
control over when inline scripts are executed makes the patch worthwhile
regardless, but that is post hoc justification and possibly a bit of personal
ego. Krinkle agrees that we may use some of the ideas in this patch in the
future but he thinks we're better off not heading down this path before we
have a better sense of where we're going, and I trust his judgment.
This reverts commit e86e5f8460.
Change-Id: I151f74a41dd664b5a0aa5cfd99fcc95e2686a1e6
The current ordering of scripts and stylesheets in <head> causes all major
browsers to serialize and defer requests that could be performed in parallel.
The problem is that external stylesheets are loaded before inline scripts. As
Steven Souders explains, "all major browsers preserve the order of CSS and
JavaScript. The stylesheet has to be fully downloaded, parsed, and applied
before the inline script is executed. And the inline script must be executed
before the remaining resources can be downloaded. Therefore, resources that
follow a stylesheet and inline script are blocked from downloading."[1]
In other words: the browser could start loading body images, but it refuses to
do that until it has executed inline scripts in head. And it refuses to execute
those scripts until the external CSS is downloaded, parsed and applied. You can
see the effect of this in this image, showing the request waterfall for
[[en:Gothic Alphabet]]: [2]. Notice how no images were requested before the
browser had finished processing the three load.php requests at the top.
To fix this, we want to move the inline scripts above the external CSS. This is
a little bit tricky, because the inline scripts depend on mw.loader, which is
loaded via an external script. If we move the external script so that it too is
above the external stylesheet, we force the browser to serialize requests,
because the browser will not retrieve the external CSS until it has retrieved
and executed the external JS code. So what we want is to move the inline
scripts above the external stylesheet, but keep the external script (which the
inline scripts depend on) below the external stylesheet.
We can do this by wrapping the inline script code in a closure (which binds
'mw') and enqueuing the closure in a global array which will be processed by
the startup module at just the right time.
Net result: external CSS and JS is retrieved in parallel, retrieval of images
(and other external assets) is unblocked, but the order in which code is
evaluated remains the same.
[1]: <http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/>
[2]: <http://people.wikimedia.org/~ori/enwiki-waterfall.png> (excerpted from
<http://www.webpagetest.org/result/150316_0C_7MB/1/details/>.
Change-Id: I98d383a6299ffbd10210431544a505338ca8643f
Replace spaces by underscore to build correct links to wiki pages. IE11
will show %20 for spaces. Also use urlencode to make the url safe.
Follow-Up: I2934b1708a0d207dcf3d940264f140613646f203
Change-Id: I5ef08441406e96aa9749476af0a81fc11fa4e4d6
Follows-up 9d390a09cd. It already wraps the only=script requests
for 'site' and 'user', but forgot about 'user.groups' which is
not 'scripts' but 'combined' (as regular module requests).
That request responds with mw.loader.implement whih will be absent
if the environment is unsupported.
With normal module requests, this is naturally covered by those
requests not being fired from mw.loader in the first place but
with hardcoded requests like these the condition wrap with
document.write is unfortunately required in the current reality.
Change-Id: Ib3a7378d0c44e601760fbbc5174da09bd7b7f492
All the chosen targets are translatable public domain help pages
on MediaWiki.org. Mostly special pages and actions for privileged
users for now.
Adapted from the Translate extension, credit to Niklas Laxström
(TranslateUtils::addSpecialHelpLink).
Depends on 6f5b29ff4e, whose commit
message has a typo addIndicator() instead of setIndicator().
Bug: T45591
Change-Id: I2934b1708a0d207dcf3d940264f140613646f203
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
Add an 'export' subpage to SpecialJavaScriptTest which allows
one to request a self-sufficient JavaScript payload that will
bootstrap a ResourceLoader client and load the test suites.
This is needed for using Karma (which only loads JavaScript,
no full html pages). As such elements from the Skin and OutputPage
will not exist. While all QUnit tests in MediaWiki core and
most extensions I've seen already use #qunit-fixture, this is
now required. This to prevent leakage of elements from one
test to another, but it also prevents tests from depending
on elements provided by the server.
While the Karma setup is still in the pipeline (might land before
this commit loses WIP status), for now this can be tested via
the 'Special:JavaScriptTest/qunit/plain' subpage.
Refactor:
* Use HTTP status code 404 in the response for "noframework".
* Simplify HTML footprint by using <div id="qunit"> instead of
hardcoding the full structure. This feature was added to QUnit
since v1.3.0 (Feb 2012), we're using v1.14.0 (Jan 2014).
QUnit's header is automatically derived from document.title.
* Remove redundant addModules() for 'test.mediawiki.qunit.testrunner'.
This is already added by default.
* Move allowClickjacking() call so that it applies to other modes
as well. The exported javascript needs to have wgBreakFrame set
to false so that test runners can frame it.
* Change mediawiki.special.javaScriptTest to not depend on QUnit.
It caused QUnit to load on error pages. And in theory the page
is suited for other frameworks and shouldn't load QUnit this way.
Bug: T74063
Change-Id: I3d4d0df43bb426d9579eb0349b8b5477281a7cfc
RevertAction::getDescription cannot set subtitle on OutputPage,
because the subtitle on OutputPage gets cleared before the
result of getDescription is added and than the subtitle is gone.
Refactored the code for building the backlink into a static function
and use it.
Change-Id: Iedad0b8e040035a9a10a0b140d2322357e6b539a
This mostly reverts commit 614d7e5c27.
Many wikis use MediaWiki:Common.css and associated pages to create a
custom "theme" for their wiki, which would no longer load on login
or preference pages, creating an inconsistent UI.
This re-adds the difference in module origin for different types
(styles, scripts, etc.), and now OutputPage::disallowUserJs()
checks the value of the "AllowSiteCSSOnRestrictedPages" config setting
to determine whether to allow site-wide CSS styles or not.
By default this feature is disabled to be secure by default.
Bug: 71621
Change-Id: I1bf4dd1845b6952c3985e179fbea48181ffb8907
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
Also, as this method is never called with an argument in any Gerrit-hosted
extension, shortened it to just `throw new ReadOnlyError;` on the assumption
that the removed portion was only left in for EditPage.
Change-Id: Icc2fc166b155eac548dfd5f3e67b0b1f92ef90d3
* No longer segment module origin allowance by an "only=" content
type. Both can be sensitive security-wise and there's no valid
use case for allowing CSS anywhere you want to disallow JS. Both
can significantly impact the user interface and cause unintended
actions to be taken on the user's behalf, or desired actions to
be made practically impossible.
* While at it, also remove the ability to set the module allowance
directly. The reduceAllowedModuleOrigin method is all we need.
I couldn't find usage or mention of setAllowedModules() in
mediawiki-core nor in any other Wikimedia-hosted repository.
Bug: 70672
Change-Id: I308e794daca27a9380c67be350f8ab51f9c2de34
- Added newline at end of file
- Removed double spaces/newlines
- Added space after if/function and parentheses/brackets
- Removed space before comma/cast
- Fixed indent of some lines
Change-Id: I29867ffdffdfb7d2b56997e9393497c7dc12f7d3
This reverts most of commit 2d842f1425,
leaving only the test added in it, and reimplements the same
functionality better.
Instead of stripping /*@noflip*/ annotations in CSSJanus, which is
incompatible with other implementations that preserve it, extend
CSSMin to allow other CSS comments to be present before the
rule-global @embed annotation. (This required making the regex logic
in it even worse than it was, but it's actually slightly less terrible
than I expected it would be. Good thing we have tests!)
Bug: 69698
Change-Id: I58603ef64f7d7cdc6461b34721a4d6b15f15ad79
Follows-up 9272bc6c47, 03c503da22, 1e063f6078.
One can't wrap arbitrary JavaScript in an if-statement and have
its inner-body mean exactly the same.
Certain statements are only allowed in the top of a scope (such
as hoisted function declarations). These are not allowed inside
a block. They're fine in both global scope and local function
scope, but not inside an if-block of any scope.
The ECMAScript spec only describes what is an allowed token.
Any unexpected token should result in a SyntaxError.
Chrome's implementation (V8) allows function declarations in
blocks and hoists them to *outside* the condition. Firefox's
SpiderMonkey silently ignores the statement. Neither throw a
SyntaxError.
Rgular ResourceLoader responses only contain mw.loader.implement()
and mw.loader.state() call which could be wrapped without issues.
However such responses don't need wrapping as they're only made
by mediawiki.js (in which case mw is obviously loaded). The
wrapping is for legacy scripts that execute in the global scope.
For those, let's wrap the script tag itself (instead of the
response). That seems like the most water-tight and semantically
correct solution.
Had to bring in $isRaw from ResourceLoader.php, else the startup
module would have been wrapped as well (added regression test).
Bug: 69924
Change-Id: Iedda0464f734ba5f7a884726487f6c7e07d444f1
Follows-up 9272bc6c47, 03c503da22.
* In 9272bc6c47, the condition wrap was removed from
OutputPage for no reason. This went unnnoticed as I had also
accidentally made the cond wrap in makeModuleResponse apply
to both only=scripts and regular (faux) responses, such as by
OutputPage embedding private modules.
* In 03c503da22, the latter bug was fixed, thus exposing the former.
This wrapper belongs in OutputPage, not in ResourceLoader. It's
OutputPage making the loader request. And just like in other places,
it's the "client"'s responsibility to ensure the request is either not
made or wrapped appropriately.
The test for "private module (only=scripts)" could be removed but
I'll keep it so we can see how this changes in the future. It's
a case that can't ever happen, but if it would, it currently gets
a double condition wrapper, which is fine.
Change-Id: Id333e4958ed769831fabca02164c1e8505962d57
This has been the subject of multiple complaints from Google, it
apparently prevents them from properly indexing the variant-specific
pages. Instead, send the variant-independent link as rel=alternate
hreflang=x-default, which is recommended by Google as the preferred way
of specifying "auto-redirecting homepages" in this help page:
https://support.google.com/webmasters/answer/189077?hl=en
Send rel=alternate links unconditionally, since that is also recommended
by that help page: "each language page must identify all language
versions, including itself".
Remove $wgCanonicalLanguageLinks since it would be rather pointless and
poorly named if it only controlled rel=alternate links.
Bug: 52429
Change-Id: Ic75717f6e4ac1f73aa600c2e1bdb9c60e607edb4
We never assign to the variable, only call some (mutating) methods on
the object. With PHP 5 we don't need to pass this by reference.
The functions that evolved into this family were originally added in
r12337, back then we probably still ran on PHP 4 or something.
Change-Id: Ib4ab141ca6d803f9df0351b1f65c7e9955c37d57
Also don't cast $model to int in LinkCache::addGoodLinkObj(); content
model IDs are non-numeric strings, not integers, so that field was
always populated with the value 0. Because 0 is a falsy value, this
caused subsequent calls to Title::getContentModel() to return the
default model rather than the correct one.
Also (hopefully) fixed every single query that could cause a
LinkCache entry to be added without the content model.
Bug: 69789
Change-Id: I94f06baf406afa538cd2b10139598442f9fc6759
To do it, just remove /*@noflip*/ annotations in CSSJanus after
we're done processing. They are not needed anymore and some obscure
interactions with CSSMin logic for preserving comments caused
`/*@noflip*/ /*@embed*/ background-image: url(…)` not to work
correctly (it would not be embedded).
This also requires us to always do CSSJanus processing, even when we
don't need flipping, to consistently handle the annotations.
I'm not entirely sure if this is worth it, but I still greatly prefer
doing it to documenting this stupid limitation. :)
Bug: 69698
Change-Id: I311b12b08b2dff9d45efb584db08cf4a11318f59
We currently have a few legacy requests to the load.php end point
that bypass the ResourceLoader client by coding a request to
load.php via a "<script src>" directly. Most prominently the
request for the 'site' wiki module (aka MediaWiki:Common.js).
Remove the manual wrapping of embedded private modules as this
is now taken are of by ResourceLoader::makeModuleResponse itself.
Misc:
* Mark "jquery" and "mediawiki" as Raw modules. While the startup
module had this already, these didn't. Without this, they'd
get the conditional wrap – which would be a problem since mediawiki.js
can't be conditional on 'window.mw' for that file defines that
namespace itself.
* Strip the cache-key comment in the unit tests because the hash
no longer matches and using the generic 'wiki' dbname was breaking
DB queries.
* Relates to bug 63587.
* See also 05d0f6fefd which expands the reach of the non-JS
environment to IE6 and helped expose this bug.
Change-Id: Icf6ede09b51ce212aa70ff6be4b341762ec75b4d
Special page transclusion returns an OutputPage, whose metadata is
copied into the ParserOutput, and then later back into an OutputPage.
The "preventClickjacking" flag should be part of that metadata.
Bug: 65778
Change-Id: I17d2720fb94bb383a92059e5adbf6c16ee3e9ef4
With the introduction of the OutputPageScriptsForBottomQueue hook,
modules loaded through it are TYPE_COMBINED, which
OutputPage::makeResourceLoaderLink was not checking on whether
or not it was safe to include them.
Change-Id: I33f39a5643b3d05db5a89e62fa6c86d437dea143
After some discussion with Roan, it turns out this
hook is unnecessary. The proper solution is to use
addModuleScripts/addModuleStyles instead of a
plain addModules.
This reverts commit e7361de181.
Bug: 68712
Change-Id: Iadbff5f7fbbc5a08d6336674b12315967f45591d
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
- Removed spaces after not operator (!)
- Removed spaces inside array index
- use tab as indent instead of spaces
- Add newline at end of file
- Removed spaces after casts
Change-Id: I9ba17c4385fcb43d38998d45f89cf42952bc791b
To do so, created ResourceLoader::createLoaderURL(), which takes a
ResourceLoaderContext object. ResourceLoader::makeLoaderURL() was
deprecated.
While reviewing usage of the old function, many of the callers only
differed by one or two parameters from their respective
ResourceLoaderContext object. To simplify that use case, I created
DerivativeResourceLoaderContext, based of off DerivativeContext for
IContextSource.
Change-Id: I961c641ab953153057be3e3b8cf6c07435e9a0b0
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
meta-keywords is completely and totally useless. It has absolutely no effect
on search engine and no-one uses it anymore. Time to euthanize it.
There isn't a single user of OutputPage::addKeywords inside any extension
inside of Gerrit. So I'm just deleting this method without a deprecation.
Change-Id: I188755521dcde3a9e191975d1ae3cabf7a5d67cd
Finish up with the /specs/web-apps/current-work/multipage/ urls that
haven't been updated to /html/.
Change-Id: I4dbee0477eea440b0e8f113b1d393c6e0c739c4c
Can't believe the fact the @deprecated has the wrong version number
made it through our review process.
Change-Id: If9beea75bb909484b242c1c4cb787fef8f6501d3
It only really made sense in pair with $wgHandheldStyle, and that has
been removed in Ia8d79b4a.
Remove irrelevant tests, adjust still relevant ones.
Change-Id: I7c24128f7b148d0244538ad95bb60bf09ec4b5cb
Remove addDefaultModules from OutputPage
Instead only enforce mediawiki.page.startup
Add a method getDefaultModules which groups modules
by type allowing a skin to tweak
Change-Id: I89d529f0378d90af0fe0a5adea5d5dbdca83a86e
OutputPage is supposed to be a container for output. It should NOT be used as a replacement for echo.
Only one seemingly unmaintained extension uses this method.
This method is deprecated now and should be removed in the next release.
Change-Id: I82711cee7204604a47cfbb5e4496b4cc737a837c
It's recommended for the meta charset to be placed before the <title> since
<title> contains text which is inside the character set defined by the meta charset.
Use of meta charset inside XHTML also seems to be redundant, not recommended,
and is very likely completely ignored.
Change-Id: I335b0598a9615540dc5e917682508b4a8d32d96e
* $wgHtml5 = false; is now ignored completely.
* $wgDocType and $wgDTD have been removed.
* $wgXhtmlDefaultNamespace is now ignored.
* XHTML5 will be output if $wgMimeType is set to an XML mime type (according to HTML5's rules).
* For backwards compatibility with extensions $wgHtml5 and $wgXhtmlDefaultNamespace are set
in Setup.php but depending on them is deprecated.
Change-Id: Iad9634e2ee420b5a3bbffe550421fde4fa1819b0
We already wrap usage of global "mediaWiki" in a condition
for window.mw (see method
ResourceLoader::makeLoaderConditionalScript) because:
1) The startup module blacklists certain
browsers in which we won't load jquery+mediawiki.
2) It might have failed to load (for whatever reason).
Adding guard for window.jQuery for the same reasons.
Follows-up Ic3d0c937268d09, which caused a TypeError
'ready of undefined not a function' in browsers where
jquery+mediawiki isn't loaded by the startup module.
Change-Id: I9dcd8d347c6b00efe207d031a480e5b85bf78936
This hook allows extensions to disable or modify the new messages
alert ('orange bar of doom') while still allowing the user_newtalk
table to be updated.
The wgUserNewMsgRevisionId JS global allows gadgets and extensions
to create their own new message alerts on the client side.
I also threw in a few comment updates for good measure!
See also Echo change I3f35a56b which utilizes this.
Bug: 47962
Change-Id: I2105bdd2bcd5b27f6f36ec8d8fa7fa99d60a2d82
Build the classes using an array that is finally imploded, instead of
concatenating strings repeatedly.
Change-Id: I2a09282d5ba33f131a4311c58e49dab5eefce418
mw.loader defaults to async=false. Overridden when $.isReady=true
or a mw.loader call sets async=true.
The problem is in calls to mw.loader.load that are not in
the HTML output but occur *before* the DOMContentReady event.
In those cases we want to use async (creating a script tag)
instead of synchronous (document.write) because in Firefox
DOMContentReady is emitted some time after it is no longer safe
to use document.write (bug 47457).
This also optimises the dom ready event cross-browser.
Bug: 34542
Bug: 47457
Change-Id: Ic3d0c937268d0943d2f770f3ca18bcf4e1eed346
This adds a new hook called LanguageLinks which is called
whenever a list of language links is returned to the user.
This gives extensions the option to manipulate the links
on the fly.
Note that this change only covers the language links used
in OutputPage and by ApiParse. Adapting ApiQueryLangLinks is
left as a follow-up task.
As explained on bugzilla, this is a precondition to
allowing Wikibase/Wikidata to update languagelinks without
forcing a (redundant) re-parse of the page content.
This change also introduces the notion of link flags that
can be used to associate flags with language links. This
will be integrated with ParserOutput and OutputPage in a
follow-up.
Change-Id: Iaec0faa131413a291fc8f77496e4f371addb3b99
* This deals with the fact that seldom edited pages can end up cached
with very stale resource (JS/CSS) references since the response to
IMS GET requests will be 304 Not Modified if page_touched is ancient.
When squid revalidates its stale cache it will keep getting 304s and
renewing the TTL on the stale cache.
Bug: 44570
Change-Id: I3889f300012aeabd37e228653279ad19b296e4ae
