These are static methods that have to do with processing language names
and codes. I didn't include fallback behavior, because that would mean a
circular dependency with LocalisationCache.
In the new class, I renamed AS_AUTONYMS to AUTONYMS, and added a class
constant DEFINED for 'mw' to match the existing SUPPORTED and ALL. I
also renamed fetchLanguageName(s) to getLanguageName(s).
There is 100% test coverage for the code in the new class.
Change-Id: I245ae94bfc1f62b6af75ea57525139adf2539fe6
This removes Language::$dataCache without deprecation, because 1) I
don't know of a way to properly simulate it in the new paradigm, and 2)
I found no direct access to the member outside of the Language and
LanguageTest classes.
Change-Id: Iaa86c48e7434f081a53f5bae8723c37c5a34f503
The way isMainCacheable() was used, it always returned false in
non-content languages, because it would try to find strings like
'hidetoc/fr' in the array of message keys (which contains strings like
'hidetoc').
The consequence of this was that MessageCache would check the database
for a MediaWiki:hidetoc/fr page even if it already knew that that page
didn't exist. This is a substantial performance hit when requesting lots
of messages, like when building version hashes for ResourceLoader's
startup module.
Follows-up 4fc5ba8bf8.
Bug: T228555
Change-Id: I20433175ca919acc1c995f4a9cd50ca53afcdd02
Probably good to start testing this in CI sometime soon.
The unit tests being changed here are:
* Hacky importing of a revision in MessageCacheTest, changed to use an
interwiki username.
* WikiPageDbTestBase will get null rather than 0 for ar_user.
* DumpTestCase was using a custom IP $wgUser when creating its test
revisions, which was winding up referring to an actor_id that had been
deleted from the database. Fixed by having it use a registered user
instead.
Also this has MediaWikiTestCase reset the $wgUser User object when the
actor table is truncated, as various tests were otherwise failing because
it was caching a later-deleted actor ID for User:127.0.0.1.
Bug: T188327
Change-Id: Ic483d0fda931810ac639b9de1cc5e5a4ef8161cc
Depends-On: I1bd0288cc132627d75b4001219522ec5e952eda7
This re-enables the "flaky" testLoadFromDB_fetchLatestRevision which
was disabled because it failed on random patches for no apparent
reason, as documented in T219042.
The reason was an invalid timestamp in the test data, which caused
the timestamp to default to "now", which was "sometimes" newer than
the timestamp of the revision immediately created before.
Bug: T219042
Bug: T218918
Change-Id: I38f4816b2dc735a7698626c7e3fe4a93ec95a9d1
In Id044b8dcd7c, we lost a condition that ensured that the cache would
be populated with the latest revision. Now it was being populated with
all revisions, with a random one winning.
Bug: T218918
Change-Id: I1a47356ea35f0abf35bb1a3489d0d3442a3400a5
Follow up to a3d6c1411d.
This avoids extra queries for messages that have a software defined value.
Bug: T193271
Change-Id: I25aa0e27200a0b417721cf1fbd34a82095405b89
Prior to I462554b30, MessageCache::replace() did just that: it took the
existing cache and updated the one entry.
In I462554b30, the rearrangement of work into a DeferredUpdate
introduced a bug: the in-process cache was updated, but when the shared
cache was loaded later the entry was never updated in there so the
shared caches kept the old value. This was found in code review and
worked around by reloading all the messages from the database instead of
updating the existing cache.
But all that extra work reloading everything from the database causes
major slowness saving any MediaWiki-namespace page when the wiki has
many such small pages. Let's go back and fix the bug so replace() can
again replace instead of reloading everything.
Bug: T203925
Change-Id: Ife8e1bd6f143f480eb8da09b817c85aadf33a923
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
Do the process cache update immediately (as before) but push
the shared cache updates to a deferred update. This update
will thus start with a clear transaction snapshot, so it can
acquire the lock before the first SELECT as is proper.
Also added some missing method visibilities.
Bug: T144952
Change-Id: I462554b300d4688b09ab80cd1bb8a4340ffaa786
The unit tests spend nearly half of their run time resetting the user table for
each test. But the majority of tests do not depend on the user table having the
exact value that the setup code resets it to, and do not need to modify the
user objects they require to run.
Fix that by providing an API for tests to get User objects, and to indicate
whether the User object will be subject to destructive modification or not.
This allows User objects to be reused across multiple unit tests.
Change-Id: I17ef1f519759c5e7796c259282afe730ef722e96
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
AuthManager is coming, which will make it easier to add alternative
methods of authentication. But in order to do that, we need to finally
get around to ripping the password-related bits out of the User class.
The password expiration handling isn't used anywhere in core or
extensions in Gerrit beyond testing for expired passwords on login and
resetting the expiry date on password change. Those bits have been
inlined and the functions removed; AuthManager will allow each
"authentication provider" to handle its own password expiration.
The methods for fetching passwords, including the fact that mPassword
and other fields are public, has also been removed. This is already
broken in combination with basically any extension that messes with
authentication, and the major use outside of that was in creating
system users like MassMessage's "MediaWiki message delivery" user.
Password setting methods are silently deprecated, since most of the
replacements won't be available until AuthManager. But uses in unit
testing can be replaced with TestUser::setPasswordForUser() immediately.
User::randomPassword() and User::getPasswordFactory() don't really
belong in User either. For the former a new PasswordFactory method has
been created, while the latter should just be replaced by the two lines
to create a PasswordFactory via its constructor.
Bug: T47716
Change-Id: I2c736ad72d946fa9b859e6cd335fa58aececc0d5
* The cache has to reload and *after* locking to avoid
losing any concurrent changes.
* Also fixed incorrect assumption in MessageCacheTest.
Message overrides for the content language do not use
the language suffix.
Change-Id: I98ff158a1575330bc59efe6badb27f8de8717951
* This ends up being more complex than its worth
and even more so for multi-DC support
Bug: T93006
Change-Id: Iaa774fe69061e42955b11dc82d30dba93208e606
If $wgMessagesDirs is initially empty, we can optimize when batch loading
extensions:
if ( !$wgMessagesDirs ) {
$wgMessagesDirs = $cache['MessagesDirs'];
}
With APC, this should be O(1) CPU time.
This was suggested by Tim in the code review of I7074b65d07c5.
Change-Id: I66fa907cdaafe18b74b5b9afaa8b6b1db069bea3
Also move the global setting to addDBData to let the test work
correctly, because the global is used indirectly in User::saveSettings.
Change-Id: I986d3a28e4fcc82ed84886c2970571e9fa6128be
Currently LocalisationCache merges the core data for all languages in
the fallback chain, then the extension data, then merges those two, and
then gives extensions like LocalisationUpdate a chance to make final
overrides with the LocalisationCacheRecache hook.
But if LocalisationUpdate doesn't want to locally duplicate all the
messages for every language (e.g. r104041), LocalisationCacheRecache is
too late: the information as to whether a message came from the primary
language or a fallback has been lost, so when LU itself has an override
for a fallback language it can't know whether or not the existing
message should be overridden or not.
The solution is for LocalisationCache to gather the data for each
fallback language separately, call a new hook for LU to affect just that
language (LocalisationCacheRecacheFallback), and only then merge the
fallback languages together.
Bug: 68781
Change-Id: Iacfe96063fcc66c1f97ca5e5292a8fc70af988cf
- Swap "$variable type" to "type $variable"
- Fixed spacing inside docs
- Makes beginning of @param/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: Ia041964250d8b7c0349d79dc9b131c5b8696e795
The core function behind wfMessage() (MessageCache->get()) did not
apply the language fallback chain to on-wiki messages.
This patch has changed the behavior to iterate over all possible
languages, first checking on-wiki and then checking the CDB cache,
until it finds the message. Note that fallback languages never
take precedence over the actual requested language.
This patch was taken from the following changes and then
adjusted to fix issues that caused bug 46579.
* Change-Id: Iaaf6ccebd8c40c9602748c58c3a5c73c29e7aa4d
- Author: Matthew Walker <mwalker@wikimedia.org>
- (cherry picked from commit d434bfcf3b)
* Change-Id: Ib607a446d3499a3c042dce408db5cbaf12fa9e3d
- Author: Mormegil <mormegil@centrum.cz>
- (cherry picked from commit 1b8cb8dc31)
Bug: 1495
Bug: 46579
Change-Id: I420457863eeb79824698d06abc7784032b267af2
This patch set reverts the following:
* Iaaf6ccebd8c40c9602748c58c3a5c73c29e7aa4d
* Ib607a446d3499a3c042dce408db5cbaf12fa9e3d
* Ic59fd20856eb0489d70f3469a56ebce0efb3db13 (partially)
Bug 46579 comment 17 describes a desired solution. In
If88923119179924a5ec091394ccab000ade16b3e we are working on a fix, but it is
taking longer than we anticipated. There was a deployment window planned
about now, but we didn't make it. It makes sense to revert for now, and commit
a proper solution somewhere next week.
Bug: 46579
Bug: 1495
Change-Id: Iac7ac4357dd80e8cdb238a6a207393f0712b3fe5
Also update some previous inconsistencies pointed out by Krinkle in change IDs:
* Ide20743a2e84ff68549286120e6cff9d9f396f54
* I811ca957b6588085d67606ebc0cd4033a1e53839
Change-Id: Ife33b931870d0d7e04fcb40974997436d27f528f
