As Matt Mullenweg rightly pointed out several years ago, simply hiding your WordPress version number is not enough by itself to stay protected from potential threats (you should always be keeping your WordPress installation up-to-date).

But perhaps you have a client who has specifically requested its removal or maybe you just like keeping things on the safe side, either way there are a lot of tutorials out there on how to remove it from various areas but none that I’ve found showing how to remove it from every area at the same time.

The WordPress version number appears in three areas:

1. Generator Meta Tag in the Header

<meta name="generator" content="WordPress 3.3.2" />

2. Generator Tag in RSS Feeds

<generator>http://wordpress.org/?v=3.3.2</generator>

3. Query Strings on Scripts & Styles

If a script or style does not specify a version number when enqueued, the current version of WordPress is used.

foo.js?ver=3.3.2

One Block of Code to Rule Them All

Just enter this into your functions.php file and your WordPress version will be safely hidden from the public.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?php
 
/* Hide WP version meta tag from header and generator tag from feeds
 * @return null
 * @filter the_generator
 */
function fjarrett_remove_wp_version_tag() {
	return null;
}
add_filter( 'the_generator', 'fjarrett_remove_wp_version_tag' );
 
/* Hide WP version strings from scripts and styles
 * @return {string} $src
 * @filter script_loader_src
 * @filter style_loader_src
 */
function fjarrett_remove_wp_version_strings( $src ) {
	global $wp_version;
 
	$parts = explode( '?', $src );
 
	if ( $parts[1] === 'ver=' . $wp_version ) {
		return $parts[0];
	}
	else {
		return $src;
	}
}
add_filter( 'script_loader_src', 'fjarrett_remove_wp_version_strings' );
add_filter( 'style_loader_src', 'fjarrett_remove_wp_version_strings' );
 
?>

However, there is one small caveat to be aware of when using this method: This function will check to see if the ver query string matches the WordPress version number, so if the version of the enqueued script happens to be the exact same as the WordPress version then its version string will be removed as well.

This will occur rarely (if ever), especially when the current WordPress version is a point release, such as 3.3.2.

The Solution

When Frankie Jarrett isn’t living his passion for working in WordPress or making music, he’s the problem solving hero known as, The Solution!

He was born with the amazing cerebral super power to solve any problem. Frankie can always figure out a way to communicate clearly with anyone. He is often there to listen and offer support to others, no matter how difficult their situation. Often Frankie only needs to say, “I’ll have to think about this problem a little”, and soon he has an exciting solution!

No situation is too big or too small and there is no danger too great for him to face. Whether you are having a tough time remembering trigonometry for your math test, or you are stranded on the roof of a burning building, The Solution can always figure out the best way to rescue someone.

Our hero also has the natural ability to inspire others, whether leading musical worship in his church or jamming with friends, Frankie uses his voice and musical talents to uplift and inspire those around him.

When not saving the innocent, Frankie spends his time watching the History channel with his wife, whom he absolutely adores.

Being HEROized is a true honor, and I am grateful to Dave and the rest of the team for recognizing me in this way.

Now to create more solutions!

You’ve probably got a fancy post separator, or a brilliant doodle to fit between your last post and the comments. Whatever the reason, you don’t have CSS class selectors for targeting the first or last posts in your archive – and you really need them.

There are a lot of tutorials on how to achieve this with jQuery. But it’s not worth relying on JavaScript for something that can easily be done with a little PHP magic.

First, insert this function into your functions.php file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
 * Display the classes for the post div and automatically mark the first and last posts
 * 
 * @param {string|array} $class - One or more classes separated by spaces
 * @param {int} $post_id - An optional post ID
 */
function fjarrett_post_class( $class = '', $post_id = null ) {
	global $wp_query;
 
	if ( $class ) {
		$class .= ' ';
	}
	if ( $wp_query->current_post === 0 ) {
		$class .= 'first';
		return post_class( $class, $post_id );
	}
	elseif ( ( $wp_query->current_post + 1 ) === $wp_query->post_count ) {
		$class .= 'last';
		return post_class( $class, $post_id );
	}
	else {
		return post_class( $class, $post_id );
	}
}

Now, open up loop.php and replace post_class() with the newly created fjarrett_post_class().

This new function accepts the same parameters as the original function, so you can use it the exact same way. The only difference will be that the first and last posts will be marked automatically with an appropriate class name. Enjoy total control.

If this helped you in any way I’d love to hear about it in the comments!

Maybe you’re already using some sort of relative path method, like:

<?php include '../../../wp-load.php'; ?>

But this can create problems if directories change. You need a clean, dynamic way to get wp-load.php. So here is the simplest way to do it, with just two lines of code (place it at the very top of your file):

1
2
3
4
5
6

<?php
 
$parse_uri = explode( 'wp-content', $_SERVER['SCRIPT_FILENAME'] );
require_once( $parse_uri[0] . 'wp-load.php' );
 
?>

Short and sweet

Disclaimer: This is intended for experimental and development purposes only. It is not advised to redundantly load WordPress on live production environments. But, why?

