MediaWiki

From DreamHost

Jump to: navigation, search
This article or section may require a cleanup.
We are hoping to create articles that meet certain standards. Please discuss this issue on the talk page. Editing help is available.

MediaWiki is most well-known for being the software behind Wikipedia. It is also the software that runs this site.

You can use the DreamHost Control Panel to install your own MediaWiki-based wiki. It's under Goodies Control Panel > One-Click Installs


Contents

Getting Started

You can use the DreamHost Control Panel to install your own MediaWiki-based wiki. It's under Goodies Control Panel > One-Click Installs

Basically, you put all mediawiki files in your chosen directory (either via the DreamHost script or by FTP), create a mysql database and user, then point your browser at http://your.install.directory/config where you fill-in a large configuration form.

Execute the form, move the newly generated LocalSettings.php to the parent directory, and delete the config directory with its content.

Troubleshooting

As of mediawiki 1.8.2 be sure to select "use backward-compatible UTF-8" in the configuration form's mysql section. "UTF-8 experimental" does not work and it causes the install script to fail silently without generating LocalSettings.php . This is mediawiki bug 6085 that depends on buggy MySQL support of UTF-8. See http://bugzilla.wikimedia.org/show_bug.cgi?id=6085

In the MediaWiki 1.8.2 installation process, the configuration form will ask for a "database host" which defaults to "localhost". It seems you must change this to an answer that looks like "mysql.<yourdomain.net>".

Beautifying URLs

If your wiki is installed under a "wiki." subdomain

  1. Install MediaWiki in a directory, e.g., ~/wiki.yourdomain.com/
  2. Configure your wiki as normal with ugly URLs
  3. Modify the following options in LocalSettings.php 
$wgScriptPath       = "";
$wgScript           = "$wgScriptPath";
$wgRedirectScript   = "$wgScriptPath/redirect.php";
$wgArticlePath      = "$wgScript/$1";
  1. In the ROOT directory of wiki.yourdomain.com place the following .htaccess file: 
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} !^/(skins|stylesheets|images|config)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA]

It seems, that if you're using mediawiki 1.12.0, then the "Special" links will be broken with this approach. One possible solution is to use the patch from this link: http://blog.gugl.org/archives/27

If your wiki is install under a "www." subdomain

See this post in the Dreamhost forums. This method is also described here at Meta.

This method will produce URLs (for content pages, not edit pages) that look like www.yourdomain.com/wiki/Content_title

  1. Install MediaWiki in www.yourdomain.com/w and not in www.yourdomain.com or www.yourdomain.com/wiki using the Dreamhost control panel
  2. Configure your wiki as normal with ugly URLs
  3. Modify the following options in LocalSettings.php 
$wgScriptPath = "/w";
$wgArticlePath = "/wiki/$1";
  1. In the ROOT directory of www.yourdomain.com place the following .htaccess file: 
RewriteEngine on

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

# do the rewrite
RewriteRule ^wiki/?(.*)$ /w/index.php?title=$1 [L,QSA]

Ampersand problems

Using rewrite rules will cause pages with ampersands and possibly question marks in the title to break.

See http://bugzilla.wikimedia.org/show_bug.cgi?id=7424 and http://mail.wikipedia.org/pipermail/mediawiki-l/2005-June/005814.html for further information. This should be updated when somebody figures out if the alias works correctly.

Blocking Spam

See main article.

Using a CAPTCHA

By using a CAPTCHA, one can prevent automated bots from adding things to the wiki. Examples of MediaWiki CAPTCHA plugins are reCAPTCHA and ConfirmEdit.

Locking Down the Wiki

There are sometimes legitimate reasons to lock down a wiki. You can shut down open account registration and disallow non user edits.

To do so edit LocalSettings.php, AFTER the line: 

require_once( "includes/DefaultSettings.php" );

Disallow edits by unregistered users: 

$wgGroupPermissions['*']['edit'] = false; 
$wgShowIPinHeader = false;

Disallow account creation: 

$wgGroupPermissions['*']['createaccount'] = false;

Mixed Techniques

A middle road is also possible. The following methods can be used to discourage spam.

