| kaldari | |
| Dec 14 2014, 2:36 AM |
| F21150: Screen_Shot_2014-12-13_at_6.18.31_PM.png | |
| Dec 14 2014, 2:37 AM |
| F21152: Screen_Shot_2014-12-13_at_6.18.53_PM.png | |
| Dec 14 2014, 2:37 AM |
This might be a WONTFIX, but we should at least decide whether or not this is desired behavior. Previously, when an edit was submitted via the API with \r characters as EOL markers, they were parsed as such. Recently, this changed and \r characters are now effectively ignored. Do we want to:
Looks like something called HotArticleBot keeps fudging-up the wiki mark-up's table syntax.
Note the |- ''table row'' tag keeps getting lumped in with end of the previous line instead of being on its own line. It just looks like it is starting its own line in the revision diff but obviously its not.
Here's an example of a currently misrendered page
Has this problem been only seen on en.wikipedia or also on other sites?
Sounds on-wiki according to last comment?
Text contains \r which is not rendered correctly.
Someone should inform the bot maintainer to change this and mediawiki should reject or replace with \n when doing a (api) edit?
It was working fine previously with \r (since September 2013). None of the bot code has changed. Something in our API or editing code must have changed recently. I'll retitle the bug...
It turns out this has nothing to do with the API. What changed recently is that, along with the change from Zend PHP to HHVM, we also changed from using Preprocessor_DOM to Preprocessor_Hash. And it turns out that the former replaces \r with \n, while the latter does not.
Change 180021 had a related patch set uploaded (by Anomie):
Normalize "\r" newlines in preSaveTransform
Change 180022 had a related patch set uploaded (by Anomie):
Normalize newlines before calling preprocessor
@Anomie: Rather than modify both the PST and Scribunto (and probably other places in the future), why not just change Preprocessor_Hash to have the same behavior as Preprocessor_DOM?
I considered that, but since we already have partial newline normalization in Parser::preSaveTransform I decided to just fix that.
