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

Krinkle <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Normal                      |Low
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---
   Target Milestone|1.21.0 release              |Future release
           Severity|major                       |minor

--- Comment #3 from Krinkle <[email protected]> ---
This is still a valid use case. Just because it can't be fixed right now
doesn't mean it should not be fixed or stay as a longer-term reminder.

Re-opening.

(In reply to comment #1)
> [..] With $wgContentHandlerUseDB=true the move would
> work, but the page would still be interpreted as JS internally.

Nah, that's not an implementation that would fix this bug, it would mask the
fact that it stays javascript and would probably not break anything since we
interpret js/css as raw.

When moving a page we should look if content models are compatible and/or
convertible. If compatible, it should move straight (with
wgContentHandlerUseDB=false, no other changes needed. with
wgContentHandlerUseDB=true we'd have to update the per-page/revision record).

If not compatible but convertible we can probably show a warning (like we
already do for possibly unintended actions, such as moving to an existing page
name), and if accepted move it and convert it in a new revision.


(In reply to comment #2)
> with $wgContentHandlerUseDB=true, conversion could be done
> as an edit, creating a new revision

Why would that only be possible with that variable enabled? Afaik that should
work fine but with and without per-page determination.

-- 
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to