Unifying how the option prefix is handled for HTMLCheckMatrix and
HTMLMultiSelectField. This needs to be deployed at the same time
as the dependant Echo extension change Ic8420b89.
Change-Id: I4049b666db554283ce953387a30a0a8a7d0cd920
Bug: 47743
Renamed remove-options parameter of HTMLCheckMatrix to force-options-on
and added additional force-options-off. Minor refactor of
PreferencesForm::filterDataForSubmit to move class specific code into their
respective classes.
Change-Id: I61a6b2bcce3102e2350088912ee77620a9f678f9
The error is Fatal error: Call to a member function msg() on a
non-object at includes/Preferences.php on line 1207.
The problem is that fields created in Preferences::getPreferences() for
validation don't have their parent set and thus an error occurs when the
validation fails since they want to use their parent to get a Message
object.
This commit adds a dummy parent object to these fields to fix the error.
bug: 41337
Change-Id: I5826d6e3f1262c8d26af0cfe7074a939f80bcaca
Susan and Base-w in #wikimedia discovered that a red box is always shown around
their email address on foundationwiki. This is because the box is shown by
default - even when email address authentication is disabled.
Change-Id: I0b906b23dec6018bc21a179e2cf950b705100c4c
Things like checkboxes have no label, yet a label div gets generated
anyway. This is annoying when maybe I don't want that empty div hanging
around (i.e., it looks like it's part of other option groups when I
have left margins on all .mw-input).
This patch will now also escape 'label' fields by default. For the old
functionality you must now explicitly use the 'label-raw' field.
Change-Id: I8f8340911b7495a91c93e7f2eb7c041b2a7f2179
- Group common checks; $wgDisableLangConversion and count( $variants ) only be need to be
executed once to decide to show or not both fields
- Move the check for existence of multiple variant directly after calling getVariants(),
so there is no need to run unnecessary code when a language doesn't have variants
- Move the declaration of $variantArray to where it will actually be used
- fix comment style
Change-Id: I2d621424904d0210336845cd82f96bb68a022514
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
* Created a new Resource Loader module
* Created an entry for the RL module in the Resources.php
* Added messages to languages/MessagesEn.php and languages/MessagesQqq.php
* Called the new RL module from the EditPage.php
* Added required entries in the messages.inc, DefaultSettings.php
Corresponding change in the Vector extension: I164f17255bc927
Bug: 46514
Change-Id: I7bdbd09f4083ccb316156307400ccfacdfec79e1
"Quickbar" was a feature of the Standard and CologneBlue skins that
allowed the sidebar to be displayed on left or right side of the page,
floated or fixed, and hidden on diff pages.
Standard was removed (Ia6d73c2d), and CologneBlue doesn't support this
anymore (bug 41246), so all things quickbar can now be safely removed.
* Removed user prefs option + interface
* Removed related messages
* Removed code for this in SkinLegacy
* Removed dead code in DifferenceEngine and Language
Change-Id: I5e6f7d48d6904a052a3a11547d3ebe6161463018
* 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
Before change I98df55f2 it was possible to set arbitrary preferences (ie.
with anything as the key) using the action=options API. That change
removed this ability by enforcing full validation of the preferences, also
introducing several regressions which were fixed by follow-ups.
Per the discussion on bug 40124, this changeset aims to restore this
ability, but in a slightly restricted way: arbitrary preferences' names
must start with userjs- prefix, to avoid any possibility of conflicting
with new MediaWiki versions or extensions.
The contents of these preferences is not escaped, sanitized nor validated
in any way; script authors are expected to sanitize them themselves to
prevent XSS attacks and other security vulnerabilities.
This commit also adds the User::getOptionsKinds() method (to determine
whether given preference keys are used by MediaWiki itself or an extension,
intended to be used via the API, or entirely unknown) and enhances the
User::resetOptions() method to allow for resetting only preferences of
chosen kinds.
These changes allow for fixing of Special:Preferences not to clear those
additional fields when saving user settings.
Change-Id: I5f9ba5b0dfe7c2ea5458d836f03429cf6d93969d
Extensions can use their own interface for user preferences, with the
help of the action=options API.
For example, Universal Language Selector has a different UI to
allow anonymous and logged in users to set language related preferences.
Validation for the preference values is up to the extensions.
Change-Id: I18a5ffb5cc202c59ba76b86cfb63e49010cc1881
GENDER support added for messages:
* username
* uid
* prefs-memberingroups
These messages require GENDER for grammatically correct sentences
at least in some Slavic languages. Perhaps, other languages may
require its support in other messages as well (e.g. yourrealname).
+ Some refactoring per review request.
Change-Id: I51cc8ea9128dda90d87de656ea3a4605a5dc04e0
Some time, long, long ago, in a MediaWiki much, much saner
the preferences form told wgAuth to update the external database.
That code disappeared at some point. This commit adds it back.
Change-Id: I91df44c8a8b38119c33d4a69b8c7e3c180e5c773
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
@fixme is simply not recognized by doxygen whereas @todo is used to
generate a nice ... todo list!!
Change-Id: If956c0a164373126ce48b791d45c56962034eecd
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
* Much more easier to find it in the User class than in Preferences and it's general enough to be in that class.
* Rewrote the function for better readbility
* It now always return a Status object so that it's easier to interpret its result.
* Update the only caller in core (in Special:ChangeEmail) and moved the PrefsEmailAdit hook there
Change-Id: I55939bb5295e73594c3fdf7287dddbc16a233ce4
- MWCryptRand: A new api for generating cryptographic randomness for security tokens. Uses whatever cryptographic source is available and if not falls back to using random state and clock drift.
- wfRandomString - A simple non-cryptographic pesudo-random string generation function to replace wfGenerateToken which was written pretending to be secure when it's really not.
- Core updates to use MWCryptRand in various places:
-- user_token generation (to do this we stop generating user_token implicitly and only generate it when needed to avoid depleting the system's entropy pool by reading random data we'll never use)
-- email confirmation token generation
-- password salt generation
-- temporary password generation
-- Generation of the automatic watchlist token
-- login and create user tokens
-- session ids when php's entropy sources are not set
-- the installer when generating wgSecretKey and the upgrade key
* Reduces the overly long code in r107002, and reduces code for {{#language:}}
* Fixes the language list in Special:Translate which contained languages that gave "invalid code" when selecting
