https://bugzilla.wikimedia.org/show_bug.cgi?id=34930

MZMcBride <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Handling of .js and .css    |Handling of .js and .css
                   |pages post rename           |pages post page move

--- Comment #3 from MZMcBride <[email protected]> 2012-06-29 22:50:23 UTC ---
The user rename issue is a red herring. The issue here is that after a page
move, CSS and JS redirects behave in a very funky way. I changed the summary
from "Handling of .js and .css pages post rename" to "Handling of .js and .css
pages post page move".

A few parts to this. Behavior is user moves a JS/CSS page from one title to
another using MediaWiki page move form. This leaves behind a redirect (by
default).

Redirect's current behavior is broken by the page's syntax highlighting, which
assumes that everything in the text area of a page ending in .css or .js is CSS
or JS. (This bug might be a duplicate.)

Problems with not redirecting:
* it's annoying as hell that the redirects don't work as you'd expect them to

Problems with redirecting:
* redirects can't easily be edited
** still usually need an admin account to do any edits due to the redirect page
titles still ending in .css/.js and getting special protection for it
*** users editing their own personal .css/.js pages shouldn't hit this issue
** bots trying to fix double redirects hit walls
* sets up a false expectation about following these redirects programmatically,
maybe?
** not sure what behavior is here nowadays with ResourceLoader

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to