.htaccess for the domain contains: 

Options -indexes

# Very VERY few legitimate clients leave their user agent field blank, and those that do should fix this behavior. 
# You can stop spam at the door by forbidding access to your wiki to anyone connecting with a blank user agent. 
# If you don't already have a .htaccess file in the root of your site, create one. Then edit .htaccess and add this:

SetEnvIf User-Agent ^$ spammer=yes     # block blank user agents

Order allow,deny
allow from all           
deny from env=spammer

<Files .htaccess>
order allow,deny
deny from all
</Files>

LocalSettings.php has the following added, just before the end: 

# Block CSS Hidden Spam from div tags. Lots of wiki spam is hidden in specially constructed div tags. 
# Mediawiki allows div tags, so I use this solution which allows most of the tags but 
# blocks them if they use any attributes which may be used for hiding and have little or no use in a wiki.

$wgSpamRegex = "/\<.*style.*?(display|position|overflow|visibility|height)\s*:.*?>/i";

# From: http://meta.wikimedia.org/wiki/Preventing_Access
# This snippet prevents editing from anonymous users
# Users will still be able to read the page and can view the source by using Special:Export/Article name.
# Note that you have to add this to the end of the LocalSettings.php file, just above the closing

$wgGroupPermissions['*']['edit'] = false;

Caution: The following was tried initially, but it caused database errors: 

# From includes/DefaultSettings.php
# Should editors be required to have a validated e-mail
# address before being allowed to edit?
# Commented out because SQL errors started, after 1st install try.
# $wgEmailConfirmToEdit=true;

Using Tex Markup

MediaWiki can use Latex Markup for Mathematics, to use it you must go to your wikiInstallationDirectory/math and run make. To do this, you first must set the user account to Enabling Shell Access, and then login to your account using an SSH shell client. Once logged in, use Unix Commands to navigate yourself to the math directory stated above, and then run the make command. The required executable will then be compiled. Once compilation has compiled, set $wgUseTeX = true; in your LocalSettings.php and then markup like 

<math>\sum_{n=0}^\infty \frac{x^n}{n!}</math>

will show up as an image in your MediaWiki.

Security

After you move LocalSettings.php from config to your root directory, have a look at its permissions. LocalSettings.php has your DB login information in it, including the db username and db password. When created/modified by the Wiki install process, it has -rw-rw-rw- permissions (i.e. everyone with an account on the server can read and write to it). While your directory permissions might prevent people from navigating the filesystem for the file, they still may be able to figure out the path and read/change it directly.

A good measure of security may be had by, after moving LocalSettings.php from config to your root directory, executing the following commands: 

$ cd <your wiki root directory>
$ chmod 640 LocalSettings.php

or 

$ chmod 660 LocalSettings.php

depending on whether you want it group writeable (latter) or just writeable for the owner (former)

Actually, if you are running PHP with CGI (instead of Apache module), it is actually better and more secure to mark the file LocalSettings.php only readable/writable by the owner, i.e. 
$ chmod 600 LocalSettings.php
So other people on the same server will not be able to steal your MySQL password from your setting file.
Another good security idea is to set up an external PHP file that stores your passwords elsewhere and will pass them in as variables. for example, my LocalSettings file, instead of explicitly including the DB passwords, etc., links to the passwords in a file stored in a directory above the web root. e.g., where wiki directory is /home/.folder/yourusername/domain.com/w/, you would create a directory called "external_includes", in which you then create a file called "database_info". The path to this file would be /home/.folder/[yourusername]/external_includes/database_info and the file would includ the following (fill in your true values in the quotes): 
<?php
$database_server = "mysql.domain.com"; 
$database_name   = "databasename"; 
$database_user   = "username";
$database_pw     = "password";
?>
Save that, then put the following lines into your LocalSettings.php (of course setting the variables accordingly in the external file and deleting the actual values from the LocalSettings.php file, which are now stored in the database_info file) 
# enhanced DB security

require_once ("/home/.folder/[yourusername]/external_includes/database_info");

$wgDBserver     = $database_server;
$wgDBname       = $database_name;
$wgDBuser       = $database_User;
$wgDBpassword   = $database_pw;

