Last modified: 2014-11-18 18:07:26 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 10422 - Render sitewide css/js pages as normal wikitext
Render sitewide css/js pages as normal wikitext
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 10425 16269 (view as bug list)
Depends on: 10410
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-01 00:11 UTC by Tisza Gergő
Modified: 2014-11-18 18:07 UTC (History)
7 users (show)

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


Attachments

Description Tisza Gergő 2007-07-01 00:11:44 UTC
Until recently, sitewide css/js pages were parsed as normal pages, so that wiki formatting could be used in them. These pages are often quite large, with parts of them being maintained by different people; being able to link to the maintaner's user page and to structure them using sections and a table of content helped a lot in managing them. So please return to parsing them as normal wiki pages. (The syntax highlight is nice, but it can be also achieved by manually putting <source> tags around code.)
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-01 03:12:47 UTC
I just changed site JS to work like user JS, which seemed more logical at the time, but it could just as easily be done the other way around.  There are, however, unexpectedness issues with allowing all wikitext, basically related to the fact that for the purposes of actually parsing the code all wikitext will be totally ignored, so people will undoubtedly get confused at their templates not seeming to work.  Also, if people don't bother with initial spaces or <pre>s, the code on the page will come out all munched up by the HTML renderer.

Bug 10410 suggested we allow wikilinks, and this bug also suggests that headings are useful.  That perhaps suggests a limited subset of wikitext, but that can get messy fast.

Another thought is to detect block comments and treat their contents like normal wikitext, and leave the code itself <pre>'d and run through GeSHi or whatever.  But we probably don't want to catch inline comments, which should display normally with the code, so then we have to introduce heuristics to catch block comments, which will also get messy.

Overall it might be best to go with this bug's suggestion and just make it pure wikitext as it was until recently, relying on sysops to be clever enough to get it to display more or less properly.  User code pages should be changed to match, however, I think.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-01 08:45:53 UTC
*** Bug 10425 has been marked as a duplicate of this bug. ***
Comment 3 Rémi Kaupp 2007-07-01 09:10:47 UTC
On users' CSS/JS pages, it makes sense to wrap the whole code in <pre> tags, as they can be used by unexperienced users. However, site-wide CSS/JS can be pretty long and is usually modified only by experienced users, so parsing wikitext is really useful in this case.
Comment 4 Tisza Gergő 2007-07-01 09:25:49 UTC
Maybe a magic word like __USEWIKICODE__ could be used to switch from <pre> to normal display?
Comment 5 Tisza Gergő 2007-07-01 14:06:51 UTC
Allowing this for user subpages might pose some security risk, as it can be used to hide malicious code in HTML comments or invisivble divs. Then again, most people probably wouldn't check the code either way...
Comment 6 Huji 2007-07-01 15:39:49 UTC
There is another problem with the colorized versin of JS pages: With long JS pages, like Lupin's Popups JS, the high amount of colorizing etc on the page makes Firefox (and perhaps other browsers) to take a longer time to render the page. In one case, my browser hanged on Lupin's page as well. I think there should be a way to at least stop this code colorizing option on such long JS pages.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-01 19:07:17 UTC
(In reply to comment #3)
> On users' CSS/JS pages, it makes sense to wrap the whole code in <pre> tags, as
> they can be used by unexperienced users. However, site-wide CSS/JS can be
> pretty long and is usually modified only by experienced users

On large wikis . . . I suspect most users with custom CSS/JS more than a couple lines long are more proficient in the language than the maintainers of a fair number of wikis' site CSS/JS.  I'll just let it be wikitext, it's not going to be a problem if a few people have HTML-munched code on their user subpages as a result.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-01 21:07:00 UTC
Done in r23617 (see also r23618).
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-02 01:17:47 UTC
*** Bug 10432 has been marked as a duplicate of this bug. ***
Comment 10 Brion Vibber 2007-07-02 19:41:55 UTC
Reopening this, needs to be WONTFIXed and reverted.

JS and CSS code renders as illegible crap when just passed through the wiki renderer, which is why it was <pre>d up in the first place. The consistent behavior needs to be fixed up and restored.

It might additionally be nice to render links within that, though, as previously noted on other bugs.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-02 23:25:30 UTC
Reverted in r23657.
Comment 12 Rémi Kaupp 2007-07-03 18:59:11 UTC
While I understand Brion's motives, this still prevents section editing on large CSS pages such as [[:fr:MediaWiki:Common.css]], which is very convenient. Allowing section editing and links would answer most concerns, I reckon.
Comment 13 Tisza Gergő 2007-07-03 19:06:15 UTC
I still think that using <pre>/<source> by default, and displaying as wikitext if a magic word is found would solve all the concerns brought up here.
Comment 14 Alexandre Emsenhuber [IAlex] 2009-12-15 15:50:53 UTC
*** Bug 16269 has been marked as a duplicate of this bug. ***
Comment 15 Helder 2011-01-09 17:23:43 UTC
(In reply to comment #12)
> While I understand Brion's motives, this still prevents section editing on
> large CSS pages such as [[:fr:MediaWiki:Common.css]], which is very convenient.
> Allowing section editing and links would answer most concerns, I reckon.

There is a workaround on English Wiktionary for section headings:
http://en.wiktionary.org/wiki/MediaWiki:JavascriptHeadings.js

For an example, take a look at
http://en.wiktionary.org/wiki/MediaWiki:Common.js

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


Navigation
Links