The problem here is that the path to 'wiki.png' is saved in users'
LocalSettings.
We likely should not remap the path, like we did for footer license
icons in Ic7c32e56:
* It's likely that users changed their logo image by overwriting the
file in skins/common/.
* If the normal upgrade process is followed (overwrite-uploading new
files), the old file will still be there with the skins/common/
directory.
* If it does cause problems, they'll be rather easy to notice and fix.
On the other hand, maybe we should?
* This is going to be annoying for git users.
* It will bite anyone who deletes all MediaWiki files when upgrading
via tarball, which is more likely with the recent skin system
changes encouraging users to remove old cruft from skins/ directory.
Bug: 69277
Change-Id: I175fe57048ebf9d348fb2fe67bf62cf5df389003
Custom LESS functions are problematic for us for a number of reasons,
as outlined by Timo on bug 67368. We should get rid of them.
The only use case was implementing CSSMin data: URI embedding in LESS,
which used to be impossible due to lessc not preserving comments (bug
54673). However, thanks to new syntax added in f3779e06 we can insert
the annotations in such a way that the compiler won't mess with them.
The same technique is used in OOjs UI since 584ed144.
The LESS-function-based embedding implementation also meant that we
were unable to flip images for RTL (bug 66091 and friends: bug 66773,
bug 68326). The annotation one doesn't have this limitation.
Bug: 67368
Bug: 66091
Bug: 66773
Bug: 68326
Change-Id: I3062346ed63272a1c22b5df27b4cc1de2a699d9a
This enables factory functions to be registered for special
pages, as an alterative to giving a class name. This follows the
same rationale as Ieb85493a7765, which introduced factory functions
for API modules.
Change-Id: Ia2107dc5af7869187ba5dc02a1bef46d6801e138
Bonus: actually make $wgResourceBasePath default to $wgScriptPath, rather than
special-casing it in ResourceLoaderFileModule.
Change-Id: I608435cef00d3e77a5bbdb0a0122d3e7e1a4eb78
While it's "semantically" incorrect (these files are not
ResourceLoader resources), putting them in that subdirectory is a lot
less hassle than introducing a new toplevel directory.
Follow-up to 2b4b9a3f. Discussion that resulted in the toplevel
assets/ took place on I6268d663 (now abandoned).
Change-Id: Iedbfd802457fe35803899e3479540177760ec30b
* All content handlers that deal with code/data tend to have
English as their page language & pageview language, so moved common
code to the abstract CodeContentHandler class.
* Renamed JSONContent & JSONContentHandler into JsonContent*
Change-Id: I46819a0572ef5becc211d0d82471ff7102edaa3c
poweredby_mediawiki_88x31.png is straightforward, just need to update
some paths.
The six license icons are more problematic, as the paths to them are saved
in users' LocalSettings. We're remapping them in Setup.php.
Bug: 69277
Change-Id: Ic7c32e56043cfbf94ef2271de4ff41ef18fbeee7
Previously ResourceLoader would store any arbitrary data about a
source, provided it had a 'loadScript' key. It would register
the 'local' source with an additional 'apiScript' key, which was
also documented in DefaultSettings.php. However, it was
completely unused outside of the ForeignAPIGadgetRepo class in
Gadgets 2.0, which should be changed to take an API url as a
parameter. This was not useful as it was not ever formally
exposed, and it could not be depended upon that a source had
registered an 'apiScript' key.
For backwards compatability, both ResourceLoader::addSource()
and mw.loader.addSource() will both take an array/object, but
discard all parameters except for 'loadScript'.
Also added tests for ResourceLoader::addSource().
Bug: 69878
Change-Id: I4205cf788cddeec13b619be0c3576197dec1b8bf
* Implemented a version of BloomCache using Redis
* Added a BloomCheckTitleHasLogs handler class for avoiding
slow logging table queries when large amounts of 404 pages
are viewed (by various web crawlers at the moment).
bug: 67439
Change-Id: I26e5034755e3a7208a45991b1cf2f12467679cc1
Since PHP 5.3, mime_content_type() is implemented as part of PHP's
fileinfo extension and thus is deprecated in favor of the newer
alternatives provided by that extension (already in use).
Also updated a comment in DefaultSettings.php that mentioned the
function. Did not modify lessc.inc.php, a third-party library
maintained separately from MediaWiki.
Change-Id: Ic4a0873989ddb634ec9a05c3340941a9ba3f5ec5
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
* 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