# DB variables not security related - leave these alone from how when you set up your wiki

$wgDBprefix     = "wiki_";
$wgDBtype       = "mysql";
This way, even if someone does somehow read your LocalSettings file from the web (I'm not sure how they could with 600 permissions, but it's theoretically possible), it still doesn't get them anything. Fungiblename 05:47, 18 Jul 2006 (PDT)

Permissions

Under the default one-click dreamhost install under Goodies, you CAN set all files and subdirectories under the wiki root directory to group writeable. This is helpful if you want to share administrative/patching and other duties with other accounts in your group. You can use a custom group to scope permissions properly. MediaWiki will still execute just fine with group writeableness turned on.

Google AdSense

If you're interested in running a MediaWiki site with Google AdSense, you should know that in order to comply with the Google TOS, you shouldn't display ads on non-content pages. The following solution will cause ads to not be displayed on Special, User, User talk, Image, Template, and edit/preview pages.

I've solved this by limiting my users' choice of skins to Monobook, and modifying the Monobook.php file as follows:

For a vertical ad below your left-side navigation, after this: 

                echo htmlspecialchars($this->data['nav_urls'][$special]['href'])
                ?>"><?php $this->msg($special) ?></a></li><?php } ?>
              <?php } ?>
            </ul>
          </div>
        </div>

put this: 

        <?php
          if(!strstr($_SERVER['REQUEST_URI'], "Special:") &&
               !strstr($_SERVER['REQUEST_URI'], "User:") &&
               !strstr($_SERVER['REQUEST_URI'], "User_talk:") &&
               !strstr($_SERVER['REQUEST_URI'], "Image:") &&
               !strstr($_SERVER['REQUEST_URI'], "action=submit") &&
               !strstr($_SERVER['REQUEST_URI'], "action=edit") &&
               !strstr($_SERVER['REQUEST_URI'], "Template:")) {
            include("adsense/adsense_vertical.php");
          }
        ?>

For a horizontal ad at the bottom of your articles, after this: 

            <?php if($this->data['catlinks']) { ?><div id="catlinks"><?php $this->html('catlinks') ?></div><?php } ?>
            <!-- end content -->
            <div class="visualClear"></div>

put this: 

            <?php
              if(!strstr($_SERVER['REQUEST_URI'], "Special:") &&
                   !strstr($_SERVER['REQUEST_URI'], "User:") &&
                   !strstr($_SERVER['REQUEST_URI'], "User_talk:") &&
                   !strstr($_SERVER['REQUEST_URI'], "Image:") &&
                   !strstr($_SERVER['REQUEST_URI'], "action=submit") &&
                   !strstr($_SERVER['REQUEST_URI'], "action=edit") &&
                   !strstr($_SERVER['REQUEST_URI'], "Template:")) {
                include("adsense/adsense_horizontal.php");
              }
            ?>

Now, you'll need to create an adsense/ directory in your main wiki directory, and place two files in it, adsense_horizontal.php and adsense_vertical.php as needed.

The contents of my files are as follows:

adsense_vertical.php: 

<div id="p-advertisement" class="portlet">
<h5>Advertisement</h5>
<div class="pBody">
  Paste Google code here
</div>
</div>

adsense_horizontal.php: 

<div style="border: 1px solid #ccc; padding: 1px; margin-top: 25px;">
  Paste Google code here
</div>

I've found that these layouts fit nicely with the Monobook skin. For the vertical ad, the 120x240 tall format ad works best.

There is a useful way to help block yourself from seeing your own adverts to prevent yourself from inadvertently clicking on them - for that see this page.

Google Analytics

For those using Google Analytics (now free and openly available), here is the short and simple way to modify your code to be recognized by Google's site tracker:

In the MonoBook.php file (or your skin file of choice), insert the following code right before the "</body>" tag (no quotes): 

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-XXXXXX-1";
urchinTracker();
</script>

Where you would replace the "XXXXXX" with the tracker number associated with your Analytics account.

Google Maps

To add google maps to your wiki, install the Google Maps Extension]

Upgrading_to_1.12.0

