* These aren't string values, but LESS code snippets. This rarely
matters, but it matters very much when it does.
* Changes to the values do not actually trigger cache invalidation.
Hashed contents are only used for "second-level" cache keys and do
not make it possible to invalidate module cache.
Change-Id: I373dfedac1e43db4d0aa709384eee7f7e7f1808c
There has been some demand, particularly in the Wikimedia cluster, for the
ability to import from any wiki of a cluster. For this to occur, the
transwiki import user interface needs a bit of a rethink.
This patch replaces the existing single dropdown with a pair of dropdowns:
the first to select the wiki project, and the second to select the
subproject (e.g. a Wikipedia/Wiktionary language, or a Wikia site).
The second one is optional (to support single-wiki sites like Meta, or
for backwards compatibility with existing setups).
$wgImportSources is now treated as a mixed array/associated array (see
comment in DefaultSettings.php). Existing configurations will still work
but will receive no new functionality.
The non-JavaScript fallback is not pretty, but (a) it works, (b) I don't
see an easy way to make it nicer, and (c) wiki sysops should probably be
using a JavaScript-enabled browser for admin actions like importing...
The intention is to alter the WMF configuration to automatically populate
$wgImportSources with all public cluster wikis. I'm not exactly sure how
this will be set up, but this patch is an important first step. I expect
some non-WMF users of MediaWiki will find it helpful as well.
Change-Id: Icdb655500c1ae5374dc7a9f4d99e6738b2269b14
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
As was discussed at the architecture summit, a basic JSON content
class which handles validation and basic display. Not intended to
be used directly, but for extensions to subclass.
Co-Authored-By: addshore <addshorewiki@gmail.com>
Change-Id: Ifcde9bcd0efcf15a3ab692dd2a0a3038559e0254
This enables factory functions to be registered for API modules,
in addition to the module class itself. This allows modules to
use proper dependency injection via the modules constructor.
Example:
$wgAPIModules['foo'] = array(
'class' => 'ApiFoo',
'factory' => function( $main, $action ) { ... }
)
Change-Id: Ieb85493a7765f466317f5fa74b0b0e262220deab
It just displays a helpful message that explains why and how to
install and enable skins. There is no navigation nor other basic page
elements (like the logo or site notice), since this is not intended to
be a fully functional skin.
Bug: 68332
Change-Id: Id14fbb8733cd8fbb912a724ac658f5e7244364b5
With Icd8662ecb9eb0f6c0ff9841bdbd5736d6dd0d015 the log for uploads was
migrated to the new system, but no formatter was set to use the new
system also on Special:Log.
There is no need for an extra formatter class, because at the moment
there is nothing extra to format.
Added the new messages and adjust them. Now upload logs supports gender.
The old messages are kept for IRC where there were already in use.
This also hide the params added with
Icd8662ecb9eb0f6c0ff9841bdbd5736d6dd0d015 on Special:Log, because there
are not needed for i18n.
Change-Id: Idf281898d8a5a023a0b9ce3bc90b3ca55c1a6376
This change adds a preference in the 'watchlist' section to
automatically watchlist a page after rollbacking.
The setting is only visible, if the user has the 'rollback'-right.
I have removed the watch reverts function per advice by Vogone.
Bug: 4488
Change-Id: I3aa831c9c04d627684641af0ca5a332795c87062
Slight syntax code change for $wgPasswordDefault in DefaultSettings.php
and fixed reference to global in BcryptPassword.php.
Change-Id: I8d1d12c09ecd2f422f21a586e948f314e29fa605
The newly introduced $wgResourceModuleSkinStyles global enables skins to
provide additional stylesheets to existing ResourceLoader module.
This both makes it easier (or at all possible) to override default
styles and lowers the style footprint by making it possible not to
load styles unused on most pages.
----
Example:
Use the file 'foo-styles.css' for the 'mediawiki.foo' module when using
the MySkin skin:
$wgResourceModuleSkinStyles['myskin'] = array(
'mediawiki.foo' => 'foo-styles.css',
'remoteSkinPath' => 'MySkin',
'localBasePath' => __DIR__,
);
For detailed documentation, see the doc comment in DefaultSettings.php.
For a practical usage example, see Vector.php.
----
Implementation notes:
* The values defined in $wgResourceModuleSkinStyles are embedded into
the modules as late as possible (in ResourceLoader::register()).
* Only plain file modules are supported, setting module skin styles
for other module types has no effect.
* ResourceLoader and ResourceLoaderFileModule now support loading
files from arbitrary paths to make this possible, defined using
ResourceLoaderFilePath objects.
* This required some adjustments in seemingly unrelated places for
code which didn't handle the paths fully correctly before.
* ResourceLoader and ResourceLoaderFileModule are now a bit more
tightly coupled than before :(
* Included a tiny example change for the Vector skin, a lot more of
similar cleanup is possible and planned for the future.
* Many of the non-essential mediawiki.* modules defined in
Resources.php should be using `'skinStyles' => array( 'default' => … )`
instead of `'styles' => …` to allow more customizations, this is
also planned for the future after auditing which ones would actually
benefit from this.
Change-Id: Ica4ff9696b490e35f60288d7ce1295766c427e87
Deprecated the old User::crypt, et. al password hashing
system and implemented an extensible password hashing
API.
The new Password class allows registering of child classes
and provides factory functions for creating new Password
objects. The built-in hash types are the old MediaWiki MD5
types, which are for backwards-compatibility only, and bcrypt.
Also included is support for wrapping existing hashes as well
as encrypting passwords with a configured encryption key.
Bug: 54948
Bug: 28419
Change-Id: I0a9c972931a0eff0cfb2619cef3ddffd03710285
When $wgDebugDumpSql is set, the logged queries are truncated to 500
bytes. This is often not enough if you're wanting to actually debug
the queries instead of just seeing that queries were executed.
Change-Id: Iad3abd20c11d647834aa5546a1a9c82916c6519f
This has no effect while $wgThumbnailBuckets is null (the default),
but once buckets are enabled, 0 is a poor setting for the minimum
distance. 50 is arbitrary but definitely better than leaving it at 0.
Change-Id: I845af18cfd00627b26f6325c1d1a512a492a8f7c
* Also tweaked the query so MySQL avoids doing a page_name
index scan when it should start with the link table index
* Added population script (triggered by update.php)
* Also removed uniqueness from some indexes where it is redundant
* Renamed two confusing variables
Bug: 60618
Change-Id: Icca99b6ae0ef76cb77695faf82c615516191da36
In this change, a new passive user right named "viewsuppressed"
which can be used in order to view suppressed page content was added
to MediaWiki core.
Furthermore, this right was also added to the list of available rights,
to qqq.json and to en.json where also the description of the
"suppressrevision" right was adjusted in order to reflect reality.
Bug: 20476
Change-Id: Id1baacb9c782763db5e05ef8b5c1b761997efcc9
Instead of always generating thumbnails based on the original,
this adds the ability to generate thumbnails based on
references buckets. The buckets themselves have their
generation chained following the same process (smaller bucket
generated based on bigger bucket). In situations where no
suitable bucket is found, the original is used, like it used to.
This is entirely optional, as most non-WMF wikis would probably prefer
to keep generating all thumbnails based on originals.
The quality implications have been verified through a survey
aimed at Commons users and people actually preferred the chained version.
Presumably due to the multiple passes of sharpening which maintained
visual details better for small thumbnail sizes.
Change-Id: I285d56b2024c81365247338f85c1e0aa708cb21e
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/600
Bug: 67525
Depending on the configuration used in LocalSettings.php, $IP can be
changed between the time that configuration is loaded and the wiki
runtime by logic in WebStart.php. Attempt to mitigate the effects of
such changes on the cache file name computation by canonicalizing both
$IP and the path using PHP's realpath() function.
Related but distinct is the possible need to configure the canonical
location for finding cache files on disk separately from
$wgCacheDirectory. This change introduces a new configuration variable
named $wgGitInfoCacheDirectory that can be set to a path that diverges
from the default location of $wgCacheDirectory/gitinfo. This will be
useful in the WMF cluster where $wgCacheDirectory points to a directory
that is not managed by the deployment system.
Finally add wfDebugLog logging to make tracking down issues such as
miscomputed cache paths easier.
Bug: 53972
Change-Id: Iceb9e1ce8d3b4bb08f89fa6ec5d5e7392aaafd46
If $wgCountTotalSearchHits was set to true, then the total
number of hits returned was zero, which caused Special:Search
to display no results.
I'm opting to remove the feature (although I don't have any
strong opinions about removal vs changing Special:Search), since
if someone both cares about performance and has a wiki where its
big enough to matter, they are going to need to use Cirrus anyways.
Change-Id: I1c3b908ae5423ce3dfbdc22b1a68dd81a85698aa
