Archive for the 'HOW-TO' Category

5/4/2008 ↓

Error Management for WordPress Plugins 9comments

Author: Ronald Huereca Category: HOW-TO, WordPress

Thanks for visiting! If you're new here, you may want to subscribe to our RSS feed. This blog posts regular Wordpress news, updates of themes, plugins, ideas, hacks, quick fixes and everything about blogging, especially about Wordpress. Go ahead, subscribe to our feed! You can also receive updates from this blog via email.

For the past few weeks I’ve been working on a WordPress plugin. One of my goals was to have fancy and relevant error messages.

I contemplated writing my own error manager, and even began a very basic one. I experienced hurdle after hurdle, and finally I thought to myself, “Wouldn’t WordPress have its own error manager also?”

So I did a quick source-code search and came across the WP_Error class.

One of the hurdles I ran into in creating my own error manager was error localization. The WP_Error class makes localizing error messages extremely simple.

Adding Error Messages

To add an error message, the first thing you’ll want to do is instantiate your own instance of WP_Error.

$myErrors = new WP_Error();

The next step is to add in your error messages.

$myErrors->add('access_denied', __('You do not have permission to do that.',$myLocalizationName));

There are a few things to notice here. There is something called an error code, which you will use to look up the full error message. You also have the full error message, which uses the __ function for localization.

Retrieving Error Messages

After you have added in your error messages, you’ll want to retrieve them at some point.

Retrieving an error message is as simple as calling the get_error_message method and passing it your error code.

$errorMessage = $myErrors->get_error_message($code);

From there you can echo out your message in whatever manner suits you.

Applications

Using the WP_Error class is ideal for those with themes and plugins.

For plugins, it’s best to have your errors as a member of a class. Using the class approach assures that you can access the errors throughout your methods, and also avoid naming conflicts.

For themes, you can also create your own class, or have a prefixed variable so you don’t have possible conflicts with other variables.

Downloadable and Example Code

Here is some downloadable code with an example of how the class might be used in a theme. As stated earlier, plugin authors may want to use a class for this.

The code is assumed to be placed in a theme’s “functions.php” file.

class my_class {
	function my_class() {
		$this->localizionName = '';
		$this->errors = new WP_Error();
		$this->initialize_errors();
	}
	/* get_error - Returns an error message based on the passed code
	Parameters - $code (the error code as a string)
	Returns an error message */
	function get_error($code = '') {
		$errorMessage = $this->errors->get_error_message($code);
		if ($errorMessage == null) {
			return __("Unknown error.", $this->localizionName);
		}
		return $errorMessage;
	}
	/* Initializes all the error messages */
	function initialize_errors() {
		$this->errors->add('my_weird_error', __('Some weird error has occurred', $myLocalizationName));
		$this->errors->add('access_denied', __('You do not have permission to do that.',$myLocalizationName));
	} //end function initialize_errors
}
$myErrors = new my_class();
echo $myErrors->get_error('my_weird_error');

The above code has two helper methods, one which retrieves the errors, and one which initializes the errors. The example is very basic, but should give you a good idea on how to use the WP_Error class.

Conclusion

There are many features of the WP_Error class not mentioned here, but you can dissect the code yourself if you like. The class is found in the wp-includes folder under classes.php.

The WP_Error class is a simple and powerful way to store errors, and output them rather easily. And the best thing, the messages can be localized.

Tags:

4/28/2008 ↓

Exporting-Importing A Category 15comments

Author: Jeff Chandler Category: HOW-TO, WordPress, WordPress Hack

When it comes to exporting, WordPress already does a wonderful job with it’s support to export posts, pages, comments, custom fields, categories, and tags. However, there is a problem. The WordPress exporter lacks granularity. What I mean by this is that, the exporter covers the entire blog instead of being able to select certain categories to export. I’ve searched the WordPress Plugin database high and low to look for a plugin that would specifically export categories and I could not find one. I did manage to come across two techniques though that get the job done.

There are two ways to export specific categories. The first is to read this forum post where HandySolo explains how to use the category RSS feed to export specific categories from a self hosted blog to a WordPress.com blog. The problem with this method is that, none of the meta data attached to the posts are carried over with the posts.

The second method is not pretty but it gets the job done. What I ended up doing was creating a new user account on my blog. I then used the post manager and filtered the posts by the category for which I wanted to export. I went through each individual post and quickly changed the post author from the original account, to the newly created user account. In my case, I had to do this to 25 individual posts. What is annoying about this method is that, when you save a post under a new author name, any blogs or posts that you have linked to within those posts will end up resending PINGs. However, I believe if you turn off this setting under the SETTINGS-DISCUSSION link in your administration panel this will prevent that from happening. Just remember to turn that back on after you’re finished.

After all of the posts within the category have been reassigned to a new author, you are ready to export. In your WordPress administration panel browse to MANAGE - EXPORT. Now here is the important step. Underneath where it says OPTIONS, you have a drop down box where you can restrict the export to a certain author.

WordPress Export Options

In the drop down box, select the newly created author and click on the DOWNLOAD EXPORT FILE and a WordPress WXR file will be downloaded to your desktop. This file will contain all of the posts from the category you wanted to export because the new user you created was assigned to only those posts within that category. This method actually allows you to export specific categories while maintaining the meta data associated with those posts such as comments and tags.

This is probably not the best way to obtain these results but it’s the only method that I’ve found that allows me to export specific posts/categories while still having all of the other data attached to those posts. If you have a better solution or know of a plugin that can obtain the same results, I’d be very interested to know about it.

4/19/2008 ↓

Paging and Custom WordPress Loops 24comments

Author: Ronald Huereca Category: HOW-TO, WordPress Hack

Last week I published two articles using custom loops. The first was about how to create a custom loop. The second was how to retrieve posts based on custom fields. In both articles, several readers commented that they would like to see paging and have it explained.

I’d like to thank Aaron Harun from Anthology of Ideas for supplying the code used in this post.

Paging, and why it doesn’t work with WP_Query

The paging magic happens in a file called ‘link-template.php‘ in the ‘wp-includes‘ folder.

Most themes have basic paging built in, with the help of two functions: next_posts_link and previous_posts_link.

These functions, as well as several others, make use of a global variable called $wp_query. This variable is actually an instance of the WP_Query object. However, when we create our own instantiation of WP_Query, we don’t have this global variable $wp_query, which is why paging will not work.

How to make paging work with a custom loop

As Aaron mentioned, the paging functions rely on a global variable called $wp_query. The “fix” is to trick WordPress into using the global $wp_query variable when using our own custom loops.

In the example below, I’ll show how to display the last five recent articles with our own custom loop with paging intact.

<h3>Recent Articles</h3>
<ul>
<?php
$temp = $wp_query;
$wp_query= null;
$wp_query = new WP_Query();
$wp_query->query('showposts=5'.'&paged='.$paged);
?>

The first thing the code does (shown above) is create a temporary variable to hold a reference to global variable $wp_query. The wp_query variable is set to null, and we instantiate a new WP_Query object.

Notice in the query above that we have these parameters:

$wp_query->query('showposts=5'.'&paged='.$paged);

The paged portion of the query is critical in order to have paging.

From there, we can now do our own query and begin our custom loop.

<?php while ($wp_query->have_posts()) : $wp_query->the_post(); ?>
	<li><a href="<?php the_permalink() ?>" rel="bookmark"><?php the_title(); ?></a></li>
