| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
Bug: T122754
Change-Id: I2cdeb98c81d4b98ea986bd2f7b23cd93c62c5930
|
|
|
|
|
|
|
| |
Deprecated since 1.21.
Bug: T122754
Change-Id: Iddf1c2d61cafc017bf361b747db38ac1bc5f3f09
|
|
|
|
|
|
| |
Just like commit f86a5590aae7fbe6d9b8a3d129c7a04a11a27579
Change-Id: Ic9d08bca6524d6bb4baf5170c081ad0f3d738e28
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Blocks are checked (checkUserBlock).
Change-Id: I3a164d1003f2bea3e3e07081c9bebfabd884ade9
|
|/
|
|
| |
Change-Id: I5d3a5eb8adea1ecbf136415bb9fd7a162633ccca
|
|
|
|
|
|
| |
All of core uses implode() consistently now.
Change-Id: Iba50898c64c43f356d1caf8869f484e90d9ff651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also removes assumptions that when a page
in one Namespace should be watched / removed
that the page in the talk / subject ns for the
page should have the same action applied
This should maintain all backward compatability
for the WatchedItem class
This also includes tests written by:
- WMDE-leszek
- Addshore
Bug: T127956
Change-Id: Iad9abafe4417bb479151a3bfbee6e1c78a3afe3c
|
|
|
|
|
|
|
|
| |
If a page language in database is set then use the current preferred variant
of this language.
Bug: T117667
Change-Id: Idfe1165346ae0068a4b73de441dc9dfa107b8e8b
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
All callers only hit this case by accident (e.g. limit/offset)
Bug: T92357
Change-Id: I4b5d1b62b2e564b40c65c82cfd4788093d61fc98
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Per wikitech-l consensus:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-February/084821.html
Notes:
* Disabled CallTimePassByReference due to false positives (T127163)
Change-Id: I2c8ce713ce6600a0bb7bf67537c87044c7a45c4b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the Title object isn't the title of the current viewed WikiPage, the page_lang
field of the database isn't requested. This results in the problem, that
Title::getPageLanguage() always returns the default content language, even if
the page language is different (changed with Special:PageLanguage, if
wgPageLanguageUseDB is true). That is problematic for the Translate extension,
which relies on the correct page language.
This change makes sure, that getPageLanguage() always return the correct page
language. If the page language isn't loaded already, Title::getPageLanguage()
now does a database lookup (if $wgPageLanguageUseDB is true) to get the correct
page language. It will use LinkCache for the page_lang field.
Bug: T121666
Change-Id: I0ae5ea39f7a124ed427ca5dfb26c1a116b27a94e
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| | |
With the roll-out of the Gadget namespace, these are going to be
especially misleading and likely to cause bugs.
Change-Id: I61f1f56762711fab173bbc54d110a7c48604d464
|
|/
|
|
|
|
|
|
|
| |
This will always return a MediaWikiTitleCodec object.
This is called in Title::secureAndSplit which expects
the method splitTitleString which is only in this
implementation and not the interface
Change-Id: Ibb6cdcf7deb6c1080e320379aa58981e9935ca33
|
|\ |
|
| |
| |
| |
| | |
Change-Id: Iee4b183ae54457d0c6cd3473f9fed3207742b54f
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To be used by things that do not care if they are
passed a Title or TitleValue so long as it has a
dbkey, namespace, possible fragment and text
Example uses include:
LinkBatch::addObj
MediaWikiPageLinkRenderer methods
MediaWikiTitleCodec methods
PageLinkRenderer methods
TitleFormatter methods
Change-Id: I2aa1a82129bb01155924a8e6a403c7a47391432f
|
|/
|
|
|
|
|
|
|
| |
This is the cause of the T76305 debug log entries relating to SpecialExport
and Echo.
Bug: T76305
Bug: T116034
Change-Id: I64d629d31be79c4b4702a4298bce68fd544df6e8
|
|
|
|
|
|
|
| |
getPageLanguage() from ContentHandler already returns a Language object.
wfGetLangObj is not necessary.
Change-Id: I556236419e445ce549598dd1752b29f619b0ca3c
|
|
|
|
|
|
|
| |
This makes it easier to have deferred atomic DB transactions
Bug: T122115
Change-Id: I67afe335f03cc21fdce78abdf3f31fa67a368419
|
|
|
|
|
|
| |
Unnecessary, and causes a deprecated notice
Change-Id: I823b2a037260d3d50a7b074d25d51c11c165d3b8
|
|
|
|
|
| |
Bug: T122754
Change-Id: Ibb895855aa1bf6b9cbbaf68643362ea485e0427c
|
|
|
|
| |
Change-Id: I8da1c995f2da2e7a43c70aeadd28b93e5f3e511f
|
|
|
|
| |
Change-Id: I433acc7990a5fcefd0d2ff5b14ba33dec0424706
|
|
|
|
| |
Change-Id: Idcc528daf28e119349155d36e30a9bcf61b2e7d5
|
|
|
|
|
|
| |
Squid is not the only possible CDN
Change-Id: Ie2a2955847c5706e630322bbbab71c9d063b378f
|
|
|
|
|
|
|
|
|
|
| |
* Using addUpdate() makes sure purges are coalesced and
de-duplicated.
* Also removed incosistent $wgUseSquid checks. If CDN caching
is not used, then $wgSquidServers will just be empty anyway.
Bug: T119016
Change-Id: I8b448366f037f668385d252f9d68289b71d1a707
|
|
|
|
| |
Change-Id: I0d4c21be1356216970d9ad424ffc848f82778e50
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Specify null as allowed value to make this method more easy to use.
The method is often used like that already and this makes it official.
Previously we were on a months-long trajectory to try and remove all
instances of passing null, but it was a never-ending quest (with new
ones introduced all the time). And in all cases the added handling
in the caller is the same as the handling for when this method
returns null. Requiring the caller to bounce null makes code more
complex, duplicates logic and serves no reason. Let this method be
a non-throwing validation method that returns null if given null.
Bug: T76305
Change-Id: I47517021471ac6fd6daca6deee039c8047224a33
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the new system introduced in
1c57794e371d74e1d88748de567a1c3358c3ad2e (see T47843).
This change allows Title::getUserPermissionsErrors() to include
MessageSpecifiers instead of string message keys in its return value.
This doesn't seem to have any bad effects, and should work seamlessly as
long as callers aren't trying to do anything stupid and just pass the
value to PermissionsError or OutputPage::showPermissionsErrorPage()
or wfMessage() or some such.
If the callers *are* trying something stupid, nothing worse than
duplicated or otherwise less-than-perfect error messages (in code
which tries to handle some message keys specially) should happen.
(I fixed wfMergeErrorArrays(), but who knows what else lurks in all
this code.) Any problems should only affect new-style errors using
MessageSpecifier, though.
Since MessageSpecifiers tend to be stringable, we probably won't get
fatals, but might get incorrect checks. Should we try to log this
happening somehow?
Goes with I42a0c5b0ea7e61088dd609b764dd7d1396c60cd5 in TitleBlacklist.
Bug: T115258
Change-Id: I1334ba21a2862973a9d8ff5be2c9bec06a82698b
|
|
|
|
|
|
|
| |
It is deprecated for public use, so indicate that it should only be used
privately.
Change-Id: I1b32f52f427a36ddb81bd7befadc9099ebc4f191
|
|
|
|
|
|
| |
There is no need for such words
Change-Id: I0294c0e2381b96fd4377d7edcdf4d7e7fc0d06d3
|
|
|
|
|
|
|
|
| |
None of these places need it to happen right now,
so for performance and consistent style, defer
them too.
Change-Id: Id0a2a352bfc04a783c3ebc54b059b241bb6a6f7e
|
|
|
|
|
|
| |
Follows-up 6b0163391.
Change-Id: I7c45e1968b6ba8db0e5b19b8ca819e6ecc5764c9
|
|\ |
|
| |
| |
| | |
Change-Id: I98e44cdffb0fc0d729f69f702799139afb988c20
|
|/
|
|
| |
Change-Id: I420998351663d92c4a101f61842e40591eebcd5f
|
|
|
|
|
| |
Bug: T102614
Change-Id: Iae4d4fbdba88ebcd9bcb018a2a0015d0c0ac607c
|
|
|
|
| |
Change-Id: I048ccb1fa260e4b7152ca5f09b053defdd72d8f9
|
|
|
|
| |
Change-Id: Ie05be75b3e1a20e241206fdae8d1496fcbffeaae
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Not special page cannot be invalid redirect target
Change-Id: Ie8cc0c9717963472bdaf5b9d143938bd05bef6ba
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This allows them to be stored in the session, for example.
Note that properly serializing a Message requires that all its
parameters be serializable as well; we don't attempt to account for that
here.
Change-Id: I3a42a2a883e8eef900eeb02355fc3b064411f642
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
strtr() is marginally faster as it runs through the string only
once. A better fit for one-for-one character translation.
The strtr() function also supports an associative array as second
parameter for entire string replacements. This, too, has the same
performance and predictable behaviour (starts with the longest key).
Whereas str_replace is for more aggressive needs where you want
multiple passes until there are no further matches.
The associative array form is arguably also easier to understand
and harder to mess up since the needle/replacement pairs are
explicitly connected instead of two separate arrays.
Also:
* Use getFormattedNsText instead of strtr( getNsText, .. ) which
reduces duplication of this fact through a more semantic intent.
Change-Id: Ie23e4210a5b6908dd79eebc8a2b931d12fe31af6
|
| |
| |
| |
| |
| |
| |
| | |
Anomie pointed out that I am the only person who writes it as "? :", and
that all other instances in core use no space.
Change-Id: I01b68eed5f866fa7582fb4257f795c4c2d1244d1
|