We thought this was a weird environment issue at first, but then I found this post that showed me it’s a common issue that’s been reported to their development team.

I continued searching for a solution and got some direction from a solution by @foralien on the BuddyPress forums. Her solution did not work for, but I created my own version and had success.

What was happening?

Our BuddyPress installation was trying to get avatars from /blogs.dir/1/files/avatars/{$user_id}/{$filename} – which did not eve exist, this was referencing a files directory for the root blog and it didn’t even exist.

As per @foralien’s solution, I created 2 filters (one for the avatar path, the other for the avatar public URL):

Download the Code

// Custom filters to clean up issues in WP 3.0 with avatar paths.
// Written by @theandystratton
function sizeable_bp_core_avatar_folder_dir( $path ) {
	$items = explode('/', $path);
	$path = ABSPATH . 'wp-content/uploads/avatars/' . end($items);
	return $path;
}
add_filter('bp_core_avatar_folder_dir', 'sizeable_bp_core_avatar_folder_dir');
function sizeable_bp_core_avatar_folder_url( $url ) {
	$items = explode('/', $url);
	$url = 'http://' . $items[2] . '/wp-content/uploads/avatars/' . end($items);
	return $url;
}
add_filter('bp_core_avatar_folder_url', 'sizeable_bp_core_avatar_folder_url');

What it’s doing

We’re filtering the path and the url for avatars to ensure it’s using the WP 3.0 location, which is the upload_path for the root site followed by /avatars/{$user_id}. This is not a forever fix. I’d use it as duct tape until they release a BuddyPress update for WP 3.0 fixing the issue.

Hope this helps you guys and saves you some time and frustration.

So, I give you the cleaner (special thanks to Michael Safovich for requesting and testing).

What’s it do

It recursively looks through it’s current directory (and subdirectories) for PHP files (by default it’s looking for php, php4, php5 and phtml extensions, but this is customizable) and killing any whitespace in the beginning of the file, turning:

   
   
   
<?php include_once './wp-blog-header.php'; ?>

into this:

<?php include_once './wp-blog-header.php'; ?>

Make sense? Good, here’s the download link.

Tips & Customization

BACK UP YOUR FILES. You agree to take responsibility for running this, because I sure don’t (though I think you’ll be fine).

To run on custom file types, edit the $fileTypes array to include the types you want to strip leading whitespace from.

The script will run for the current directory. You will need to set the $directory variable to contain the path you’d like to recursively clean, in most cases you’d drop the cleaner.php file in your document root and hit it in the browser.

It will run immediately and output a log. Hope it helps. ¡Hasta luego!

I have also updated the download of the fix on this page to strip leading white space.

So GoDaddy wasn’t the only host attacked by this malware PHP hack. I’ve found traces on client’s BlueHost shared Linux hosting as well. Apparently some other hosts, including Network Solutions.

One host I use (along with multiple clients) who I haven’t seen or heard about being affected is HostGator. My dedicated box(es) have not been affected either.

This is NOT an issue exclusive to WordPress installs. Tons of WordPress installations have been affected but WordPress is currently the most-installed PHP/MySQL web application on the web today, especially in these shared Linux hosting environments. I’ve seen this same attack affect sites with basic PHP files using only include statements as well as other PHP/MySQL applications such as Joomla (*shudder*).

What the attack seems to be doing

