WordPress is a great piece of software driving billions of sites across the internet. One of the main reason WordPress does so well is because the community gives back freely and often. While these community contributions to the project mean that WordPress is continually enhancing its feature set, it also means that a web site powered by WordPress is continually in need of upgrades.

Being the excellent software that it is, WordPress gives you the ability to ‘Auto Upgrade’ to the latest version. If you’re running an unmodified installation and you don’t have too many plugins, this is an excellent option and I would highly suggest you give it a try.

If you’re going to upgrade WordPress to 2.9 on your own, we want to provide you with the following suggestions and resources.

1. Always backup your database and your file structure (especially the wp-content folder) before upgrading. You can never be too safe. This goes for manual upgrades as well as auto upgrades!
2. Always deactivate plugins prior to upgrading. If you have a lot of plugins and your site gets a lot of traffic, this may be tricky. It’s not ‘necessary’ but its safe practice because if one of your plugins doesn’t mesh with the new version of WordPress it may render your site inaccessible.
3. We would suggest checking with all your plugins’ authors to see if their plugin is compatible with the latest release of WordPress prior to upgrading.
4. Most hosts give priority to index.html over index.php. We often use this tactic to put up a nice “Site down for scheduled maintenance” message during the upgrade. This is obviously optional.
5. You can find a detailed step-by-step instructions for manually upgrading WordPress on their website: http://codex.wordpress.org/Upgrading_WordPress_Extended

Finally – and lets be honest, the real reason we wrote this post – if you have had trouble with WordPress upgrades in the past or are a little bit hesitant to do it yourself, check out http://wpupgrade.com. It’s a site that FullThrottle just launched with the sole purpose of helping others upgrade their WordPress installations.

It has recently been reported that WordPress blogs are being attacked by a Brute-Force campaign.

A Brute-Force attack happens when a malicious individual creates an automated script with the sole purpose of guessing your administrative password. It does this by pointing the script at your blog’s login URL: http://yourblogsdomain.com/wp-login.php. The script repeatedly guesses at your login name and password from a dictionary of commonly used usernames and passwords.

Here is an explanation from the post linked above:

The wp_brute_attempt() function takes 3 parameters, $ch which is cURL’s structure (cURL is a command line tools that can be used to perform HTTP requests). The other two parameters define the site and the password that will be tried. If the script logged in successfully, the page that gets returned by the server will contain the phrase “Log Out”, and the function will return a true value.

If you are currently running a WordPress blog and would like to secure your site against these attacks, the easiest thing to do is to simply change your admin username and to make sure you have a strong password in place.

If you would like assistance securing your site against this attack, FullThrottle is available to help. Simply contact us for more details.

One of my first experiences with the social web was Del.icio.us. I stopped using it shortly after Yahoo! aquired it, but that’s a different story. The reason I bring it up is because I loved the way that you could search for multiple tags by including a + sign in between each tag in the URL. Can you even do that anymore?

So, I’ve been wanting to do this with WordPress categories for a while now and recently had the motivation to make it happen (aka: a client needed it).
Below is my first draft. It only works with permalink structures for now. I’m looking for some feedback and ‘beta testing’ before I put it into the WordPress plugin repository. Would anyone like to help?

How it currently works:

1. Download, unzip, FTP to your site’s plugins folder.
2. Activate the plugin.
3. Visit http://yourdomain.com/categories/cat1-slug+cat2-slug+cat-3slug+etc/
4. You should get a listing of all your current posts that are in all of the above categories.

Templates, Titles, etc

I am currently using the following logic for determining what theme file is used to display your posts:

1. If there is a file called categories.php, use that.
2. If there is a file called archive.php, use that.
3. If there is a file called index.php, use that.
4. If there is a file called 404.php, use that.

I currently have the following functions available to help you build a title for your archive page

1. is_categories() returns true if you are on a categories page ie: /categories/ is in the URL
2. ft_mca_titles() returns an array of titles for each of the categories in your URL

Download the zip file here: ft-multiple-category-archives.php.

Leave comments below. Thanks!

