https://bugzilla.wikimedia.org/show_bug.cgi?id=62856
--- Comment #22 from MWJames <[email protected]> --- > In the meantime, I'm slating https://gerrit.wikimedia.org/r/#/c/105829/ for a > revert. Could one of you verify that reverting that code fixes this problem? Thanks, finally I was able to track the relevant change that introduced the changed behaviour. > Could one of you verify that reverting that code fixes this problem? Yes, running the mentioned integration test passes again on MW 1.23 after reverting the change. > it appears that SMW depends on some undocumented behavior of MW. Whether documented or undocumented, it still doesn't explain the difference in behaviour of Parser::parse() and ContentHandler::getParserOutput() which at least should behave consistently. > I still believe that since the #REDIRECT line shouldn't be being parsed it > shouldn't be included in the wikitext passed to the parser; if it were being > passed to Parser::parse() If this is the intend behaviour for Parser::parse() and ContentHandler::getParserOutput(). > It would make more sense to me that the redirect target be included as > metadata somehow, which probably means storing it in the ParserOptions. Would > that work for you? If Parser::getOptions() by the time InternalParseBeforeLinks hook is called does contain information such as being a redirect page/has target page for the selected revision, I would see no problem to use that instead of doing ContentHandler::makeContent( $text, null, CONTENT_MODEL_WIKITEXT )->getRedirectTarget() or Title::newFromRedirect( $text ) manually during the InternalParseBeforeLinks hook. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