After just three days of communicating back and forth (and one Skype call) he offered me a full-time position, and I wholeheartedly accepted! He flew me to Los Angeles a few days later to sync up with his top developers, Weston and Josh, who have been temporarily living here while working at FOX Broadcasting.

Needless to say, it’s been an outstanding experience working with these two. They’re not only top notch programmers but also great guys who are a blast to hang out with and have become good friends of mine. Since I’ve been here I’ve really enjoyed soaking up all the new information and techniques X-Team uses, specifically learning to incorporate version control with Git via command line into my workflow. I’m very happy to say I’m no longer Cowboy Coding!

My next big task (apart from client projects) is to bring a WordPress framework into fruition for X-Team that we’re calling: WPized. Weston Ruter has laid a ton of groundwork for the WPized framework already, so I’ll be taking a lot of what he’s started and simplifying it into a tool for creating themes rapidly. I’ll also be writing a lot of documentation for our other WP developers so they will know how to use the custom helper functions the framework will offer and all of this will hopefully make the process of theming much more unified within X-Team.

It’s an extreme privilege to be doing what I love for a company that boasts some very big clients, has a long history of doing extraordinary things and has a lot of fun doing it! I am very fortunate to not only be running my own theme shop but now also working with a superb international team on WordPress projects full-time…from home!

If you’re a theme or plugin developer you may have ran across the need to populate a dropdown list of your custom taxonomies. Essentially there are two different (easy) ways to accomplish this. One you always hear about and the other you don’t.

Method #1

Since WP 2.1 the wp_dropdown_categories function has been around but in WP 3.0 the taxonomy argument was introduced. So just calling this function and using the taxonomy argument is probably the absolute easiest way to populate a dropdown list of your custom taxonomies.

<?php wp_dropdown_categories( 'taxonomy=my_custom_taxonomy' ); ?>

This method is great if you need the output of your dropdown values to be the category ID. Because this is the HTML that will be generated:

1
2
3
4
5
6

<select name="cat" class="postform">
	<option value="3">Tax A</option>
	<option value="14">Tax B</option>
	<option value="26">Tax C</option>
	<option value="29">Tax D</option>
</select>

However, let’s say you want your option value output to be the taxonomy’s slug instead of the ID. Well, that’s impossible to achieve using the wp_dropdown_categories function.

Peering into the WordPress core we see that this function is using a walker class called Walker_CategoryDropdown. This walker is designed to output only the ID as the value for each dropdown item. There is not an argument in the function to control value output.

Method #2

That’s where Method #2 comes in. We’ll have to write our own custom function that will generate the dropdown so we can output each option value as a slug:

1
2
3
4
5
6
7
8
9
10

function fjarrett_custom_taxonomy_dropdown( $taxonomy ) {
	$terms = get_terms( $taxonomy );
	if ( $terms ) {
		printf( '<select name="%s" class="postform">', $taxonomy );
		foreach ( $terms as $term ) {
			printf( '<option value="%s">%s</option>', $term->slug, $term->name );
		}
		print( '</select>' );
	}
}

So, now that we’ve got a cool custom function, we can call anywhere in our code like so:

<?php fjarrett_custom_taxonomy_dropdown( 'my_custom_taxonomy' ); ?>

Expansions on Method #2

If you’re a coding rockstar you can take Method #2 even further by making room for more parameters. This will give you even more control and make it function more like wp_dropdown_categories does:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

function fjarrett_custom_taxonomy_dropdown( $taxonomy, $orderby = 'date', $order = 'DESC', $limit = '-1', $name, $show_option_all = null, $show_option_none = null ) {
	$args = array(
		'orderby' => $orderby,
		'order' => $order,
		'number' => $limit,
	);
	$terms = get_terms( $taxonomy, $args );
	$name = ( $name ) ? $name : $taxonomy;
	if ( $terms ) {
		printf( '<select name="%s" class="postform">', $name );
		if ( $show_option_all ) {
			printf( '<option value="0">%s</option>', $show_option_all );
		}
		if ( $show_option_none ) {
			printf( '<option value="-1">%s</option>', $show_option_none );
		}
		foreach ( $terms as $term ) {
			printf( '<option value="%s">%s</option>', $term->slug, $term->name );
		}
		print( '</select>' );
	}
}

Then call it in your code like so:

<?php fjarrett_custom_taxonomy_dropdown( 'my_custom_taxonomy', 'date', 'DESC', '5', 'my_custom_taxonomy', 'Select All', 'Select None' ); ?>

Conclusion

As you can see, WordPress has done a fabulous job of making room for you and I to do pretty much whatever we want.

To reference all available arguments and parameters, please see:
http://codex.wordpress.org/Function_Reference/wp_dropdown_categories
http://codex.wordpress.org/Function_Reference/get_terms

Was this code helpful to you? Let me know in the comments!

The Scenario

Let’s imagine you love to browse with Chrome on your beloved Mac and you frequently visit Facebook. So you type the letters fa in your browser’s address bar and *bam!* the URL auto-completes to read facebook.com.

It truly is a wonderful thing. But sometimes, it’s not so wonderful.

The Problem