[Update] WordPress 2.8.5 just dropped. It addresses the DoS attack among other issues. Get it here.

There have been several reports this morning of a DOS attack affecting the WordPress wp-trackback.php file.

• [original post] http://www.stevefortuna.com/new-0-day-wordpress-exploit/
• http://jarraltech.com/2009/10/new-0-day-wordpress-exploit/
• http://www.hashbangcode.com/blog/wordpress-dos-attack-script-solution-2135.html

All the the solutions have been the same thus far and require editing your .htaccess file or the wp-trackback.php file.

FullThrottle has composed this quick plugin that accomplishes the same thing as the edit to the wp-trackback.php file. You may download the plugin below or paste the following code into your theme’s functions.php file.

We will update this post and our code if further insight into the attack deems it necessary.

function ft_stop_trackback_dos_attacks(){
	global $pagenow;
	if ( 'wp-trackback.php' == $pagenow ){
		// DoS attack fix.
		if ( isset($_POST['charset']) ){
			$charset = $_POST['charset'];
			if ( strlen($charset) > 50 ) {  die; }
		}
	}
}
add_action('init','ft_stop_trackback_dos_attacks');

Download the plugin here: ft-stop-trackback-dos-attacks.php

One reason that WordPress is such a great tool for blogging is due to its excellent commenting features. As a blog owner, you can choose whether you want to allow comments on your posts, whether you want to moderate the comments, or whether you want to let each of those comments automatically post without moderation.

WordPress allows you to specify a couple options for comment moderation out of the box:

• An administrator must always approve the comment
• Comment author must have a previously approved comment
• Hold comments for moderation if more that ## links appear in the comment
• A black list of terms that always send a comment to moderation

This plugin provides you with one more option: Always moderate comments for the following categories.

So, if you have a blog where you allow people to comment freely, but you always want to moderate comments for one specific category, follow the directions below to implement our solution:

1. Download the plugin here until its listed in the WP repository
2. Unzip the file
3. Place the ‘ft-auto-moderate-comments-by-category.php’ file in plugins folder
4. Activate FT Auto Moderate Comments By Category in the WordPress plugin admin page
5. Go to Settings -> Discussion and look for the ‘Auto Unapprove Comments by Category’ setting.
6. Place a comment separated list of categories you want always moderated as false in this field. ie: 1,3,4,6
7. Save and test.

Please let us know if you have any questions or comments

[update: you can now download this as a plugin. file at bottom of post]

WordPress has a great admin interface for managing just about every aspect of the software. One integral part of this interface is the “Authors & Users” screen:

This is a great utility and it gives us,  as the developers, the freedom to let our clients have control over their own authors and users.

If you develop like we do though, you’ve probably learned that its better for everyone when we limit the clients ability to have access to areas of the site that they don’t need on a day to day basis. The Plugins and Appearance utilities are a great example.

This usually isn’t a problem because WordPress integrated role management into their software. A common solution – and one that we use at FullThrottle – is to simply retain the “Admintrator” role for yourself and split up the remaining roles for your client as needed. No problem!

What if we don’t want our clients to be distracted by the default “Administrator” account that we leave in tact though? Is there a simple way to remove this from the client’s screen? Well… if simple means fool proof and strictly using PHP and WordPress hook, then no (though we may submit some patches to make this possible). Regardless, what you can’t do with PHP, you can always do with jQuery. Below is our ‘smoke and mirrors’ way to remove all administrator level roles from the User’s screen if being viewed by anyone not in that role.

Removing Administrators from WordPress Users & Authors

All of the code below will be placed in your theme’s functions.php folder:

Step one: Queue the jQuery. Technically, jQuery should already be enqueued, but better safe than sorry:

// Enqueue jQuery
add_action('admin_enqueue_scripts' , 'ft_hide_administrator_jquery' );
function ft_hide_administrator_jquery(){
	global $pagenow;
	if ( 'users.php' == $pagenow ){
		wp_enqueue_script('jquery');
	}
}

Step Two: Remove ‘Administrator from the dropdown boxes

