Proposal to add Lua support

User avatar
tactica

01 Feb 2018, 13:06

MediaWiki can use scripting languages embedded by means of the Scribunto extension, which currently supports Lua only. This extension is being used at large on Wikipedia to do many tasks where wikitext and templates alone just won't cut it. If you visit Wikipedia every now and then, surely you have noticed the references list at the bottom of every article, where the structure is implemented using a Lua module (a program stored just like any other wiki page) that also takes care of the syntax checking. If you take a look at the documentation for several random Wikipedia templates, it is quite likely that a large proportion of them depend on Lua.

I'd like to have the extension added to the DT wiki as well, so this is a kind of IC to assess if others would also support this addition; if I am the only one who cares, the wiki will remain as it is, as webwit will not install it just for me.

I'm not a Lua expert so I can barely mention the possibilities this addition would offer, but anyone familiar with Lua or just some of the most popular Wikipedia templates can see the potential. Right now, I'd like to have it to be able to use better references, as well as other useful templates such as Anchor. We can also use it to offer better (looking) infoboxes; in fact, all kinds of graphics boxes become possible, including timelines. Make no mistake, this IS a powerful addition.

For Daniel: no, this extension by itself won't make the wiki have more pictures uploaded, but Lua provides the means to overcome some of the limitations in MediaWiki that you loathe so much, and gives me a personal incentive to keep going too.

Thank you for reading.

User avatar
Daniel Beardsmore

01 Feb 2018, 18:50

You just want to watch my head explode from trying to learn yet another programming language. (Each individual language isn't bad, but keeping them all separate in your head, is much harder.)

User avatar
tactica

01 Feb 2018, 19:04

Nah, if a template or module we want is available on Wikipedia, we can use it right away without changes other than the usual adaptation to remove references to Wikipedia-only namespaces, categories and the like. For example, module "Citation" from enwiki only needs a single line changed to work here, I'm using it already on my private wiki. I don't foresee any need to learn a new language, and I'd take care myself of keeping modules in sync with enwiki to get updates and fixes where appropriate.

User avatar
chuckdee

01 Feb 2018, 21:50

Are there any security concerns?

User avatar
tactica

01 Feb 2018, 22:58

Quoting https://www.mediawiki.org/wiki/Extension:Scribunto :

* PHP's proc_open must not be restricted
* The web server must be able to run binary files in the MediaWiki tree

... and little else.

I don't see anything special even if we were running on Windows, which I suspect we aren't :)

For "optimal" use it would be nice to have the CodeEditor and SyntaxHighlight extensions installed too, otherwise trying to edit a module would open the stock editor, which isn't terribly useful when dealing with code. They are listed under "Optional installation".

There is also a "LuaSandbox" extension for PHP written in C that promises better performance when compared to the standalone binaries, but I have not tried it. They use it on Wikipedia though.

PS. This being a public server, I suppose that editing of any modules we import should be restricted to sysops and trusted accounts.

User avatar
chuckdee

02 Feb 2018, 00:55

I meant in putting a scripting language into the wiki that might be leveraged to create problems.

User avatar
tactica

02 Feb 2018, 01:32

There is a technical explanation for that here.

If the world's #1 target for spambots is using it, it must be secure...

User avatar
chuckdee

02 Feb 2018, 14:28

The question needed to be asked. And now others will evaluate that. Thanks.

User avatar
Blaise170
ALPS キーボード

02 Feb 2018, 21:13

The difference between "the world's #1 target for spambots" and Deskthority is that we are many orders of magnitude smaller than wikipedia. Sure it could provide some benefit, but I don't forsee the primary DT wiki editors actually using it all that often and I wouldn't trust new accounts to use Lua. I'm sure that I'd be considered a "trusted" contributor but I personally wouldn't find much benefit in it. Alas, I'm just one person.

User avatar
webwit
Wild Duck

02 Feb 2018, 21:23

@tactica Do you know how easy it is to maintain? For example, let's say it is installed, and one or two persons use it, but then they give up the keyboard hobby to pursue one in intarsia. Would that leave stuff that's easy maintain and edit, or difficult?

