In action=help this is reflected by the "Type" field, but that field
isn't displayed in ApiSandbox.
Change-Id: I7e491acc8ba7fdc3463f3cf1656b13fb3949d7d3
According to T150455#2789277 it shouldn't be able to allow 'max' even
though this is a mostly-numeric field with one non-numeric value.
Oh well.
Change-Id: I620a233aab20c715db354eff77ea8a3ffee3bc77
An A-type hash is an unsalted hash. A B-type hash is a salted hash of
the form md5(salt "-" md5(password)). So it's not correct to have an
A-type hash with a salt. User::comparePasswords() and
CentralAuthUser::getPasswordFromString() already get this right, they
generate :B: prefixes for legacy salted hashes where the salt is not
specified in the database.
Change-Id: Icb809274f9f63641e54daf98332a5646fd58b550
Added for use in the CategoryTree extension to show the category count
on the special page, see If3815586c2a280b4e8958c13010c9f7436b8723d
Change-Id: If195fb55dee1350a6de095892ce89e6565287cd9
I came looking for a test with comments inside transclusions
because of bug T89615. I could only find a test for Parsoid
and not for PHP, so I added it.
Bug: T89615
Change-Id: I4ee3bc75ec86cc6fde6449790b81d287f0ca8345
This is a direct follow up to my comments in Ia6ec10d.
Relevant for T146416 are the two messages I added. They explain why these
assertions are duplicated.
assertEquals behaves bogus when used with strings, especially when used
with formatters and parsers, which is the case here. For example,
assertEquals( '9a', 9 ) succeeds. assertEquals is useful when comparing
objects.
Bug: T146416
Change-Id: Ie8df41b3ce6678f3add55bab6701b56b66447a2e
Assert that they don't begin with 'api.php?'.
Change-Id: Idf5e8e08863a379a37a427a11936e5f9ce567396
Depends-On: I8a82eecefbb0ba327d8e8bc24ec535bcf40e6429
Depends-On: I476aad09655a2822381a2c61690b4b0ad423151e
5bd6de6 converted CryptRand to use the logger command but kept the
newlines in the message which is needed for wfDebug() but not with the
logger interface.
Patch also removed a call to wfGetAllCallers() from the first debug
message of generate(), leaving an uneeded debugging message.
Hence we had output such as:
---
[CryptRand] Generating cryptographic random bytes for
[CryptRand] mcrypt_create_iv generated 20 bytes of randomness.
[CryptRand] 0 bytes of randomness leftover in the buffer.
---
Drop the newlines from all debug message.
Drop the lonely debug message from generate().
Result:
---
[CryptRand] mcrypt_create_iv generated 20 bytes of randomness.
[CryptRand] 0 bytes of randomness leftover in the buffer.
---
Change-Id: I572206296fc3a0a498febb18925672a67480eb18
