Category Archives: Wordpress

WordPress: Get path to uploads folders

Working with other people’s code can be quite frustrating at times, because coders, even the best, sometimes make unwarranted assumptions.

Among these assumptions are the locations of certain folders. Often people will hard-code a path wp-content. While this is a convention, this is not a universal. This value can be changed, and many do simply as a small added defense against bots.

Along these lines is also hard-coding a path to the uploads folder.

WordPress allows us to access the path programatically using wp_upload_dir() as such

$path = wp_upload_dir();
echo $path['url'];

Sometimes, though, one doesn’t necessarily want that extra line. I prefer to keep a minimum of code in my templates, when possible. Here’s my small little work-around. Just copy and paste the following code into you functions.php file, or where ever you please.

Call it as such get_uploads_dir('baseurl');

See in-line comments for a reminder of which path you would like it to return.

function get_uploads_dir( $arg ) {
	 * A small utility to make these paths available in a one-liner
	 * [path]   => /home/
	 * [url]    =>
	 * [subdir] => /2008/11
	 * [basedir]=> /home/
	 * [baseurl]=>
	 * [error]  =>
	 * */
	$image_path = wp_upload_dir();
	switch ( $arg ) {
		case 'path':
			$str = $image_path['path'];
		case 'url':
			$str = $image_path['url'];
		case 'subdir':
			$str = $image_path['subdir'];
		case 'basedir':
			$str = $image_path['basedir'];;
		case 'baseurl':
			$str = $image_path['baseurl'];
			$str = '';

	return $str;

For more details on wp_upload_dir();


Twitter Widget Pro does not update Tweets: one fix

Twitter Widget Pro Stopped updating Tweets
Twitter Widget Pro stopped working.
Twitter Widget Pro fails to update Tweets

Just a quickie for those who are stymied by the fact that the WordPress plugin Twitter Widget Pro seems to work, then stop, or to fail to work at all.

It’s not Twitter Widget Pro’s fault. There might be a conflict with other plugins, something in your theme, or in your .htaccess file.

I’ve just re-discovered the cause of my own issue.

It is a conflict with another plugin. Specifically Better WordPress Security, and even more specifically, one of the rules that are inserted into the .htaccess file when one chooses to add the anti-hacking rules (Ban tab ▶ User and Bot Blocklist ▶ Add Host and Agent Blocklist ▶ [ ] Check this box to enable’s blacklist feature.).

My fix was to remove the added .htaccess rules. I haven’t taken the time to figure out exactly which one it is, however. That would be a long and tedious testing process.

May I recommend to the developer, should they read these comments to include the above fact in their FAQ? I bet it would save a lot of headaches both in terms of support and for the general users.

Good luck, fine people, I hope this helps.

Updated BlogCFC2WordPress to be compatible with WP 3.5

From the original BlogCFC2Wordpress utility:

This utility will migrate your data from a BlogCFC db into an existing WordPress 2.0 db. It has been tested on CFMX7 and BlueDragon 6.2 running on Windows against a MySQL 4 db and BlogCFC v. 3.8. The schema for v.5 of BlogCFC has some new fields added but it doesn’t look significantly different so it will probably work with minor modification. All the logic is contained in cfc’s and there is no funky sql syntax or stored procs so it should work with other databases.

This is an update to the above utility that will migrate your BlogCFC database to WordPress 3.5+

Download the WordPress 3.5 compatible version here.

Download the WordPress 2.0 compatible version here.

Thank you to Sean Tierney from for writing it, and of course to Ray Camden for BlogCFC and to the WordPress team.

WordPress Security: Preventing hackers and spammers: Better WP Security, Sucuri and CloudFlare

WordPress security: It’s time to start ramping it up again

My ISP provided me with the following link by ArsTechnica

Huge attack on WordPress sites could spawn never-before-seen super botnet

Ongoing attack from >90,000 computers is creating a strain on Web hosts, too.

WordPress security is a particularly big deal at this moment in time. It’s a huge platform and well recognized enough to be considered worth it’s own attacks by spammers and crackers.

While I don’t know these people, they’ve written an excellent primer on securing your WordPress setup.

How to ward off spammers and crackers?

I had already been using Better WP Security. It’s an excellent plug in, free and donationware. Over a period of about 90 days, it has reported the following to me:

Your database contains 9416 bad login entries.
Your database contains 1530 404 errors.

Interestingly enough, other than the occasional typo on my part, the 9416 bad logins used “admin”. Having not only changed the default user name, but squarely removed it (No user ID 1 in the database) and using strong passwords, I felt relatively secure, and Better WP Security gave me a baseline of this particular activity on my site. The 404’s in this case were pointing to non-existent files (duh!) such as FrontPage files, or various config paths.

Recent spammers are aggressive enough to be considered de facto crackers.

I followed up with this article by

Protecting Against WordPress Brute-Force Attacks

By the way offers a very use malware scanning service. Very handy if you use WordPress security techniques.


While I’m relatively confident of the security of my site, I’m not one for shunning potential positive layers of services..

Cloudflare stands as a CDN between you and the web. Sign up, and simply change your DNS name servers, and it does the job. The free version offers enough to make it worthwhile to give it a serious try. Cloudflare offers a free and feature-full group of services for the little guy, as well as an extended range of services (such as SSL support) for paid accounts.

Now, with a baseline provided by Better WP Security, we’ll see how CloudFlare fares over the next 90 days. I’ll keep you posted.


Using categories and tags on WordPress pages (not posts)

This may belabouring the obvious to those with more experience, but I busted my chops on this for a couple of weeks, so I thought that I’d share it.

By default, WordPress allows us to use categories and tags on posts only.

The key point here is to remember that both categories and tags are taxonomies.

To allow pages to use categories and tags, include this simple function in your functions.php file.

function addCatAndTagsOnPage(){
    register_taxonomy_for_object_type('post_tag', 'page');
    register_taxonomy_for_object_type('category', 'page');
add_action('admin_menu', 'addCatAndTagsOnPage');

Once this is done, you’ll surely want to access your pages that have a given category. In this case, I set it my category.php template.

// Get the current category slug
$cat = get_category( get_query_var( 'cat' ) );

// Arguments for our query to retrieve category taxonomy
   'post_type' => 'page',
   'taxonomy' => 'category',
   'term' => $cat->slug,

// Instantiate a value for the query
$the_query = null;

// Perform the query
$the_query = new WP_Query($args);

// Loop over the query results. In this case we're stuffing the title and link in a list
if( $the_query->have_posts() ) {
   echo '<ul>';
   while ($the_query->have_posts()) : $the_query->the_post();
      echo '<li><a href="' . get_permalink() . '" rel="bookmark" title="Permanent Link to ' . get_the_title() . '">' . get_the_title() . '</a></li>';
   echo '</ul>';
wp_reset_query(); // Restore global post data