Last modified: 2013-04-22 16:14:33 UTC
Whenever I enter a module page, the exception is thrown about an unknown content type. I will introduce proper content handler soon, but right now this blocks ContentHandler from being deployed on Scribunto-enabled wikis.
Have you tried with $wgContentHandlerUseDB set to false? (This is going to be the case for WMF wikis)
(In reply to comment #1) > Have you tried with $wgContentHandlerUseDB set to false? (This is going to be > the case for WMF wikis) $wgContentHandlerUseDB is irrelevant to the problem (tested).
Tim / Victor: Does someone of you have time to investigate this in the next two days, or in case this cannot be worked around / fixed soon, any opinions how to proceed? Would you consider it acceptable if 1.21-wmf2 on Monday was without Lua/Sribunto support, or should this issue block deployment? [Setting tentative "Highest" priority.]
(In reply to comment #3) > Tim / Victor: > Does someone of you have time to investigate this in the next two days, or in > case this cannot be worked around / fixed soon, any opinions how to proceed? > Would you consider it acceptable if 1.21-wmf2 on Monday was without > Lua/Sribunto support, or should this issue block deployment? > > [Setting tentative "Highest" priority.] Right now merging <https://gerrit.wikimedia.org/r/#/c/27399/> *should* be (by "should" I mean "I have not done extensive testing") sufficient in order for everything to work as intended (I'm currently working on proper ScribuntoContent support).
This is because Scribunto hooks TitleIsWikitextPage to make modules not be wikitext. Previously, TitleIsWikitextPage only affected EditPage::getPreviewText() and WikiPage::isParserCacheUsed(). ContentHandler extended the meaning of $retval=false from that hook to cause the content model to switch from "wikitext" to "text", however due to a flaw in ContentHandler, "text" was not usable and generated an exception. I8963c968 should be a sufficient fix.
Note that I8963c968 also prevents any wikitext parsing/processing on the page. Which is probably the right thing, as far as I understand.
Given that Scribunto is a beta extension that's so far only deployed on mediawiki.org and test sites, I'm of the opinion that this is not a blocker to Monday's deployment.
(In reply to comment #7) > Given that Scribunto is a beta extension that's so far only deployed on > mediawiki.org and test sites, I'm of the opinion that this is not a blocker to > Monday's deployment. The issue here is that Monday deployment will happen in the places where Scribunto is deployed.
(In reply to comment #8) > The issue here is that Monday deployment will happen in the places where > Scribunto is deployed. Yes, but my understanding is that Scribunto's usage is still confined to testers and experimenters, and a showstopper that stops Scribunto from operating at all, while unfortunate, won't throw all of mediawiki.org into chaos. Will it? Are there important templates, or lots of templates, on mediawiki.org that are now written in Lua and/or functioning via Scribunto?
(In reply to comment #9) > (In reply to comment #8) > > > The issue here is that Monday deployment will happen in the places where > > Scribunto is deployed. > > Yes, but my understanding is that Scribunto's usage is still confined to > testers and experimenters, and a showstopper that stops Scribunto from > operating at all, while unfortunate, won't throw all of mediawiki.org into > chaos. Will it? Are there important templates, or lots of templates, on > mediawiki.org that are now written in Lua and/or functioning via Scribunto? By "rendering nonfunctional" I mean "throwing exceptions in the whole namespace". I am not sure if deploying code which causes exceptions when even viewing a page is a good idea.
OK, yeah, that's pretty terrible. Marking this as blocking deployment.
Should be fixed by I8963c968
Merged.
