Bryan's picture

I am trying to enable mediawiki extensions in my turnkey installation and it is not working. The instructions available here are for either an older or newer version than I have.

In my mediawiki, there is a dedicated etc/mediawiki-extensions folder, rather than an extensions sub-folder in etc/mediawiki, as per the above guidelines. It is in this sub-folder that the extensions.php file is found. However, unlike the file in the above link, mine appears to auto-load all extensions in the /etc/mediawiki-extensions/extensions-enabled folder. This is the file itself:


// Include base functions
include( '/usr/share/mediawiki-extensions/base/ExtensionFunctions.php' ) ;

$mw_debian_extensions_dir = "/etc/mediawiki-extensions/extensions-enabled";

// Including all enabled extensions.
if ( is_dir( $mw_debian_extensions_dir )
     $dh = opendir( $mw_debian_extensions_dir ) ) {
        while ( ( $file = readdir( $dh ) ) !== false ) {
            $absolute_file = $mw_debian_extensions_dir . DIRECTORY_SEPARATOR . $file ;
        if ( preg_match( "/.php$/",$file ) && file_exists( $absolute_file ) &&
                 is_readable( $absolute_file ) ) {
                include_once( $absolute_file );
        closedir( $dh );

?> I copied the desired extensions (Cite.php) from the etc/mediawiki-extensions/extensions-available folder to the etc/mediawiki-extensions/extensions-enabled folder, and it broke my wiki (e.g. when I try to access the wiki I get an "The wiki page isn't working, is currently unable to handle this request". Chaining the file permissions to allow read/write/execute of the file by all user/group/other did not fix the issue, but removing the file restores functionality.

What am I doing wrong?



Bryan's picture

I've attempted to follow the instructions at the mediawiki site:

This too has failed, even with file permissions set to 775

Any suggestions?


Jeremy Davis's picture

It looks like our Mediawiki docs page is REALLY out of date... Thanks for the heads up. FWIW it looks like the last time it was edited was 2009! I've opened an issue relating the that.

When you say "This too has failed" do you mean that you are getting the same (or similar) error to what you noted in your first post?

Have you had a look at the logs? I'm not sure if Mediawiki itself logs anything anywhere, but often PHP apps provide at least some error logging via the webserver log. You should find that in /var/log/apache2/error.log Perhaps that gives some insight?

If you think that this is a TurnKey bug, then please feel free to lodge a new issue on our tracker.

Finally as a heads up, please also see this issue on the tracker related to Mediawiki. It's completely irrelevant to your immediate issue, but is relevant to all Mediawiki appliance users. Hopefully we'll have some further info on that for you really soon.

Bryan's picture

The error is always the same. I cleared the log and then repeated the process that led to the error previous, specifically:

1) I copied Cite.php from /etc/mediawiki-extensions/extensions-available to /etc/mediawiki-extensions/extensions-enabled, which resulted in the same error as I described in my OP upon trying to access the wiki

2) I chmod'd Cite.php to 775, in the /etc/mediawiki-extensions/extensions-enabled folder; this did not change the error

3) I then checked the log file, it was empty

The error is "HTTP ERROR 500", which from what I understand is a geneic "something is broken " error. I'm not familiar enough with these systems to know whether it is a turnkey issue, mediawiki issue, or a user issue (i.e. me).


Jeremy Davis's picture

A couple of possibilities here.

My first guess is that you didn't restart Apache ('service apache2 restart') after deleting the log file. If you delete a file that is in use by a program then the program will keep merrily writing to the old (now non existent) file rather than the new one...

Other possibilities that occur to me are either it is an internal PHP issue (which by default are often not logged) or if Apache doesn't consider it a "real" error (i.e. Apache itself isn't erroring, just PHP) then it will sometimes log it to the access log (/var/log/apache2/access.log) however, that will rarely include anything useful (other than a note of the error).

Regardless, thanks for the extra info.

Yes, as a general rule a 500 error is a somewhat generic "internal server error". TBH my guess is that there is actually some PHP error going on under the covers. Unless you can get some useful error message, it sounds like I'll need to dig in a little deeper and test this out myself. Unfortunately I don't have time right now, but to ensure that it doesn't get forgotten, I've created a separate issue for your plugin woes.

Bryan's picture

I only cleared the contents of the file with an editor, and apache is writing to the log file (I have an error in my email setup that produces a nightly error, including one last night after I cleared the log). But even restarting apache and attempting to reproduce the error did not result in anything written to either /var/log/apache2/access.log (which is completely blank, even though I've never accesssed it before) or to var/log/apache2/error.log 

I'll keep an eye on the error page, and will help where I can.


Jeremy Davis's picture

Sorry my vague troubleshooting guesses weren't of much value to you. FWIW we'll be updating Mediawiki for v14.2 so hopefully this issue will be fixed then (the upstream docs will work with the TurnKey appliance).

We plan to document how you can manually upgrade it for yourself too so you won't be stuck. Sorry that I can't do it instantly for you but we'll try to get it done ASAP.

Bryan's picture

No problem, ghosts in the machine and all that. 

NowellMorris's picture


I know this was almost 3 months ago, but for the thread's sake, make sure that you are using the mwenext (to enable) or mwdisext (do disable) , where mwlsext will list your available extensions.  The framework here is very Debian-esque and I don't know if I should attribute it to Debian or TKL.  Essentially you are dealing with links, not actual files.  The files all live in only once place.  

/usr/share/mediawiki-extensions/(base:collection:geshi:openid)/<extension dir>/<extension>.php 

Your etc/mediawiki-extensions/extensions-available is a link to those files, and your etc/mediawiki-extensions/extensions-enabled are links to extensions-available

The concept here is that nobody has to know how to code php to enable an extension.  You can use a simple command to enable or disable the included extensions.  

What I am up against is adding an extension to this framework (or out of it) that doesnt bust mediawiki.  I guess by the time the next person who is barking up this tree gets here I will have long figured that out.  In the mean time I am happy to share that understanding to my current level.  

Jeremy Davis's picture

Thanks tons for your input! As you hint/note MediaWiki in our appliance comes from a Debian package. We don't provide any MediaWiki specific tweaks, just install from the Debian repos. Your insight makes a ton of sense and actually is news to me. I used the TurnKey MediaWiki server years ago (before I worked with TurnKey) but only in a limited capacity. In more recent times I have had little to do with it beyond initial pre-release testing.

FWIW we are hoping to release a new updated appliance ASAP. It will install MediaWiki from the latest upstream source.

PS I just read back up the thread a little and noticed that I have been threatening this new build of the Mediawiki appliance for quite a while now! Please be assured that it's much closer now! :)

NowellMorris's picture

Thanks for the response!  Yeah, I was just stunned by the LTS version that is currently used (that is out of date).  If we make use of the current LTS (1.27) it will be supported into mid 2019. 

Thanks guys for your creation/work on TKL!  Quite handy!

Jeremy Davis's picture

We have already done much for the work to update the MediaWiki appliance, but we have some Core/common tweaks we want to tidy up prior to releasing any new builds.

Thanks for the pointer re LTS version. That's probably the best path! FWIW we were intending to just use the latest, but that sounds like a much better plan.

n the meantime, if you would like to build and help test the new version in a VM, I can point you in the right direction?! I need to do some final testing and code review before I merge it, but the build code has been updated (just not yet merged into the TurnKey repo). You can see the changes on GitHub. In the meantime if you are interested, please build from Anton's (@qrntz) "v14.2" branch (you'll need to clone his repo, then checkout the "v14.2" branch).

Add new comment