Last modified: 2014-05-27 17:39:24 UTC
I created a page MediaWiki:Group-sysop.js somewhere and then found out I accidentally named it .js instead of .css. It used to be possible to rename it, but no longer: (Special:MovePage) > You do not have permission to move this page, for the following reason: > The desired destination uses a different content model. Can not convert from JavaScript to CSS.
I don't see a way to resolve this in a general and reliable fashion with $wgContentHandlerUseDB=false. With $wgContentHandlerUseDB=true the move would work, but the page would still be interpreted as JS internally. (also, $wgContentHandlerUseDB=true needs expensive schema updates). There is no good way to know that *.js can safely be re-interpreted as *.css (which wouldn't really be true anyway). So we'd have to at least call Content::convert() on the JS text to get CSS. But Title::moveTo doesn't even load the revision content. It just manipulates the page table. How should old revisions be treated anyway? Should they be converted? That would mean updating the associated text blob... no. That can't be good. As far as I understand, you want to re-interpret the content (not convert). I suppose the best way to do this is using copy&paste. I'm closing that as wontfix for now, since it's not really a bug that can be fixed in a concise manner. It's rather a nasty edge case caused by the current system design. We'd need to come up with a good concept of how to understand and handle this use case, and develop a feature request for implementing that solution.
(another side note: with $wgContentHandlerUseDB=true, conversion could be done as an edit, creating a new revision).
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.
(In reply to comment #3) > 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. Yea, I would just have suggested to have a separate entry on bugzilla for that. This is not a bug to fix but a feature to design. > 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). It's unclear what "compatible" means, or in what sense JS and CSS are "compatible". They are already considered convertible. But just re-interpreting content without giving the handler the chance to adjust it seems wrong to me. > 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. Showing warnings from the move operation is not currently possible. Adding it isn't hard, but would probably break B/C for extensions calling Title::moveTo. > (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. Because with $wgContentHandlerUseDB=false, the older revisions would also get the new content model, without actually being converted.
I just tried moving [[MediaWiki:Common.js/sandbox]] to [[MediaWiki:Common.js/sandbox.js]] but got the same error still. > You do not have permission to move this page, for the following reason: > The desired destination uses a different content model. Can not convert > from wikitext to JavaScript. This is very annoying. If the feature to avoid bad moves is not working properly, perhaps we should disable it until it is at least not blocking genuine actions (perfectionism aside, this is not a feature request but a bug, a regression at that). Or perhaps allow sysops to override it?
*** Bug 53115 has been marked as a duplicate of this bug. ***
(Cite bug 53115 comment #4) > I'm cleaning up an old script page in the Wikipedia Project-namespace > (Wikipedia:FooBar) but unable to do a rename to MediaWiki:FooBar.js > > This seems an unnecessary and unproductive restriction. They're both plain > text models that have no conversion or abstraction layer. This used to be possible. Now we have to resort to copy/paste moves with no history preservation? By the way, this is additionally annoying because users in the "Edit interface" user group[1] have the permission to deal with protection and moving, but not deleting. Where normally I can move a page belonging in the MediaWiki namespace to it (suppressing redirect of course, since #REDIRECT is invalid js/css), I now have to resort to copy/paste moves and leaving the old page behind (maybe blanking it or asking a sysop to clean it up, which is a waste of time and only requires additional duplication of efforts and explanation). [1] https://meta.wikimedia.org/wiki/Global_editinterface