// Remove Administrator from "Editable Roles"
add_action( 'editable_roles' , 'ft_hide_adminstrator_editable_roles' );
function ft_hide_adminstrator_editable_roles( $roles ){
	if ( isset( $roles['administrator'] ) && !current_user_can('level_10') ){
		unset( $roles['administrator'] );
	}
	return $roles;
}

Step Three: Use some jQuery magic to remove the administrator

// Hide Administrator from list of users
add_action('admin_head' , 'ft_hide_administrator_user');
function ft_hide_administrator_user(){
	if ( !current_user_can('level_10') ){
		?>
		<script type='text/javascript' >
			jQuery(document).ready(function(){
                          var admin_count;
                          var total_count;

			  jQuery("#list-filter > .subsubsub > li > a:contains(Administrator)").each(function(){
			  	admin_count = jQuery(this).children('.count').text();
				admin_count = admin_count.substring(1, admin_count.length - 1);
			  });
                          jQuery("#list-filter > .subsubsub > li > a:contains(Administrator)").parent().remove();
			  jQuery("#list-filter > .subsubsub > li > a:contains(All)").each(function(){
			  	total_count = jQuery(this).children('.count').text();
				total_count = total_count.substring(1, total_count.length - 1) - admin_count;
				jQuery(this).children('.count').text('('+total_count+')');
			  });
			  jQuery("#users > tr .administrator").parent().parent().remove();
			});
		</script>
		<?php
	}
}

That’s it! As always, if you find any bugs or have any suggestions, just leave a comment. Below is a link to download the whole chunk of code. Just paste the contents into functions.php and you should be good to go!

Download Code:

• Zipped PHP file
• Text File
• Plugin zip

Final Result:

In WordPress MU there are two levels of users. There are users who have a blog and users who do not have a blog. This option is usually chosen when the user creates their account. If they choose to have just a username only (no blog), then the user is added as a subscriber to the main site (default setting). If they chose to have a blog, WPMU adds a subsite for them with an administrator user for that subsite. However, it does not give them subscriber permissions to the main site.

This became an issue with a site I was working on recently. The main site had a calendar that any logged in user needed to be able to add an event to. To do this I had to create a custom group that allowed users to post in a specific category only, which worked great, except for blog users. Since blog users are not given any rights on the main blog, I needed to find a way to automatically create the same functionality that normal users have on the main site.

This is what I came up with:

function ft_new_user_meta($blog_id, $user_id) {
add_user_to_blog('1', $user_id, 'calendar' );
}
add_action( 'wpmu_new_blog', 'ft_new_user_meta', 10, 2 );

Basically, I hook onto the wpmu_new_blog function, so whenever it is called, it calls my ft_new_user_meta function. Which passes in the two variables $blog_id and $user_id. Then I run the function, add_user_to_blog with 1 as the blog_id for the main site, the $user_id that I’m adding, and the role that I want to give. In this case it is my custom “calendar” role.

I added that into a file named new_user.php which I placed in the mu-plugins directory. Now, whenever a user goes to the site and creates their own blog, it gives them access to the main site with rights to add events to the calendar.

If you have any WordPress blogs on 1and1 then you’ve probably ran into some problems with updating certain plugins, updating the blog, or even importing to your blog. The reason is because 1and1 has some issue with PHP4 but there is an easy fix.  You need to hand edit your .htaccess file (located in the root of your WordPress directory). Here you will add the line, AddType x-mapp-php5 .php to the end of the file. It doesn’t matter too much where you put it, so it’s best just to put it at the end.

Let us know if this helps you out or not.

We recently ran into a client who needed help getting his WordPress installation and his WordPress MU installation communicating together. They had WordPress installed in the root directory of their website, and WPMU installed in a sub-directory of the same website. Both WP installations were on the same DB.

Unfortunately I was unable to get a good copy of their MySQL tables, so I had to recreate this setup on my own. I did a little research and found out that many people have similar setups and many people have different solutions. I felt like it might be beneficial to share my experience with this.

First, I downloaded the latest WP and WPMU (2.8.1 at the time). I setup a new MySQL DB and extracted WP and WPMU into their respective directories (remember WordPress was in the root and WPMU in a sub-folder).

