Last modified: 2011-03-13 18:06:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14899 - When __INDEX__ and __NOINDEX__ both occur, the last one in the source should win
When __INDEX__ and __NOINDEX__ both occur, the last one in the source should win
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 8068
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-23 19:58 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2011-03-13 18:06 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-23 19:58:22 UTC
Currently (r37973) when __INDEX__ and __NOINDEX__ both occur on the page, the page is indexable, regardless of the order or the number of times they appear.  This is because in line 3386 of Parser.php, I only check whether $this->mDoubleUnderscores has the appropriate indexes.  By this point we don't know which one came first.  It wasn't immediately obvious to me how best to fix it -- how do __NOTOC__ and __FORCETOC__ work?  It's not a big thing, so I figured it didn't need to block the new feature.
Comment 1 Tim Starling 2008-07-25 11:01:10 UTC
I'm not sure why you think this is worth doing. The resulting code would be quite a bit more complicated.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-25 14:03:01 UTC
It seems to me that the current way of doing it is less intuitive.  I would certainly expect the last one in the page to win.  If it's complicated to do this with our current setup (and you would know that better than I), I guess it's not worth doing in the foreseeable future.

It seems __NOTOC__ and __FORCETOC__ work the same, at a glance, with __FORCETOC__ always overriding __NOTOC__.  It would be nice if some mechanism could be added to get this to work more nicely, but there are probably better things to do, yeah.  Don't see any reason to close the bug, though.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links