User avatar
tactica

02 Feb 2018, 22:36

Blaise170 wrote: The difference between "the world's #1 target for spambots" and Deskthority is that we are many orders of magnitude smaller than wikipedia. Sure it could provide some benefit, but I don't forsee the primary DT wiki editors actually using it all that often and I wouldn't trust new accounts to use Lua. I'm sure that I'd be considered a "trusted" contributor but I personally wouldn't find much benefit in it. Alas, I'm just one person.
As far as MW is concerned, Lua is only a script that is run whenever a template invokes it. If no template is written to use it or if no Lua based templates are used, Lua is never touched.

On Wikipedia, only Lua modules (the scripts themselves) are edit protected except for sysops, but that's because those modules may be in use in thousands, possibly even millions of pages (actual example). It is no different to any popular template (including those not based on Lua) - you protect the most "popular" pages to prevent a potentially massive overload to the servers in case some random guy decides it is a good idea to use a popular template to learn how to use wikitext.

I mentioned Wikipedia in the sense that they have potentially the single largest base of betatesters AND users willing to break it. There is one reason for extensions to be categorised in MW.org according to how well tested/maintained they are - on top of that, if something is in use in Wikipedia and tagged as sound material by the WMF, common sense says you're OK to use it on your own MediaWiki instance, too, if you follow some simple instructions and have a minimum idea of what you are doing.

The real security problem here is not created by Lua, but is already in place, and has been since the very beginning. The DT wiki is using a stock configuration where everyone can edit about everything except the site's common CSS code (MediaWiki:Common.css) and little else, so if one wanted to cause havoc they would only need to edit Template:Stub with some pr0n or whatever. Given the fact that creating an account here is enough to gain write access to the wiki, it's not like Lua is going to pose a massive security risk when applied to a basically "wide open" system as long as its modules are sysop protected to cater for the particular policy in use here. If you ask me, even that may be OTT considering the fact that nobody really cares about the wiki except the handful of us who post on this subforum.
webwit wrote: @tactica Do you know how easy it is to maintain? For example, let's say it is installed, and one or two persons use it, but then they give up the keyboard hobby to pursue one in intarsia. Would that leave stuff that's easy maintain and edit, or difficult?
That would depend on how much the extension is involved in the general flow of the wiki by the time the guy left. Again, I don't foresee Lua getting used at the level it is on Wikipedia (hundreds or who knows how many templates depending on it), so *realistically* speaking, if the DT "maintainer" left, it should be pretty easy to go on, either leaving things as they are (updating the modules every now and then, keeping them in sync with enwiki) or replacing the relevant templates with the older, Lua-free counterparts.

Honestly, I think you people are getting worried over nothing (and giving me too much credit) if you are afraid that I'm going to turn the DT wiki into Wikipedia for keyboards. I mean, I can barely create an usable list of IBM P/Ns...

Besides, webwit, didn't you tell me that you keep loads of backups? :twisted:

User avatar
webwit
Wild Duck

02 Feb 2018, 23:48

I don't mind it to install it at all, just taking some things into consideration. First, I don't consider myself the wiki master who's going to decide, just the guy who will implement (or not) whatever the decision will be. Currently the wiki has been without a leading manager of sorts. Of course, Beardsmore is the natural wiki leader, but he cowered to formalize that position when I asked him once :twisted: Bo-ooh. Formally, it may be matt3o. Second, I'll not update all your software forever. :twisted: Third, I'm not worried about security or backups, but, like, if you make something with it, will other persons be willing to learn and able to edit it in the future? Of course, this might be an advantage because you can make stuff without Beardsmore being able to edit it (just joking Beardsmore! Don't kill me!) But seriously, the worst thing about mediawiki is accessibility. Knowledge about the topic and willing to share it is not enough, you need to learn mediawiki. And this may increase that barrier of entrance. That all said, once again I don't mind installing it, as Cool Stuff (tm) can be made with it, and as a developer I approve. We can just do it and see where it leads.

