We currently embed the full set of user options in a <script> tag in the HTML
output of every page. This is grossly inefficient, because the full set of
options is usually largely made up of site defaults which the user hasn't
customized.
So instead of doing that, let's emit the default options using one
ResourceLoader module and then apply the user's customizations on top.
This has the effect of slightly increasing the total bytes of JavaScript code
(because options that the user has customized will be emitted twice: once with
their default value in the user.defaults module, and then again with the
customized value in user.options). But this is more than offset by the
fact that the bulk of user options code (~4 kB uncompressed on enwiki) becomes
cacheable across requests.
Bonus round:
* Varnish gets to cache 4 kB fewer per page.
* Changes to the default options don't take 30 days to propagate.
Change-Id: I5a7e258d2d69159381bf5cc363227088b8fd6019
We effectively did this when outputting an HTML link in the function above, but
not for the wiki text version.
Just use getFullText instead of getPrefixedText, which handles adding anchors
where necessary and nothing else.
Bug: T75959
Change-Id: I1a4aa46d26e738c2a97e41463231da632e4ca8e5
Add the user right 'editcontentmodel', which is required to change the
content model while editing a Page.
Bug: 70901
Change-Id: I54f59539f1045092ec0de76c31cb47ca19c56874
In trying to avoid hitting RequestContext::getLanguage() from a call to
User::idFromName(), I05aacd30 made it no longer safe for user input.
A closer analysis of the call stack involved reveals that
Title::makeTitleSafe() is constructing a prefixed dbkey using the
localized name for NS_USER, and then Language::getNsIndex() is needing
to get the variant in order to handle that localized name. But if we use
the canonical name for NS_USER, Language::getNsIndex() short-circuits
and skips the problematic code path.
And it turns out that it doesn't actually matter which prefix
Title::makeTitleSafe() uses, since the prefix doesn't make it anywhere
into the resulting Title object. So let's revert I05aacd30 and Ibeef0409
and just do that instead.
Change-Id: Ib902573996c69d1e77527cc7b2faf4e7fa5d3daf
We don't want to call Title::makeTitleSafe yet, since that call path
ends up needing the user language, which ends up trying to load the
user object, which ends up back in User::idFromName.
Bug: 54193
Change-Id: I05aacd30be66fe505b5c211113ea938fa82e2492
By only updating the user row in the database, if needed
and by making use of md5 for passwords instead of slower
hashing.
This cut down run time of some Wikibase API tests to 20%
of the original value for me!
Also it reduces the run time of MediaWiki's test suite
by about 45s on jenkins.
Change-Id: I7024b287a71fe9b327dbcdc5427cd8edb5047606
Tokens returned from User::getEditToken will now include an encoded
timestamp (and therefore will be up to 16 bytes longer).
User::matchEditToken and User::matchEditTokenNoSuffix are gaining a
"maxage" parameter: when specified, only tokens with an encoded timestamp
within $maxage seconds will be accepted.
Change-Id: Ic4cf148cc1fa9d0561aac0bd2d68a09c7851896d
Various code passes null around to mean "an invalid password". It
shouldn't all have to test for null and specially handle that.
This also fixes a codepath where User::$mNewpassword could get set to an
empty string rather than a password object, which would cause problems
later when anything else tries to use it.
Bug: 71421
Change-Id: Ib5f94b52c07e7dba89328b98fb43c86db95ee09f
This way, outside code can load data from cache only if present. E.g. when data
for a lot of users is needed, it'd be preferable to batch-load all that is not
yet in cache.
Since there's currently no way to check for data in cache, one would have to
load all User objects separately (which may result in lots of DB queries if
nothing is in cache) or batch-load all of them (which may result in few DB
queries, but ones that may not be needed if all data is already in cache)
Change-Id: Ia22d04744760c3b6f3264786434e218b8aa88d53
Call loadPasswords when expiring the user's password, otherwise the
change is overwritten with the previous value.
This lets you do:
$u = User::newFromName( 'User' );
$u->expirePassword();
And the user will have to reset their password on the next login.
Change-Id: I47325dde1ce14280088efdc90ce7887b45e0dc6a
Change I4049b666 changed the way Preferences combines the prefix with
the row and column for HTMLCheckMatrix, but did not adjust the
corresponding code in User::getOptionFromUser().
Bug: 69146
Change-Id: I69ed9c875443ba44d1a5e12e51165ebf8d6d6a06
In User::setPassword() and User::setNewpassword(), added
calls to loadPasswords() so that the passwords are not
overridden when they are eventually actually loaded.
Bug: 69102
Change-Id: I0b881986323051abed7d1af816eae9eafdbd6782
In I0a9c972931a, User::load() no longer loaded the
mPassword and mNewpassword member variables, and
User::loadPasswords() is private. So this lets
things that need to access the Password objects directly.
Change-Id: Ib79ce01a47f90af681e376ce918eda559b4b94a6
- Two global constants unused outside of this class so removed
- Shorten name since MW and USER are redundant since it's in a class
- Use class constant instead of global define consistently
Change-Id: I0e8b05372512de568a230a6e5026751aa37c4c4e
Otherwise mNewpassword could be null.
Mlpearc reports on irc getting fatals about mNewpassword not
being an object. I couldn't reproduce, but loadPasswords() should
definitely be called here.
Change-Id: I6d1b74b79c87d1a1870971aafd1349255170123d
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
With r41328 the title validation was changed to allow rename of invalid
user names, by always creating a title object.
That removes the title validation for validation of 'usable' and
'creatable', but in that case it is also a good idea to apply title
rules to normalize spaces and reject user names which can not have a
valid title. At the moment that is done in User::isValidUserName.
Change-Id: I27c488e4008a924117ff6bac2216f148cd5e7abd
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
$wgDefaultSkin is allowed not to actually be a valid key (although
doing that is obviously very unwise), which in turn can cause
exceptions from Preferences::loadPreferenceValues()
(MWException "Global default…"), which in turn causes failure of
SpecialPreferencesTest::testBug41337() test.
Change-Id: I8f8ae9ba301337b2e6facd3dcfadbf2ab12ac605
- use tab as indent instead of spaces
- Added space after closures "function"
- Added spaces around string_concat
- Added newline inside empty blocks
- Removed four spaces after comma
Change-Id: I4425b0c6a69b36f40acfea6511b8950cf09ce2b2
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
Location is a tad bit different now than on the wikiHow codebase and some
arguments have been added, as per code review.
Because sometimes you have things that are stored in the user_properties
database table that should *not* be reset even when the user has requested
to reset all prefs back to the site defaults.
Live example of a thing using this hook (well, its previous iteration) is
wikiHow's WikihowPreferences extension.
Change-Id: I1da936c786adb21e2c1802ef405bb904c9cf4918
Special page PageLanguage to set the page language of a page.
To enable the feature, set $wgPageLanguageUseDB to true
and assign the 'pagelang' user right to a user group.
Bug: 35489
Change-Id: I0f82b146fbe948f917c1c5d29f7469644d797e80
* Avoid doing the DELETE for unchanged rows. This method is often
called when one new preference (e.g. watchlist token) is set.
These cases will now simple result in an INSERT, even if the
user already has some preferences set.
bug: 36116
Change-Id: Ib7c558e7c06927875086b86ea719ac1323a7b4a8
