Last modified: 2011-02-19 20:19:16 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 27539 - some pagelist parameters are no longer passed to the extension
some pagelist parameters are no longer passed to the extension
Product: MediaWiki extensions
Classification: Unclassified
ProofreadPage (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Sean Colombo
: code-update-regression
Depends on:
Blocks: 27339
  Show dependency treegraph
Reported: 2011-02-18 16:00 UTC by Philippe Elie
Modified: 2011-02-19 20:19 UTC (History)
3 users (show)

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


Description Philippe Elie 2011-02-18 16:00:30 UTC
tags <pagelist > accepted parameters of the form 1to10=roman to specify attribute value applying to a range of page, some change in attribute name sanitizing break this feature, see #17031. While 17031 state it increase the possible attribute names, it also decrease them in some case. As extension tag are not valid xml anyway, I don't see why we would apply such restriction to extension attribute name.
Comment 1 ThomasV 2011-02-18 16:09:37 UTC
the problem seems to come from here:
Comment 2 Platonides 2011-02-18 22:09:35 UTC
So it seems. <pagelist > tag is provided by ProofreadPage extension.

The attributes passed to tags are obtanied with Sanitizer::decodeTagAttributes() which in turn uses the regex modified by r70849.

I think we can modify the regex to also accept attributes beginning with digits. It seems used just for wiktiext processing, so we can be more liberal than HTML.
Comment 3 Sean Colombo 2011-02-19 01:13:04 UTC
Would be a simple fix.. just add "0-9" inside the brackets in the $attribFirst variable if we want to allow that.

Alternatively, we could just set $attribFirst = $attrib for now and let anarchy reign ;)

It's nice right now to have a spec that the rules conform to, but Platonides makes an interesting point that this is wikitext, not HTML.  Alternatively, I could see the argument that since we basically took the syntax for parser-tags from XHTML syntax, that we should just use that standard as much as possible.

I'm not sure which is best. If we want to leave it xml compliant, it shouldn't be hard to rename that parameter in &lt;pagelist> and have a bot replace all instances of the old param with a new, valid name.

Both fixes are pretty easy.  Anyone else have opinions?
Comment 4 ThomasV 2011-02-19 10:49:58 UTC
XML compliance is a great idea, but it should have been decided right from the beginning. Here we have a major regression that affects thousands of pages, I think it should be fixed asap; we do not have time to organize a debate on XML compliance.

I suggest that for now, we go for your first suggestion (add "0-9"). If it later  turns out that we need to comply with XML syntax, we will have to fix the wikitext of thousands of pages simultaneously, and educate users about the new syntax; a pretty heavy process, since Wikisource users have been using this syntax for years.
Comment 5 Sean Colombo 2011-02-19 19:26:51 UTC
I'm convinced.  Committed r82475 to phase3.  Will that get released to production automatically or is there a branch I should merge this to?
Comment 6 Platonides 2011-02-19 19:45:11 UTC
It needs to be tagged as 1.17wmf1 (and probably 1.17 too). But I wouldn't have added . and - to begin an attribute. I will remove them if you don't mind.
Comment 7 Platonides 2011-02-19 20:19:16 UTC
Done in r82480

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