Ed's Big Plans

Computing for Science and Awesome

Archive for the ‘mediawiki’ tag

Move a Subdirectory to a Subdomain (Apache mod_alias)

without comments

In this post, I’m going to explain how to move resources located at a subdirectory of your domain to its own subdomain. The reason why I came across this was because I decided to move my MediaWiki installation to better separate the URLs corresponding to my blog and my notebook — this is paired with better separation of the actual files and directories corresponding to my blog and notebook as they exist on my server. I’ll assume that you’re running Apache; I’ll further assume that you’ve already gotten your A-RECORD set up with your domain registrar or name server provider (DNS) — if you don’t know what that means, ask me.

I’ll use my MediaWiki move as my running example for this post.

Here are some properties we want a redirect to satisfy — I’ll lead you through to making a redirect such that each of these conditions are met.

  1. Moving the subdirectory to a subdomain corresponds to moving files on the server filesystem.
    • (URL) http://eddiema.ca/wiki = ~/Sites/eddiema/notebook (server filesystem)
    • (URL) http://wiki.eddiema.ca = ~/Sites/notebook (server filesystem)
  2. Requests to the subdomain must work.
    • http://wiki.eddiema.ca
  3. Requests to the subdirectory must be forwarded to the subdomain.
    • http://eddiema.ca/wiki →
    • http://wiki.eddiema.ca
  4. Requests to subdirectories of the former subdirectory must be forwarded to subdirectories of the subdomain.
    • http://eddiema.ca/wiki/index.php/Special:AllPages
    • http://wiki.eddiema.ca/index.php/Special:AllPages
  5. URLs with GET requests to the subdirectory must be forwarded to the subdomain without losing the GET requests.
    • http://eddiema.ca/wiki/?search=Notes+CIS+6050
    • http://wiki.eddiema.ca/?search=Notes+CIS+6050

Let’s meet each of our above properties.

Changing the URL corresponds to a physical move (Property 1)

Move your subdirectory on the server to its target location on the server.

For my example, I moved my notebook out of my main site directory.

mv ~/Sites/eddiema/notebook ~/Sites/notebook

(If you’re moving a MediaWiki installation like me, there’s one more thing you have to do — this is explained at the end.)

Requests to the subdomain must work (Property 2)

Update your Apache httpd.conf configuration file with a new VirtualHost entry. This new entry stipulates a new document root for your target subdomain.

#<VirtualHost *:80>
#    ServerName {full URL to your new subdomain}
#    DocumentRoot {full path to your new document root}

# Example ...
<VirtualHost *:80>
    ServerName wiki.eddiema.ca
    DocumentRoot /Users/eddiema/Sites/notebook

Requests to the subdirectory must be forwarded to the subdomain (Properties 3~5)

There are two ways to accomplish this task — you can either modify Apache’s httpd.conf file, or you can create a new .htaccess file. I chose the latter because I wanted to keep all of the changes related to this move localized.

To accomplish this task, you must perform two steps.

First, you must recreate the subdirectory on your server filesystem that you have just moved elsewhere. We do this so that a request for that directory causes Apache to look there for a .htaccess file in the correct place. This .htaccess file will tell Apache to redirect to your new subdomain instead.

For my example, I recreated the subdirectory with…

mkdir ~/Sites/eddiema/notebook

Second, Create a new plaintext .htaccess file in the recreated subdirectory with a RedirectMatch rule.

#RedirectMatch 301 ^/{subdirectory}/(.*)$ http://{full subdomain URL}/$1

# Example ...
RedirectMatch 301 ^/wiki/(.*)$ http://wiki.eddiema.ca/$1

RedirectMatch is part of mod_alias. If you’re doing something more sophisticated than just forwarding URLs, then you will need to use mod_redirect which has the ability to manipulate query strings.

The number 301 tells browsers and search engines that the URL pointing at your subdirectory is no longer valid and has permanently moved to the one pointing at your new subdomain. The next part is a PERL style regular expression. Let’s break it apart.

  • ^ and $ match the start of, and end of the string respectively.
  • .* means we want to match zero or more characters in a string.
  • (.*) means we want to save the matched string as an autovariable $1.

The last string is appended with $1 to push the tail of any URL of your subdirectory onto the tail of your subdomain.

A final note for moving a MediaWiki installation

In order to stop MediaWiki from appending the subdirectory “wiki” to the tail of your new subdomain (“http://wiki.{your domain}.*/wiki“), you can change the variable $wgScriptPath to the empty string in LocalSettings.php found in the root directory of your MediaWiki installation.

#$wgScriptPath       = "/wiki";
$wgScriptPath       = "";

Note that MediaWiki doesn’t seem to like this idea — but they don’t really say explain why.

After this step, you can use Short URLs (same as above link) to get rid of index.php appearing in the URL, but I won’t go into that today.

That’s everything 😀

Eddie Ma

February 23rd, 2011 at 12:36 pm

URL mangling for HTML forms (a better Mediawiki search box)

with 3 comments

Followup: This is better than my previous Mediawiki search box solution because it doesn’t require an extra PHP file (search-redirect.php) to deploy. It relies completely on URL mangling inside the HTML form on the page you are putting the search box. Previous post here.

A valid HTML form input type is “hidden”. What this means is that a variable can be set without a control displayed for it in a form. Other input types for instance are “text” for a line of text and “submit” for the proverbial submit button — both of these input types are displayed. Variables set by the “hidden” input type are treated as normal and are shipped off via the GET or POST method that you’ve chosen for the whole html form…

So, to create the following mangled URL…


There are the following variables … with the following values:

  • title … “Special%3ASearch” (%3A is the HTML entity “:”)
  • search … “searchterms” (the only variable requiring user input)
  • go … “Go”

The only variable that needs to be assigned from the form is “search” to which I’ve assigned the placeholder “searchterms” in the above URL.

The form thus needs only to take input for the variable “search” with a “text” type input, while “title” and “go” are already assigned– a job for the “hidden” type input.

Here’s what the simplest form for this would look like…

<form action="http://eddiema.ca/wiki/index.php" method="get">
Search Ed's Wiki Notebook:
<input name="title" type="hidden" value="Special:Search" />
<input name="search" type="text" value="" />
<input name="go" type="hidden" value="Go" />
<input type="submit" value="Search" />

Again, replace the text “Search Ed’s Wiki Notebook” with your own description and replace “http://eddiema.ca/wiki/index.php” with the form handler that you’re using– it’ll either be a bare domain, subdomain or could end with index.php if it’s a Mediawiki installation.

And that’s it! A far simpler solution than last time with the use of the “hidden” type input to assist in URL mangling.

Update: Here’s an even more improved version — this time, the end user doesn’t even see a page creation option when a full title match isn’t found. Demo (hooked up to my wiki) and Code below …

<form id="searchform" action="http://eddiema.ca/wiki/index.php" method="get">
<label class="screen-reader-text" for="s">Search Ed's Wiki Notebook:</label>
<input id="s" type="text" name="search" value="" />
<input name="fulltext" type="hidden" value="Search" />
<input id="searchsubmit" type="submit" value="Search" />

Notice that the variables “Special:Search” and “go” are not actually needed — instead, the variable “fulltext” is assigned the string “Search” — this causes mediawiki to hide the “You can create this page” option.

Eddie Ma

June 4th, 2010 at 8:39 am

Add an arbitrary Mediawiki search box anywhere!

without comments

Update: A better solution that doesn’t require a separate “search-redirect.php” file has been posted here.

I’ve been looking for this solution for a long time now and I’m happy to have finally found it. Following hints from Dave Taylor and Peter De Decker, I’ve glued together a solution that doesn’t take too much effort and doesn’t require any additional hacking around in SQL.

The objective was to add a search box on the right-column navigation of this blog that would search my wiki notebook. It wasn’t until I stumbled on the above two blogs that I realized I can just mangle URLs to conduct a search on mediawikis! The specific URL used to search my wiki looks a little like this…


It might be a bit different for your installation depending on the version that you installed and a few of your settings– to find out what it looks like, search for something and copy down the URL in the address bar.

The file “search-redirect.php” used by Wikipedia takes in your search terms, and mangles those terms into a URL conforming to the above example. It then redirects you to that constructed URL. You can find this used on the main page of Wikipedia as noted by Dave.

My search-redirect.php based on Peter’s work above is two lines long, and looks like this:

$redirect_url =
@header( "Location: ".$redirect_url );

You probably want to place your own search-redirect.php in the root directory of your wiki installation– however, it looks to me like it doesn’t really matter since the whole URL is rewritten anyway. I bet you can put this file anywhere on the net that supports PHP. The final thing that’s missing is the search box– anything that uses this formula will work:

<form action="http://eddiema.ca/wiki/search-redirect.php" method="get">
Search Ed's Wiki:
<input type="text" name="search" />
<input type="submit" value="Search" />

Putting this code on a page with your own wiki URL as a stem instead of mine will allow you to search your own wiki from any other page.

Eddie Ma

June 3rd, 2010 at 9:54 am