Something like this:

/wordpress/
/wordpress/wpmu/

After messing around for a while I determined it was easiest to install WPMU first. There was two reasons for my thinking, one of which was no necessary. First, if you were to install WordPress first, when you tried to install WPMU it would get confused because it would see the wp-config.php file below. Don’t ask me why this is, it just is. Second, I was thinking about changing the WP DB prefix (default: wp_) to something else. In WordPress you can do this during the install, in WPMU you have to edit the files to get this accomplished. This was the part that wasn’t really important, because I actually kept both using wp_ as the prefix.

Ok, WPMU is installed and working, now I installed WP. At the end of the install, it sees that there is already a wp_users table, with an Admin user in it. This caused me a little problem because I think it actually reset the password without telling me the new password. So I had to go into phpMySQL to reset the password to something I knew. Hardly a huge problem, but still it might make you think that everything is broken when you cannot log into either WP or WPMU!

Now, the goal is to be able to log into either WP or WPMU and then not have to log in again when you switch to the other. So, I needed to be able to log into WP and then go to WPMU without it asking me to log in again (and vice-versa). This is all about COOKIES! There are a bunch of people who have different solutions, but the easiest solution for me was to make sure that both the WP auth cookie and the WPMU auth cookie were identical. This is not as easy as it sounds, because MU handles cookies slightly different than WP. But ultimately, I just needed to edit wp-config.php in both WP and WPMU to get it to work perfectly.

Here are my setting changes:
define(‘COOKIE_DOMAIN’, false);
define(‘ADMIN_COOKIE_PATH’, ’/’);
define(‘COOKIEPATH’, false);
define(‘SITECOOKIEPATH’, false);
define(‘COOKIEHASH’, ‘vy48u9w38868t7t99jh8g137x221r5h1h8’);
define(‘AUTH_KEY’, ‘49uld4y46i3432ugvi346uv86uci53v5529jj5z265i987u43snbxwj3ps92u2lr’);
define(‘SECURE_AUTH_KEY’, ‘f2et8b6xck64m4j2vmqcuqxb57s3rk5edh5d19pq114ef7y67g35i6m682lr288z’);
define(‘LOGGED_IN_KEY’, ‘mywu969v3tcf2uer82vxisx8k6sq2neib5qs1qt4sx383slslb5t1xep12hbtcxs’);
define(‘NONCE_KEY’, ‘bde6j26r93lvwmgwydw7x3kp74r5299q8vxe832y7r616lf215142e5t4vc55j36’);
define(‘AUTH_SALT’, ‘3856m559klvidrx34fi574ct32r94x77bepr7638jmuw22d29883i82k76un2tm4’);
define(‘LOGGED_IN_SALT’, ‘jq4p67bv772nd73w4zm6286552x755v6293qpj5fbe34fxy894trdu77h38586n2’);
define(‘SECURE_AUTH_SALT’, ‘i9hlmd67n21j2u485645in9vu6v92itgfmja6bjfbc36gqc673svlis9u789316p’);
define(‘TEST_COOKIE’, ‘TEST_COOKIE’.COOKIEHASH);

I actually copied the AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, LOGGED_IN_SALT, and SECURE_AUTH_SALT from the WPMU wp-config.php file. I just copied it over the normal WP wp-config.php settings. Then I added the other lines and everything worked. It didn’t require any additional plugins or work.

I sent the instructions to the client, he followed exactly what I did here and it worked fine for him. So, if you have a similar need, I’m pretty confident this will work for you.

I thought it would be cool to see what the WordPress 2.8.1 source code would look like as a Wordle. To make this, I had to merge all the .php files from WordPress into one file and copy the text into the Wordle engine. In linux, I unziped a fresh copy of WordPress and ran this command in the wordpress directory:

find . -name "*.php" -print | xargs cat >> ../wordpress.txt

Then I copied the text from the file (approx. 4.2MB worth) and pasted it into Wordle. I played around with the Wordle settings a bit and thought this was a pretty good representation of WordPress. What do you think?