When I used the Dreamhost Installer Robot to upgrade to 1.13.0, it sent me an email saying I should go to Upgrading_to_1.12.0. But really you want to visit "Upgrading" below. Thunderrabbit 06:33, 23 August 2008 (UTC)

Upgrading

Firstly, current versions of Mediawiki require PHP5. If you've been running PHP4 on your domain, switch to PHP5 by going to the Manage Domains page of panel.dreamhost.com and clicking on the Edit button under the Web Hosting column for your domain.

  1. If you haven't done so yet, upgrade Mediawiki using the Goodies > One-Click Installs.
  2. Now you need to run two update scripts. Here's what you need to do:
    • Login through the shell and cd to your Mediawiki directory
    • At the shell prompt, type cp AdminSettings.sample AdminSettings.php
    • (Optional) Type this command to hide your file from casual snooping: chmod 640 AdminSettings.php
    • Edit the AdminSettings file by typing nano -w AdminSettings.php
    • Edit the appropriate lines in this file with the username and password for your Mediawiki's MySQL database
    • Press Ctrl-o to save the file
    • Press Ctrl-x to exit nano editor
    • Type the following commands into your shell:
      • cd maintenance/
      • /usr/local/php5/bin/php update.php ("Deleting old default messages" may take 5-10 minutes, depending on the size of your database)
      • /usr/local/php5/bin/php refreshLinks.php (only really required for updating from 1.5.x)

And you're in business. (You may also want to delete the AdminSettings.php file to be on the safe side.)

Upgrading when using the Auth_phpBB.php Extension

You may get fatal errors when trying to run the update.php command (noted above) where it fails on the line 

 require_once './extensions/Auth_phpBB.php';

Apparently referring to this particular extension does not sit well with the update script. You can comment out the entire block of code that handles the phpBB login (just add "/*" to the beginning of the block and "*/" to the end): 

/* 
// PHPBB User Database Plugin. (Requires MySQL Database)
require_once './extensions/Auth_phpBB.php';

$wgAuth_Config = array(); // Clean. 

$wgAuth_Config['WikiGroupName'] = 'Wiki';       // Name of your PHPBB group
                                                // users need to be a member
                                                // of to use the wiki. (i.e. wiki)

$wgAuth_Config['UseWikiGroup'] = false;          // This tells the Plugin to require
                                                // a user to be a member of the above
                                                // phpBB group. (ie. wiki) Setting
                                                // this to false will let any phpBB
                                                // user edit the wiki. 
 
$wgAuth_Config['UseExtDatabase'] = true;       // This tells the plugin that the phpBB tables
                                                // are in a different database then the wiki.
                                                // The default settings is false.  

$wgAuth_Config['MySQL_Host']        = 'mysql.YOURDOMAIN.XXX';      // phpBB MySQL Host Name.
$wgAuth_Config['MySQL_Username']    = 'YOUR MYSQL USERNAME';       // phpBB MySQL Username.
$wgAuth_Config['MySQL_Password']    = 'YOUR MYSQL PASSWORD';       // phpBB MySQL Password.
$wgAuth_Config['MySQL_Database']    = 'YOUR MYSQL DATABASE NAME';       // phpBB MySQL Database Name.

$wgAuth_Config['UserTB']         = 'phpbb_users';       // Name of your PHPBB user table. (i.e. phpbb_users)
$wgAuth_Config['GroupsTB']       = 'phpbb_groups';      // Name of your PHPBB groups table. (i.e. phpbb_groups)
$wgAuth_Config['User_GroupTB']   = 'phpbb_user_group';  // Name of your PHPBB user_group table. (i.e. phpbb_user_group)
$wgAuth_Config['PathToPHPBB']    = '../forums/';         // Path from this file to your phpBB install.

// Local
$wgAuth_Config['LoginMessage']   = 'You need a phpBB account to login.
<a href="' . $wgAuth_Config['PathToPHPBB'] .
                                   'ucp.php?mode=register">Click here to create an account.</a>'; // Localize this message.
$wgAuth_Config['NoWikiError']    = 'You are not a member of the required phpBB group.'; // Localize this message. 

$wgAuth = new Auth_phpBB($wgAuth_Config);     // Auth_phpBB Plugin.
   */

