function gmail() {
    curl -u yourgamilusername --silent "https://mail.google.com/mail/feed/atom" | tr -d '\n' | awk -F '<entry>' '{for (i=2; i<=NF; i++) {print $i}}' | perl -pe 's/^<title>(.*)<\/title><summary>(.*)<\/summary>.*?<name>(.*?)<\/name>.*$/\n$3\n\t$1\n\t$2/'
}

The developer has done a great job, adding several options to allow you to configure it as desired. While there are some widgets and modules for other CMS platforms out there, I didn’t see one for WordPress so I thought I’d draft one up real quick.

As always, this was created for a client and I don’t have a ton of time to keep up with most of my plugins right now. If you find a bug, let me know though.

== Changelog ==
* 1.1 – Minor tweak to make work in all webkit browsers
* 1.0 – Initial Release

== Installation ==
1. Upload the entire `ft-netbible-tagger` folder to your `/wp-content/plugins/` folder.
2. Go to the ‘Plugins’ page in the menu and activate the plugin.
3. Navigate to Settings -> NETBible Tagger in your WordPress dashboard to customize the settings.

== Download ==
You can download it here until its accepted at the WordPress plugin repo

== Screenshot ==

When he left, we mutually agreed to send his FacePress plugin with him (its his baby and he’s best qualified to support and enhance it). In doing so, we needed to create a permanent 301 redirect for the support page but we didn’t want to install a plugin that included an admin panel, etc. Instead, we elected to put this short code in our theme’s functions.php file.

Please feel free to take and modify as needed. Only one condition: if you have a way to improve this, please share in the comments!

// Permanantly Redirect FacePress Plugin
function permanent_301_redirect_facepress() {
	if ( isset( $_SERVER['REQUEST_URI'] ) && '/facepress-ii' == $_SERVER['REQUEST_URI'] || '/facepress' == $_SERVER['REQUEST_URI'] ) {
		header( 'HTTP/1.1 301 Moved Permanently' );
		wp_redirect( 'http://knoxwebdev.com/facepress-ii' );
		exit();
	}
}
add_action( 'template_redirect', 'permanent_301_redirect_facepress' );

Test it by going to http://fullthrottledevelopment.com/facepress-ii!

function global_404() {
	if ( is_404() ){
		wp_redirect( 'http://site.com/global404' );
		die();
	}
}
add_action( 'template_redirect', 'global_404' );

If placed inside a plugin that is activated on every site in your network, the above code will do the following:

1. Determine that the user looked for a page that didn’t exist.
2. Redirect to a URL of your choice, regardless of the site that they are currently viewing.

This request was made by a client. I have no idea how many people are interested in it, but here it is:

function ft_rtt_remove_title_attribute( $output ){
$output = preg_replace('/title=\"(.*?)\"/','',$output);
return $output;
}
add_filter('wp_list_categories','ft_rtt_remove_title_attribute');
add_filter('wp_list_pages','ft_rtt_remove_title_attribute');

This plugin allows you to hide and expand the children categories from view to make navigation a little less complicated.

Goes great with Scribu’s Category Checklist Tree plugin found here.

Download it here until I find time to submit it to the repository.

Here’s a screenshot of it in action on a custom taxonomy I happen to have created it for:

My first real tipping point in efficient development came with a better understanding of how the wp-content folder interacts with the rest of the core files. This was ground breaking for me and it almost immediately ‘powered up’ my WordPress related development.

Over the past several months I have been experiencing a second surge in both my level of understanding and my efficiency in WordPress development. This is directly related to my involvement in the WordPress 3.0 development cycle. I wanted to quickly share four aspects of this process that have helped me increase efficiency in my overall WordPress development. It’s my hope that this encourages you to jump in and contribute as well.

Familiarity with new tools and technologies
WordPress.org manages their code base in a web application named Trac. Trac is an opensource software that integrates SVN and ticket based bug reporting. You can view the WordPress installation for the core files here: http://core.trac.wordpress.org. Although I had a basic understanding of what Trac was and knew where it existed online, my interactions with it were in the single digit range (and less than 1).

Trac
It is impossible to seriously contribute to WordPress core as a developer without diving into Trac. It was intimidating for me to do so at first, but has proven well worth the learning curve it took to become comfortable with the process of creating tickets, creating patches, and submitting them for review and possible inclusion into WordPress.

• Taking the time to understand how the WordPress community uses Trac in our development process has increased my efficiency in the following ways:
• Comments in the individual tickets help me understand why specific changes were made in the code.
• Milestones help me to better judge what features and bug fixes will be included in future releases.
• The ability to browse existing tickets and submitted patches help me to determine legitimate bugs and discover possible solutions.
• The ability to navigate revisions in an intelligent GUI using the power of Annotate helps me track down unresolved bugs more quickly.

SVN
Although I was already familiar with SVN due to the plugin repository and other non-WordPress related projects, contributing to WP core has substationaly increased the frequency at which I find myself using it. Increased use inevitably leads to increased knowledge and efficiency with any tool.