<?php endwhile; ?>
</ul>

Notice in the above code that the loop is initiated using the $wp_query variable. Since we are using $wp_query, paging should work.

Now it’s time to create our navigation links for paging:

<div class="navigation">
  <div class="alignleft"><?php previous_posts_link('&laquo; Previous') ?></div>
  <div class="alignright"><?php next_posts_link('More &raquo;') ?></div>
</div>

And finally, we assign the variable $wp_query back its original value using the $temp variable we set earlier.

<?php $wp_query = null; $wp_query = $temp;?>

The Full Code

<h3>Recent Articles</h3>
<ul>
<?php
$temp = $wp_query;
$wp_query= null;
$wp_query = new WP_Query();
$wp_query->query('showposts=5'.'&paged='.$paged);
?>
<?php while ($wp_query->have_posts()) : $wp_query->the_post(); ?>
	<li><a href="<?php the_permalink() ?>" rel="bookmark"><?php the_title(); ?></a></li>
<?php endwhile; ?>
</ul>
<div class="navigation">
  <div class="alignleft"><?php previous_posts_link('&laquo; Previous') ?></div>
  <div class="alignright"><?php next_posts_link('More &raquo;') ?></div>
</div>
<?php $wp_query = null; $wp_query = $temp;?>

Additional Applications

The above technique can allow paging for custom loops. All you have to do to modify this is to use your own query parameters, and change the code within the custom loop.

recent-articles-screenshot.jpeg
Recent Articles Example

The above example is live at raproject.com under Recent Articles.

Conclusion

Paging is a powerful WordPress feature, and fortunately you can use it when defining your own custom loops.

The example I demonstrated was rather generic, but hopefully you’ll be able to apply it to your own custom loops where paging is necessary.

Please feel free to share your own examples or problem code in the comments. If you use code, please use something like pastebin since some code isn’t allowed in the comment section.

4/13/2008 ↓

How to Only Retrieve Posts With Custom Fields 22comments

Author: Ronald Huereca Category: HOW-TO, WordPress, WordPress Hack

One question I come across a lot regarding custom fields is how to only retrieve posts based on a custom field.

For example, if a post has a custom field of “MyData”, someone might want to only retrieve that particular post.

The WordPress Codex has a technique for retrieving posts based on custom fields, which consists of writing your own query and going through the results.

The technique in the Codex is good, but I’ve found a re-usable way one can retrieve only posts with certain custom fields.

The technique I use makes use of two custom functions placed in a theme’s “functions.php” and a custom WordPress Loop.

Let’s get started — The “functions.php” file

First, let’s place the two custom functions in the “functions.php” file. This file should be in your theme directory, but if it isn’t there, you can create one using any text editor.

Here are the two functions below:

function get_custom_field_posts_join($join) {
	global $wpdb, $customFields;
	return $join . "  JOIN $wpdb->postmeta postmeta ON (postmeta.post_id = $wpdb->posts.ID and postmeta.meta_key in ($customFields)) ";
}
function get_custom_field_posts_group($group) {
	global $wpdb;
	$group .= " $wpdb->posts.ID ";
	return $group;
}

The function “get_custom_field_posts_join” makes use of an advanced WordPress filter called “posts_join“. Each time posts are called, you can add on extra MySQL parameters using filters. In this case, I add on an option to find certain postmeta. Please note the use of a global variable called “customFields“, which I’ll explain a bit later.

The function “get_custom_field_posts_group” makes use of another advanced WordPress filter called “posts_group“. This is used to avoid duplicate entries in our return query.

Now Let’s Work on Our Loop

After the two functions are placed in the “functions.php” file, it’s time to work on placing the appropriate code into one of our template files.

For this example, I’ll be modifying the “sidebar.php” file in the WordPress default theme. You could place the below code in any of your theme files, however.

<?php /* Begin Custom Field Posts */ ?>
<h2>Custom Posts</h2>
<ul>
<?php
global $customFields;
$customFields = "'Links', 'MyData'"; //Comma seperated 's1', 's2', 's3'

The first part of the code deals with establishing the structure of the output. You really could do anything you want here.

Please note the use of the global variable “customFields“. What we’re doing here is setting up a comma-separated variable that will be used to search for our custom fields. The “customFields” variable is used in the “get_custom_field_posts_join” function.

In this example, it is assumed we want to find posts with custom fields of “Links” and “MyData“.

Custom Fields - Links and MyData
Custom Fields - Links and MyData

The next bit of code instantiates a new instance of WP_Query and runs a query to return some posts.

$customPosts = new WP_Query();
add_filter('posts_join', 'get_custom_field_posts_join');
add_filter('posts_groupby', 'get_custom_field_posts_group');
$customPosts->query('showposts=5' );//Uses same parameters as query_posts
remove_filter('posts_join', 'get_custom_field_posts_join');
remove_filter('posts_groupby', 'get_custom_field_posts_group');

Note the use of the “add_filter” and “remove_filter” functions. Since we are doing a post query, we can tap into the query and add our own parameters. So before the query is initiated, two query-type filters are added, and after the query is initiated, the two filters are deactivated since we only want them run once.

This last bit of code initiates our custom loop, gets the custom values, spits them out, and ends the loop.

while ($customPosts->have_posts()) : $customPosts->the_post();
$links = get_post_custom_values("Links");
$data =  get_post_custom_values("MyData");
?>
<li><a href='<?php echo $links[0]; ?>'><?php echo $data[0]; ?></a></li>
<?php endwhile; ?>
</ul>
<?php /* End Custom Field Posts */ ?>

The “get_post_custom_values” WordPress function returns an array of matching keys. It’s assumed there is only one key per post, which is why we echo out the first value (Ex: echo $links[0]).

The Full Post Code

Here is the full post code. The only thing you need to change for your own use is the custom fields needed (change the customFields text) and what type of output is desired within our custom loop.

<?php /* Begin Custom Field Posts */ ?>
<h2>Custom Posts</h2>
<ul>
<?php
global $customFields;
$customFields = "'Links', 'MyData'"; //Comma seperated 's1', 's2', 's3'
$customPosts = new WP_Query();
add_filter('posts_join', 'get_custom_field_posts_join');
add_filter('posts_groupby', 'get_custom_field_posts_group');
$customPosts->query('showposts=5' );//Uses same parameters as query_posts
remove_filter('posts_join', 'get_custom_field_posts_join');
remove_filter('posts_groupby', 'get_custom_field_posts_group');
while ($customPosts->have_posts()) : $customPosts->the_post();
$links = get_post_custom_values("Links");
$data =  get_post_custom_values("MyData");
?>
<li><a href='<?php echo $links[0]; ?>'><?php echo $data[0]; ?></a></li>
<?php endwhile; ?>
</ul>
<?php /* End Custom Field Posts */ ?>

Custom Field Output
Custom Field Output

Downloadable Code

The full code mentioned in this post is available for download. Within the “zip” file are a sample “functions.php” and “sidebar.php“.

Conclusion

With the above technique, you can do some pretty fancy stuff. For example, you can only retrieve posts with custom images for a nice magazine effect.

If you have any questions regarding the code, I’ll do my best to answer them in the comments.

Define Your Own WordPress Loop Using WP_Query 29comments

Author: Ronald Huereca Category: HOW-TO, WordPress Hack

We all know what the WordPress Loop is right? If not, there are many great tutorials around the web that explain the WordPress Loop.

