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
Message::__toString() used the same formatting mode that the last
explicit transformation used:
$msg = new Message( 'foo' );
echo $msg; // escaped
echo $msg->plain();
echo $msg; // not escaped
This is not particularly useful and makes code review hard, so let's
get rid of it.
The same behavior with $msg->toString() is left intact (and logged)
for now.
Bug: T146416
Change-Id: Ia9b2a1dcf09d52348b2c6d8299fd849b809f6e74
To accomplish this, the responsibility for setting the HTTP status code
in the response is moved to ApiFormatBase.
This also adds a line to the pretty-printed response and to ApiSandbox's
output to indicate the status that would be used.
Bug: T150344
Change-Id: Iaf0698ee1b93565d9b02b5a9aa8f93ceb135658b
Apperently something went wrong when manual rebasing
If5909f7a16c98504e78388a5ea6c26196f82cd12 and went unnoticed.
Change-Id: Icf8964b0fa0857a44814df3bb11eaf2907e9af56
This is also mainly done so they can be better utilized when
extending the EditPage class.
Bug: T143823
Change-Id: Id592c9ffa60dc6a904da7ce514e19954125c8ee5
This change resulted in unreasonable feature loss (human-readable
limit report was gone). Three months and multiple followups later,
the functionality is still not completely restored. Given lack
of response from the original author, I think it is time to revert
and reconsider, especially since the 1.28 release is soon.
A machine-readable limit report would be a very useful feature,
but not at the cost of losing human-readable limit report.
This reverts the following commits:
* Move NewPP limit report HTML comments to JS variables
b7c4c8717f
* Only pretty-print the parser report JS vars
28adc4d7ee
* Show wgPageParseReport on page previews too
1255654ed5
* Re-add human readable parser limit report
0051f108b9
* Restore hooks.txt for ParserLimitReportFormat
4663e7a737
Resolved minor merge conflicts in OutputPage (with 80e5b160)
and release notes.
Bug: T110763
Bug: T142210
Change-Id: Id88c8066fae3f369e8977b4b7488f67071bdeeb7