A better awareness of WordPress community
Possibly the greatest benefit I have gleaned from my involvement in contributing to WordPress is a greater awareness of who the WordPress community includes. Prior to contributing to comments and patches on Trac and finding a suitable IRC client, I didn’t know who Andrew Nacin, Ptah Dunbar, Austin Matzko even existed… let alone understand their contributions to WordPress. These are only a few names that immediately come to my mind… several more exist.

Its funny how you think you know ‘who’ a community is because you’re following a couple mailing lists or a couple of opinionated talkers on Twitter. Getting plugged into the development process has opened me up to a whole new world of very intelligent individuals that I continue to learn from by listening in on their conversations. My coding has become more efficient due to the little tidbits of information I skim off of their public discussions every day.

Familiarity with More of the Core Functionality
Troubleshooting your own code inevitably leads you to a greater understanding of the code surrounding it and supporting it… troubleshooting somebody else’s code multiplies this effect several times over. I’m pretty familiar with the WordPress core files, but diving into Trac and hunting down bugs that can only be reproduced by a remote set of users have taken me to places in the codebase that I never would have found otherwise. I can’t tell you the number of times I’ve been hunting down a specific bug and ran across an amazing function that I was previously unaware existed. Finding all these hidden jewels and obtaining a better understanding of how different functions work within WordPress has largely increased my development on a day to day basis.

Coding Standards
I’m pretty anal about the way my code looks. I try to document as much as possible while I develop it. Additionally, all my code is formatted the same way to increase comprehension if I have to dive back into a file months or years after initially creating it. With this being said, I still have several habits that are less than productive in the long run… my guess is that you’re just as lazy.

WordPress has a guide sheet dictating what coding standards should be followed when contributing to the core software. Many of these standards are nothing more than the lead developers collaborative opinions. The standards are not ‘right’ or ‘wrong’ in any global or authoritative manner… rather, they’re simply the way that WordPress has determined to standardize its code base.

This has been helpful to me because it has encouraged me to clean up some less than standard areas in my own code. Once you work on a couple large patches it becomes natural to start applying those standards to your own work. Again, I’m not suggesting that you have to accept these standards as rule in your personal development… but I am reporting that once I got past the basic control issues I had with not doing things the way I previously did them, adopting many of the WordPress coding standards has actually increased my overall efficiency… a result that I am always happy to discover.

Conclusion and Resources
When I first ventured into the world of WordPress Trac it was with a very utilitarian purpose… I had a problem and I needed it fixed. Two months later, I’m still there and its extremely addictive. Contributing to WordPress core has introduced me to new technologies, new friends, and it continues to increase my efficiency in day to day development. If you’re a WordPress developer and you’ve yet to jump into core contribution, I would highly encourage you to start today. Here are some resources to get you started:

• WordPress Trac
• Trac Page on Codex
• Mark Jaquith’s WordPress Toolbox (Mac/Linux)
• Peter Westi’s WordPress Toolbox (Windows)
• WordPress Coding Standards
• Twitter list of Core Commiters by Andrew

WordPress MU currently has a minimum limit of four characters set in its core. Unfortunately, this limit is still imposed in WordPress MS 3.0. The limit is probably there because usernames were used for the domain too and WP-Devs didn’t want to conflict with country codes. But that is not an issue for my client, so I wanted to kill the limit (without touching core).

Basically, I wrote a quick mu-plugin that unset the error message when someone tries to add a user with fewer than four characters. Doing this removes any halts that would stop processing the new user. Here is my code:

function remove_username_char_limit($result) {	
  if ( is_wp_error( $result[ 'errors' ] ) && !empty( $result[ 'errors' ]->errors ) ) {

    // Get all the error messages from $result
    $messages = $result['errors']->get_error_messages();
    $i = 0;
    foreach ( $messages as $message ) {

      // Check if any message is the char limit message
      if ( 0 == strcasecmp("Username must be at least 4 characters", $message)) {
        // Unset whole 'user_name' error array if only 1 message exists
        // and that message is the char limit error
        if ( 1 == count($messages) ) {
          unset( $result['errors']->errors['user_name'] );
        } else {
          // Otherwise just unset the char limit message
          unset( $result['errors']->errors['user_name'][$i] );
        }
      }	

      $i++;
    }
  }

  return $result;	
}
add_action('wpmu_validate_user_signup', 'remove_username_char_limit');

We also needed to customize the output a little bit, which required me to rely on PHP’s preg_match and preg_replace functions. Here is some simple example for embedding a feed into your WordPess website:

<?php
include_once(ABSPATH.WPINC.'/rss.php'); // path to include script
$feed = fetch_feed('http://url.to.feed/'); // specify feed url
?>

<?php
if (!is_wp_error($feed)) : 
	$rss_items = $feed->get_items(); 
?>


	// Loop through each feed item and display each item as a hyperlink.
	<?php foreach ( $rss_items as $item ) : ?>

	

		<?php echo $item->get_title(); ?>
	

	<?php endforeach; ?>

Check out the codex for more information about WordPress’ function feed_fetch()… and with a little extra coding you can format the feed any way you like, see our example at NC Capital Homes.