One of the easiest ways to navigate and manipulate the loop is to use the function called query_posts. Nathan Rice calls it a WordPress developers best friend.

When you use query_posts, however, you risk the following:

  • Potential to interfere with plugins which make use of the Loop.
  • Potential to invalidate WordPress conditional tags.
  • Having to deal with resetting, rewinding, offsetting…

I say skip query_posts. In a way you’ll still be using it, but the better (and sometimes easier) technique is to instantiate your own WP_Query object and create your own loop.

Creating Your Own Loop With WP_Query

The first step is to instantiate your own variable using the WP_Query class.

What we’ll be doing in this example is creating a common feature on blogs, which is to display a list of the recent articles.

<?php
    $recentPosts = new WP_Query();
    $recentPosts->query('showposts=5');
?>

All I’ve done in the above code is defined a variable named recentPosts and instantiated an instance of WP_Query.

I then used a method of WP_Query to start a query (pretty much the same thing as using query_posts). You even use the same usage parameters as query_posts.

Now it’s time to start our own loop:

<?php while ($recentPosts->have_posts()) : $recentPosts->the_post(); ?>
   <!-- do some stuff here -->
<?php endwhile; ?>

Notice the use of the recentPosts variable to start the loop. We utilize two methods of WP_Query, which is have_posts and the_post. You can read more about those two methods on my article Global Variables and the WordPress Loop.

The beauty of this is that once you are inside your own loop, you can use the standard post tags.

The Full Code

Here’s the full code for showing the last five recent posts using your own loop:

<h3>Recent Articles</h3>
<ul>
<?php
    $recentPosts = new WP_Query();
    $recentPosts->query('showposts=5');
?>
<?php while ($recentPosts->have_posts()) : $recentPosts->the_post(); ?>
    <li><a href="<?php the_permalink() ?>" rel="bookmark"><?php the_title(); ?></a></li>
<?php endwhile; ?>
</ul>

Update: Using Pagination

This comment is from Aaron Harun -

@Ron and Monika

If you use the query:

$recentPosts->query('showposts=5'.'&paged='.$paged);

it will automatically page the wury based on the page number passed
through the url eg "/page/4"

However, this doesn't work with the “post_nav_link” function because it
only checks the $wp_query variable. To get around this you have to
trick the function by switching $wp_query on it. Add the first block
before your custom loop and the second after to achieve this effect.

<?php //query_posts('paged='.$paged);
$temp = $wp_query;
$wp_query= null;
   $wp_query = new WP_Query();
   $wp_query->query('showposts=5'.'&paged='.$paged);
?>

<?php $wp_query = null; $wp_query = $temp;?>

Thanks Aaron for the contribution.

Conclusion

Defining your own loop using WP_Query is an easy way to run your own custom queries without interfering with the default Loop. It’s also a great way to run multiple loops that are completely independent of each other.

WordPress Resources mentioned:

3/8/2008 ↓

Managing Trackbacks and Pingbacks in Your WordPress Theme 32comments

With all of the recent discussion regarding trackbacks and pingbacks on Weblog Tools Collection, I thought I’d mention several ways one can deal with trackbacks and pingbacks in the context of a WordPress theme.

The topics I will be covering in this article are on separating trackbacks/pingbacks from regular comments, and also how to remove trackbacks and pingbacks from a WordPress theme completely.

Separating Trackbacks/Pingbacks From Comments

I know what you’re thinking: numerous posts have already been written on how to separate trackbacks from comments.

But what I present here is an actual separation using the “functions.php” feature for WordPress themes along with the regular “comments.php“. Both should be located in your theme directory.

theme_setup.jpg
Figure 1: Theme Directory Setup

Modifying the functions.php File

The “functions.php” file is a lifesaver for any theme developer or tinkerer wishing to add custom code or functions to themes. The code in the “functions.php” file can be called from all theme files, and can act as makeshift WordPress plugins (without the need for activation).

What we’ll be doing here is adding four functions and two filters into the file.

You don’t really have to understand the functions, but here are some brief explanations:

functions_php.jpg
Figure 2: functions.php Filter and Function Additions

  • filterPostComments: Updates the comments number for all posts so that trackbacks aren’t included in the count.
  • filterComments: Separates the trackbacks from the comments as global variables.
  • stripTrackback: Strips trackbacks from an array.
  • stripComment: Strips comments from an array.

The two filters we add in are explained below:

  • comments_array: Basically the comments before they are read in the comments loop.
  • the_posts: An array of all found posts.

Ok, enough with the explanations. Here’s the code for the “functions.php” file:

add_filter('comments_array', 'filterComments', 0);
add_filter('the_posts', 'filterPostComments', 0);
//Updates the comment number for posts with trackbacks
function filterPostComments($posts) {
	foreach ($posts as $key => $p) {
		if ($p->comment_count <= 0) { return $posts; }
		$comments = get_approved_comments((int)$p->ID);
		$comments = array_filter($comments, "stripTrackback");
		$posts[$key]->comment_count = sizeof($comments);
	}
	return $posts;
}
//Updates the count for comments and trackbacks
function filterComments($comms) {
global $comments, $trackbacks;
	$comments = array_filter($comms,”stripTrackback”);
	$trackbacks = array_filter($comms, “stripComment”);
	return $comments;
}
//Strips out trackbacks/pingbacks
function stripTrackback($var) {
	if ($var->comment_type == ‘trackback’ || $var->comment_type == ‘pingback’) { return false; }
	return true;
}
//Strips out comments
function stripComment($var) {
	if ($var->comment_type != ‘trackback’ && $var->comment_type != ‘pingback’) { return false; }
	return true;
}

Do you need to know how it works? Not really. But in summary, it separates comments from trackbacks and updates the comment count for all posts.

Modifying the comments.php file

Unlike most separation tutorials, we will not be modifying the comments loop.

In essence, we are expanding on a previous tutorial that also uses the “functions.php” file for separation of trackbacks and comments.

What we’ll be doing is the following:

  • Adding a “trackbacks” global variable right after the comments loop.
  • Initiating a trackbacks/pingbacks loop.

comments_php.jpg
Figure 3: comments.php Load Order

Right after the comments loop ends, you would add the following:

<?php global $trackbacks; ?>
<?php if ($trackbacks) : ?>
<?php $comments = $trackbacks; ?>
<h3 id="trackbacks"><?php echo sizeof($trackbacks); ?> Trackbacks/Pingbacks</h3>
	<ol class="commentlist">
	<?php foreach ($comments as $comment) : ?>
<!-- Your trackback HTML -->
<?php endforeach; /* end for each comment */ ?>
	</ol>
<?php endif; ?>

The code looks just like the comments loop except for a few lines of code, and the best part is, no editing of the original comments loop was necessary.

Download the Code

Here is a downloadable copy of the code presented in this post. The files within this zip file are:

  • Sample “functions.php” file.
  • Sample “comments.php” file.

I realize this solution is not the simplest demonstration of comment/trackback separation, but it allows for two actual and separate loops, and also produces a valid comments number(comments with trackbacks/pingbacks subtracted out) for all posts.

Removing Trackbacks/Pingbacks from WordPress Themes - Three Ways

When I asked the readers here if trackbacks were still useful, several expressed that they would be willing to remove trackbacks/pingbacks from comments.

With WordPress, I have found three ways to remove trackbacks and pingbacks from a WordPress theme.

Method 1: Edit the comments.php File

