* 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
Some cases were already covered by I595b3af190, but in the case
where the module is disabled entirely it was setting it to missing.
This is inconsistent with the behaviour of load.php (which will implement
an empty module resulting in state=ready) and confusing as it
implies there is a problem (a missing module) whereas in fact it
isn't a problem. Modules that depend on it to allow customization
wouldn't load as it will fail on missing dependencies.
Also makes asserting problems (bug 44299) hard as it would have
to whitelist state 'missing' for user/site/user.groups.
Bug: 46857
Change-Id: I46b5bc6f714abe4b66186d7b7a14c69195f00ee1
Removed rel="next" link that was put on every
page that had a returnto because otherwise
Firefox (and possibly others) might prefetch
the page, which is not desired in returnto
situations.
Bug: 46680
Change-Id: Ifaf40c663dc25e51bffc317144d9bdc1dab21785
The target URI parameter is already used by ResourceLoaderStartUpModule
to filter modules, this change introduces the ability to produce
mobile-aware load.php links in the core and filter out modules not suitable
for current target.
Change-Id: Ie03990e11d9a0ac8cd81dd0aae5c5a95f1d23e81
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
* This is much more useful if it can be passed to new Date. As a side
effect, this means straight arithmetic comparisons can be done.
* Add a method for this to mediawiki.user (getRegistrationDate).
* Improve docs on server User::getRegistration method by documenting possibility that data is null.
Change-Id: Id7ae0faa930433876939b73d47fc294975e14fb1
This change adds user ID, registration time, and edit count to the
default set of JavaScript configuration variables.
These values are all included in $mCacheVars and so require no additional
database lookups.
Change-Id: Id0adb795567d4ba932104938f2793cdb4084883c
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
Fatal errors break test execution, exceptions not
See also bug 42145
PS: how many months does it take to fix a bug that
prevents running unit tests? Answer below.
Change-Id: I0b351a05be9d0850b467046e807651be254dcae2
(bug 43466) If enabled, send a rel=canonical link on every page
indicating the correct server to use. I tested all three callers:
Article, ImagePage and the variant feature in getHeadLinksArray().
Change-Id: I59b7c1d5589825ea390967036190218d5ce2db88
It's reported that IE is actually sending language code in BCP 47
format (like zh-Hans), instead of uppercasing the whole 2nd part.
Change-Id: I6761191f299373d9267660a7eb14dc0b34cd5a38
* 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