Extension talk:Scribunto

Jump to navigation Jump to search

About this board

  • This page uses "Flow".
  • It has most recently started discussions at the top.
  • The page loads dynamically, meaning you can't tell how much more you will see when you scroll down
SANtosito (talkcontribs)

I'm trying to make syntax highlighting working in modules but apparently sth is missing. I have installed WikiEditor, SyntaxHighlight, CodeEditor and have done everything as said in manual. All installed extension are working , just seems it dosen't work with Scribunto, so I guess the problem must be sth else

wfLoadExtension( 'WikiEditor' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'CodeEditor' );

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['key'] = 'value';

$wgScribuntoUseGeSHi = true;

$wgScribuntoUseCodeEditor = true;

http://escforumwiki.com/index.php?title=Module:Documentation

WikimeSteve (talkcontribs)

I do not see a solution and outcome here. I am having the same issue. We do not have CodeEditor installed though. Is that required?

Syntax highlighting is working on all other pages as expected. With the following should we see module syntax highlighting or do we need anything else?

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['key'] = 'value';

$wgScribuntoUseGeSHi = true;

wfLoadExtension( 'WikiEditor' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'Scribunto' );


Update: I just copied the Lua code from a Module window. Pasted it into a blank page and surrounded it with <syntaxhighlight lang="Lua">. When I click show demo it was all nice and colorful and matches how it looks on the same module on Wikipedia. So our SyntaxHighlight seems fine. The Module view just does not show it on our Wiki.

Reply to "Syntax highlighting not working"

How to disable Scribunto error logging

4
Latisc (talkcontribs)

Is there any way to keep Scribunto from logging errors into /dev/null? I don’t want to keep an enormous log file on my server. I tried putting $wgScribuntoEngineConf['luastandalone']['errorFile'] = null; in LocalSettings.php, but that didn’t solve the problem.

Rayanth (talkcontribs)

Unless you have an extremely bizarre setup, /dev/null by definition takes up no space - anything routed to /dev/null is deleted by the OS. Think of it as an empty void things get sent to, to remove them from existence.

Latisc (talkcontribs)

Is there still any way I can turn off error logging?

Anomie (talkcontribs)

The way to turn it off is to write it to /dev/null.

Jeblad (talkcontribs)

There are no real explanation on how to uninstall this extension. It can be fairly dangerous to do so, and it can be wise to advice against it on a production system, but a description exist in a previous revision. This explanation is later removed, so use it at your own peril.(diff)

Anomie (talkcontribs)

Note that the same can apply to other extensions, Scribunto isn't particularly special in this respect. Anything that adds a new content model can give issues when removed, as can other things in some cases (e.g. T212742). Even when actual exceptions don't arise, you can easily be left with strange unformatted log entries.

We seem to generally not "officially" post instructions telling people to manually mess around with their databases to try to fix things, as it's easy to make things worse when doing so.

Jeblad (talkcontribs)

Not providing uninstall instructions is pretty bad. I guess all extensions that create new content models should have a warning about corruption of the database if the extension is removed.

And no, I don't do what anyone claim to be “official”, I do what I believe is right.

Anomie (talkcontribs)

Note there's no "corruption of the database" going on. The problem is that removing the extension removes the handler for the perfectly valid data left behind in the database, so attempting to access that data results in an error about the missing handler for the content model.

I'm well aware that you do what you believe is right. Most people do, even if their beliefs conflict with objective reality. (NB: I don't think there's an objective reality in this particular situation, just tradeoffs between different considerations)

Jeblad (talkcontribs)

You are the objective reality? Good to know.

Anomie (talkcontribs)

I specifically said the opposite of that.

Reply to "On uninstalling Scribunto"

On having a lot of random bugs during testing

1
Jeblad (talkcontribs)

This extension have a nasty habit of throwing really weird errors during unit tests in Vagrant. I've been asking several people about the real root cause for this, but the explanation goes from slightly wrong to complete whimsical. When it is present it only affects the sandboxed environment, so a known fix is to use the standalone environment. That has a real impact in production, but for testing it works. (Actually, if you turn off one of the environments the tests goes twice as fast. Pretty obvious as it runs the tests in bot environments, and the setup consumes most of the time spent in a test, thus turning one of them off will make the tests run faster.)

The fun thing is; I've experienced the problems on both Ubuntu and Win10, on two different machines. My two different machines has in fact the same motherboard and nearly the same CPU from AMD.

Backtracking what I did when the bug (?) turned up and later when it disappeared, made me wonder if has something to do with the microcode for avoiding the Spectre vulnerability. It seems to have hit when Ubuntu included an update that had a reference to the micocode, and later it seems to have disappeared when there were an other update also involving the microcode.

