Page MenuHomePhabricator

Make moved css/js pages not fail on parse error due to "#REDIRECT"
Closed, ResolvedPublic

Description

This is a followup for bug 31827 (and bug 30074).

From bug 31827 comment 5:

Why not actually making redirects work in css and js pages? Is there anything that makes this fundamentally more complicated than other cases? By now we're using redirects for pages, images, templates, and it all works seamlessly.


Version: 1.20.x
Severity: enhancement
URL: https://pt.wikipedia.org/w/index.php?title=MediaWiki:Wikibugs.js&oldid=28517012
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34930

Details

Reference
bz33973

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:07 AM
bzimport added a project: MediaWiki-Redirects.
bzimport set Reference to bz33973.
bzimport added a subscriber: Unknown Object (MLST).
He7d3r created this task.Jan 26 2012, 8:15 PM
  • Bug 27509 has been marked as a duplicate of this bug. ***

The wikitext content of a redirected page is #REDIRECT[ [ target page ] ]. That is how it is and how it should be, and there is absolutely nothing wrong with that.

The main reason why that should say as-is, is so that when viewing the page normally, the redirect is followed (whether or not that is currently happening is a separate issue).

When dealing with ResourceLoader wikipage modules, the redirects can (and should) be omitted because in that case we're not dealing with wikitext but with a page on the server side. And that was fixed in bug 30074.

When dealing with action=raw the incentive is to get the raw wikitext, so that should not be modified for the same reason. Bots and scripts expect the response of action=raw to match the wikitext, and that should not be altered, regardless of whether or not the pagename ends with ".js" or ".css".

I think an exception could be made for ctype=text/javascript and ctype=text/css, which is why I re-opened bug 31827.

(In reply to comment #0)

Why not actually making redirects work in css and js pages? Is there anything
that makes this fundamentally more complicated than other cases? By now we're
using redirects for pages, images, templates, and it all works seamlessly.

Because contrary to all of the above, CSS and javascript are not Wiki-specific
objects. They are native scripts interpreted by the browser - while at the same
time being an ordinary wikipage that should be editable, watchable, and...
redirectable (when viewing normally).

Marking this bug "won't fix" because we don't want to change the wikitext of redirects regardless of whether or not the filename edits with .js. They should behave just like any other wiki page.

Though usage of raw user scripts (as opposed to modules, whether or not originating from gadgets) should decline - I know non-authorized users can't create gadgets, this is a feature request for Gadgets 3.0 - we can make this work. See bug 31827.

Change 162491 had a related patch set uploaded by He7d3r:
Support redirects in JavaScriptContent

https://gerrit.wikimedia.org/r/162491

Restricted Application added subscribers: Luke081515, Aklapper. · View Herald TranscriptJul 21 2015, 4:21 PM

Change 225709 had a related patch set uploaded (by Paladox):
Implement redirects in CssContent

https://gerrit.wikimedia.org/r/225709

Change 225709 merged by jenkins-bot:
Implement redirects in CssContent

https://gerrit.wikimedia.org/r/225709

Legoktm closed this task as Resolved.Jul 30 2015, 11:03 PM
Legoktm claimed this task.