deskthority

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.

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.)

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.

Are there any security concerns?

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.

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

There is a technical explanation for that here.

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

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

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.

@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?

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?

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 Bo-ooh. Formally, it may be matt3o. Second, I'll not update all your software forever. 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.

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...

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?

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

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

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.

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?

I do? That's news to me.

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.

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

Thank you for trying anyway.

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