Located in almost every theme directory is a file called “comments.php“. Within this file is what’s known as the Comments Loop, which is what displays all of the comments for a post.

The start of Comments Loop looks like this:

<?php foreach ($comments as $comment) : ?>

To remove trackbacks/pingbacks from your theme, simply insert this code in the line right after the start of the loop:

<?php if ($comment->comment_type == "pingback" || $comment->comment_type == "trackback") { continue; } ?>

The above code skips over the trackbacks and pingbacks. The disadvantage of this method is that WordPress will still display the number of comments with trackbacks and pingbacks in the count.

trackbacks_comments.jpeg
Figure 4: Comments count with trackbacks included in the count

Method 2: Edit the functions.php File

Most themes should already come with a file named “functions.php“. If not, you can easily create one using any text editor.

Any code or functions in your “functions.php” file is immediately accessible by all of your theme files. The benefit of removing trackbacks/pingbacks using this technique is that you won’t have to modify any of the core template files and risk messing up your theme.

Within the functions.php file, insert this code:

add_filter('comments_array', 'filterTrackbacks', 0);
add_filter('the_posts', 'filterPostComments', 0);
//Updates the comment number for posts with trackbacks
function filterPostComments($posts) {
	foreach ($posts as $key => $p) {
		if ($p->comment_count <= 0) { return $posts; }
		$comments = get_approved_comments((int)$p->ID);
		$comments = array_filter($comments, "stripTrackback");
		$posts[$key]->comment_count = sizeof($comments);
	}
	return $posts;
}
//Updates the count for comments and trackbacks
function filterTrackbacks($comms) {
global $comments, $trackbacks;
	$comments = array_filter($comms,”stripTrackback”);
	return $comments;
}
//Strips out trackbacks/pingbacks
function stripTrackback($var) {
	if ($var->comment_type == ‘trackback’ || $var->comment_type == ‘pingback’) { return false; }
	return true;
}

This code is very similar to the code I used for separating trackbacks from comments.

Although not nearly as simple as the “comments.php” method, this method is more flexible and provides WordPress with an actual number of comments without the trackbacks/pingbacks being counted.

comments_wo_trackbacks.jpeg
Figure 5: Comments count without trackbacks included

Method 3: The Plugin Solution

For those not wishing to modify themes, there is always the plugin solution.

A plugin I wrote called Comment Sorter has a feature that allows a blogger to remove trackbacks/pingbacks (not permanently) from within the WordPress Administration Panel. There is absolutely no theme modification involved.

comment_sorter_admin.jpg
Figure 6: Comment Sorter Admin Interface

Using the above configuration for Comment Sorter (with the auto-include off and trackbacks disabled), one can easily remove trackbacks and pingbacks from a theme. It’s basically Method 2 in the form of a plugin.

Update for WordPress 2.5 - May 1, 2008

A reader pointed out that the comment count is incorrect on WordPress 2.5. For both techniques, you will want to exclude the filter the_posts and the function filterPostComments. Instead, use this filter and function:

add_filter('get_comments_number', 'filterCommentsNumber');
function filterCommentsNumber($count) {
	global $id;
	if (empty($id)) { return $count; }
	$comments = get_approved_comments((int)$id);
	$comments = array_filter($comments, "stripTrackback");
	return sizeof($comments);
}

Conclusion

Within this post I presented techniques on separating trackbacks/pingbacks from regular comments, and also how to remove trackbacks and pingbacks from a WordPress theme.

If you have any questions, please leave a comment and I’ll do my best to address them.

3/4/2008 ↓

Add WP Search Engines To FF 8comments

Author: Jeff Chandler Category: HOW-TO, Wordpress Tips

Jeremy Clarke mentioned to me about a way to search the Codex, WordPress support area and the plugin repository all from within FireFox. If you support users as I do in the WordPress IRC chat room, there are a lot of times where I do a search on the Codex to look up the page for a certain function that someone is inquiring about. Thanks to Jeremy’s tip, I no longer have to visit the actual page to perform a search.

If you visit the MyCroft page on Mozdev.org you’ll notice a number of links that you can click on. Each one of these links are a search engine plugin that was coded for FireFox. What this means is that, you can add WordPress specific search engines to the search engine tool bar within FireFox which is usually occupied by Google by default.

In order to install a SE plugin, simply click on the link that represents the search engine you want to have installed. For example, if you want the WordPress Codex to be one of the search engines within FireFox, click on the WordPress Codex plugin name. Upon clicking on the plugin name, FireFox will ask you if you would like to add the search engine to the list of search engines available in the search bar. Clicking the ADD button will add that specific SE to the list of choices within the search bar.

This tip has been an awesome time saver. Not only can I quickly answer questions in the chat room, but it is more convenient to search the plugin repository from within my browser than to actually search from the actual page.

3/3/2008 ↓

Gravatars and WordPress 2.5 84comments

Author: Ronald Huereca Category: HOW-TO, WordPress

Several commenters mentioned on yesterday’s post regarding Gravatars without a plugin that WordPress 2.5 would be having built-in Gravatar support.

And indeed WordPress 2.5 will come with Gravatar (aka, Avatar) support. Within this post I will demonstrate how Gravatars will be used with WordPress 2.5. As a side note, 2.5 has yet to be released as of this writing.

Gravatars in the WordPress Admin Panel

WordPress 2.5 marries theme authors and casual WordPress users together with support for Gravatars in the WordPress admin panel.

WordPress users can access the Gravatars settings in the Settings->Discussion panel.

If a theme author has decided to use the WordPress 2.5 function, then WordPress users can easily control their Gravatar usage in the admin panel.

In the admin panel, WordPress users can change:

  • Whether Avatars (aka, Gravatars) are displayed or not.
  • Which rating of Avatars are shown.

avatar_admin_panel.jpeg
Avatars in the WP Admin Panel

Please keep in mind these settings will have no effect if the theme author didn’t make use of the WordPress 2.5 function.

And what is the functon you ask?

Theme Authors: Adding Gravatars to Your Theme

The function to add Gravatars to your theme is called: get_avatar. The function returns a complete <img> tag of the Avatar.

The function get_avatar is setup as follows:

function get_avatar( $id_or_email, $size = '64', $default = '' )

  • id_or_email: The author’s User ID (an integer or string) or an E-mail Address (a string)
  • size: The size of the Avatar to display (max is 80).
  • default: The absolute location of the default Avatar.

Some things to note here:

  • The default Avatar size is 64×64.
  • The default Avatar is Gravatar
  • The Avatars will show only if the user allows them in the WP Admin Panel (enabled by default).
  • The Avatars will only show based on the rating the user has selected in the WordPress admin panel.

Here are some examples of the function in use:

Example 1 with a default Avatar

echo get_avatar( 1, '80', 'http://mysite.com/avatar/avatar.gif' )

In this example I used a user ID of ‘1‘ and specified the location of a default location. This example is useful if you want to display an Avatar outside of the comment’s section and you have an idea of the person’s User ID.

Example 2 with an e-mail address and size

echo get_avatar( 'myname@mysite.com', '60' )

This example is useful if you want to display the Avatars within the Comments Loop.

If calling Avatars from the Comments Loop (in comments.php), you will want to use the get_comment_author_email function in place of the above e-mail address.

echo get_avatar( get_comment_author_email(), '80' )

Backwards Compatibility

