Language::markNoConversion is used only within Parser.php and differs
from LanguageConverter::markNoConversion in that, contrary to its name
and its namesake, it only protects *things which look like URLs* from
language conversion.
This wasted several days of my time before I realized what was going on.
It's needless; just hoist the "looks like a URL" special casing inline
to the single place where that functionality is used. (And I wonder
if the "looks like a URL" case is actually needed at all any more,
since most of those cases are probably free external links, which
go through a different code path, not bracketed external links.)
This is a clean-up to the clean-up that liangent performed in 2012
with e01adbfc0b.
Change-Id: I80479600f34170651732b032e8881855aa1204d8
Selectable sort orders were added to search some time ago, but never
appear to have been used. Expose them in ApiQuerySearch.
There is one large problem here, but it's not easily solvable.
Specifically supported sort orders vary per search engine, but the
available api parameters are calculated with the default search
engine. This is already a problem with search profiles so it's
nothing new, just continuing the existing problem. Much like
search profiles we hide the functionality when multiple engines
are available.
Bug: T195071
Change-Id: I187a530bc973c08386d2c2126e02a85b952d9022
Using 'trash' icon instead of misleading 'clear' and changing 'remove'
to 'delete' accordingly.
Bug: T191530
Change-Id: I8369977df5cdf0dca63683bc682e470223cf6fed
See comment in I3423011c467b0a6426cfa0dad522435618f24bd0
and https://mathiasbynens.be/notes/javascript-unicode#poo-test
Decided on using something more positive than a pile of poo though.
Change-Id: Ic34d0d78044cede71fd1cd8742214c117ed2e99f
This was using the same content for the edit before this
patch, so no edit was actually made, (just a null edit).
Change-Id: I945090647226e82f22b5b10a414a2a0bf9f2bc19
Having randomly generated strings is great, but sometimes
it can help to allow a human to easily see where the string
is actually being generated in code, so add an optional suffix
to the string being generated.
Change-Id: Ibfe45f74b4880a70a76c01223a787dabcd43607e
I have run into this before and we fixed it in the README
but not in this script (I wasn't using this script at the time)
This was changed in the README in change:
I85a9e7dbd9a66418c85585969adb5ac1548f5ef6
Bug: T182421
Change-Id: I6ab92c6a61a57dc313b05321d0789dcbeb776c94
git bash for windows apparently doesn't have killall
by default, so instead get the PID of the chrome driver
we start and kill that specifically.
Change-Id: I8a9a773a7d3dc23807dc3ec12f5b3ef03661c9e3
The getConverterLanguage() method was added in March 2012 in commit
561424c266 as a workaround for a regression
in mediawiki 1.19. It was an indirection which checked the global variable
$wgBug34832TransitionalRollback to return a different converter language
for Chinese wikis.
When this temporary bugfix was reverted in January 2013 in commit
a3fbdaaa2c, the temporary global variable
was removed, but not the getConverterLanguage() indirection. Since then,
new code in the parser seems to have faithfully used getConverterLanguage()
instead of getTargetLanguage(), even though they are identical and the
need for getConverterLanguage() has long since passed.
Strike a small blow for elegant minimalism by removing the completely
unnecessary Parser::getConverterLanguage() indirection. Well, sort
of: since this blight has been slowly growing inside Parser.php for
so long, we need to deprecate getConverterLanguage() first just in
case any external dependency has been infected. Next release we
can finally excise the unnecessary method.
Change-Id: I567c29c9c7699020955699b76cbe8578d02e2fe6
This file is a disaster, but now at least we actually wrap at 80 chars
for all the hooks, not just the ones where the developer felt like it.
Change-Id: I10d3d51412af29b135fd7e9a0393ff0b57eb25aa
Many of these are still soft-deprecated, so tracking down their age
and kicking off the full deprecation process is hard, let alone
actually removing them. Doing this makes that future work easier.
Change-Id: Ib096190accceabf9082f621ba96243f7dedb025d
When jobs are being run synchronously post-send, we don't want to allow
bugs to result in a job somehow setting cookies or headers that
interfere with those that were intended to be set in the request.
Bug: T191537
Change-Id: Ib5714a17af417797140f99e41eaacbba1bfd20f4
We've noticed a large increase in deadlocks between
LinksDeletionUpdate deleting categorylinks rows and
Category::refreshCounts() trying to update the category table.
My best guess as to what's going on there is that LinksDeletionUpdate
locks the category row via the call to WikiPage::updateCategoryCounts()
then the categorylinks rows via its own deletions, while Category first
locks the categorylinks rows (in share mode) and then the category row
when it tries to update or delete it.
To break the deadlock, let's have Category do a SELECT FOR UPDATE on the
category row first before it locks the categorylinks rows.
Bug: T195397
Change-Id: Ie11baadf2ff0ba2afbc86b10bc523525c570a490
Previously it would affect all actions that use Title::userCan.
This used to be less noticable, but recently was expanded to include
the 'read' action. This only affected the case where both
$wgBlockDisablesLogin and $wgEmailConfirmedToEdit were enabled.
I don't think anyone was relying on the old behaviour as it was
undocumented, and only affected obscure permissions (checked with
Title::userCan and not depending on "edit" rights)
Follow-up b675be2083
Bug: T143790
Change-Id: I4ad93ed78de4f1ed444f73df6dc26d405a67e553
