Forum archive
Enabling Mediawiki Extensions
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:
<?php
// 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 );
}
?>...so 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
Replies (11)
No problem, ghosts in the
Reply 1Ok Bryan
Reply 2We 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.
I only cleared the contents
Reply 3I 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.
Bryan
Did you restart Apache?
Reply 4My 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.
The error is always the same.
Reply 5The 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).
Bryan
Hmmm, not sure...
Reply 6It 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.
I've attempted to follow the
Reply 7I've attempted to follow the instructions at the mediawiki site: https://www.mediawiki.org/wiki/Manual:Extensions
This too has failed, even with file permissions set to 775
Any suggestions?
Bryan
Awesome, thanks for the added info!
Reply 8Thanks 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).
Thanks for the response!
Reply 9Thanks 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.
https://www.mediawiki.org/wiki/Version_lifecycle
Thanks guys for your creation/work on TKL! Quite handy!
Hi Nowel
Reply 10FWIW 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! :)
Bryan, I know this was
Reply 11Bryan,
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.
No problem, ghosts in the machine and all that.