After you comment out the code, save it to the default location on your MediaWiki directory. Run the update script: 

/usr/local/php5/bin/php update.php

You should update successfully. Go back and restore your Auth_phpBB code (the same block you commented above) and save to your MediaWiki directory.

You should be back to normal.

Installing Extensions

MediaWiki extensions are small bits of code that you can install (in your own MediaWiki install), that add functionality to MediaWiki. The way they are installed is by copying the *.php file of the extension over to [Your wiki-domain name]/extensions/ directory (see above), and then appending the following code to your [Your wiki-domain name]/LocalSettings.php. 


include( "extensions/[Insert php filename here]" );


Other Extensions

  • query.php
  • rss.php
  • ParserFunctions are the set of extensions that permit the relatively more complex if/then expressions, which are helpful with templates and transclusion. meta.wikimedia.org includes the php files and very brief, simple instructions for install.


Modifying the .css file

With MediaWiki, you can change or add features to the look of an article by changing the default css file. Each skin has its own css file, and there is also a common css file for all skins. To open any of these files for editing, simply search in the wiki for "MediaWiki:[Name of skin].css" (no quotes), or for the common css file search for "MediaWiki:Common.css" (no quotes).

Example

A fairly useful addition to the Common.css class is the Infobox. By changing the common.css code, you can add a small floating information table on the right hand side of the article, without interfering with its contents. To do so, take the following steps:

  1. Open the common.css file for editing by searching for "MediaWiki:Common.css" (no quotes) within the wiki itself.
  2. Add the following code: 
/* Infobox template style */

.infobox {
   border: 1px solid #aaaaaa;
   background-color: #f9f9f9;
   color: black;
   margin-bottom: 0.5em;
   margin-left: 1em;
   padding: 0.2em;
   float: right;
   clear: right;
}
.infobox td,
.infobox th {
   vertical-align: top;
}
.infobox caption {
   font-size: larger;
   margin-left: inherit;
}
.infobox.bordered {
   border-collapse: collapse;
}
.infobox.bordered td,
.infobox.bordered th {
   border: 1px solid #aaaaaa;
}
.infobox.bordered .borderless td,
.infobox.bordered .borderless th {
   border: 0;
}

.infobox.sisterproject {
   width: 20em;
   font-size: 90%;
}

/* styles for bordered infobox with merged rows */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
   border: 0;
   border-top: 1px solid #aaaaaa;
   border-right: 1px solid #aaaaaa;
}

.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
   border: 0;
   border-right: 1px solid #aaaaaa;
}


/* styles for geography infoboxes, e.g. countries, national subdivisions, cities, etc. */

.infobox.geography {
   border: 1px solid #ccd2d9;
   text-align: left;
   border-collapse: collapse;
   line-height: 1.2em; 
   font-size: 90%;
}

.infobox.geography  td,
.infobox.geography  th {
   border-top: solid 1px #ccd2d9;
   padding: 0.4em 0.2em 0.4em 0.8em;
}
.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
   border-top: solid 1px #ccd2d9;
   padding: 0.4em 0.2em 0.2em 0.8em;
}

.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
      border: 0;
      padding: 0 0.2em 0.2em 0.8em;
}

.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
   border-top: 0;
   border-bottom: solid 1px #ccd2d9;
   padding: 0 0.2em 0.4em 0.8em;
}

.infobox.geography .maptable td,
.infobox.geography .maptable th {
      border: 0;
      padding: 0 0 0 0;
}

Now you can take advantage of the new .css class, just like how Wikipedia uses it in the Infobox Template.

Changing User Default Preferences

To change the default preferences for users who are not logged in and/or new accounts, you can check out this article.

MediaWiki licensing

When MediaWiki is installed the installer selects the appropriate licensing (usually, GFDL or Creative Commons). Changes to the licensing can be made in LocalSettings.php .

See MediaWiki licensing settings for settings and detailed intructions.

See Also

External Links

Retrieved from "http://wiki.dreamhost.com/MediaWiki"
Personal tools