If you wish to develop a theme that displays Avatars for 2.5 and below, I recommend using a combination of the code mentioned here and the code from Connor Wilson’s post on using Gravatar without a plugin.

Your code would look something along the lines of:

if (function_exists('get_avatar')) {
 	//2.5 code
 } else {
 	//alternate gravatar code for < 2.5
 }

Further Reading

For more reading on the get_avatar function, please read Ryan Boren’s Avatars in WordPress 2.5, which he covers several additional points not mentioned here.

Conclusion

The inclusion of the get_avatar function is a nice addition to WordPress 2.5, but it relies on theme authors to include it. If you are comfortable editing your own theme, you can easily add the function into your own theme when 2.5 is released.

2/9/2008 ↓

Adding Your Plugin to WP Extend Plugins With a Mac 7comments

Author: Ronald Huereca Category: HOW-TO, Wordpress Plugins

A while back I wrote about listing your plugin to the official WordPress plugins directory. The tutorial was for windows and I have been on the look-out for a Mac version. Since I have been unable to find one, I will present to you a step-by-step tutorial on how to add and modify your WordPress Plugin using a Mac.

To begin this tutorial, I first have to make some assumptions.

My Assumptions

  1. Your plugin has already been approved over at WP Extend Plugins.
  2. You are running at least OSX Tiger
  3. You have WordPress locally installed. If not, please read Jeff’s tutorial on installing WordPress locally.
  4. You already have Subversion installed. If not, here’s a good tutorial on installing Subversion on a Mac. If you have Leopard, Subversion is already installed.
  5. You have downloaded and installed svnX. svnX has a nice GUI for those who don’t like to use Terminal commands.

Step 1. Ensure the Subversion (svn) Path is Correct

After you’ve installed svnX, go to its Preferences screen and ensure the path to your svn install is correct. Mine is set up at ‘/usr/local/bin‘, but yours may be different.

Subversion Path
Subversion Path Interface

Step 2. Access Your Subversion Repository

Using svnX, open up the “Repositories” window and add the path to your plugin using the “+” button.

From there, enter your plugin information:

  • Name: Your Plugin’s name.
  • Path: The svn path to your plugin. You should have received this in your approval e-mail.
  • User: Your WP Extend username.
  • Pass: Your WP Extend password.

Add Repository Using svnX
Accessing Your Repository

After you’ve entered your information, double-click your repository to open it up. You should now see a screen (assuming your credentials are correct) similar to the screenshot below:

Repository View svnX
Repository View

If you have never added your plugin before, the directories will be empty.

Step 3. Check Out Your Repository

Select the “trunk” directory and right-click it. You’ll want to select “Browse as sub-repository“.

Sub-repository View svnX

After selecting to view as a sub-repository, you should see a view of only your trunk’s contents. If you have never added your plugin before, this directory will be empty.

Sub-repository View svnX
Sub-Repository View in svnX

Once in the sub-repository view, you can now check out your repository. Click the “svn checkout” button to check out your repository.

svnX Checkout Button

From there, browse to your local WordPress installation’s plugins folder, and add a new folder and give it the name of your plugin. Please note that this should be the same folder name you would normally give your plugin prior to a release.

Checking out into a new folder - svnX
Add a new folder to your plugin’s directory.

After adding the new folder, click the “Open” button. The “Working Copies” window for svnX should now be showing.

Working Copy Window - svnX
Working Copies Window after a Checkout

Make sure you update your User and Pass to reflect those on WP Extend.

Step 4. Add or Modify Files

In the case of my plugin, I am just editing a few files. In your case, you may be adding plugin files for the first time.

Double-click your plugin in the “Working Copies” window. You should now see a screen similar to the one shown in the screenshot below:

Working Copy View - svnX
Working Copies Window

The best way to edit or add your plugin is through Finder. Click the “Reveal in Finder” button.

Reveal in Finder button - svnX

From there, add or modify your plugin files.

Step 5. Commit the Changes

After adding and/or modifying files, hit the “Refresh” button after you have opened up your Working Copy.

If the file is new, you will need to add the file to the repository by clicking the “Add” button. If an existing file is modified, it will show a “M” next to it.

To commit the changes, select the files you want to commit and select the “Commit” button. Type in a detailed message and click “Commit” again.

Please see the screenshot below for the commit screen:

Commit Dialog - svnX
Working Copy Commit Dialog

Step 6. Tag Your Release

Assuming you have prepared your plugin’s readme file (see this tutorial, Step 7), head over to your plugin’s repository (Open the Repositories Window in svnX and open your plugin - See Step 2 above).

You should see the changes you have just committed. If not, try clicking the “Refresh” button (a very small circular arrow).

To “tag” your release, select your “trunk” directory and click “svn copy” in the repository window.

svn copy button - svnxX

To successfully tag your release, follow these steps:

  1. Select the “tags” directory.
  2. Add an appropriate version number for the “Target Name”. This should match the stable version in your plugin’s readme file.
  3. Add in a commit message. You can just state that you are tagging a release.

Tagging Dialog - svnX
Tagging Your Release

Step 7. Verify Everything Worked

Head over to WP Extend Plugins and browse to your plugin (wait about fifteen minutes after you’ve tagged your plugin).

Make sure the versions match and that the changes you made were indeed captured. If everything is good, then you’re done.

Conclusion

Within this article, I demonstrated how to modify or add your plugin to the WordPress plugin repository using a Mac and svnX.

If you have any questions or suggestions on how to make this tutorial better, please leave a comment below.

1/18/2008 ↓

Plugin Authors: Organize Bug Reports and Feature Requests Using the WordPress Plugin Repository 16comments

Author: Ronald Huereca Category: HOW-TO, Wordpress Plugins

One of the downsides of having a popular plugin is the amount of support requests, bug reports, and feature suggestions that come in. Well, it’s not that bad, but sometimes it’s difficult to organize what features should be added, what bugs must be tackled first, and what can just be ignored.

If you’re one of the few and the proud over at WP Extend Plugins, you have a nice tool at your disposal to keep track of all your plugin related needs. The tool, you ask? It’s the trac ticketing system over at the WordPress Plugin Repository.

WordPress Plugin Repository
WordPress Plugin Repository

WordPress Plugin Repository - Trac

Each plugin hosted on WP Extend allows the plugin author to post and assign tickets to their plugin. In fact, any member of the WP Support Forums can post a ticket against any plugin hosted in the official repository.

Logging into the WP Plugins Repository

Login Button
Login Button

The first step to start assigning tickets (besides creating a user account) is to head over to the repository and log in.

Username/Password Dialog
Username/Password Dialog

After you are logged in you can view the “New Ticket” button.

New Ticket
New Ticket Button

Creating the New Ticket

After clicking on the “New Ticket” button, you are presented with a form for creating a new ticket. Creating the ticket is as simple as filling out a few form fields.

  • Short summary: Basically a title for the bug or feature request.
  • Type: Is it a defect (bug), enhancement (feature request), or task?
  • Full description: Detailed description of the issue with code examples if applicable.
  • Priority: How seriously you think the developer should take the request.
  • Severity: How much damage (or potential damage) the issue causes
  • Component: This is where you select which plugin you’re creating the ticket for.

Creating a New Ticket
Screenshot of the “Create New Ticket” Screen

Once you’re all set creating the new ticket, you can either preview it or hit the “Submit Ticket” button. Once the ticket is finally submitted, you’ll get a nice summary screen with your new ticket (shown below).

