* adds $wgResponsiveImages setting, defaulting to true, to enable the feature
* adds 'srcset' attribute with 1.5x and 2x URLs to image links and image thumbs
* adds jquery.hidpi plugin to check pixel density and implement partial 'srcset' polyfill
** $.devicePixelRatio() returns window.devicePixelRatio, with compat fallback for IE 10
** $().hidpi() performs a 'srcset' polyfill for browsers with no native 'srcset' support
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images load
Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6, Chrome 21, Firefox 18 nightly on MacBook Pro Retina display, and IE 10 in Windows 8 at 150% zoom, 200% zoom, and 140% and 180%-ratio Metro tablet sizes.
Internally this is still a bit of a hack; Linker::makeImageLink and Linker::makeThumbLink explicitly ask for 1.5x and 2x scaled versions and insert their URLs, if different, into the original thumbnail object which (in default handler) outputs the srcset. This means that a number of places that handle images differently won't see the higher-resolution versions, such as <gallery> and the large thumbnail on the File: description page.
At some point we may wish to redo some of how the MediaHandler stuff works so that requesting a single thumbnail automatically produces the extra sizes in all circumstances. We might also consider outputting a 'srcset' or multiple src sizes in 'imageinfo' API requests, which would make ApiForeignRepo/InstantCommons more efficient. (Currently it has to make three requests for each image to get the three sizes.)
Change-Id: Id80ebd07a1a9f401a2c2bfeb21aae987e5aa863b
This introduces the ContentHandler facility into MediaWiki,
see docs/contenthandler.txt.
For convenient review, a squashed version is available at
https://gerrit.wikimedia.org/r/27191
The ContentHandler facility is a major building block of the Wikidata project.
It has been discussed repeatedly on wikitech-l.
Change-Id: I3804e2d5f6f59e6a39db80744bdf61bfe8c14f98
Created a new method User::groupHasPermission and check also
$wgRevokePermissions for the given right
Change-Id: I41edb091fa35c8c68b6f95cc5fd208ea99418cdb
When a message name is passed, addWikiMsgArray() is used, so it adds a <p> arround the
result. Do the same when a Message object is passed to that method.
Change-Id: Ie97ad9a921ae3fc6d327531b0ace64b6a08e1fa2
The module has been broken for a while now, but nobody noticed
because in plain core it is disabled by default, and in the
bundle we ship with Extension:Vector (and its SimpleSearch).
This commit removed the mediawiki.legacy.mwsuggest module (and
related components that become obsolete with its deletion) and
replaces it with the new mediawiki.searchSuggest module, which is
based on SimpleSearch from Extension:Vector (where it will be
removed soon).
The following and all references to it in core have been removed,
I also made sure that they weren't used in any of extensions/*.
Only matches in extensions/Settings and some file that dumped the startup module, and in extensions/Vector which are addressed in
I1d5bf81a8a0266c51c99d41eefacc0f4b3ae4b76.
Had to make a few updates to jquery.suggestions to make it work
in other skins. So far it was only used in Vector, but now that
it is used in mediawiki.searchSuggest, I noticed several issues
in other skins. Most importantly the fact that it assumed the
default offset was from the right corner, which isn't the case in
Monobook where the search bar is on the left (in the sidebar).
It now detects the appropiate origin corner automatically, and
also takes directionality of the page into account.
It also uses the correct font-size automatically. Previously it
used font-size: 0.8; but that only works in Vector. Every skin
seems to have its own way of making a sane font-size. In Monobook
the <body> has an extra small font-size which is then fixed in
div#globalWrapper, and in Vector it is extra large, which is then
fixed as well deeper in the document. Either way, the size on
<body> can't be used, and since this suggestions box is appended
to the <body> (it is a generic jQuery plugin without knowledge of
the document, and even if we could give it knowledge inside
the configuration, it'd have to be per-skin). So I removed the
Vector specific font-size and let it handle it automatically.
This was needed because it is now used in all skins.
Removed modules:
* mediawiki.legacy.mwsuggest:
> Replaced with mediawiki.searchSuggest.
Removed messages:
* search-mwsuggest-enabled
* search-mwsuggest-disabled
> No longer used.
Removed mw.config.values:
* wgMWSuggestTemplate
> Obsolete.
* wgSearchNamespaces
> Obsolete.
Removed server-side settings:
* $wgEnableMWSuggest
> Suggestions are now enabled by default and can be disabled
through the user preference `disablesuggest` still.
They can be disabled by default site-wide or hidden from
prefs through the standard mechanisms for that.
* $wgMWSuggestTemplate
> Obsolete.
Removed methods
* SearchEngine::getMWSuggestTemplate()
> Obsolete.
Filters:
$ ack mwsuggest -i -Q --ignore-dir=languages/messages
$ ack wgSearchNamespaces -Q
Message changes:
* vector-simplesearch-preference
> It was wrong, it didn't activate search suggestions, that
was handled by the Vector extension. This preference in
MediaWiki core controls whether the SimpleSearch bar HTML
and CSS will be used (e.g. the rectangle search box with
the magnifying class instead of the browser-default input
field with the plain submit buttons).
* searchsuggest-search
* searchsuggest-containing
These come from Extension:Vector message and should be imported
by translatewiki:
- vector-simplesearch-search
- vector-simplesearch-containing
Change-Id: Icd721011b40bb8d2c20aefa8b359a3e45413a07f
Added new argument to the Linker options array to allow
the forcing of an HTTP or HTTPS protocol. In order to facilitate
this, a protocol argument was added to Title::getLinkURL.
Also, an options argument was added to OutputPage::addReturnTo
so that options can be passed to the linker and so that the
returnto URL can be forced to a certain protocol.
Change-Id: Ia9cc11e310ad6ef23c221bdba3a4834e7c5556e7
Called before final ob_end_flush() which will send the buffered output to the client. This allows for last-minute modification of the output within the buffer by using ob_get_clean().
- patch-set2: moved the hook before OutputPage::sendCacheControl() is called, as suggested by Reedy.
Change-Id: I264a37ac74e0c18ff141f82156e669ece3212c2d
It was not used[1] and complicated migration to Message class.
[1] Checked uses in 100 extensions, including most Wikimedia, twn and SMW extensions.
Change-Id: Id2ac68ef79e98272d02117165e2f04034f209fb3
- This removes the duplication of MWDebug::$debug and
OutputPage::$mDebugtext, so there's no need to store two times
the same text
- Removed OutputPage::debug() since it's no longer used
- Had to keep OutputPage::$mDebugtext because it's still
referenced by SemanticPageMaker extension
- Moved Skin::formatDebugHTML() to MWDebug::GetHTMLDebugLog()
and replaced the call in Skin::generateDebugHTML() to use it
- Also check $logonly before sending entries to the debug
toolbar in wfDebug(), for consistency
- Changed MWDebug::getDebugHTML() to also return the debug log
in an HTML comment if $wgDebugComments is set to true and
changed the location of this call to BaseTemplate::printTrail()
so that its result is the latest possible. This also includes
the debug toolbar.
- Removed MockOutputPage and related test cases since they are
no longer accurate
Change-Id: Ie0f389f8566457b1c938c627ed930040741ac9d9
Changed OutputPage::showErrorPage() so that the title parameter
can be either a string or a Message object, just like the
message parameter. This allows titles that take parameters.
Change-Id: Icb7f7b0db8599984774f438333b60d66956b6075
Signed-off-by: Tyler Anthony Romeo <tylerromeo@gmail.com>
Also moved debug string generation a bit lower so that
it's executed only when it will actually be used.
Change-Id: Ia01e7fb1dba1f2f55c156d3ac097acf2a68dca70
Make javascript variables wgDefaultDateFormat, wgMonthNames and wgMonthNames, used to sort dates in tables, depend on the page content language.
Change-Id: I18a53ba004f3dd877e2d06ed722491167e31b473
'stmap' instead of 'stamp'. I have updated:
- doc block
- function argument
- inner use of the argument
Change-Id: Ie7b663372632e4044464ae49ab42dce500838985
When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
Maybe WebResponse would be a better place for this, but this'll work for
now.
* Add getVaryHeader() to get the serialized version of $mVaryHeader.
* Remove 'Cookie' from the initializer, and add it explicitly later
** This allows reuse by code that doesn't want 'Cookie' in there
Change-Id: Ifa8f74a21f832154b05e54ced95b9f9eb6052fcd
* No need to cast to array twice
* Should cast to array before doing count()
* Avoid variable name conflict in the for loop with the one outside
the loop for clarity.
No functional changes.
Change-Id: I93e7829e23372ea25e2f5123f7a990b6718663f3
method in mw.page.watch. Update method to toggle watch, unwatch
list item id attribute.
Patchset 2- Expose method with less code duplication, restore
comments, cleanup whitespace.
Patchset 3-5 Whitespace cleanup
Patchset 6 - Trigger a watch event on the updated li
Patchset 7 - Only trigger watch event if not updating
state, announce opposite of icon action, to properly
indicate action taken.
Patchset 8 - Cleanup spacing and comments issues,
change event namespace.
Patchset 9 - actually add the change
Change-Id: I591f9f847db391c5d1477dc2ed41de54ec266261
addVaryHeader() converts $options to an array, so null values (no XVO
options) are converted to empty arrays. This led to headers like:
X-Vary-Options: Foo;string-contains=bar,Baz;,Quux;string-contains=xyz
This fix changes the "Baz;," part to "Baz,"
Change-Id: I2fa0b374f5d4cfa6b894cbd9de8c14354f04ad86