It is a rather weak correlation here, so whether it was the real root cause is unclear, but if you get a lot of really weird errors while running unit tests try to run a newer version of your OS. If that does not help, and you have enough server juice, use the standalone version.

Reply to "On having a lot of random bugs during testing"
68.49.56.122 (talkcontribs)

Hello,

I'm managing a wiki that had the Scribunto extension installed for some time but really wasn't used much except on a couple of test pages. I'm upgrading the wiki now (from 1.28 to 1.31) and have removed the Scribunto extension. However, when I run the scripts to populate the CirrusSearch index, I get the following traceback:

<code>

[7c132a3761cb626266d8cab6] [no req]   MWUnknownContentModelException from line 306 of /var/www/html/mediawiki-1.31.0/includes/content/ContentHandler.php: The content model 'Scribunto' is not registered on this wiki.

See https://www.mediawiki.org/wiki/Content_handlers to find out which extensions handle this content model.

Backtrace:

#0 /var/www/html/mediawiki-1.31.0/includes/content/ContentHandler.php(243): ContentHandler::getForModelID(string)

#1 /var/www/html/mediawiki-1.31.0/includes/Title.php(4984): ContentHandler::getForTitle(Title)

#2 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(892): Title->getPageLanguage()

#3 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(2126): Parser->getTargetLanguage()

#4 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(2091): Parser->replaceInternalLinks2(string)

#5 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(1318): Parser->replaceInternalLinks(string)

#6 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(443): Parser->internalParse(string)

#7 /var/www/html/mediawiki-1.31.0/includes/content/WikitextContent.php(323): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)

#8 /var/www/html/mediawiki-1.31.0/includes/content/AbstractContent.php(516): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)

#9 /var/www/html/mediawiki-1.31.0/includes/content/ContentHandler.php(1324): AbstractContent->getParserOutput(Title, integer, ParserOptions)

#10 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/includes/Updater.php(363): ContentHandler->getParserOutputForIndexing(WikiPage, ParserCache)

#11 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/includes/Updater.php(204): CirrusSearch\Updater->buildDocumentsForPages(array, integer)

#12 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/maintenance/forceSearchIndex.php(218): CirrusSearch\Updater->updatePages(array, integer)

#13 /var/www/html/mediawiki-1.31.0/maintenance/doMaintenance.php(94): CirrusSearch\ForceSearchIndex->execute()

#14 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/maintenance/forceSearchIndex.php(679): require_once(string)

#15 {main}

</code>

I found a few phabricator tickets that appear to be related but haven't yet found a workaround beyond reinstalling the Scribunto extension. Is there one? Is there a way to remove the Scribunto content model and/or references to it?

68.49.56.122 (talkcontribs)

Additionally, I thought if I did an XML dump of all pages and revisions I would find a page using "<model>Scribunto</model>" but I don't seem to have any pages with that.

2620:11E:1000:120:1792:B56B:4655:6029 (talkcontribs)

Okay, I think I got it fixed. It turns out that if pages exist in the database in a namespace that mediawiki doesn't know about, there is no way to display them and they don't show up in an XML export either. I was able to reset the page content model of the single interfering page in the database like so:

UPDATE page SET page_content_model = 'wikitext' WHERE page_content_model = 'Scribunto';

217.236.248.190 (talkcontribs)

You are my hero; just had the exact same problem. Thank you _very_ much for posting the problem and the solution. I've never installed or run Scribunto, so never occurred to me to check for it.

#GrayanOne

86.165.83.48 (talkcontribs)

Thanks for this!! I also had to run UPDATE content SET content_model = 1 WHERE content_model = 11 and delete the Scribunto row from the content_model table before the error would go away.

Tenbergen (talkcontribs)

Two small things...

  • I think I use a default install of mediawiki, and the table names are prefixed with "mw_", so I had to modify the two queries accordingly.
  • * for me the content_model was "3", not "11", so I suspect that is variable depending on what else is installed on your wiki.

Here is what I had to do:

  • Run the following to get the content mode ID:
    • SELECT * FROM mw_content_models WHERE model_name = 'Scribunto';
    • note the model_id and use it in the next SQL queries
  • Delete the Scribunto line from content model
    • DELETE FROM mw_content_models WHERE model_name = 'Scribunto';
  • Replace all lines in content where content model was ID of Scribunto with ID of wikitext
    • UPDATE mw_content SET content_model = 1 WHERE content_model = <the id you retrieved in the first query>
  • Replace all lines with Scribunto in the page table with wikitext
    • UPDATE mw_page SET page_content_model = 'wikitext' WHERE page_content_model = 'Scribunto';

I have added this to a section "Uninstalling Scribunto" on the extension page, so if you find corrections, please update there as well.

