This was developed for translatewiki.net, which has but
millions of messages in MediaWiki namespace. To avoid
exploding the message cache, not all of them can be
loaded. Instead of logging what messages have been
requested, now it uses the fact that if the
message has not been customised in the
site language, there is most likely
no reason to load it in any other
language either.
Change-Id: I6dd81b3858acfd2b73332e46668d46015e99c748
Syntax:
* Call parent setUp from setUp.
* Set required globals for the test inside the test class instead
of assuming the default settings.
* Data providers are called statically and outside setUp/tearDown
("public static function")
* Test function names should be prefixed with "test"
("testIsRedirect")
* Marked 2 functions as unused. JavascriptContentTest has 2 data
providers for tests that don't exist in it (nor in TextContentText)
but do exist in WikitextContentTest.
Style:
* Single quotes
* Remove odd comment "# =====" lines
* Consistent tree wrapping with arrays.
array(
array(
.. ) );
array(
array(
..
)
);
Some were closing on the previous line instead.
Made it consistent now.
* Remove odd indentation to make nested arrays line up:
array( 'foo' => array( 'bar' => true,
'baz' => array() ) )
array( 'foo' => array(
'bar' => true,
'baz' => array()
) )
We don't do this kind of indentation because it is fragile
and becomes outdates when any of the earlier keys ("foo")
change. Converted to a regular tree instead.
Also triggered git warnings for mixing spaces with tabs, which
is almost always an detector for this style.
* Not using @annotations in inline comments, reserved (and only
parsed/meaningful) for block comments.
Follows-up 8b568be5e2
Change-Id: Ic55d539b9a58f448b550bcd98894d389764e0694
* Has to keep actual messages for IRC notification
* Catch really old log entries with no parameters and use an
appropriate message in that case to not always display erroneous
"X changed group membership for Y from (none) to (none)".
Change-Id: Ie188bc6fcdf672fe31f0f389a158aab6256031fa
ContentHandler removed wikitext parsing for CSS and JS pages.
However, people seem to rely on links and categories embedded
in script comments.
Change-Id: I0736f15878fbd3292e75854bf16f04df656ce363
A setting to have uploading by URL, but not on Special:Upload.
Reverted this out when I thought we were going to be able to
support more widespread URL uploading, but currently, it is only
reliable for some domains, so although we can theoretically support
the new Flickr interface in UploadWizard, it probably isn't reliable
enough to add general URL uploading from Special:Upload.
Change-Id: I66b287bf173a4ea0b23f43180505d4c7de5acb26
We'll eventually want to set this to true by default, but right now
the content handler stuff is still semi-experimental stuff that isn't
widely used yet.
Before we turn this back on, let's make sure to give some notice
since it's a pretty major schema change they'll have to make.
Change-Id: If501a065a410a31a4232cd8386b498d7d18a73a4
* Added support for different queue types and methods for storing queues.
* Treat each job type as being on its own queue, at least logically.
* Added $wgJobTypeConf to configure queue types for each job type.
* Improved the job DB table so that duplicate job checks actually work
and are faster. Also improved the method for popping rows of the table.
* Disabled duplicate job removal for everything except refreshLinks.
The DELETE statements just add DB overhead and are not useful for cheap
jobs, especially ones with start/end params (which are unlikely to have
exact duplicates).
Change-Id: I49824c7fa855fea4ddcac5c9901ece8c2c0101d0
Rename $wgPurgeHttp11 to $wgSquidPurgeUseHostHeader, set it to true by
default, and update the documentation per the research I've done on
Squid's behaviour. See bug 39005.
Rewrote the release note and moved it to the correct section.
Change-Id: I9ef6a0c43fc1ba4547b34124a47815296f45b20e
Allow SquidPurgeClient to send HTTP/1.1 PURGE requests with a Host header instead of
only sending HTTP/1.0 requests with the whole url in the PURGE line.
This is necessary to support some other reverse caching proxies like Varnish.
Change-Id: I85fe93a8ca97c5169f250967540e29fc70725119
Made TextContent and TextContentHandler usable directly.
CONTENT_MODEL_TEXT is unused in core, but may be used by extensions.
Change-Id: I8963c968800b98e286cd917a1038a9905b3a0fef
List of query generators is now not built using reflection, instead it
is defined in code. Per Domas, make this a hard coded list instead of
loading all the child classes.
Added $wgAPIGeneratorModules for people to register their API generator
modules.
Change-Id: I12da92da33527e414c9b125a50b82c9bdbb3ed99
This code is meant to replace the current interwiki code, but does not do so just yet. It is however used by the Wikibase extension. This allows us to try out some more things and have the code stabilize more before we migrate over existing interwiki functionality.
Change-Id: I23c47c2c3909a1500350fb560a5f2ec654e2c37e
* 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
Deprecate $wgSharedDB in response to it accidentally being used in
Wikidata. It was always an ugly hack.
Change-Id: I68f3bfe7afc49a49cd310b66dc03cf52507d3e58
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
To prevent large template DOM caches from sending servers into swap,
throw an exception when more than some number of DOM elements are
parsed. Unfortunately, it wasn't possible to return a normal error
message, because it broke PST and extractSections and corrupted the
article text. It's safer to refuse to save the edit, and we don't
have decent ways to do that short of throwing an exception.
Ideally we would like to have an upstream patch that hooks libxml to
allocate memory from PHP's request pool, then a fatal error would be
raised instead of swapping.
Change-Id: I4cb4f6fd313e1e0940b56cc5e586afd1bea9267a
InfoAction needs a bit of work, so this might want to wait a little
while. The patch removes $wgAllowPageInfo which was used to enable the
action=info action (which was disabled by default).
https://gerrit.wikimedia.org/r/#/c/15847 is needed to disable the
counter query.
Change-Id: I467e688090919b627bf1fb124ef712821c2257f6
This reverts commit 8c6c29b3fc
I erroneously assumed there was a practical reason why
wgAllowCopyUploads was turned off on Commons, i.e. it was
too easy to abuse, causing too many copyvios, etc. I didn't
realize that the reason it was turned off was purely
technical (since the apaches on the cluster have no
external internet access). So there's no reason we need a
separate config.
Change-Id: I293a59d756335909898fd647edd6eddb68f06e17