A Submitted Ticket
Screenshot of “Submitted Ticket” Screen

After the ticket is submitted, it’s up to the plugin author to accept and assign the ticket.

Viewing Open Tickets

It’s simple to view your open tickets once one has been created against your plugin. If you are logged in, click on the “View Tickets” button.

View Tickets Button
View Tickets Button

Once on the “View Tickets” page, you will want to browse to “My Tickets”.

view-tickets-page.gif
“View Tickets” Page

From there you will be able to see all of your plugin’s open tickets based on priority. You can then click on a ticket, assign it, mark it as resolved, add comments, or a number of other options.

All Tickets
Open Tickets - Priority Based

Conclusion

The WordPress Plugin Repository is a great asset for plugin authors who receive a lot of bug reports and/or feature requests. The ticketing system allows for one place to store all bug reports and feature requests in a nice priority-based system.

This article touched on just one of many features available to plugin authors (and regular WordPress users) over at the repository. For plugin authors, becoming familiar with the repository is recommended.

1/16/2008 ↓

Configuring WP Permalinks 45comments

Author: Jeff Chandler Category: HOW-TO

Pretty Permalinks

Quite often, we hear of the terms (permalinks or pretty permalinks) which can also be called SEO-friendly URLs. These URLs are not only SEO friendly, but I believe they are human friendly as well. By default, WordPress uses URLs that look like a mishmash of letters and numbers with a few question marks mixed in for good measure. These types of links are frowned upon by search engine spiders and as a human being, they are also hard to read.

Fortunately, WordPress provides a way for us to change this linking structure to something understandable. WordPress calls these Permalinks. Permalink settings can be configured a number of different ways. One of the ways to quickly configure permalinks is by choosing one of the Common Options. These common options include:

Default - http://www.domain.com/?p=123

Date and name based - http://www.domain.com/2008/01/15/sample-post/

Numeric - http://www.domain.com/archives/123

There is no sense in using the default option so choose either Date and name based or Numeric if you don’t feel like tinkering with the Custom Structure.

The custom structure of the permalinks settings area allows you to customize the way permalinks are displayed by using any combination of the following permalink tags.

%year% - 4-digit year (for example, 2008)

%monthnum% - 2-digit month (for example, 01 for January)

%day% - 2-digit day (for example, 15)

%hour% - 2-digit hour of the day (for example, 20 for 10PM)

%minute% - 2-digit minute (for example, 50)

%second% - 2-digit second (for example, 24)

%postname% - Text separated by dashes which usually ends up being the post name. (for example, configuring-wp-permalinks)

%post_id% - The unique, numerical ID of the post (for example, 124)

%category% - The text of the category name that the post is filed in (for example, how-to)

%author% - Text of the post author’s name (for example, ronald-huereca)

Example of custom structure in use:

Custom Structure: /%year%/%monthnum%/%day%/

Link Output: http://www.domain.com/2008/01/16/

Make sure that you include the back slashes at the beginning of the custom structure, after each tag and at the end. This will ensure that WordPress writes the correct rules in the .htaccess file via mod_rewrite.

For my own blog, I seem to have done fairly well in the search engines by using the Custom Structure method and using the %postname% tag. I can’t say for sure which combination would do better or worst for search engines. The only thing I can suggest is that you configure your permalinks to look whats best for you.

*WARNING*

Changing the structure of your permalinks affects all of the permalinks on your blog. This is important to know because search engines will have indexed posts on your site via their permalinks. If you change the permalink structure mid stream, you will end up invalidating all of those links.

What to do if you don’t have a .htaccess file?

If you notice that you don’t have a .htaccess file within the same directory as your WordPress installation, you can create one by first creating a blank .txt file and saving the file as htaccess.txt. Upload this file via FTP to the same folder that houses your WordPress installation. Once the file is uploaded, set the permissions to the file as 666. Next, rename the file to .htaccess. Now you should have a blank .htaccess file for which WordPress can write the proper permalink rules to.

Servers That Don’t Use Apache Or mod_rewrite.

If the webhosting server you are on does not have the apache module mod_rewrite enabled, you can still use the permalink settings in WordPress by placing index.php in front of any custom permalink tags.

For example: /index.php/%year%/%monthnum%/%day%/

Equals: http://www.domain.com/index.php/2008/01/16/

Using index.php in this way eliminates the need for a .htaccess file.

I hope this little primer on how to configure your permalinks within WordPress was helpful. I’ve seen too many blogs out on the net that have yet to take advantage of this awesome feature. As I’ve said before, using any sort of permalink structure is better than the WP default. Not only is it beneficial in terms of SEO, but it also makes it easier for human beings to see at a glance, what a particular link is pointing to without having to visit the page.

If you use the custom structure aspect of permalinks, I’d be very interested in knowing which configuration of permalink tags you have chosen to use and why.

1/3/2008 ↓

Install WordPress Locally - Part 2 Of 2 49comments

Author: Jeff Chandler Category: HOW-TO

Welcome to part two of a two part series of articles that will guide you through the process of installing a fresh copy of WordPress or your public WordPress blog to your local machine. The first part of this series covered the installation and configuration of WampServer. Now it’s time to move on to the hard, technical stuff.

Installing WordPress Fresh:

One thing you must know before we move on is that, by default, your database username is ‘root‘ and the default password is blank. In other words, there is no password assigned to the username of root. This would be extremely insecure if this web server were made available to the public but because it’s assigned to the local address of your machine, you have nothing to worry about.

To begin, left click on the WampServer icon and select PHPMyAdmin. Where the text labeled CREATE NEW DATABASE is located, type in the name of the database that will house your installation of WordPress. For simplicity, I normally call the database wordpress. Then click on the Create button. We now have an empty database that the WP installation files can work with.

Download the latest version of WordPress, then extract the files to your desktop. Open the WordPress folder and look for WP-Config-Sample. Open this file in your preferred text editor. The DB_Name is the name of the database you created for WordPress. The DB_User is root. The DB_Password is blank. These three values are the only ones you’ll have to change. Once those changes are in place, save the file as WP-Config.PHP

WP Config Example

If you want to install WordPress into the ROOT directory as you would on a public web server, take all of the files and folders within the WordPress folder and move them into the WWW folder. WWW is the same as Public_HTML and is the folder which houses all of your web documents. If you don’t want to install WordPress into the root directory, create a new directory and place all of the files into that one. Just make sure the files are within the WWW folder, or else they won’t be accessible.

Once that’s finished, point your browser to http://localhost/wp-admin/install.php Follow the directions as they are pretty self explanatory and when your finished, you’ll have a fully functioning, fresh install of WordPress that you can do whatever you want with.

Migrating WordPress From Public To Localhost:

Migrating an existing WordPress install onto your local computer is not as easy as a fresh install. If you haven’t already, make sure you have made the appropriate PHP.ini file changes that were explained in part 1. If you don’t, you will run into numerous errors about the SQL file being too large to import.

In my circumstance, my webhost offers it’s customers Cpanel as a means to control all aspects of my Webhosting account. Cpanel provides me with a way to generate a full backup of my domain. This backup includes all of the hardcoded directories and files attached to my domain as well as any databases I have created. After you create a full backup of your domain through Cpanel (if you have that option) download the backup to your desktop. Once downloaded, open up the file and browse to the Public_HTML directory. Extract this directory’s contents into the WWW folder on your hard drive.

