r89706 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r89705‎ | r89706 | r89707 >
Date:22:28, 7 June 2011
Author:platonides
Status:resolved (Comments)
Tags:post1.18deploy, tstarling 
Comment:
Reinstate r79122 (fix for bug 14404), reverting r83868. The real bug seem to have been r86131, fixed in r88902 (1.17) and r88902 (1.18).
This is not merged with the r86131 change to Article::getParserOptions() since I don't see the point for the new function yet.
Reenabled its test ArticleTablesTest which was disabled in r85618
Modified paths:
  • /trunk/phase3/includes/Article.php (modified) (history)
  • /trunk/phase3/tests/phpunit/includes/ArticleTablesTest.php (modified) (history)

Diff [purge]

Index: trunk/phase3/tests/phpunit/includes/ArticleTablesTest.php
@@ -5,9 +5,7 @@
66 * @group Destructive
77 */
88 class ArticleTablesTest extends MediaWikiLangTestCase {
9 - /**
10 - * @group Broken
11 - */
 9+
1210 function testbug14404() {
1311 global $wgUser, $wgContLang, $wgLanguageCode, $wgLang;
1412
Index: trunk/phase3/includes/Article.php
@@ -63,7 +63,7 @@
6464 var $mTouched = '19700101000000'; // !<
6565
6666 /**
67 - * @var ParserOptions
 67+ * @var ParserOptions: ParserOptions object for $wgUser articles
6868 */
6969 var $mParserOptions;
7070
@@ -3541,7 +3541,7 @@
35423542 $edit->revid = $revid;
35433543 $edit->newText = $text;
35443544 $edit->pst = $this->preSaveTransform( $text, $user, $popts );
3545 - $edit->popts = $this->getParserOptions();
 3545+ $edit->popts = $this->getParserOptions( true );
35463546 $edit->output = $wgParser->parse( $edit->pst, $this->mTitle, $edit->popts, true, true, $revid );
35473547 $edit->oldText = $this->getRawText();
35483548
@@ -4329,12 +4329,23 @@
43304330
43314331 /**
43324332 * Get parser options suitable for rendering the primary article wikitext
4333 - * @return ParserOptions object
 4333+ * @param $canonical boolean Determines that the generated options must not depend on user preferences (see bug 14404)
 4334+ * @return mixed ParserOptions object or boolean false
43344335 */
4335 - public function getParserOptions() {
4336 - global $wgUser;
4337 - if ( !$this->mParserOptions ) {
4338 - $this->mParserOptions = $this->makeParserOptions( $wgUser );
 4336+ public function getParserOptions( $canonical = false ) {
 4337+ global $wgUser, $wgLanguageCode;
 4338+
 4339+ if ( !$this->mParserOptions || $canonical ) {
 4340+ $user = !$canonical ? $wgUser : new User;
 4341+ $parserOptions = new ParserOptions( $user );
 4342+ $parserOptions->setTidy( true );
 4343+ $parserOptions->enableLimitReport();
 4344+
 4345+ if ( $canonical ) {
 4346+ $parserOptions->setUserLang( $wgLanguageCode ); # Must be set explicitely
 4347+ return $parserOptions;
 4348+ }
 4349+ $this->mParserOptions = $parserOptions;
43394350 }
43404351 // Clone to allow modifications of the return value without affecting cache
43414352 return clone $this->mParserOptions;

Follow-up revisions

RevisionCommit summaryAuthorDate
r97091FU r89706: Cleaned up getParserOptions duplication problemsaaron19:57, 14 September 2011
r97173Merged revisions 97087,97091-97092,97094,97096-97098,97100-97101,97103,97136,...dantman16:19, 15 September 2011
r97206Follow up r89706, building up on r97091....platonides21:09, 15 September 2011

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r36093Some tweaks to the {{int:...}} parser function:...ialex17:57, 9 June 2008
r36185Revert r36093 (bug 14404)....brion02:51, 11 June 2008
r79121Add failing test for bug 14404.platonides18:43, 28 December 2010
r79122Fix bug 14404. The articles are now always saved with the default options....platonides18:44, 28 December 2010
r83868Revert r79122, causes bug 27891 (old version seen immediately after edit).tstarling04:26, 14 March 2011
r85618Various fixes for PHPUnit tests:...pcopp14:54, 7 April 2011
r86131* Pass around parser options instead of users and made some parser options co...aaron18:40, 15 April 2011
r88902Merge r87235 to 1.17, fix will have to go in 1.18.btongminh16:57, 26 May 2011

Comments

#Comment by Aaron Schulz (talk | contribs)   20:12, 21 June 2011

The process cache logic of getParserOptions() is confusing at first look.

#Comment by Platonides (talk | contribs)   20:23, 21 June 2011

It's actually skipping the cache if requesting the canonical parser options.

#Comment by Aaron Schulz (talk | contribs)   20:24, 21 June 2011

Right.

#Comment by 😂 (talk | contribs)   18:09, 24 June 2011

Opaque booleans aren't nice. Make it a string and pass 'canonical' or something.

#Comment by Tim Starling (talk | contribs)   06:37, 2 September 2011

The introduction of makeParserOptions() in r86131 does appear to have a point after r89124, and it seems like this revision could benefit from it too, since makeParserOptions(new User) would be a lot more readable than getParserOptions(true). This revision seems to sabotage it, by duplicating its content and exposing it to bit rot, negating the point of moving it out of FlaggedRevs in the first place.

The commit message is incorrect, presumably you mean "the real bug seems to have been in r72475". It's true that r72475 broke ChronologyProtector, but this change (i.e. r79122) made the bug a lot worse, causing it to break regular edits rather than just page creations. If there is any problem with ChronologyProtector in the future, then with this change in place, the same severe problem will recur.

For users with non-default parser options, this revision will cause the page save time to increase by a factor of two. For instance, it currently takes 40 seconds to parse the Barack Obama article; with this change, users with non-default options will have to wait 40 seconds for the redirect plus 40 seconds for the page view, before they are able to verify their edit and interact with the page. I'm not sure if bug 14404 is severe enough to warrant such a huge hit to apparent site performance.

#Comment by Platonides (talk | contribs)   21:19, 3 September 2011

I will take a look at r86131 + r89124. I didn't expect to wait so much for that feedback. :)

Yes, the first r86131 is wrong. Seems it didn't correctly copy the r72475 and pasted another revision I had in the clipboard.

We try to move the time of the second parsing to 0, so that few people would have incompatible parser options. Although it can still be improved, there's work to do.

#Comment by Aaron Schulz (talk | contribs)   19:13, 26 September 2011

Any idea how often user parser options will be incompatible with canonical ones when editing?

Status & tagging log