Avoid synchronous document.cookie reads unconditionally during page load.
At least avoid the read where it isn't needed, such as non-view actions
and special pages.
Ideally this would happen in mw.requestIdleCallback, but unfurtunately
various extensions have a fragile dependency on reading mw.config
wgPostEdit at initialitation time which would likely fail if this is no
longer set synchronously. To be revisited...
Change-Id: Ib655bf6507333c1a9845a05eb436dca522efbab7
This will allow searching on user id instead of just the name.
This is how ContribsPager, LogPager, ... all work already.
Bug: T160415
Change-Id: I4db7bd0f917a428f40eb315246f89d49c7ae5b6a
These are a few minor fixes to improved the
UX of the new sister search sidebar.
- Making the link color on sister search results blue
- Fixing the order of the multimedia search results widget
- added a more explicit 'more results' message instead
of the current '(more)' message.
- aligning the top of the sidebar with the top of the regular
search results.
- fixing a typo in the multimedia widget.
Bug: T158935
Change-Id: Iaae603cc217b7847bebfa61b050b7c86bdd19f14
Update the CREDITS file using maintenance/updateCredits.php script that
uses `git log` to identify contributors. For each added user it was
checked by hand that no user with the same mail adress but an other
"Real Name" was already in the CREDITS file. This is the case with one
entry, prevent this using .mailmap. Also remove (WMDE) at end of real
name in one case using .mailmap file. Also change version name MW 1.28
to 1.29 while at it.
Change-Id: I4c3bb8c3e5f0c1317ea8711efc4f88e571b0c5c6
Generate old RC, Related changes (it was already displayed and working
on 'Related changes' before this change), and Watchlist/etc. and data
for new UI from back-end.
This moves everything used for defining the old (unstructured) and new
(structured) filters into unified objects, ChangesListFilter and
ChangesListFilterGroup (and sub-classes).
This includes the query logic (see below) and logic for adding
CSS attribution classes.
This is a breaking change (for subclasses of ChangesListSpecialpage)
due to the signature (and name) change of buildMainQueryConds and
doMainQuery. An alternative that I don't think is a breaking change
would be to put the filter->DB logic in runMainQueryHook, but then it's
doing more than just running a hook.
This is because it used to only build $conds here, but it's clear from
filterOnUserExperienceLevel filters need more than this. I added all
the DB parameters from the hook, but this could be debated.
I have an checked and fixed the WMF-deployed extensions affected by
this.
Other than that, there should be full back-compat (including legacy
filters not using the new system).
* add hidepatrolled/hideunpatrolled to new UI.
* Move userExpLevel from RC to ChangesListSpecialPage. Although for
now the structured UI only displays on RC anyway, when it displays on
watchlist, it seems we'll want userExpLevel there.
Change this to make 'all' exclude unregistered users.
* Don't have front-end convert none-selected to 'all' on string_options.
* Needs the hideanons/hideliu special redirect to be done before this
is merged (T151873)
Bug: T152754
Bug: T152797
Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
curl is the preferred HTTP implementation as far as I'm a aware and the
only implementation used by MultiHttpClient, a requirement for
something like VisualEditor
Change-Id: I40a015339d4a3f92cfadcd92dfd70425639d0412
$wgDummyLanguageCodes is a set and mapping of different language codes:
* Renamed language codes: ['als' => 'gsw', 'bat-smg' => 'sgs',
'be-xold' => 'be-tarask', 'fiu-vro' => 'vro',
'roa-rup' => 'rup', 'zh-classical' => 'lzh',
'zh-min-nan' => 'nan', 'zh-yue' => 'yue'].
The old language codes are deprecated because they are invalid but
should be supported for compatibility reasons for a while.
* Language codes of macro languages, which get mapped to the main
language: ['bh' => 'bho', 'no' => 'nb'].
* Language variants which get mapped to main language:
['simple' => 'en'].
* Internal language codes of the private-use-area which get mapped to
itself: ['qqq' => 'qqq', 'qqx' => 'qqx']
This is a very strange conglomeration which should get differentiated,
and were split up in the following ways:
* Renamed language codes are available from
LanguageCode::getDeprecatedCodeMapping().
* Language codes of macro languages and the variants that are mapped to
the main language are available as $wgExtraLanguageCodes and are set
in DefaultSettings.php.
* Internal language codes are set in $wgDummyLanguageCodes in Setup.php.
Change-Id: If73c74ee87d8235381449cab7dcd9f46b0f23590
Change the SpecialWanted*-Pages so that they do sort
1. by the number of links to a site (as is now) and
2. alphabetically for entries which have the same number of links (new)
Bug: T4335
Change-Id: If54cd52b69007ee81af4733a14be3fd893c4abfe
According to their documentation, these messages are no longer used
since MediaWiki 1.22. They only waste translators' time.
The messages appear to not be used by any skins or extensions
in Wikimedia version control.
Change-Id: I4b8e91558654b5f9006ed44bad6971237f057d07
Per T20578, change a9c243b7b5 (r97044)
has replaced these messages with a new set that doesn't rely on
"lego" concatenation. But the old messages were never removed.
Some were blacklisted on Translatewiki, but others continue to
waste translators' time.
The messages appear to not be used by any skins or extensions
in Wikimedia version control.
+--------------------------------+--------------------------------+
| Deleted old messages | Replacements in current system |
+--------------------------------+--------------------------------+
| revdelete-logentry | logentry-delete-revision |
| revdelete-log-message | |
+--------------------------------+--------------------------------+
| logdelete-logentry | logentry-delete-event |
| logdelete-log-message | |
+--------------------------------+--------------------------------+
| revdelete-hid | revdelete-content-hid |
| revdelete-unhid | revdelete-content-unhid |
| | revdelete-summary-hid |
| revdelete-content | revdelete-summary-unhid |
| revdelete-summary | revdelete-uname-hid |
| revdelete-uname | revdelete-uname-unhid |
+--------------------------------+--------------------------------+
Change-Id: I27c616ca1aaca3058ad48753f5e4bfc64a71636e
This file seems to be a stress-test for the MediaWiki preprocessor.
It doesn't really matter whether the messages references here exist.
As messages are occasionally renamed or deleted, and since this file
was generated in 2011, people keep getting confused when they grep
for a message name and run into this list (and sometimes needlessly
spend their time updating this file, as seen in its Git history).
This commit replaces all of the message names with their SHA1 hash
truncated to 8 hex characters.
Regexps used for matching:
(?<=\?title=MediaWiki\:)([^&{}<>|\[\]]+)
(?<=int:)([^&{}<>|\[\]]+)
(?<=\[\[MediaWiki_talk:)([^&{}<>|\[\]]+)
(?<=action=edit )([^&{}<>|\[\]]+)
Change-Id: I52a71c0cc0e6fa21a61420d52df755066c6e9a08
Pull in the RemexHtml library, which is an HTML 5 library I recently
created.
RemexCompatMunger mutates the event stream, inserting <mw:p-wrap>
elements where necessary, and occasionally taking even more invasive
action such as reparenting and removing nodes maintained in Serializer's
tree.
RemexCompatFormatter produces a MediaWiki-style serialization which is
relatively compatible with existing parser tests. It also does final
empty element handling, including translating <mw:p-wrap> to <p>
Tests are imported from both Html5Depurate and Subbu's pwrap.js.
Depends-On: I864f31d9afdffdde49bfd39f07a0fb7f4df5c5d9
Change-Id: I900155b7dd199b0ae2a3b9cdb6db5136fc4f35a8
Due to a regression in popups positioning in OOUI, the popup
renders wrongly when it is unanchored.
Fixing this to an anchored popup while the OOUI bug is being fixed.
Bug: T159906
Change-Id: I38ca560929f7f9488ff48b148b089f0613d67d97
