The patch adds the localised commit date of i) core and ii) extensions
in the Special:Version page tables. It requires the Git version control
system being installed, which is checked during the installation.
Introduces a new parameter for the git binary in DefaultSettings.php:
$wgGitBin = '/usr/bin/git';
Patch authored by DaSch <dasch@daschmedia.de> and updated and fixed
by Wikinaut<mail@tgries.de>.
Bug: 38783
Change-Id: I0931400ecacf91ed2ab4fc7aa46dceac17661768
If a global variable is set or if you add ?useNew=1 to the query string,
Special:Userlogin loads a different login template (UserloginVForm.php)
with the new Vertical Form appearance and different messaging.
Otherwise the current unchanged template renders so that wikis can cut
over to the new look when ready (with messages and links). Once they do
so, the variable and flag will be retired.
The new template applies mw-ui-vform and mw-ui-button styles defined in
a new 'mediawiki.ui' CSS module in core to create a compact vertical
form. The mw-ui styles specify a Helvetica font stack (that we tested
in the Account creation experiment) in the form area, but NOT if the
user is using some other skin than Vector.
The CSS code is developed using Sass. The patch includes the
Sass scss files, along with a Makefile that uses their Compass build
configuration (config.rb).
The redesigned Special:Userlogin also:
* Displays a "secure login" link if HTTPS is available.
* Loads additional CSS for its form features (e.g. more attractive
errorbox, "Join wiki" messaging).
* Defines new "userlogin-xx" messages; many are the same as
existing messages but without ':' on the end.
* Uses a distinct title for Login instead of generic "Log in /
Create account".
* Removes the [mailmypassword] code branch from its login template as it
is never executed.
Bug: 44628
Change-Id: I489042c50aa060c90ca18b05097dbe25c4ae6395
* 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
* Use the stale message cache while the new one is being generated
* Revert I811755d4 (make message cache load failure fatal). This
escalated several very plausible temporary site issues from barely
noticeable to complete downtime -- for example, memcached being down
on a site with only one memcached server.
* Remove $wgLocalMessageCacheSerialized, it's always been pointless
* Clarify a couple of comments.
* Increased lock wait timeout to 30s
* Make lock() fail immediately on memcached connection refused
Tests done:
* With local cache enabled: normal cold refill; refill local from
global cache; use stale local cache during remote refill; use stale
global cache during remote refill; cold cache wait for remote refill;
saveToCaches() failure; memcached connection refused.
* With local cache disabled: saveToCaches() failure; cache disabled due
to "error" status key; memcached connection refused.
Setting a 1-day expiry in memcached, with a ~10s CPU cost to replace, is
not the best idea since it inevitably leads to a cache stampede. Dealing
with the stampede by waiting for a lock is not ideal, even if it were
implemented properly, since it's not necessary to deliver perfectly
fresh message cache data to all clients.
This is especially obvious when you note that barring bugs, expiry and
regeneration always gives you back the exact same data, because we have
incremental updates (MessageCache::replace()). Keeping all clients
waiting for 10s just to give them the data they have already is pretty
pointless.
So, continue to serve the site from the stale message cache while the
new one is being generated.
One caveat: if local caching enabled, when the message cache becomes
stale, a sudden spike in network bandwidth may result due to the full
array (also typically stale) being fetched from the shared cache.
Bug: 43516
Change-Id: Ia145fd90da33956d8aac127634606aaecfaa176b
"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
This was an experimental authentication system intoduced a couple
of years ago with a pretty narrow use-case. It's been pretty much
ignored since introduction, and makes login more complicated than
it needs to be.
I didn't drop the external_user table on the off-chance someone
out there actually has data in it, but they should use AuthPlugin
for their external authentication needs.
Change-Id: I794338dbb75961ee033d41fa44bb7aa22e54f447
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3faa9c3e8107c6e46cdf21f8c18adda1f42890d7
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3e38b94d10600a60d2d4857de54307f34c4662c4
The usability testing for this feature is over. We've had it enabled on the largest
family of wiki in existence for ages. People are generally expecting to see this
enabled when they install a new MediaWiki wiki.
Change-Id: I6e7f4cf6c874fe9e34cc141c4305a6808c1fe576
The code did not go through a proper review process, and - quite
simply - it is unacceptable by core standards (or by any standards, to
be honest).
* It "[u]ses JavaScript to munge the create account CAPTCHA", to quote
the commit message
* It is littered with TODOs and FIXMEs, as well as messages from one
coder to the other and commented-out code
* It modifies some HTTPS-related logic for no obvious reason (it's not
documented or even mentioned *at all* in a otherwise front-end
changeset)
* It happily disregards code conventions (trailing spaces, #-comments,
CSS formatting)
* It includes different CSS font-family rules that the entire rest of
software uses for display, creating design inconsistency
* It hardcodes links in the format "/wiki/XXX"
* It hardcodes English-language link hrefs
This reverts commit 92bb00d356
Conflicts:
languages/messages/MessagesEn.php
Change-Id: I00d72fe157e697d5cf926e75bcea5db0bee153e5
If a global variable is set or if you add ?useAgora=1 to the query
string, Special:Userlogin loads a different login or create account
template (Userlogin-/UsercreateAgora.php) with an Agora look and
different messaging. Otherwise the current form is unchanged so
that wikis can cut over to the new look when desired.
These new templates apply mw-ui-formlist and mw-ui-button styles defined
in a new 'mediawiki.ui' CSS module in core (copied from Extension:Agora).
In useAgora mode, Special:Userlogin also:
* Adds new modules with some additional CSS for new form features
("Join wiki", benefits of creating an account).
* Defines new "userlogin/usercreate-xx" messages, many are the same as
existing messages but without ':' on the end.
* Uses a distinct title for each mode instead of generic "Log in /
Create account".
* Uses JavaScript to munge the create account CAPTCHA.
* Outputs checkboxes using UserloginTemplateAgora::labelledCheck()
* Displays a benefits column of wiki edits/users/contributor numbers.
TODO:
- Restyle/reposition language selector
- Munge CAPTCHA in PHP not JavaScript, i18n of new CAPTCHA messages.
- Identify the subset of Agora appropriate for non-Vector skins and
create mediawiki.ui.default.css from that.
Patch set 18: Agora styles now in core.
Bug: 44628
Change-Id: I859edab4fc4fa9fe35fdef15fc429ae19a95305d
* 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
maintenance/migrateCurStubs.php does not exist; and I was unable to find
any script that would achieve that functionnality.
Bug: 44719
Change-Id: I78d8a8aa95a5406bf5a979867bc12a9bb34907f6
Having all group mapping for Special:SpecialPages in the global
$wgSpecialPageGroups is not a good OO style.
Created a method SpecialPage::getGroupName, which than can be overridden
by each subclasses to the featured group name.
Added also SpecialPage::getFinalGroupName to get the groupname on
Special:SpecialPages to handle the customization and
to keep $wgSpecialPageGroups for b/c
Change-Id: I1de3a186f0a59ec5ecb8996c5f805cf164e9637f
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
Use lowerCamelCase.php format for all files (per [[mw:CC#File_naming]]),
and make filenames more specific:
- clear_stats.php -> clearCacheStats.php
- clear_interwiki_cache.php -> clearInterwikiCache.php
- initStats.php -> initSiteStats.php
- proxy_check.php -> proxyCheck.php
- stats.php -> showCacheStats.php
- showStats.php -> showSiteStats.php
Also changed the class names accordingly (per [[mw:CC/PHP#Naming]]),
and make class names more specific:
- clear_stats -> ClearCacheStats
- InitStats -> InitSiteStats
- CacheStats -> ShowCacheStats
- ShowStats -> ShowSiteStats
Updated files that made references to the changed files/classes:
- DefaultSettings.php and SpecialBlockme.php (proxy_check.php -> proxyCheck.php)
- maintenance/showSiteStats.php (initStats.php -> initSiteStats.php)
- maintenance/README and docs/memcached.txt (stats.php -> showCacheStats.php)
- docs/maintenance.txt and docs/memcached.txt (clear_stats.php -> clearCacheStats.php)
Thanks Hashar for the initial help and encouragement :)
Change-Id: I60f76fc971e06e1b710dcda35f9c2d931b93bdd7
* This should lower the rate of queue activity when major templates change.
* Also fixed a broken array_diff() call in nextJobDB.php.
* Additionally removed checkJob from nextJobDB.php. This is redundant to
runJobs.php de-listing queues via JobQueueGroup::pop() when the queue
is empty.
Change-Id: I1518a0de9e7ada22350d9993dd7ffe5f2ce23745
Disable of MessageBlobStore clear
Reset $wgAutopromote (should be moved to a config change!!)
Disable setting of wgStyleSheetPath
Throttle page_touched
Add apc htcp packet numbers to SquidUpdate
Disable set names binary/utf8
Commment out searchindex table indexes
Was c532e81d583d3d0439fe76eea4d105d675461b56
Original revision Change-Id I42c4f859e55eb198f6c6841e582b3552aad7b31f
https://gerrit.wikimedia.org/r/#/c/7606
Change-Id: I5ec8dd53188e9e4128f99ceaff38ebf9dcf570bb
Following up I1cb6ee22, which added this information to each page's
action=info, this adds inprop=watchers to query the number of people
watching the page. It is subject to the same limitations (user has
unwatchedpages or watchers >= $wgUnwatchedPageThreshold) as action=info.
Also, update doc for $wgUnwatchedPageThreshold to match reality.
Bug: 44244
Change-Id: Ideaac1d84bbe0349154ffe96ba54d74305e3da1d
It would be useful to be able to list pages using a particular page
property, particularly in light of the new Disambiguator extension.
This adds a special page Special:PagesWithProp and an API query module
list=pageswithprop to do just this. It also adds an API query module
list=pagepropnames to list the prop names currently in use on the wiki.
Change-Id: Ib0d4e17f22b8d0cb9894eac6095962315480e809
* Cleaned up 'server' option to not fragment the pool.
Also made it actually match the documentation.
* Made it use doGetPeriodicTasks() for job recycling.
* Made it so that other job queue classes can be tested.
* Renamed "redisConf" => "redisConfig".
* Tweaked comments about the "random" order option.
Change-Id: I7823d90010e6bc9d581435c3be92830c5ba68480
* The default class is JobQueueAggregatorMemc.
This essentially has the logic that nextJobDB.php used.
* Also created a JobQueueAggregatorRedis class.
This is much more efficient and more responsive.
* This can speed up calls to getQueuesWithJobs().
* Removed unused getDefaultQueuesWithJobs() function.
Change-Id: Ifb3c6c881decd643da1b662956ded69db4b39431
* $wgAPIGeneratorModules is now obsolete and will be ignored
* Removed generator tests - obsolete because there is no more list
Change-Id: I014260a42226854a2178345dc3cd0f50b41b3c08
