Last modified: 2014-09-25 12:56:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35973, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33973 - Make moved css/js pages not fail on parse error due to "#REDIRECT"
Make moved css/js pages not fail on parse error due to "#REDIRECT"
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
1.20.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
https://pt.wikipedia.org/w/index.php?...
:
: 27509 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-26 20:15 UTC by Helder
Modified: 2014-09-25 12:56 UTC (History)
4 users (show)

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


Attachments

Description Helder 2012-01-26 20:15:08 UTC
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.
----
Comment 1 Helder 2012-02-11 19:57:22 UTC
*** Bug 27509 has been marked as a duplicate of this bug. ***
Comment 2 Krinkle 2012-07-22 03:05:44 UTC
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.
Comment 3 Gerrit Notification Bot 2014-09-25 12:56:53 UTC
Change 162491 had a related patch set uploaded by He7d3r:
Support redirects in JavaScriptContent

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

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


Navigation
Links