Page MenuHomePhabricator

Special:Import fails poorly if ContentHandler models don't match
Closed, InvalidPublic


I'm not sure if this is a Scribunto problem or a something else problem, but I tried to use Special:Import to move a module from test2wiki, and I got the following error:

Import failed: No handler for model 'Scribunto'' registered in $wgContentHandlers

My test settings were:


Copy all
Destination all
comment: test import.

No entry is created in the import log. However, a broken page is created at the destination saying:

The revision #0 of the page named "Headnote" does not exist.
</p><p>This is usually caused by following an outdated history link to a page that has been deleted.
Details can be found in the <a class="external text" href="//;page=Module:Headnote">deletion log</a>.

And it won't let one save anything to the page, instead giving a bogus edit conflict that can't be resolved. The broken page can be removed using page deletion.

The import log does show that some Module pages were imported previously (abotu two weeks ago), so maybe this is a recent problem, or maybe my specific request is triggering it in some way.

Version: 1.21.x
Severity: major
See Also:



Event Timeline

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

The general cause is a version incompatibility. In order to properly support the auto-transclusion of /doc subpages, Scribunto's page handling was changed from "generic wikitext with an overridden display function to do it completely differently" to using ContentHandler with a new page type. test2 was updated yesterday, but enwiki won't be until next week.

But Special:Import shouldn't be creating a broken page like that, no matter what else is going on. So I'm going to poke this bug in that direction.

I had the same error and stumbled here. I've downloaded MW 1.21.0rc5, and started to export few templates from id.wp (notably string manipulations), but received the error. I've installed all the bundled extensions (minus two) plus the Scribunto extension.

Disregarding the effect on what I was trying to do, I concluded that from now on, people cannot (easily) export and import some very useful templates from the WMF projects that uses Scribunto to be used on previous installations of MW, thus making lives harder for some people who have to upgrade their sites. Please point me if the effect of Scribunto on non-WMF installations has been discussed and weighed before, because now I think that the way the Wikipedia templates have been used (exported/imported) should not have been "overwritten" with Scribunto (Modules) scripts...

The second thing is, Scribunto should be included in the bundled extensions from now on, because it's become integral part of how complex templates are handled in Wikipedia and other projects. (heck, there should be a list of "core" templates in the future releases!)

  • Bug 51504 has been marked as a duplicate of this bug. ***

stefan wrote:

If just tried to import the Module/doc file

  • exported from Wikipedia/en (This file: Module:HtmlBuilder/doc)
  • tried to import to Wikivoyage/de

got this error:

"Import fehlgeschlagen: Can't save non-default content model with $wgContentHandlerUseDB disabled: model is wikitext , default for Modul:HtmlBuilder/doc is Scribunto"

TTO changed the task status from Open to Stalled.Oct 10 2015, 4:46 AM
TTO added a subscriber: TTO.

When importing a Flow board to my local test wiki that does not have Flow installed, I see the error message Import failed: No handler for model 'flow-board' registered in $wgContentHandlers. The actual page doesn't get imported at all - no row is inserted into the page table at all. This seems like the correct behaviour to me.

Setting this to "Stalled" for now. If you think there is still something worth fixing here, please leave a comment.

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

wgContentHandlerUseDB has been deprecated as of MediaWiki 1.34 and removed as of MediaWiki 1.35. Consequently, I'm going to speculatively close this as Invalid.