Last modified: 2013-04-22 16:15:43 UTC
docs/contenthandler.txt says: * Javascript and CSS pages are no longer parsed as wikitext (though pre-save transform is still applied). Most importantly, this means that links, including categorization links, contained in the code will not work. But IMHO this is too important to just note it down as caveat, and should be fixed, since parsing those pages as wikitext and storing the links in the tables etc. has several impotant use cases, that now break (see also bug 32858): * __INDEX__ / __NOINDEX__ should work for all pages * js/css pages should appear in categories: ** some wikis might organize their user scripts using categories (ok, this is an argument not to parse them, as it forces users to write documentation and categorize these instead) ** speedy deletion templates should put the pages in the right category, it's much easier to find such a template than a page to ask for help by sysops * backlinks are used to find users who are using a certain script (the German documentation on [[de:Wikipedia:Technik/Skin/JS#Laden_.C3.BCber_den_Titel_einer_Seite]] suggests this, english: [[User:js]], Krinkle uses global file usage for this: [[m:User:Krinkle/Scripts/InsertWikiEditorButton]]) Knowing who uses your script is not just nice, but important, I use this regularily: ** Inform users about major changes ** Find out if somebody is using a feature you want to deprecate ** For scripts that do some automatic editing: Find out if there are bugs the users didn't report (you might not believe it, but there are users who accidentaly edit "Undefined", "Null", ... but don't tell the author of the script about this) * Since PST are applied users have to use <nowiki> anyway, so they can decide which parts should be parsed. * The last time js/css pages weren't parsed, this provided an easy way to circumvent Extension SpamBlacklist, see [[mw:Special:Code/MediaWiki/105664#c27321]] for the details.
Not parsing JS/CSS was a conscious decision made after getting feedback from the MediaWiki core team. It can be revised, but I'm not going to do that unilaterally. I'll write a mail to wikitech-l. About he baclkins: Backlinks as such work, and are completely unrelated to whether the page itself is parsed or not. However, since links on JS pages don't work, backlinks from JS pages don't work either. Can you provide an example of how scripts are usually "used" by users? What'S the exact syntax? Template inclusion? Something based on wiki links? I'll look into what would be required to enable wiki parsing of scripts, and perhaps propose a patch. But as I said, I'd like to see it discussed first.
(In reply to comment #0) > * The last time js/css pages weren't parsed, this provided an easy way > to circumvent Extension SpamBlacklist, see > [[mw:Special:Code/MediaWiki/105664#c27321]] for the details. Maybe this is resolvable by rejecting transclusion from pages in another content type?
(In reply to comment #1) > About he baclkins: Backlinks as such work, and are completely unrelated to > whether the page itself is parsed or not. However, since links on JS pages > don't work, backlinks from JS pages don't work either. Can you provide an > example of how scripts are usually "used" by users? What'S the exact syntax? > Template inclusion? Something based on wiki links? A typical line in User:X/common.js is importScript('User:Name/script.js'); //[[User:Name/script.js]] Then you could see all users using your script at Special:WhatLinksHere/User:Name/script.js as User:X/common.js is in that list. This no longer works, as the link in the comment in User:X/common.js is no longer treated as link, and thus not stored in the table as a backlink to User:Name/script.js.
Ah(In reply to comment #3) > A typical line in User:X/common.js is > importScript('User:Name/script.js'); //[[User:Name/script.js]] Ah, I see - a Wiki link in a comment is used to generate the backlink. Neat. Actually, parsing only JS *comments* as wikitext would be a nice solution - but would take more work than I'm currently ready to invest. I have wr4itten to wikitech-l about this. No response so far: <http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/063909.html>
(In reply to comment #0) > * backlinks are used to find users who are using a certain script > (the German documentation on > [[de:Wikipedia:Technik/Skin/JS#Laden_.C3.BCber_den_Titel_einer_Seite]] > suggests this, english: [[User:js]] > Krinkle uses global file usage > for this: [[m:User:Krinkle/Scripts/InsertWikiEditorButton]]) > Knowing who uses your script is not just nice, but important, > I use this regularily (In reply to comment #4) > Ah(In reply to comment #3) > > A typical line in User:X/common.js is > > importScript('User:Name/script.js'); //[[User:Name/script.js]] > > Ah, I see - a Wiki link in a comment is used to generate the backlink. Neat. > Like // [[File:Krinkle_RTRC.js]] * https://meta.wikimedia.org/wiki/User:Krinkle/Tools * https://meta.wikimedia.org/wiki/User:Krinkle/Tools/Real-Time_Recent_Changes * https://commons.wikimedia.org/w/index.php?title=Special:GlobalUsage&target=Krinkle_RTRC.js All gadgets combined: http://krinkle-tools.grizzdesign.nl/KrinkleSausage.php (slow) Marking as high priority regression for 1.21. All hot drama aside, this is a very frequently used feature that ContentHandler just broke out of core without any discussion. Okay, thought it was a minor bug that could be fixed along the way, a simple mistake to make. But as we know now it is very much not a bug (maybe originally, but it has become an irreplaceable feature that until actually replaced, must not be removed).
(In reply to comment #5) > Marking as high priority regression for 1.21. > > All hot drama aside, this is a very frequently used feature that ContentHandler > just broke out of core without any discussion. Okay, thought it was a minor bug > that could be fixed along the way, a simple mistake to make. But as we know now > it is very much not a bug (maybe originally, but it has become an irreplaceable > feature that until actually replaced, must not be removed). In my defense, I did discuss this with some people, though not on the mailing list. Actually, I think it was also in one of the mails with questions I had about the ContentHandler design, but never got any answer. And there was a reason there was a big XXX comment on the relevant code when I first submitted it for review. Seems like nobody looked at that. Anyway, I'll post a fix. Should be simple enough. Have to fix a fatal exception first, though.
Fix submitted: I0736f158
Note: the fix provided causes the script to be parsed and the links to be placed in the database. However, categories and interlanguage-links do not get shown on the page. If this is not desired, please file that as a separate issue.
(In reply to comment #8) > Note: the fix provided causes the script to be parsed and the links to be > placed in the database. However, categories and interlanguage-links do not get > shown on the page. If this is not desired, please file that as a separate > issue. Annoying as it is, this was already the case prior to ContenHandler.
(In reply to comment #9) > Annoying as it is, this was already the case prior to ContenHandler. I hope then nobody will complain if I fix it later ;)
(In reply to comment #6) > (In reply to comment #5) > > Marking as high priority regression for 1.21. > > > > All hot drama aside, this is a very frequently used feature that ContentHandler > > just broke out of core without any discussion. Okay, thought it was a minor bug > > that could be fixed along the way, a simple mistake to make. But as we know now > > it is very much not a bug (maybe originally, but it has become an irreplaceable > > feature that until actually replaced, must not be removed). > > In my defense, I did discuss this with some people [..] Sure, by all means. You're not to blame. It looked like a bug, and if it weren't for the hacky undocumented usecases that evolved over time, it was a good fix to make :)