Reply to "Uninstalling Scribunto"

How to solve the Internal link helper error?

1
Readmanhe (talkcontribs)

Hello guys, I find out that, my Scribunto throws a error

黄绍铭Lua错误 ...ribunto/includes/engines/LuaCommon/lualib/mwInit.lua的第23行:bad argument #1 to 'old_ipairs' (table expected, got nil)Billy Ng


when it works on source code with double brackets

Reply to "How to solve the Internal link helper error?"

chcon: can't apply partial context to unlabeled file ‘lua’

6
AndyPKU (talkcontribs)

When I follow the manual instruction, and did "chcon -t httpd_sys_script_exec_t /path/to/extensions/Scribunto/engines/LuaStandalone/binaries/yourOS/lua" this, it sais that can't aplly partial context to unlabeled file 'lua'. What should I do?

Dinoguy1000 (talkcontribs)

Did you change the system path as appropriate for your environment? The path shown on the page is only a sample and won't work verbatim unless you intentionally set up your server with that directory structure. Specifically, the /path/to/extensions refers to the /extensions directory in MediaWiki's base directory; on a default server this might therefore be /var/www/html/extensions. Additionally, the /yourOS directory is just an example and needs to be replaced as appropriate; check what directories are contained in /extensions/Scribunto/engines/LuaStandalone/binaries and select the correct one for the operating system your server is running.

AndyPKU (talkcontribs)

in fact, my lua is in the path /var/www/html/extension/Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic,and I use the command CD into this directory and use command as chcon -t httpd_sys_script_exec_t lua, I am not sure whether it is suitable, but I take it for grunted..

83.77.23.177 (talkcontribs)

Same issue here.

Trying with chcon -t httpd_sys_script_exec_t /var/www/mediawiki/extensions/Scributon/engines/LuaStandalone/binaries/lua5_1_5_linux_32_generic/lua sends the same error my way.

I am trying to setup my wiki using a Raspberry Pi 3, using 32-bit Raspbian.

185.43.188.16 (talkcontribs)

Have anybody resolved this problem? What was the reason?

118.148.171.25 (talkcontribs)

same problem here, tried running using just lua (from inside the 1_5_* folder) as well as using proper paths


Reply to "chcon: can't apply partial context to unlabeled file ‘lua’"
Alex Mashin (talkcontribs)

Can any of the two new hooks provided by Scribunto be used to enable requiring .so Lua modules?

Reply to ".so lua modules"
Probus (talkcontribs)

Hi everyone,

I've been trying to solve this using error fixing advice I found elsewhere on this site, but it hasn't worked. I'm desperate at this point and really need help. I'm afraid I also know very little about all this, so please be patient with me.

What I'm trying to do is import Infoboxes from Wikipedia onto my own wiki. I followed the instructions under [1] and believe I've imported everything I need, but when I load e.g. [2], I get the following red error message:

"Lua error: Internal error: The interpreter exited with status 126."

This is new actually. It had previously been "status 11" (I think), but after following the instructions I found at [3], the message changed to "status 126".

Please, please help me!! And thank you in advance! :)


[1] Manual:Importing Wikipedia infoboxes tutorial

[2] Trying to avoid the spam filter here. My wiki is at "lacerta.palfreyman.de/wiki". There, search for "Template:Infobox".

[3] (Solved) Lua scribunto error on many pages (status 127)

Mr. Stradivarius (talkcontribs)

Status 126 means that your Lua binary is not executable, according to bug T48135. To fix it, you need to change the permissions for the Lua binary. Probably running a command like this will work:

chmod +x path/to/lua

That bug report says that the message "The interpreter exited with status 126" was replaced with a more helpful error message, but on checking the code, it seems that the helpful error message is not output if you set the path to the Lua binary explicitly using the "luaPath" option.

Reply to "Lua Scribunto error (status 126)"

Some visual problems with the Module pages

3
WikimeSteve (talkcontribs)

I have functional Template pages showing the Green box for Documentation pages and showing the <nowiki>[view] [edit] [history] [purge]</nowiki>. Our Module pages have Documentation pages but they show up without the styling (plain white background) and I have to enter /doc in the URL to view and edit them since I do not see the 4 item menu.

I am not seeing the syntaxhighlighting but just found that there is a setting to turn that on so I think that will be fine.

We do not have CodeEditor Extension installed so that will remain false unless it is required.

Is there another setting in the Scibunto configuration that we are missing so it uses the common.css like templates is?

I have tried to import all Documentation Templates and Modules.

Dinoguy1000 (talkcontribs)
WikimeSteve (talkcontribs)

Works fine now. Thank you very much.

Reply to "Some visual problems with the Module pages"