Topic on Extension talk:Scribunto

I have an old wiki farm running MediaWiki 1.23 - we have an appropriate version of this extension working as far as I can tell, using LuaJIT, but one part doesn't seem to be working - the page content handler isn't processed even though the content model is set correctly (shows up as 'Scribunto' in JS), and the end result is that Module: pages are displayed as one line of text, without formatting, even though in the source you can see it formatted.

Has anyone else encountered this? Perhaps it could be a known [old] issue interacting with another extension, of which we have many? (I don't fully understand the code, but it seems to be trying to override the parser, and there's probably other stuff doing that too.)

Obviously upgrading to MW 1.35+ is a target of ours, but it will take some time to prepare and we have people who want to work on importing Wikipedia's Lua-dependent templates.

Mmm, I see what you mean.

Shot in the dark, but one difference I note, when comparing your wiki's Special:Version (my word that's a lot of extensions!) and enwiki's is the lack of a Pygments version (in the "Installed software" block at the very beginning). Since I would expect Pygments to be involved in syntax-highlighting the code listing, I wonder if perhaps that's part of the issue? (Does content using the CSS or JS model show up with correct formatting?)

Nice idea, but in fact the reason you don't see Pygments is that SyntaxHighlighter only switched over to that in 2015, for REL1_26, whereas we're on REL1_23.

SyntaxHighlight lang="lua" works as well, on a normal page. The CSS/JS functionality seems to require TemplateStyles, which I believe only became available in MW 1.27 (at least, that is the first branch in its repo). However, CSS is available as a SyntaxHighlight language and works. It seems to be just not hooking in.

Ah, didn't realize Pygments support was that "new"!

When I asked about CSS or JS, I was referring to the display of pages like wikifur:MediaWiki:Common.css and wikifur:MediaWiki:Common.js, to verify that they _were_ formatting properly. But I see that they are, so we can reasonably expect Module-namespace pages to, as well.

(Ah, right, syntax highlighting used GeSHi back then! As the HTML source for https://en.wikifur.com/wiki/MediaWiki:Common.css just reminded me.)

This feels like a PHP issue, to me. Seems like Scrbunto/includes/common/ScribuntoContent.php (assuming it was at the same path, way back when) isn't being run, despite the content model being correctly set on the page. I'd recommend trying the steps in Manual:How to debug for enabling PHP errors and extra logging, see if you can figure out why the extension isn't formatting the code.

I'm confused, too, though I'm sure there's a perfectly logical explanation, possibly linked to our esoteric wiki-farm setup with shared code. I did get debug comments working, and it looks like it knows what the right handler is:

[caches] main: APCBagOStuff, message: APCBagOStuff, parser: APCBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
Unstubbing $wgParser on call of $wgParser::setHook from ExtDynamicPageList::setupDPL
Parser: using preprocessor: Preprocessor_DOM
LocalisationCache::isExpired(en): cache for en expired due to GlobalDependency
LocalisationCache::recache: got localisation for en from source
Connected to database 0 at localhost
DatabaseBase::query: Writes done: DELETE FROM `msg_resource`
Fully initialised
Title::getRestrictionTypes: applicable restrictions to [[Module:Arguments]] are {edit,move}
[ContentHandler] Created handler for Scribunto: ScribuntoContentHandler
IP: x.x.x.x
MessageCache::load: Loading en... got from global cache
Article::view using parser cache: no
Article::view: doing uncached parse
Unstubbing $wgLang on call of $wgLang::getDatePreferenceMigrationMap from User::getDatePreference
Title::getRestrictionTypes: applicable restrictions to [[Module:Arguments]] are {edit,move}

I tried taking out all the extensions that unstubbed $wgParser early, as that's been an issue before [DPL, nicecategorylist, stubmanager, piclens, randominclude], but it didn't have any obvious impact beyond the relevant message.

Yeah, that's really all I've been able to come up with so far. I realize it isn't very helpful, sorry about that. Perhaps someone else with a better memory of older MW configs will turn up, and be able to provide more information.