I started out wanting to create a Linux environment where I can experiment with MediaWiki software. I have a RedHat 9 Linux machine, which means I needed to:

• Upgrade Apache, to include dynamic module loading and mod_rewrite.
• Upgrade PHP, since MediaWiki requires newer versions
• Install MySQL, which wasn't available and the version that came with RH9 is too old.

Another goal I had was to change the skin of my wiki. Monobook is used for most of the wiki's out there, and I wanted my site to look different. Since this is a personal web site, I will also need to lock down the number of contributors allowed to edit my site.

Ultimately I want to move this work to a live system (what you are reading), this article outlines the steps I took to create such a sandbox environment and eventually move to production.

Compiling Apache 2 and PHP

If you download Apache from http://httpd.apache.org/download.cgi, in the archive there is an INSTALL file that describes the steps you need to perform. The important ones are, when running the configuration script you need to add --enable-so --enable-rewrite. You can make the modules static or dynamic; see `./configure --help` for more information.

Apache needs to be compiled and installed first, because one of the utilities from Apache is required to build PHP. After you install Apache, note that it is not in the same location as the default RH9 httpd. You can correct this any way you like, I just created symbolic links to point to new httpd.

PHP from http://www.php.net/downloads.php also includes an INSTALL file that describes everything, includes the necessary flags for Apache 2.

Installing MySQL

You can download generic RPM binaries or source code from http://dev.mysql.com/downloads/mysql/5.0.html. Check the start up scripts under /etc/init.d/ and make sure they point to correct locations.

If this is a new installation of MySQL server, you should create root password first.

Configuring Web Server

After installing PHP, you need to copy PHP library to modules directory of Apache, and update httpd.conf so that Apache can load PHP library and handle new types of files (.php and .phtml).

If you want error documents to be pointing at an article in your wiki, you can edit httpd.conf or .htaccess to include:

ErrorDocument 401 <action/path> # authentication failed
ErrorDocument 403 <action/path> # access denied
ErrorDocument 404 <action/path> # document not found
ErrorDocument 500 <action/path> # internal server error

For a list of error codes, see this page.

Installing MediaWiki

MediaWiki is installed in-place, you extract the directory structure into your WWW root, and point your web browser to location of MediaWiki directory. It will ask you to fill out forms that defines name of site, MySQL password and database connect information, copyright schemes, etc.

Should you decide to delete MediaWiki, you just need to remove the tables created in your database (they have a prefix you defined during MediaWiki setup) and remove the directory containing all MediaWiki files. You may want to keep LocalSettings.php for future reference, if it's heavily modified.

Once installation is complete, and you can access article Main_Page with the default skin, MediaWiki is running.

Blocking Public User Creation

This is done by adding the following lines to LocalSettings.php:

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

Once this is done, the "create new account" link will not be visible at the login page. As a logged in sysop (which you specified during MediaWiki setup), however, you can access Special:Userlogin and create new accounts, and later add the new users to the groups you designate.

Shorter URL

By default, you can see index.php all over the place because it is the script that generates HTML code for you. Sometimes it is useful to hide this portion of the URL because it makes the final URL easier to remember or type by people. This is done by creating and editing a .htaccess file at MediaWiki or WWW root directory of your web server, and include in that file rewrite rules for mod_rewrite.

Please see this bookmark, under Customizations for link to a site that shows the rewrite rules.

You can add additional lines to avoid rewriting certain directories (such as the directory you use for uploads):

RewriteCond %{REQUEST_URI} !^/<wiki_directory>/<directory>/

Without such exclusions, if your upload directory is under the rewrite root, the link will be re-written to point to (non-existing) articles instead of your files.

Skin Customization

I started by designing in HTML and CSS the layout site. This is done so that I could easily experiment with:

• Cross-browser compatibilities
• CSS/Javascript files for your site
• Navigation for your site

Know that once you try to integrate PHP components into your site template, the end result is not nearly as readable for debugging. A good way maybe to start with the monobook.php skin, as it contains all of the hash keys to data you can use in context (you can compare generated HTML with source code). Note that monobook.php extends SkinTemplate.php, so that's another file you can read to get more information.

Personally I felt that in order to distinguish the site completely, I needed to start fresh and not inherite too much design or code from monobook.php. So puchu.php, skin used by this site, has a lot of new code that changes strings dynamically for my design, and some code from monobook.php to manage views and special links.

For views and special links, the original monobook.php skin has many navigation links on the side. Most of them are not helpful to a small site, such as the one I am running. Also, because there are limited number of contributors, I decided to hide all of the navigation links and views using JavaScript. This is only used to hide the links because I still want lynx users have a chance of using the site.

