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
