Author: jacob.jose
Description:
Screenshot
While attempting to import Module:xxxx/doc, gives following error
Import failed: Can't save non-default content model with $wgContentHandlerUseDB disabled: model is wikitext, default for Module:xxxx/doc is Scribunto.
This error has been observed on both ml.wikipedia and ml.wiktionary
Version: 1.23.0
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45750
Attached:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T61194 Can't import Module:xxx/documentation due to content type mismatch | |||
| Resolved | Anomie | T148137 Deprecate $wgContentHandlerUseDB |
Hi, what exactly is the request here? To enable $wgContentHandlerUseDB on ml.wikipedia and ml.wiktionary?
[Moving to "Wikimedia" product as this request is about settings / configuration of the website, not about the codebase of MediaWiki itself.]
The documentation for a module have to stay on the page which is defined with message 'scribunto-doc-page-name'.
En.wp has set that to /doc, while ml.wp has a translated word there. A import does not change the name of a page, therefor the import does not work, because the content model is mixed.
Try import to to another namespace or as user sub page (set destination root page to User:Jacob.jose) and move the page after import to the correct name along to 'scribunto-doc-page-name' on ml.wp.
Perhaps we should add an option to the import form, to rename a page when this error occurs ?
(In reply to comment #4)
Perhaps we should add an option to the import form, to rename a page when
this
error occurs ?
Imports can also contains more than one page (for example when importing templates) this can be difficult when you can change the name of the page, see bug 6808 (in special bug 6808 comment 9).
jacob.jose wrote:
I suggest you add an option to either:
If not, the import process with multiple templates breaks once it hits a doc template and errors eventually pop up due to incomplete import of required modules..
(In reply to comment #2)
[Moving to "Wikimedia" product as this request is about settings /
configuration of the website, not about the codebase of MediaWiki itself.]
This seems like a bug in MediaWiki's import system.
Ideally, you would be warned when importing a page with the wrong content type. You would get an option to either proceed with the import (implicitly converting the content type perhaps? this may be needed if the source wiki is misconfigured?), or else to enter a new destination title for the page with the wrong content type, so it gets imported to a place where it is allowed.
jacob.jose wrote:
Could this be fixed? It has been around 7 months and the problem still exists. eg: Try importing Module:Location map/doc to ml.wiki and you will get "ഇറക്കുമതി പരാജയപ്പെട്ടു: Can't save non-default content model with $wgContentHandlerUseDB disabled: model is wikitext, default for ഘടകം:Location_map/data/USA/doc is Scribunto". Now that most templates have moved to modules, this bug is creating a lot of problems in ml.wiki !
[reverting last priority change, as nothing has happened that would suddenly make this a higher priority.]
Could this be fixed?
In theory most bugs could be fixed, but somebody needs to write the code. See https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker for information. Might make sense for any contributor to concentrate on fixing bug 45750 first.
jacob.jose wrote:
The reason why it is high priority now:
Due to above, may I request to change the priority to high?
jacob.jose wrote:
The immediate high priority issue has been resolved and involved lack of namespace conversion in Module:Location map. So let's keep the priority normal.
Pulling down to lowest priority. This issue is no longer occurring on WMF wikis now that $wgContentHandlerUseDB has been set to true. The setting is still present in MediaWiki, however, so other installations may be faced with this issue.
If I understand correctly, the issue at mlwikis has been fixed, therefore I will remove that tag.
wgContentHandlerUseDB has been deprecated as of MediaWiki 1.34 and removed as of MediaWiki 1.35.