Account creation messages don't need to be parsed. This is
a temporary fix to follow up when double-parsing was accidentally
added in 69ea440003 (I402c6bebcfe).
Bug: 44718
Bug: 52191
Change-Id: I333d5468820994625348316ebf6c57d4df025284
Also split 2 tests off into their correct test classes,
this methods are clearly no longer global functions
Change-Id: I482433f3099e72507a766e85d9576ff36e58b9ad
The regular expression in the linkprefix message is run against the
entire page up to each wikilink, and is expected to capture one group
having everything except the prefix and another having only the prefix.
For long pages this winds up being a lot of text, so inefficient regular
expressions are going to cause problems.
The current regex is this:
/^(.*?)([a-zA-Z\\x80-\\xff]+)$/sD
This is not efficient: it will scan through the string trying to match
against every run of one or more letters/non-ASCII characters,
backtracking at every one except possibly the last. The only reason this
hasn't been a huge problem everywhere is because only a few languages
have this feature enabled.
This change replaces this with this regex:
/^((?>.*(?<![a-zA-Z\\x80-\\xff])))(.+)$/sD
This is rather more efficient: it will grab the whole string (which is
actually fast even for huge strings), then back off character by
character until it finds one that isn't a letter/non-ASCII.
Note that the above could be simplified somewhat:
/^((?>.*[^a-zA-Z\\x80-\\xff]|))(.+)$/sD
The performance improvement here is minor, and Gujarati, Church Slavic,
Udmurt, and Ukrainian would still need the other style for their current
implementations.
For Gujarati, we also use another regex trick: a look-behind assertion
in PCRE must be fixed length, so something like (?<!a|bb) won't work.
But that regex fragment is equivalent to (?<!a)(?<!bb) which is allowed,
so we use that instead.
Bug: 52865
Change-Id: Iaa7eaa446b3f045a9ce970affcb2a889f44bdefd
* Use $.toJSON rather than JSON.stringify. Make mediawiki.inspect depend on
jquery.json.
* Firefox doesn't define a console.table, but doesn't throw an exception either
if you attempt to invoke it. Use Function.prototype#call to call Firefox's
bluff.
Change-Id: Ib45487d10488f08a98d9635ab9a2a9212e9ef69f
Within Special:RecentChanges the default non-extended query contains
( rc_this_oldid=page_latest OR rc_type=3 )
Wikidata has previously used the SpecialWatchlistQuery hook to look for
this exact string and change rc_type=3 to rc_type IN (3,5). Flow is another
type of change that doesn't have a matching row in revisions to match
page_latest for and needs to be added to this query.
This patch adds a new hook, SpecialWatchlistGetNonRevisionTypes, which allows
different extensions to add to a list of values for rc_type (or rc_source once
85787 is merged). This will allow multiple extensions to affect the resulting
query without them breaking eachother.
Change-Id: Id6916fe999c0faa38de878b7b5687e7ea00901bd
It's possible that a wiki could introduce new protection levels that
should be considered "semiprotected". For example, if an
"emailconfirmed" protection level were added and an appropriate entry
were made in $wgAutopromote, that might be considered semi-protection
since anyone can automatically gain the ability to edit those pages
merely by setting and confirming their email address.
The most straightforward way to take care of this is to add a config
variable to specify which protection levels are considered
"semiprotected". So let's do that.
Also, let's take the opportunity to make
$title->isSemiProtected( 'create' ) works correctly.
Bug: 43462
Change-Id: Ic9db6ff6cbd84bd9734be09efbea5a5891197fa0
It's elitist mathematical jargon. In all cases dealt with here, it adds
no additional meaning compared to "if", beyond what was already obvious
from context. Thus, its only purpose is to smugly demonstrate that the
author attended their second-year mathematics classes, at the expense of
causing confusion for everyone who doesn't have such a background.
If you really think you need to convey extra information beyond what
"if" gives you, the English language contains plenty of devices for doing
so, without resorting to neologisms.
Change-Id: Iae21095d02ec2935c10e94f532235c2671c115b1
One class of errors left unaddressed: Class name "WebInstaller_Language"
is not in camel caps format. I think this can be changed, too, but I
wasn't able to quickly find out where class names are being created.
Change-Id: I920b0231db1b70b68c6c8907257c288a0e112668
Regression from If758499f. Trailing dot was being removed
for genitive forms instead of abbreviated forms.
Bug: 56038
Change-Id: I353da785ff4a1203ae54a981c3c946f9df452902
- Give methods scope
- Make providers static
- Add @covers todo
- Merge the Providers file that is only used in here
Change-Id: I60a6bbd5a8ad3d9d414de493ec2b083f52114a7b
The parser unnecessarily made individual checks for existence of
pages that were neither in LinkCache nor linked only with a fragment.
A Title::isKnown() call in Parser::replaceInternalLinks2() (added in
bca8b8ad7d) caused this.
Title::isKnown() was used to avoid treating a link to a distinct page
as a self-link even when the title happened to match one of the variants
returned by Language::autoConvertToAllVariants(). This change fixes
the bug by moving the problematic portion of the self-link check into
LinkHolderArray::doVariants().
Change-Id: I586e11e8b47308980ea04087ebc4246c397a8f53
The current implementation of Linker::formatTemplates only checks for
"sysop" and "autoconfirmed", and completely ignores any other protection
levels. That needs fixing.
Rather than introducing additional messages "template-protected-*" to
match template-protected and template-semiprotected, let's just use the
existing restriction-level-foo messages and wrap them in parentheses.
The old messages are kept for backwards compatability, but could
probably be considered deprecated.
Bug: 43462
Change-Id: I0c507f4ecc1921f599acbda834fa55e96388fa7b
The fallback to master makes sense in Revision::newFromId(), since a
revision ID known to exist by some other means might be present in the
master but not in the slave. But it doesn't make sense for
Revision::newFromTitle(), where by far the most common cause of this
case being hit is the page being nonexistent.
Change-Id: I41189fcde1b8065ac134982241376d63b78732a1
Due to the PHP serialization, the Redis native INCR and INCRBY do not
work. This instead falls back on the parent class's incr, which uses
lock and unlock, and incrementing on the PHP side.
Bug: 55986
Change-Id: I500199aeb935963ca118fde163bd7ba0cba8f79f
* Also reduced rount trips in doUnlockingRequestBucket().
* Also removed some redundant doc comments.
Change-Id: I81878e92332509bd7fda9ddeef950b774f5b015d
This change:
- Adds method scope
- adds @covers tags
- adds various @todos
- fixes some comments
Before the changes tests ran with:
1383 tests, 1412 assertions 10 skips
After changes the results remain the same
Change-Id: Iee57447bdb47026952ef5dcce6fed5dad0f80e52
Without this fix the callers of this function could not read the
failure code and result, because we returned undefined. Because
we are using a filter function, we need to explicitly return the
promise to pass it forward.
Change-Id: I71984ac827618459f723b0b9f47d4dc29e2a2f70
Follows-up 55dac1f which errounously changed a few <html:msg />
to <html:msg> while trying to fix up <span/></span>.
Bug: 40598
Change-Id: I987fa288cc1b97a8a5fb367aae2626d7d0b48238