Some users are reporting that when you first startup Safari or Chrome on a Mac the browser may take a while to load those auto-complete gems from your history. That’s not good when you’re used to typing fa and rapidly pressing Enter.

Oops! Now you’ve just asked your browser to visit fa (which does not exist) and from this point on facebook.com will show up as the second auto-complete option. Yikes! How do we remove that darn fa entry now showing above the actual entry we want?

There is hope.

The Solution

On a PC everyone seems to have the answer. You simply highlight the entry and press Shift + Delete. But us Mac users have an extra step that no one seems to be talking about.

On a Mac, you need to highlight the entry and then press Fn + Shift + Del. Now, you might need to wait a bit, or restart the browser to see it removed but I found it to work perfectly.

Did this work for you? Let me know in the comments.

Titanium
PhoneGap
Rhomobile
Corona
Sencha Touch

Has anyone had any experience with one or more of these?

However, there’s one pretty big feature that Cart66 is missing: the ability to display the Order History of a logged in user.

What? Really?

Yes. Really.

This doesn’t really require a lot of explanation. It was easy to achieve with a simple SQL query and a custom loop. And all without editing the Cart66 core! So you can keep updating the plugin without worry.

Websites that sell digital goods will especially find this handy since users will be able to view their past receipts to re-download purchases.

Just insert this code into the functions.php file of your WordPress theme and use the shortcode [order_history] on a member’s only page to show the Order History for that user. Enjoy!

The original code for this idea came from a post by Alison Barrett.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/* Shortcode for displaying Cart66 order history for the current logged in user
 *
 * @return {string} $table
 * @shortcode order_history
 */
function cart66_order_history( $atts, $content = null ) {
	extract( shortcode_atts( array(), $atts ) );
	global $wpdb;
	$results = $wpdb->get_results( "SELECT ouid, ordered_on, trans_id, total, status FROM " . $wpdb->prefix . "cart66_orders WHERE account_id = " . Cart66Session::get( 'Cart66AccountId' ) . ' ORDER BY ordered_on DESC' );
	foreach ( $results as $order ) {
		$data .= sprintf( '<tr><td>%s</td><td>%s</td><td>%s</td><td>%s</td><td><a href="%s" title="%s" target="_blank">%s</a></td></tr>', $order->trans_id, date( 'F j, Y', strtotime( $order->ordered_on ) ), $order->total, ucwords( $order->status ), home_url( '/store/receipt/?ouid=' . $order->ouid ), __( 'Click to view receipt', 'cart66' ), __( 'View Receipt', 'cart66' ) );
	}
	$table = '<table id="viewCartTable">
				<thead>
					<tr>
						<th>Order Number</th>
						<th>Date</th>
						<th>Total</th>
						<th>Order Status</th>
						<th>Receipt</th>
					</tr>
				</thead>
				<tbody>' . $data . '</tbody></table>';
	return $table;
}
add_shortcode( 'order_history', 'cart66_order_history' );

Once, I heard Matt Mullenweg mention in a podcast interview (can’t remember where, sorry) that he really wasn’t happy with the app and agreed there was still a lot to be done. I’m always glad to see Matt pushing for more and it makes me very optimistic about the app’s future.

I don’t intend for this post to be a rant, I just believe that in order for the app to have a successful future, it should be supporting what WordPress is already known for. Otherwise, Tumblr, Posterous and a slew of other platforms who are thinking more “mobile” could gain a significant portion of the WordPress market share.

It seems to me that there are five major components of WordPress that just aren’t supported by the app yet.

1. Custom Post Types
This is a big one. WordPress introduced them in June 2010 with version 3.0 and we still don’t have them supported in the iOS app. This is probably the biggest upset of the five since it has been around for over a year and involves the very core of WordPress: Writing posts.

2. Widgets
Seriously? Yes, seriously. Currently, there is no way to add, modify or remove widgets from your WordPress site using the iOS app. Some may disagree that this belongs on my list, but I think it’s deserving. Widgets were introduced in version 2.2 and are one of the core things that makes WordPress unique and attractive. The mobile app should reflect WordPress’s existing core strengths to differentiate itself from other mobile players.

3. Post Formats
Post formats were introduced in version 3.1 and I think it was an excellent addition. It took the Custom Post Types functionality from version 3.0 and expanded it even further. We even saw the birth of “Tumblogs”, or WordPress themes that function like Tumblr sites, all because of Post Formats. Hell, I can’t even use the default Twentyeleven theme effectively on iOS because support for Post Formats is still missing. This would be a huge improvement.

4. Custom Fields (Post Meta)
Some plugins and advanced themes take advantage of Custom Fields on WordPress posts and pages. Although not always crucial, this is another capability that already makes WordPress unique and is part of core functionality so I believe it should be a part of the mobile strategy.

5. Theme Options
Almost every theme these days has a variety of Theme Options. And I’m not just talking about the “Theme Options” item under the Appearance menu, but also Header, Background, Sidebars and any other options page available for a particular theme. Why is this last on my list? Because Theme Options aren’t exactly critical for delivering content, which is what mobile is really all about: creating and publishing content quickly while on-the-go.

Jump on over to the WordPress iOS App Forum to join the conversation or be part of the solution.