• Adding a line of base64 encrypted PHP to be evaluated before most PHP scripts run
• Common strings in hacked files include:
  • <?php eval(base64_decode(
  • <?php eval(gzinflate(base64_decode(
• Some of this code is injecting content into your page’s output for search engines, some redirecting users
• I’ve found some sites commonly have the file ./wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/style.css.php which is a lot of eval() wrapped base64 encoded strings (it’s been recursively encrypted and after 15 iterations I needed to get back to client work)
• I also found some files without extensions in the ./wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/ directory (t (looks to be a template), lb (links, link back perhaps?) and kwd (keywords) — there was also a file named cnf which looked to be encrypted configuration for the hack as well as another file called csi which contained an IP and Unix timestamp.

Updated Fix for the Hosting Hack

Please note: this is not an all comprehensive fix. This can help clear out some code very quickly but you should still take some drastic efforts (see below) to clean up your site and protect yourself.

Download Shared Hosting Attack Fix »

Instructions:

1. Make time this week to figure out and implement a plan for backing up your site and database, either via your hosting provider, your own shell scripts, or VaultPress.com is looking very good right now if you’re on WordPress.
2. Back up your site files. Even if they are hacked, get a copy of everything locally just in case.
3. Download shared-hosting-fix.php.txt and rename it shared-hosting-fix.php
4. Place the file somewhere in your document root and visit it in a browser to review what files are infected. If you’re not seeing affected files here, make sure the contents of the $hack_str variable on line 30 is the same as the beginning of the hack’s code. Some have been different by a space here and there, which will affect this clean up script.
5. If you have infected files, you can press the “Fix Files” button at the bottom of the page to start the automated task of removing the first line of malicious code
6. Confirm that you want to make the changes on the popups and you will see a simple log display when all is said and done
7. Back up your clean(er) files and take more steps to audit your files and database to try to avoid recurrence

Do More to Clean Up and Protect Yourself (WordPress)

Just a few notes about other things you can (and should) do:

• Make regular backups — Lazy? Checkout VaultPress
• Clear any and all cache files on your server. I’d literally de-activate the caching plugins, remove them and their associated directories and then download and re-install them
• Back up your wp-config.php file and wp-content directory then completely remove all of your WordPress files and directories, then re-upload from a fresh and up-to-date WordPress install. Audit your wp-content directories and wp-config.php file before re-uploading.
• Use some WP Security plugins:
  • WP Security Scan
  • WordPress File Monitor
  • WordPress Exploit Scanner
• Check your database, specifically the wp_options table for suspicious code (see Chris Pearson’s post below, How to Diagnose and Remove the WordPress Pharma Hack

WordPress Security Reference Links

Thanks to some friends at Automattic and in the WordPress community, here are some links for your reference:

• WordPress Security Presentation
  A great WP security presentation by Brad Williams of WebDevStudios
• Securing wp-admin
• Securing wp-config.php
• Moving wp-content
• Installing WP with Clean SVN Repositories
• If you’re a busy, well-to-do, business person who just doesn’t have the time, you could contact and hire a outstanding WordPress and PHP developer and occasional blogger… </shamless_self_promotion>

Some Reference Posts For Reading:

• CONTINUING STORY – Dangerous Malware Alert – Self-Hosted Sites Hack Update – Go Daddy Responds! | WPSecurityLock
• Simple cleanup solution for the latest WordPress hack
• http://smackdown.blogsblogsblogs.com/2010/05/13/hosting-with-godaddy-might-want-to-rethink-that-decision/
• How to Diagnose and Remove the WordPress Pharma Hack
• How to cure your GoDaddy WordPress hacked blog

This can prove to be a pain during the development or migration process. It can also make it annoying if you happen to change your permalink structure and have tons of posts.

Introducing dynamically inserted WordPress permalinks with The Permalinker

The Permalinker will allow you to use WordPress short codes to dynamically insert permalinks and permalink URLs into your posts via the content editor.

How it works:

When editing content, simply use the the short code to insert a link:

[permalink]This is a link to the current post

Linking to a different post:

You can set the id attribute in the short code to point to a specific page/post:

A link to post 23

Supported anchor attributes:

Currently, the following attributes are supported in the short code and will be added to the resulting anchor element: class, rel, and target.

[permalink id=23 class="my_class" rel="self" target="_blank"]Open post 23 in a new window

Want more control over your markup?

Using a non-terminating or empty http://theandystratton.com/2009/the-permalinker-wordpress-plugin-dynamic-permalinks short code will simply output the permalink URL:

<a href="http://theandystratton.com/2009/9-revision-3" class="thickbox" id="link_23">Another link to page/post 23</a>

There’s more: Dynamically grab your template directory

As a request from fellow WordPress designers and developers, I’ve included a http://theandystratton.com/wp-content/themes/theandystratton short code as well, allowing you to quickly and dynamically get the full URL to your active template directory from the content editor:

<img src="http://theandystratton.com/wp-content/themes/theandystratton/photos/yoda.gif" alt="A picture of Yoda!" />

Download Permalinker

You can learn more and download The Permalinker from the WordPress plugin repository.

Happy coding ;]

I started by displaying a count($posts), but since I’ve got my installation showing 5 posts per page, that consistently displayed 5 or less posts. Less than desirable.

So, the next step was duplicating the search query so I could get the count, and as usual I like to try to use the WordPress functions as opposed to touching the database directly:

<?php
$tmp_search = new WP_Query('s=' . wp_specialchars($_GET['s']) . '&show_posts=-1');
$count = $tmp_search->post_count;
echo $count . ' results for ' . htmlentities($_GET['s']) . '.';
?>

Unfortunately, the code above still gave me the wrong count. Why? My settings were still set to 5 posts per page; and the WP Query object as assuming this constraint.

The Solution: send posts_per_page=-1 as part of the query.

<?php
$tmp_search = new WP_Query('s=' . wp_specialchars($_GET['s']) . '&show_posts=-1&posts_per_page=-1');
$count = $tmp_search->post_count;
echo $count . ' results for ' . htmlentities($_GET['s']) . '.';
?>

…and there you have it. A nice functional search results page. For even further refinement, I’m limiting my search to blog posts, and excluding pages by including post_type=post in my query.

Some Requirments.

1. Sorry, but you’re going to need ISAPI Rewrite 3. You can download a lite version for free, but I suggest purchasing it. I’ve used ISAPI Rewrite for years now with clients on Windows hosting, and it’s the bees knees. Version 3 is now supporting many common mod_rewrite directives, which is sweet.
2. Your .htaccess file. Here’s an example that has worked with WordPress 2.7.x, ISAPI Rewrite 3, and Windows Server 2003/IIS 6.0:

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

How it works.
Even with ISAPI Rewrite, your WordPress permalinks most likely will be broken without the ugly, prepended /index.php/. The problem is that the REQUEST_URI server variable is not sent by IIS or ISAPI Rewrite. This plugin solves this.

This solution is more elegant that changing the WordPress core files because it allows you to easily upgrade WordPress without additional maintenance.

Download and Documentation.
You can download ISAPI Rewriter from the WordPress Plugin directory.

You can view documentation at the ISAPI Rewrite plugin page.

Check out more about it on Matt’s blog and check out all of Matt’s great WordPress plugins he has made available for free.

The Problem

Let’s say in header.php of my template, I’m pulling a post:

if ( have_posts() ) :
	the_post();
	$current_page_id = get_the_ID();
endif;

This works, but, it increments the cursor of the global $posts array by one. The issue it caused in one of my older projects was that the blog home page (where the array contains 5-10 posts) was never displaying the most recent post.

The Fix – rewind_posts()

Luckily, WordPress has a nifty little function call rewind_posts() that will… rewind posts.

if ( have_posts() ) :
	the_post();
	$current_page_id = get_the_ID();
	rewind_posts();
endif;

Using this will throw The Loop back to where it should be.

A better way?

An alternative method of grabbing the ID, san-WordPress functions/tags, would be to grab the ID from the global $posts array. This would save the trouble, but strays from using WP’s built-in library of functions:

global $posts;
$current_page_id = $posts[0]->ID;

This works well, and requires fewer lines of code, but I tend to try to stick with the WP functions, as they will aid in keeping your code/plugins/themes future compatible.

• WPLookup now accepts the function parameter in a get or post request, allowing some fun browser plugins and the ability to direct link to queries if you so desire.
• Instead of a notice and link to the function reference when documentation is not found, WPLookup will send you to the documentation search results for your query. This makes WPLookup both get you to documentation and search the Codex itself. Note: WPLookup will exchange spaces for your underscores in this scenario to create real search terms.

Adding a custom search engine to Firefox and Opera

Thanks to @aaronwaggs for the idea to create a custom search engine for WPLookup.

Here’s how you can add WPLookup to your web browser’s search toolbar.