Once thats finished, look inside of the mysql directory within your backup file. This directory contains all of the MySQL databases you have created through your webhosting account. Extract the SQL file that pertains to your WordPress install and place it on the desktop.

Ok, before we move on, lets review where we’re at. We backed up all of the files related to the hosting account and then downloaded that file to the desktop. We then extracted all of the files within the Public_HTML directory into the WWW directory. We then looked inside of the backup file and extracted the SQL file that pertains to the WordPress installation. At this point, the folder structure within the WWW folder on your hard drive should mimic that of what you would see within the Public_HTML folder on your webhost.

Now, left click on the WampServer icon and click on PHPMyAdmin. Click on the link that says IMPORT. Click on the BROWSE button and locate the SQL file you extracted to your desktop that pertains to your WordPress installation. After you locate and double click on the file, click on the GO button. It might take a little while, but the import process should be successful. If you receive an error that states the SQL file was too large, please re-visit part 1 and make sure the changes were saved to your PHP.ini file. Also, I wanted to share that if you have the SezWho comment rating plugin installed, you may receive errors that are related to the plugins database tables. If this is the case, you will need to open the SQL file in a text editor and remove all of the lines that pertain to those tables which are usually prefixed with sz_ and then try to import the SQL file again.

If the import was successful, pat yourself on the back because were almost through with this process.

If you do not want to do the next step through the database you can instead, add these constants to your WP-Config file and they will perform the same function as the database edits.

define('WP_HOME', 'localhost' );
define('WP_SITEURL', 'localhost');

In PHPMyAdmin, the database you imported will now be selectable in the drop menu that is located near the top left portion of the webpage. Click on the drop down arrow and select the database you just imported. Near the top center of the page, there will be a series of tabs. Click on the SEARCH tab. In the search box, type in the full URL to which your public WordPress install refers to. In my case, I typed in http://www.jeffro2pt0.com This will search the entire database for entries of that domain. The search results should find entries related to that domain within the table WP-OPTIONS. Click on the Browse link to dig into this particular table.

SQL Option Names

You only need to concern yourself with the top two entries, SiteURL and HOME. Click on the Pencil icon for SiteURL which is just to the left of the X icon. This will open up the editing page. In the large text box on the bottom, change the URL to http://localhost then click on the GO button. Now do the same thing for HOME. After you change HOME, you can exit out of PHPMyAdmin.

If you have never opened the .htaccess file to hard code redirection attributes, you can skip the next step and you are essentially finished.

The last thing to do is to edit the .htaccess file and remove any hard coded redirection attributes. If you don’t do this, each time you try to load your blog on your local machine, it will automatically redirect to your public blog or which ever URL you configured in your .htaccess file.

Victory Lane:

If you’ve managed to read this far, congratulations. After all of that, you should be able to access and browse your blog on your local machine exactly how you would in a public domain. This guide is by no means a cure for all. This was my detailed approach as to how I migrated my public install to a local install. Some of the actions I performed may not have been necessary, nor required, but this is the way I did it and it worked!

If you have a correction or a different way of doing things, by all means leave a comment. I will edit this article as corrections come in so the most accurate information is presented.

Also, now that you have the ability to dig around the ins and outs of your blog through the database, you’ll be able to see some things that you might not of known about before. Stay tuned for another article which highlights a VERY important issue pertaining to plugin developers that needs to be discussed. Perhaps we’ll be able to come up with a solution.

12/30/2007 ↓

Install WordPress Locally 1 Of 2 58comments

Author: Jeff Chandler Category: HOW-TO

Wamp Server Logo

Welcome to part one of a two part series of articles that will guide you through the process of installing a fresh copy of WordPress or your public WordPress blog to your local machine. The first part of this series will guide you through the installation and configuration of a piece of software called WampServer. Why would you want to do this you ask? Having your WordPress blog installed on your local machine not only acts as a backup, but it gives you the option of really digging into the inner workings of your blog without having to worry about it breaking and therefor, rendering the thing useless to the public. Not only that, but it’s much faster to play with things on your local machine than it is with a LIVE site on the internet.

For this article, I am using Windows XP Service Pack 2 and something called WampServer. WampServer is a piece of software that installs everything you need to turn your PC into a webserver. This includes Apache, MySQL, PHP, SQLitemanager and PHPMyAdmin. Before we get started, head on over to the official WampServer download page and grab a copy of WampServer 2.

WampServer Installation:

The installation process is pretty simple. After accepting the license agreement and specifying where the WampServer files will be installed to, the installation file will be unpacked, doing all of the heavy work for you. Using a software application such as WampServer to install all of your webserver needs for you automatically, is the easiest way to turn your machine, into a web server. Once the installation is finished, you’ll be prompted to locate your default browser executable file. In my case, I had to direct the install to my FireFox executable file which is usually within the Mozilla folder.

One of the first things you’ll have to configure is the PHP mail parameters. For SMTP, the default value of localhost is correct. As for the email address, you can choose to type one in, or not. This can always be changed later. Once this setting is configured, you’ll be greeted with a confirmation box that tells you the installation of WampServer has been completed. Leave the option “Launch WampServer 2 now” check marked and click the finish button.

Installation Is Completed

Configuring WampServer Files:

One important piece of information I have to mention. The webserver acts on port 80 which is the port responsible for HTTP traffic. If you are running Skype with it’s default configuration, you’ll notice that your Webserver is offline once you start the program. This is because by default, Skype uses port 80 and 443 for incoming connections. You can either change the port that Skype uses or you can close, then re open Skype after your Webserver is online, forcing Skype to use a different port. In essence, make sure port 80 is clear before you launch WampServer or else the Apache web service will not run.

I’ve also been informed by ayusli that will you also need to disable IIS if that is running on your system. If you don’t, you may not be able to access localhost.

Accessing PHP.ini

Once your WampServer is online, you’ll need to edit a few files to change the configuration to allow for larger databases to be imported. These changes will take place within the PHP.ini file. The PHP.ini file is a text file that contains the configuration for the PHP programming language. The first thing you’ll need to change is the upload_max_filesize attribute. By default, this is set to 2Megabytes. This is too small of a value, so increase this to 50 or 100megs. It doesn’t need to have a specific value so long as it is larger than the size of the database file you will be importing later on in this guide. The other setting you’ll need to change is post_max_size. By default this is set to 8Megabytes. Change this to the same value as the upload_max_filesize limit. After you make this change, reboot your computer. This will ensure the changes you made to the php.ini file take effect.

End Of Part 1:

If you plan on doing a fresh install of WordPress, you won’t have to worry about making any changes to the PHP.ini file after you install WampServer. However, if you plan on taking a copy of your public blog and transferring it to your local machine, the changes described above need to happen or else you will likely run into problems such as your database file being too large to import.

Part 2 of this series will go into details on how to install a fresh copy of WordPress as well as how to transfer your existing WordPress blog on the internet onto your local machine. It’s not as easy as transferring the database and then extracting a backup of files into a folder. There are a few more required tricks that need to be performed before a public blog can be successfully transferred. Look for these tips in part two which should be published in the next few days.