User avatar
tactica

03 Feb 2018, 00:35

Lua does not really add any more red tape than it already exists when a newbie decides to start editing a wiki. You don't need to learn Lua at all unless you intend to write your own modules or edit whatever is already installed, and that's way beyond what 99.9% of people who edit a wiki need to know. For the most part, things would remain the same after installing Scribunto, the difference is that new functionality becomes available if you want to use it with a suitable template/module combo.

Seriously, I don't expect Daniel to learn Lua, just like I don't intend to myself. Heck, I was a "bureaucrat" in a wiki running on a hosted server without knowing a word about PHP, skinning, CSS or anything. Sure, knowing how everything works would be nice, but it isn't mandatory, just like you don't need to know how the kernel works in order to be able to use Linux. There's plenty of information out there to go by without being an expert at everything.

Writing wikitext isn't much harder than posting in a forum. Heck, posting a basic article works THE SAME as posting in a forum. The problem is that most people can't be bothered, and there is no easy solution for that. I *suppose* some would feel more enticed to give it a try if a visual editor was available, but really, I wouldn't count on it either...

User avatar
Blaise170
ALPS キーボード

03 Feb 2018, 01:43

Just for the record, I am not necessarily for or against this, just ensuring that the experience is reasonable for everyone. But, I am confused why you are recommending the installation of Lua if you do not even know it yourself?

User avatar
tactica

03 Feb 2018, 01:51

I answered that in the last two paragraphs of my original posting above.

User avatar
Blaise170
ALPS キーボード

03 Feb 2018, 02:03

My point is, why include the functionality for something that you wouldn't count on people using?

User avatar
chuckdee

03 Feb 2018, 03:42

Blaise170 wrote: My point is, why include the functionality for something that you wouldn't count on people using?
Users will not use Lua. Certain other functions require it be installed, from what I get.

User avatar
tactica

04 Feb 2018, 17:33

Lua is invoked from within templates. I intend to begin with the templates I mentioned. I know Daniel wants to create timelines, and that might come next. (misunderstanding)

As I said, I don't *need* to speak Lua to import some modules and modify the templates to use those modules. And as soon as some common templates depend on Lua, anyone visiting the wiki would be also using the added functionality. For example, if I were to replace the "company" infobox with something like what they use on enwiki for geography, automagically everyone visiting a company-related article here would see the additional content and have e.g. an interactive map or whatever.

Is this clear now...? :)

Oh, BTW...
webwit wrote: I don't consider myself the wiki master who's going to decide
Heh. Well, someone has to decide and I don't see @matt3o doing it :?:

Should I start a poll or what?
Last edited by tactica on 04 Feb 2018, 17:44, edited 2 times in total.

User avatar
Daniel Beardsmore

04 Feb 2018, 17:37

I do? That's news to me.

User avatar
webwit
Wild Duck

09 Feb 2018, 13:07

I tried to add it, but it doesn't play nice with CentOS. I doubt it was ever even tested with CentOS.

Requirements: needs PCRE 8.33. CentOS has an ancient PCRE 8.32, no newer packages. I'm not sure if I want to get into this on a production server.

So I wondered if I could ignore that, and then I tried to install SyntaxHightlight. It breaks the editor with this errror:
"sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)" when it launches the "pygmentize" command. Yeah, C.UFT-8 appears to be a Debian thing, there is no such locale on CentOS, nor does there seem to be an easy way to add it.

It's a crapfest.

User avatar
tactica

09 Feb 2018, 15:13

If you depend on CentOS and precompiled packages to run a company (?) then I suppose this is a dead end as CentOS is probably the most conservative distro known to man, with server-centric packages several years behind current developments.

Oh well :cry:

Thank you for trying anyway.

User avatar
Blaise170
ALPS キーボード

09 Feb 2018, 17:28

CentOS is reliable and mirrors RHEL quite well. Nothing wrong with it especially for a site of this size.

Post Reply

Return to “Deskthority wiki talk”