Page MenuHomePhabricator

Can't import Module:xxx/documentation due to content type mismatch
Closed, InvalidPublic

Description

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:

Details

Reference
bz59194

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:41 AM
bzimport set Reference to bz59194.
bzimport added a subscriber: Unknown Object (MLST).

jacob.jose wrote:

Screenshot attached

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.

TheDJ added a comment.Jan 2 2014, 11:14 AM

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:

  1. rename or
  2. forcefully use source wiki name or
  3. skip the specific template only (not stop import process altogether) when "include all templates" option is chosen.

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..

TTO added a comment.Jan 6 2014, 4:34 AM

(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:

  1. More en.wiki templates now use Lua and ml.wiki relies on en.wiki templates to translate them and use in ml.wiki as new articles are created
  2. As newer templates are imported to ml.wiki, it has started affecting the user experience and lot of users are complaining.. eg: https://ml.wikipedia.org/wiki/%E0%B4%B5%E0%B4%BF%E0%B4%95%E0%B5%8D%E0%B4%95%E0%B4%BF%E0%B4%AA%E0%B5%80%E0%B4%A1%E0%B4%BF%E0%B4%AF:%E0%B4%AA%E0%B4%9E%E0%B5%8D%E0%B4%9A%E0%B4%BE%E0%B4%AF%E0%B4%A4%E0%B5%8D%E0%B4%A4%E0%B5%8D_(%E0%B4%B8%E0%B4%BE%E0%B4%99%E0%B5%8D%E0%B4%95%E0%B5%87%E0%B4%A4%E0%B4%BF%E0%B4%95%E0%B4%82)#.E0.B4.B8.E0.B5.8D.E0.B4.95.E0.B5.8D.E0.B4.B0.E0.B4.BF.E0.B4.AA.E0.B5.8D.E0.B4.B1.E0.B5.8D.E0.B4.B1.E0.B5.8D_.E0.B4.AA.E0.B4.BF.E0.B4.B4.E0.B4.B5.E0.B5.8D
  3. The wiki is at crossroads on whether to stop importing further templates until this bug is fixed or continue to merge the new changes in templates and hamper the user experience even further

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.

TTO lowered the priority of this task from Medium to Lowest.Aug 1 2015, 5:13 AM

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.

Quiddity added a subscriber: Quiddity.

If I understand correctly, the issue at mlwikis has been fixed, therefore I will remove that tag.

Quiddity removed a subscriber: Quiddity.Mar 14 2017, 6:42 AM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptSep 10 2019, 8:11 PM
Jdforrester-WMF closed this task as Invalid.Apr 15 2020, 1:52 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

wgContentHandlerUseDB has been deprecated as of MediaWiki 1.34 and removed as of MediaWiki 1.35.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptApr 15 2020, 1:52 PM