Talk:MediaWiki

From DreamHost

Editing Sidebar

It would be very useful to have the ability to edit the "MediaWiki:Sidebar" in order to customize sites hosted by DH. Am I missing something here, or is this a permissions issue altered in the DH install that only allows sysops to edit the sidebar. Does anybody have suggestions about how to configure this on DH?

It's a "Protected" page by default, which means only sysop users of your wiki (you!) should be able to edit it (nothing to do with being a DreamHost administrator)

Obviously you'll need to be logged in as a sysop yourself before you can do any of this. If you're stuck on this, go to your Special:Listusers page to see which username is set up as sysop

Actually, I've noticed that in DH one-click installations, as of version 1.11, pages under Mediawiki namespace are not shown even if you are a sysop or a bureaucrat. So, you won't be able to reach it through special pages. Just drop [[MediaWiki:Sidebar]] link somewhere on the page, and access the sidebar through this link.

If you want to allow other people to edit the "MediaWiki:Sidebar" you could either unprotect the page ('unprotect' tab at the top) to let everyone edit it, or you could promote a few more people to 'sysop' status (probably a better idea) by going to 'User rights management' in the special pages. -- Harry Wood 09:57, 28 Nov 2006 (PST)

Performance tips?

I installed a mediawiki (why not? it's so easy :-)...) but I'm a bit disappointed by performance. Anyone got any tips for speeding it up somehow? I'm talking about general page viewing access time. Seems to take a second or so to come back with each page, while my other PHP content is accessed more quickly. Is there some way to configure caching better than the default? -- Harry Wood 10:26, 28 Nov 2006 (PST)

maybe here? --ThurnerRupert 15:29, 27 March 2007 (PDT)

Thanks. That is the kind of thing I'm talking about. I need to look into it, but does anyone have any recommendations/experiences of implementing caching on their dreamhost wiki? Which of these approaches is the easiest/most effective? -- Harry Wood 08:56, 4 April 2007 (PDT)

Well I tried setting $wgUseDatabaseMessages=false and $wgUseFileCache=true. Nothing broke, and I presume it made it slightly faster, but not really noticeable.

I guess the first tip "use PHP cache engine such as eAccelerator or APC", would probably have more of an impressive speed-up effect. But how would one go about installing and using one of these with a dreamhost account? Probably a bit too complicated for me.

I think I'll try simplifying the MediaWiki skin, to avoid the need for several CSS request, plus maybe drop some of the panels to reduce clutter, which might also reduce the number of background function calls going on every time. That's my next plan, unless anyone can suggest anything better? -- Harry Wood 09:57, 19 April 2007 (PDT)

The use of eAccelerator or APC would require installing your own custom version of PHP, instructions of which (for PHP5) can be found here.

But yes, if you're not too comfortable working in a *nix environment, I'd stay away from doing so unless you can find someone interested in installing it for you. -- Mousee 10:30, 19 April 2007 (PDT)

Aha now this did make a difference. You have to manually create the cache directory, otherwise no file caching happens.

It's better now although mediawiki's file-cache only gets applied for non-logged-in users, so I'm still disappointed with performance.

I guess the dreamhost servers lack the CPU or disk to serve up MediaWiki at the speed I've seen elsewhere (on a university server, so not really a fair comparison) MediaWiki does a lot of including of many php files. I wonder if that slows things down a lot. -- Harry Wood 16:32, 7 November 2007 (PST)

Getting Started tutorial

The first thing I would like to see in this MediaWiki article is a Getting Started tutorial. It should be very simple and cover the basics that the user needs to know and a step by step process for setting up a DreamHost wiki for the first time. The goal should be that by the time the user finishes reading the tutorial they will have no fear in setting up their first wiki. -- Dan Oetting 19:38, 24 May 2006 (PDT)

Agreed. The MediaWiki page is currently a list of unrelated points, which dont tie together very nicely. Would be better to start with some basics at the top of the page, relatad to dreamhosts's One Click Installs. Maybe I'll start a section called 'getting started' -- Harry Wood 10:01, 28 Nov 2006 (PST)

What currently exists in the getting started section isn't at all what I had in mind. I haven't created my first wiki yet so I can't fill in the details but I've scratched out this outline of what I would like to see. My reluctance to just trying it is that I'm not managing my own site so I can't just take it all down and start over if anything goes wrong. If enough of this outline gets filled in so that I feel comfortable creating the wiki in an existing account, I'll be able to contribute more (especially in the what can go wrong area). Dan Oetting 10:36, 1 November 2007 (PDT)

The outline has been expanded into the new article titled MediaWiki - Getting Started Tutorial so it can stay focused on what the first time user needs to know. --Dan Oetting 19:53, 3 November 2007 (PDT)

Pretty URLs on this site

We could do with those pretty URLs on this site. I'm tired of seeing a pointless index.php in the address bar. -- Scjessey 15:12, 26 Apr 2005 (PDT)

De-personalize

The article needs de-personalizing. Comments like "Anyone have ideas?" are better suited to the associated discussion page (this page). -- Scjessey 17:56, 26 Apr 2005 (PDT)

done - Ryan 02:19, 30 Apr 2005 (PDT)

Transition from Hand installed Wiki

Now, all I have to do is transition my hand-installed Wiki over to the one-click (which seems to run much faster for some reason). Anyone have ideas? - 68.230.123.227

Thanks

Many thanks to the person who wrote this! It's short and works! --TorbenGB 02:56, 30 Apr 2005 (PDT)

Indeed, many kudos! I just set up TeX markup! can you believe it!? I was like "oh my gawd!" I could have never dreamed of even having email features for the wiki installation I have on my server with the mediawiki documentation having an acronym per word ratio of 1:1. But this is awesome XD Qwertyui 13:49, 4 October 2007 (PDT)

MediaWiki vs. the Suggestion panel

(rant alert) In the Suggestion web panel, there's been an entry to "add TWiki/KWiki" to the one-click installers. It puzzles me *why* DH went ahead and did a *different* wiki instead -- one which I feel is inferior in several essential areas. While I appreciate the one-click concept, I don't like that they chose MediaWiki. I've established 2 of these one-click MediaWiki installs now, and I must say the installation is great. It just works. But once it's installed and I start working seriously in it, it becomes apparent why the Suggestions asks for TWiki instead -- because MediaWiki is not very nice. TWiki allows you to use simpler, easy-to-type and easy-to-remember syntax like *bold* and _italic_, and you can attach files to webpages much easier. MediaWiki doesn't even automatically create links to other pages; people have to hand-code each link themselves! In the end, I installed TWiki by hand instead, which took all of 45 minutes of work instead of the one-click install; not a lot of effort for something that I feel is much, much better. So I guess I'll just stick to installing TWiki websites manually instead of using MediaWiki one-click install. --TorbenGB 03:32, 2 May 2005 (PDT)

Well I have to disagree with you there. Having played with many wiki engines, I can see that MediaWiki is certainly one of the best. Personally I find Twiki is too cluttered and doesn't hide the confusing advanced features so well. But that's just my impression. The fact of the matter is, there's a whole myriad of different softwares to choose from, with advantages and disadvantages of each. MediaWiki and Twiki are two of the more mature wiki engines. wikimatrix.org provides detailed feature comparisons, but when it comes down to it, you have to like the feel of the website. So each to their own I guess. -- Harry Wood 05:19, 14 Mar 2006 (PST)

Note about hackers accessing MediaWiki

I recently had a burst of subscribers all with the names of hexadecimal characters. Approximately 50 in all. If this happens to you, go to the dreamhost panel, click on your mysql database, look for a user table and select those names and delete them, also look for any other tables that have a user id that matches those you deleted. Keep track of that last known true user, so you do not accidently delete a link that belongs to a true user. Once this is done, MediaWiki will run as normal, but those names will no longer appear. One last note, it is advisable to back up your database, before you atempt to edit it, as a precaution. Silkrooster

Beautifying URLs

Thanks for the tip. In my case it caused the wiki search to break — every search returned a “Badly formed search query” error. A Google search led to this bug report. Changing the last .htaccess line to RewriteRule ^(.*)$ index.php?title=$1 [QSA] fixed the problem. Has anyone else experienced the same issue? — Austicke 04:12, 30 May 2005 (PDT)

Yes, I experienced the same issue on the test installation. Your change on the .htaccess file fixed my problem as well. Running the latest release, 1.4.5. — DavidCollantes 13:01, 20 Jun 2005 (PDT)

The same happened on my installation. I've added the QSA option to the instructions. --AdamBackstrom 06:15, 5 Aug 2005 (PDT)

I've also noticed that this breaks my stats directory. The authentication request isn't going through property. Has anyone found a fix for this? --AdamBackstrom 06:16, 5 Aug 2005 (PDT)

Whenever I try this I keep getting this error: "Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden:" Any ideas?

I follow all the steps under "# 2.1 If your wiki is installed under a "wiki." subdomain". Everything works except if you go to wiki.mysite.com. It loads the "Index of /" page instead of the Main Page. My .htaccess file is as follows. If I go to wiki.mysite.com/iurl/ it does load as wiki.mysite.com/Main_Page

RewriteEngine on 

# uncomment this rule if you want Apache to redirect from wiki.mysite.com/ to wiki.mysite.com/Main_Page
RewriteRule ^/$ /Main_Page [R]

# do the rewrite
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /iurl/index.php?title=$1 [PT,L,QSA]

Why don't any of the Meta pages exist?

I just did a one-click installation of MediaWiki. When I tried to click on Editing help on the edit page, the editing help page came up blank. It seems stupid that it doesn't come with editing help. Is there some way I can easily add it? Is there something missing in my installation? -- annon

You have to add this kind of 'meta' information yourself. This is something the mediawiki development community should improve, but that's how it comes out-of-the box from mediawiki.org. One reason they've been slow to improve this, is that the documentation they have built up, is GFDL licensed wiki pages. This means that strictly they can't be plonked onto fresh wiki installations very easily (need attribute all the authors). The project which aims to imrpove this: Public Domain Help Pages, is a little slow to get off the ground.

On the plus side, it means you have a blank canvas to play with, and fill in as you see fit. -- Harry Wood 05:11, 14 Mar 2006 (PST)

PHP Safe Mode

The article writes:

Register globals is only enabled in PHP4. If you set your site to use PHP5 (where we have register_globals off), you can avoid this error message.

Are PHP4 users allowed to turn off register_globals using a php_flag directive in .htaccess?

php_flag register_globals off

-- Mark Quinn 11:15, 18 May 2006 (GMT)

DefaultSettings.php

To my knowledge it is highly recommended NOT to do any changes in DefaultSettings.php, for update reasons. Rather copy whatever you want to change in DefaultSettings.php to LocalSettings.php and do the changes there. --Helge 13:04, 2 Dec 2005 (PST)

The above was in the article, moved here by myself. I agree with the comment, made the changes in the article to reflect it. Dori | Talk 23:35, 3 Jun 2006 (PDT)

I will offer someone a small fee to help me get very short URLs working

I have tried every suggestion here, as well as some on wikimedia's site. whats a small fee? maybe $10. just post answer here, and a way to get ahold of you.

Honestly... the following (from previous page) should work:

# first, enable the processing - Unless your ISP has it enabled
# already.  That might cause weird errors.
RewriteEngine on
 
# test if rewrite should stop for 
# special directories
RewriteRule ^(images|skins)/ - [L]
# all php scripts.
RewriteRule .*\.php$ - [L]
 
# uncomment this rule if you want Apache to redirect from www.mysite.com/ to
#  www.mysite.com/Main_Page
# RewriteRuin_Page [R]
#RewriteRule ^/$ /wiki [R]
 
# do the rewrite
#RewriteRule ^wiki/?(.*)$ /index.php?title=$1 [L,QSA]
RewriteRule ^/?(.*)$ /index.php?title=$1 [L,QSA]

and add:

$wgArticlePath      = "/$1";

to LocalSettings.php --NigelJ 01:26, 16 Jul 2006 (PDT)

Here's what I use.

.htaccess

Options -indexes

RewriteEngine on

# Don't rewrite requests for files in MediaWiki subdirectories,
# MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt
RewriteCond %{REQUEST_URI} !^/(stylesheets|images|skins)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/robots.txt
# include these last two lines if you use the analog stats
RewriteCond %{REQUEST_URI} !^/failed_auth.html$
RewriteCond %{REQUEST_URI} !^/stats/

RewriteRule ^(.*)$ index.php?title=$1 [QSA]

LocalSettings.php

$wgArticlePath      = "/$1";

I think that's exactly what's on the article page. One of my wikis is at www.nwnwiki.org, and it works fine. Perhaps you're not using the root directory of the domain? -- Austicke 22:45, 16 Jul 2006 (PDT)

Pruning Beautifying URLs

Someone please delete the sections which are verified non-working with 1.7.1+ and also look into the fact that all of those break pages with ampersands in the title. --Neurophyre 10:06, 27 Sep 2006 (PDT)

upgrading

I'm having trouble upgrading. The vocabulary on this page is too esoteric. Someone please explain the last two bullet points to me, please. I can find the files, but what do I do with them? Buddy13 09:53, 27 Oct 2006 (PDT) Must I offer money? The site's sitting dead while I wait. Name your price. Buddy13 15:28, 29 Oct 2006 (PST)

Hi, those last two bullet points are the commands you should type into your SSH command line. They will run update.php and refreshLinks.php respectively. Once you run those, you should be good to go. If you have any other urgent wiki questions, I don't check this wiki often... you can get me on my userpage on LyricWiki.org pretty much any time though. Good luck!

-Motiveforce 18:19, 31 Oct 2006 (PST)

I just edited the 1.8.2 section to give more information to one-click upgraders. The use of /maintenance/update.php relies on setting the DBadmin credentials somewhere. I just suggested doing it in update.php itself. I assume the manual upgrade sets the DBadmin credentials somewhere else important. - Perigee 05:28, 24 Jan 2007 (PST)

Upgrading - database error

I've run a one-click update to bring it up to version 1.9.3. but when I edit a wiki page now I get "Table 'dbhost.wiki_redirect' doesn't exist" Which is true. It doesn't exist. I'm guessing this is a new table introduced in the version of the software. Did the upgrade fail to update my database schema? Do other people have a 'wiki_redirect' table? -- Harry Wood 04:36, 6 May 2007 (PDT)

I always upgrade my wiki myself, so I can't say I've had this problem, but it's probably so; log into the shell and run the upgrade script (it should take care of bringing the database up to date). —Emufarmers 20:14, 7 May 2007 (PDT)

Yeah I needed to just read the page here didn't I? sorry.

It's one-click to install it, but for upgrading it's not quite as automatic as the dreamhost console makes it look. -- Harry Wood 04:49, 23 June 2007 (PDT)

Upgrading to 1.11 - database error

I just upgraded from 1.10 to 1.11 and got this error:

 Notice: Undefined index:  globals in /home/.upside/simsong/forensicswiki.org/maintenance/refreshLinks.php on line 27

Any clue what it means or if I should be worried? Simson 18:43, 17 September 2007 (PDT)

This directive was a bit misleading

"In the ROOT directory of www.yourdomain.com place the following .htaccess file:"

I took this too literally, and created the .htaccess in the mydomain.com directory, where I should have created it in the wiki.mydomain.com directory. I'm sure I'm not the only one to misread this as such.

SVG thumbnailing?

To enable support for SVG two things should be specified in LocalSettings - svg as one of the allowed file types and path to SVG converter, like this: $wgSVGConverterPath = "/path/to/ImageMagick"; the path to converter is pretty much the same as $wgImageMagickConvertCommand without the convert command at the end (that's what worked on my server on my computer - the convert command was C:\ImageMagick\convert and path to converter was C:\ImageMagick)

So I specify path to converter /usr/bin considering convert command is /usr/bin/convert.

But it doesn't work and the weirdest thing is that thumbnails of svg images don't display the error message ("wasn't able to find converter in the specified directory!" or something) but are just thumbnailed to blank white pngs which means ImageMagick does convert them to white pngs.

my image settings in LocalSettings are

$wgEnableUploads       = true;
$wgFileExtensions = array('png', 'gif', 'jpg', 'jpeg', 'doc', 'xls', 'mpp', 'mpi',
'ppt', 'mp3', 'sxc', 'pdf', 'ogg', 'txt', 'svg', 'kml');
$wgUseImageResize = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgAllowTitlesInSVG = true;
$wgSVGConverterPath = "/usr/bin";

Help greatly appreciated Qwertyui 11:52, 12 October 2007 (PDT)

Sorry for spamming the talk page. I just made a second try with a different image and it works! woot!! I assume there was something wrong with my configuration *at the moment* of uploading and although I edited a test page making different thumbnails different sizes to see if my attempts to fix it work perhaps the blank image was already being pulled from some obscure cache so basically I recommend uploading an entirely new svg each time there is a need to check if the svg settings are correct. Qwertyui 12:52, 13 October 2007 (PDT)

Lengthy page

This page is getting pretty long. I suggest migrating content to separate pages and creating a Category:MediaWiki for documentation. --Lquilter 10:38, 13 October 2007 (PDT)

Math extension?

Can we get the math extension to work on Dreamhost? Thanks.

Special:Statistics is broken

Statistics page is broken

MediaWiki version: 1.14.0

URL: http://wikademia.org/Special:Statistics

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)
from within function "SiteStatsUpdate::cacheUpdate". MySQL returned error "1054: Unknown column 'ss_
active_users' in 'field list' (mysql.wikademia.org)".

My statistics page does not work.

Then also: