How often is it that we want to clarify our text by explaining our terms, so most of our readers actually understand what we’re saying and how often is it that we end up with an article that’s either bloated with explenational lyrics to a song called “The article I was supposedly writing” or an article far too in-depth for the common reader. A lot of people stop reading when they find out they have to read a Wiki article every five sentences, but others really love that and spend their late hours on browsing through all that extended information.

I myself came up with a solution. It’s not uncommon to link to Wiki articles and even so uncommon is the absense of a JavaScript library. Given the static link structure of Wiki articles, it’s not that hard to extract the part that says what article you link to. My solution involves jQuery, some raw JavaScript, some PHP, some configuration using .htaccess and either a subdomain or a folder on a working domain.

So, what’s the big idea?

We’re going to make a proxy for Wikipedia, using the TXT records, which we will use to generate balloons with a summary of the Wiki for that keyword. This way we solve three things:

1. We don’t bloat our article, but do give extra info for difficult terms;
2. We provide readers who don’t like to constantly be sent to Wikipedia with a good summary of the article;
3. People whom still wish to read the full article can click on the link and still get all the info needed;

As an addition, it’s a great support for SEO, because linking to articles with extra information on your article is what helps you rank high on “the Google”.

Provide me with the goodies

Okay, so lets assume you either made a new subdomain or a folder on your website where we send the queries to. First we want to prepare our Apache settings:

RewriteEngine On
RewriteBase /home/wiki/public_html/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

The RewriteBase should fall back to the current working directory by default, but sometimes this works and sometimes this doesn’t, so making this static prevents it from failing. The conditions are there to assure the file we requested doesn’t already exist (which we will use later on to make a cache) and the same for directories. Next up we make sure the request in a whole is given to index.php.

Now we want to populate index.php with some code:

<?php
$q=substr($_SERVER['REQUEST_URI'],1);
exec('dig +short txt '.$q.'.wp.dg.cx',$dig);
$dig = str_replace('" "','',implode("\n",$dig));
if(!file_exists($q) && !empty($dig)) { file_put_contents($q,$dig); }
die($dig);
?>

And what does this do? Well, maybe I should give an example of how we request the text first:

If I want to know something about Unix systems, I simply make a request for http://wiki.johmanx.com/unix.
Since I actually went for making a special subdomain, wiki, I can make requests like that.

Back to the code: In the first line we see the variable $q, which is simply the Request URI minus the first character, since in my example that would be /unix and we only want unix. Then comes a system command. Windows users should actually stop reading at this point, because dig is in no way available on a Windows server. No worries, because when I get to the Ajax part, there’s still a lot of fun stuff we can do. The dig command is a tool in Linux that allows us to get information about DNS records from a domain. In this case we don’t request information about the typical A record, but we do so for the TXT record. Now, normally we use that to store some information that clarifies what we do with a certain domain, but something.wp.dg.cx actually stores the wiki summary for the term something. By giving it the +short parameter, we make sure we don’t get any fancy data for that domain, but only the contents of the TXT record.

The only thing that remains in the code is a basic filtering for weird closing and opening quotes and to make sure that when it ever happens that a TXT record exists of multiple lines, we actually make sure all the lines are present. Then we check if we don’t overwrite a file by putting this in cache (god forbid I don’t do this and someone gets the bright idea to create and query the article index.php). Then finally we make sure to stop the script and end with only echoing the text we just queried.

But now we’re stuck with Cross Domain AJAX calls

Hmm. I have to give you that. Well, the reason I went for a subdomain approach is because I can provide Windows users with my proxy as where the Linux users can put this in a folder and get a more optimal aproach. So, provided we stick with the cross domain solution, we need to make something like XD.php for our AJAX. It should contain something like this:

<?php
echo file_get_contents('http://wiki.johmanx.com/'.$_SERVER['QUERY_STRING']);
?>

Now, if we request XD.php?waffles, we should get some text rambling about a “batter based cake”.
For a simple AJAX call, I tend to fall back to this simple piece of code:

var createXMLHttpRequest = function() {
    if (window.ActiveXObject) {
        return function() { xmlHttp = new ActiveXObject("Microsoft.XMLHTTP"); }
    } 
    else if (window.XMLHttpRequest) {
        return function() { xmlHttp = new XMLHttpRequest(); }
    }
}();
 
function GETRequest(queryString,cb) {
    createXMLHttpRequest();
 
    xmlHttp.onreadystatechange = cb;
    xmlHttp.open("GET", queryString, true);
    xmlHttp.send(null);
}
 
function POSTRequest(url,query,cb) {
    createXMLHttpRequest();
 
    xmlHttp.open("POST", url, true);
    xmlHttp.onreadystatechange = cb;
    xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");    
    xmlHttp.send(query);
}
 
function ajaxDone() {
    if(xmlHttp.readyState == 4 && xmlHttp.status == 200) {
        return true;
    }
    return false;
}

Now we can make a very jQuery like request for our article:

$("body")
	.delegate("a","hover",
		function(){
			var keyword = $(this).html();
			GETRequest('XD.php?'+keyword,
				function(){
					if(ajaxDone()){	
						$('#balloon-keyword-'+keyword).html(xmlHttp.responseText).show();
					}
				}
			);
		}
	)
	.delegate(".balloon","mouseout",
		function(){
			$(this).hide();
		}
	);

Provided each summary is given a link to the original article, we could add a filter to automatically make anchor links, but to keep this article as simple as possible for quick implementation, I provide the filter apart from that bit of jQuery:

function txt2html(txt) {
  var exp = /(\b(https?|ftp|file):\/\/[-A-Z0-9+&@#\/%?=~_|!:,.;]*[-A-Z0-9+&@#\/%=~_|])/ig;
  return txt.replace(exp,"<a href='$1' target='_blank'>$1</a>");
}

That way you could apply a filter to the summary, which will automatically transform a URL to an anchor link.

Now, say you’d want to do this the proper way and put the wiki script in a folder called /wiki/, you could replace ‘XD.php?’ with ‘/wiki/’ and get the same result. This way you don’t have to make Cross Domain calls and you can make optimal use of the cache I provided.

Some other thoughts

Now we’re finished setting up our fine proxy, some thoughts come to mind.

This would make for a good HTTP proxy to apps for the iPhone, iPad and Android platforms. I could see a number of apps coming from this. On top of that list is an App for quickly getting extra information about the ingredients of your recipe. Somewhat lower I’d suggest a Trivia app that generates random questions and gets the answers via a similar proxy. In my opinion, there’s a whole number of apps that could bloom this way. Anyone up for the challenge?