To remove all other available skins so that user can only use puchu.php, the following code is added to LocalSettings.php:

$wgSkipSkins = array('monobook', 'chick', 'cologneblue', ...);

Color By Categories

Navigation of this site is done mainly by the tabs at upper-right. Each tab defines the color theme of the pages under them. So for example, the majority of the pages under "home" section is green.

In order to achieve this, most of the documents are tagged with a category like this:

[[category:<category_name>]]

And puchu.php parses the data $this->['catlinks'] to determine which tab the page is under, and changes the id of body element. The CSS, looking at that id, then renders the tabs and colors accordingly. This has a nice benefit of the navigation degenerating nicely into a list when the browser does not support CSS.

There may be better ways, but hey, I am new to this.

Patching Up CSS

Once the basic site is up and running, I started to realize that my original CSS did not include all the new classes used to format various pages generated by MediaWiki, for example, the diff view in history, user preference, the portlet for views and navigation on the side.

Looking at generated HTML it is easy to figure out what I missed, and I added the missing classes back into my CSS file.

Finally, there are HTML segments generated by MediaWiki that are not necessary when you try to print the page. When designing the interface I already had separate CSS files for different media, so all I had to do is edit the CSS for print and change the unwanted classes to include display: none; somewhere.

Supporting LaTeX

To support adding mathematical formulas on Puchu.Net, I ended up using mimetex by John Forkosh as suggested from Mimetex alternative article. The reason for not using the built-in texvc utility is because it requires utilities not available on my web server, such as gs, latex, dvips, and I have to compile it with OCaml. In this case mimetex is really the only solution.

Compiling mimetex is easy, and there are a few options you can enable to make sure other people are not abusing your CGI resource (-DREFERER=\"puchu.net\"). It is also possible to cache generated images (-DCACHEPATH=\"...\"). The output is nice and anti-aliased (-DAA). The author's web site has all the instructions necessary to make it work.

JavaScript Integration

In addition to some JavaScripts used to help with the user interface or presentation of Puchu.Net, additional JavaScripts not authored by me have been integrated with some modifications:

1. Nifty Corners Cube™ by Alessandro Fulciniti, is used to create round corners. Please see 2007-02-12_News for more information.
2. Basic Calendar by Brian Gosselin with minor modifications by Dynamic Drive and myself. Original author's page is here.

These JavaScripts are small, easy to modify and they render on the client side, so they are a great way to introduce helpful features without complicated server-side codeing.

Uploading Files

Uploading files via HTTP POST is supported by MediaWiki, but you are restricted by the default limits of PHP. You can see what those limits are, by calling a built-in PHP phpinfo(); function and it will generate all of the information for you.

If you are getting an error complainiing about files being bigger than server's configured limit, then you need to check with the following PHP parameters (I included the values I use also):

upload_max_filesize "3M"
post_max_size "3M"
memory_limit "8M"
file_uploads "On"

You can add these to .htaccess or http.conf files by prefixing keyword php_value. Adding them to LocalSettings.php as suggested by some sites did not help me at all.

Deploying Site

When I setup the directory structure and coding in my sandbox, the references were all relative, and all the passwords to connect to database server are the same. All I needed to do is FTP the files in place and initialize the database.

I also installed extensions, such as DynamicPageList to automatically generate content for navigation. You can see it at work on the front page. All documents in Puchu.Net belong to at least one category, making this particular extension very useful to integrate.

Certain extentions used together causes an error in the form of a message "UNIQ...<extension>...QINU"; for example, NewestPagesBlog conflicts with DynamicPageList. some researching shows that the cause is $wgOut->parse() being called recursively. If you can use newer versions of the extensions sometimes the issues are fixed, but I am not so lucky because I am stuck with older versions of PHP, MySQL and MediaWiki with the current server.

The solution is to use a locally instantiated parser class, like what DynamicPageList did. But in the end, instead of changing NewestPagesBlog, I modified DynamicPageList myself to include the news text.

To disable caching for extensions, I used this hack and disabled both server and client caching by adding to LocalSettings.php:

$wgCachePages = false;
$wgCacheEpoch = 'date +%Y%m%d%H%M%S';

This hurts server performance, but this is not a busy site.

To set up default time zone for my site, the following code (from this page) is added to LocalSettings.php:

$wgLocaltimezone = "America/Los_Angeles";
$oldtz = getenv("TZ");
putenv("TZ=$wgLocaltimezone");
$wgLocalTZoffset = (date("Z") / 3600) + date("I");
putenv("TZ=$oldtz");

Check PHP Manual on using the date() function. The version of MediaWiki running on this site is older, uses hours instead of minutes. The code above should also take care of daylight saving time.