11/3/2007 ↓

  • Be More Than a Blip in the Blogosphere

    The Washington Post has an article called Be More Than a Blip in the Blogosphere which is on how to make your blog more popular. I used to like linking to a couple of these in a month but lately “write a better blog” articles have turned into “how to make affiliate money online”. This one from the Washington Post however, is down to earth and easy to read and follow, which are important qualities in How To articles. (13)
  • WordPress Theme Cheat Sheet

    The WordPress Help Cheat Sheet: Is a nifty little collection of code snippets and helpful bits of information aimed directly towards theme and template developers who need a reminder once in a while. Nice to print out and put somewhere handy. If you get lost looking for the link to the actual PDF download, look for it at the bottom of the post, towards the right under the word link. (yes, the authors need to make the most important content of a post easily visible and identifiable) (5)

9/27/2007 ↓

Blogs and the Mobile Web 17comments

Five Reasons Why The Mobile Web Sucks and the counter arguments from Russell (warning, littered with expletives) made me think about blogs, mobile web and the proliferation of blogs on mobile phones and mobile browsers. Since I am closely involved with many of the technologies that are being bolstered or criticized on those posts, I have my own opinions about some of them.

  1. Wireless carrier networks are SLOW: I am not so sure. Sprint has decent speeds and I can surf just fine on my phone or by using it as a modem. It is not as good as my 17 Mbps cable modem, but when I was stuck in a hospital and needed to call my parents in India using Skype via Sprint through my 755p, it worked like a charm. My VPN back to work and most surfing done over the phone was painless and got me through our crisis without loss of communications. The experience left me wishing (among other things) more sites and blogs used Alex’s Mobile Edition plugin including Weblog Tools Collection.
  2. Public WiFi access is a SCAM: Scam is too strong a word and quite misleading. Localized public WiFi has been successfully deployed over and over again. Airport WiFi, WiFi in smaller stores and shops, public arenas and other public locations work and work quite well. Citywide WiFi however runs into trouble. Some of my friends and co-workers own WiFi enabled phones such as the iPhone and the Sprint Mogul and they browse the web with aplomb on their phones.
  3. Sites aren’t formated for small screens: Yes and no. I say yes because more sites and blogs need to be mobile web enabled. I say no because Opera Mini and Blazer do a terrific job of making the large screen formatted sites so much easier to use and navigate. You really have to use these browsers in their present incarnations to know how far they have come. I regularly browse my favorites and answer emails from my phone during lunch.
  4. Mobile device screens are too small: Yes. But I would rather carry a phone and use it for all my web needs than carry a laptop (in addition to the phone) if I don’t have to.
  5. Advertising gets in the way: This point is completely lost on me.

The real contention is how badly you want to browse the web over your phone and not how the mobile experience is not as good as that on your desktop or laptop. My father used to hate browsing the web on my phone but that was because he was averse to new technology and he had a hard time using it. However, since he has gotten interested in blogging, he wants to check his visitor stats and his email on my phone when we are traveling and that desire has helped him try to understand mobile browsing a little better. I suspect that a lot of the hoopla and complaining about the mobile web is done by people who have pre-conceived notions about the mobile technology and are not giving it a fair shot. Wireless, WiFi and mobile browsing technology has come a long way and much of it is due to dedicated, fanatical and enterprising professionals and technologists such as Russell.

With that in mind, I did some research on mobile tools, plugins and themes for Wordpress. What have you done to your WordPress blog to make it accessible from mobile browsers? If having a mobile version was as simple as installing a plugin in WordPress, do you think that it would be worth having a mobile version of your site?

  • The first one on the list is Alex’s Mobile Edition. Everyone uses it, it works well and everyone loves it. (Alex, I know I have whined about this before, but we really need some anchors for your plugins)
  • iWPhone plugin and theme combination from Content.Robot which displays an iPhone version of your Wordpress blog to visitors from the iPhone and the iPhone Touch
  • Andy Moore’s Wordpress Mobile Plugin which allows you to view posts, pages, archives and comments on a mobile device. Standards are supported, posts and comments can be submitted by phone and your WordPress is easily moneitized by AdMob.
  • iPhone Mobile Admin provides an iPhone interface to your Wordpress backend. Dan promises that though the iPhone is the only phone supported in this version, he has plans to support other phones as well.
  • WordPress PDA is a plugin that allows you to view your WordPress blog on a PDA browser
  • WP-WAP is a plugin from the amazing Lester Chan that will let you browse your WordPress blog from a WAP enabled phone

If you use any other plugins that enhance the mobile experience on WordPress please let me know. Do you have a mobile edition of your WordPress blog?

9/18/2007 ↓

9/13/2007 ↓

  • WordPress File Uploads With IIS 7

    WordPress File Uploads With IIS: Joseph figured out how to fix permission issues with IIS 7, PHP 5 and Windows Vista. This might help someone in the future. (1)

7/9/2007 ↓

The “More” Tag on a WordPress Page 16comments

Author: Ronald Huereca Category: HOW-TO, Wordpress Tips

Nathan Rice wrote about WordPress’s ability to make any page a homepage. One problem I ran into using the technique of pages was the inability to use the <!--more--> tag to display partial posts. Apparently this is default behavior (for good reason) on pages. However, when using Nathan’s technique, I found myself in a unique situation where I only wanted to show a partial post (on a page) if the post was making use of the <!--more--> tag (apparently, I’m not alone).

The technique is rather simple. Simply declare a variable named $more as a global and set it to false right before showing your content. If you wish to resume normal behavior after the content is shown, simply set the variable back to true.

<?php global $more; $more = false; ?>
<?php the_content('Continue Reading'); ?>
<?php $more = true; ?>

Reduce the Size of Your WordPress Plugin Footprint 18comments

Author: Ronald Huereca Category: HOW-TO, Wordpress Plugins

For each WordPress plugin you install, you are adding to the bandwidth/server overhead of your site. As a plugin author, there are some simple steps to take to reduce the footprint of your plugin (whether it be helping with server load or conserving bandwidth), even if your plugin still requires a lot of code.

Break Out Admin Panels Into Separate Files

Even for simple plugins, adding admin panels can easily balloon a plugin’s file size. A simple, yet effective technique, is to copy the code used for the admin panel to a separate file and simply provide an include in the function that loads the admin panel.

For example, say you load in your admin panel using this code:

add_options_page('Plugin Name', 'Plugin Name', 10, basename(__FILE__), 'printAdminPage');

The function printAdminPage is going to be the function that loads the admin panel. Within this function you could have:

function printAdminPage() {
	include 'includes/admin-panel.php';
}

The above snippet assumes you have an ‘includes’ directory with your admin panel code in ‘admin-panel.php’.

Note: Per Dougal Campbell, includes pose a security risk. Here is one technique for securing PHP include files.

Use Includes to Separate Major Functions

If your plugin has separate functionality, why not separate this functionality into separate files that can be included when needed? For example, what if your plugin deletes or saves something? You could include the delete code in its own file, and the save code in another file.

function save_or_delete($task) {
	switch($task) {
		case 'save':
			include 'includes/save.php';
			break;
		case 'delete':
			include 'includes/delete.php';
			break;
	}
}

The above code includes the appropriate code only when certain tasks are performed.

Load Parts of Your Plugin on Relevant Pages

With more plugins coming with their own stylesheets and JavaScript files, it may be necessary to specify which pages these files should be included. Fortunately, WordPress has a nice collection of conditional tags and/or actions that can help you determine what kind of page the end user is using.

Say that you want to load a piece of JavaScript only when a user is in the admin panel. Fortunately WordPress has an action specifically for loading scripts in the admin panel called admin_print_scripts. A simple action call would look like:

add_action('admin_print_scripts', 'addAdminJS');

Within this ‘a