Last modified: 2013-04-22 16:14:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42908, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40908 - ContentHandler renders Scribunto nonoperational
ContentHandler renders Scribunto nonoperational
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Scribunto (Other open bugs)
unspecified
All All
: Highest critical (vote)
: ---
Assigned To: Nobody - You can work on this!
: code-update-regression, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 00:09 UTC by Victor Vasiliev
Modified: 2013-04-22 16:14 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Victor Vasiliev 2012-10-10 00:09:40 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.
Comment 1 Sam Reed (reedy) 2012-10-10 00:10:39 UTC
Have you tried with $wgContentHandlerUseDB set to false? (This is going to be the case for WMF wikis)
Comment 2 Victor Vasiliev 2012-10-10 00:12:51 UTC
(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).
Comment 3 Andre Klapper 2012-10-10 22:22:20 UTC
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.]
Comment 4 Victor Vasiliev 2012-10-10 22:29:54 UTC
(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).
Comment 5 Tim Starling 2012-10-11 10:15:34 UTC
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.
Comment 6 Daniel Kinzler 2012-10-11 14:13:56 UTC
Note that I8963c968 also prevents any wikitext parsing/processing on the page. Which is probably the right thing, as far as I understand.
Comment 7 Sumana Harihareswara 2012-10-12 14:38:29 UTC
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.
Comment 8 Victor Vasiliev 2012-10-12 14:57:14 UTC
(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.
Comment 9 Sumana Harihareswara 2012-10-12 15:00:57 UTC
(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?
Comment 10 Victor Vasiliev 2012-10-12 15:02:25 UTC
(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.
Comment 11 Sumana Harihareswara 2012-10-12 15:35:51 UTC
OK, yeah, that's pretty terrible. Marking this as blocking deployment.
Comment 12 Daniel Kinzler 2012-10-12 15:42:41 UTC
Should be fixed by I8963c968
Comment 13 Tim Starling 2012-10-14 23:27:57 UTC
Merged.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links