There are two elements to this project: the decision on whether to cloak or not, and then the final output of the cloaked content.
In this case, WordPress is *really* going to mess with you because the code base is HTML with PHP Tags, rather than PHP outputting HTML, if you understand the difference. If not, here you go: The right way to code PHP looks like this:
<?php
$str = <<<HTML
<html><body>
Hello World
</body></html>
HTML;
echo $str;
?>
as opposed to the Word Press methodology (the files look like this):
<html><body>
<?php echo 'Hello World'; ?>
</body></html>
The problem is that in the second version, HTML is output *immediately* to the client and you have no chance to modify it. In the first version, you can modify the code to change how/when things are spit out - in the second you cannot. Ergo, in the first version you could change do str_replace on $str before it gets spit out to the surfer, in the second version you cannot. This, obviously, offers a particularly grueling challenge to cloak word press.
How do you modify a link when you have no idea when/where in the code it's being "spit out" at the user? If it's already gone, how do you modify it?
There are a couple options here, none of which are pretty:
First option: Huge and very custom mods to the WordPress code base. At first glance, I'd probably wrap all link outputs into an object method call, so that I could modify it. Consider this first example, then modified so that I can cloak the link:
Uncloaked example:
<table><tr>
<td></td>
</tr></table>
Cloakable example:
<table><tr>
<td><?php $cloaker->translate(''); ?></td>
</tr></table>
... then I'd have a class definition and an object called "cloaker" that decided, based on the IP address, if I should return the URL as passed in, or use a REGEX to convert it to my cloaked version. Obviously you'd need to get into the codebase for WordPress and see where it is appropriate to define this class and instantiate the object.
Second option: Man in the middle attack. This is a more "weighty" approach and may complicate other things like posts and such, but if you had WordPress answering on port 81, for example, and you had your man-in-the-middle server answering on port 80, then when a page request came into the site, your process would proxy the request into WordPress on port 81, then when it got all the HTML back, it would be one big string and you could have your way with it utterly. This solution would be very powerful since you could change anything about WordPress in the future (your theme, capabilities, plugins etc) and none of your modifications would be affected since they exist in a layer completely separate from Word Press. I'll not describe the Apache VirtualHosts and such that you'd need here unless you find that you like this option and need help. But consider this code (I'm using my webRequest class here for example - I think cURL would be far better but this is fine for an objective example):
<?php
$req = new webRequest2();
preg_match('/(^(*.\.com)(.*)$/iU'), $_SERVER['REQUEST_URI'], $parts);
$newURL = "{$parts[1]}:81{$parts[2]}";
$pagebuff = $req->simpleGet($newURL);
$pageBuff = str_replace('<a href="http://anothersite.com/">', '<a href="http://anothersite.com" rel="nofollow">', $pageBuff);
echo $pageBuff;
?>
This is a rather silly example and would need (obviously) to be considerably more complicated in the search/replace phase, but I hope you get the idea.
This problem is probably why people aren't giving you much joy @ syndk8 on this issue Natt... it's not pretty but can be done. Depends on your stomach and will for it. Doesn't scare me one bit, but I'd really need to have a strong reason to go that deep.
/p
