if ( !is_admin() ) { 
    $theme  = get_theme( get_current_theme() );
    wp_register_style( 'your-style', get_bloginfo( 'stylesheet_url' ), false, $theme['Version'] );
    wp_enqueue_style( 'your-style' );
}

I don’t really like the get_theme() line, but I am not aware of a better way to get the version info. What’s good about that line is that it gets the version of the current child theme, if you’re using one.

One problem with enqueuing styles is that most themes need one or two additional CSS files inside conditional comments for a certain browser. Nacin pointed me to a solution:

if ( !is_admin() ) { 
    $theme  = get_theme( get_current_theme() );
    wp_register_style( 'your-style', get_bloginfo( 'stylesheet_url' ), false, $theme['Version'] );
    $GLOBALS['wp_styles']->add_data( 'your-style', 'conditional', 'lte IE 8' );
    wp_enqueue_style( 'your-style' );
}

See also the relevant discussion on trac. Using this could lead to script concatenation problems in the WordPress core (which doesn’t concern a theme developer) and if a website uses plugins like wp-minify. So you probably only want to use this in your own themes, not public ones.

I have another equally stupid pet bug. Basically, a CSS file can break core functionality which can lead to bugs in plugins like my theme switching plugin. It’s a rather rare bug but the sloppiness of the coding is on the same level.

I have a code-centric blog. I post a lot of code, and of course readers post code themselves from time to time. Of course WordPress has to mess with comments as well. I realize that removing potential XSS code is a good security measure. But seriously. Do not delete any content before it goes into the database (besides SQL sanitization). I can’t even recover that comment now.

Wordpress rant over

In your theme’s functions.php add something like the following code:

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

function mytheme_addmenus() {
	register_nav_menus(
		array(
			'main_nav' => 'The Main Menu',
		)
	);
}
add_action( 'init', 'mytheme_addmenus' );
 
function mytheme_nav() {
    if ( function_exists( 'wp_nav_menu' ) )
        wp_nav_menu( 'menu=main_nav&container_class=pagemenu&fallback_cb=mytheme_nav_fallback' );
    else
        mytheme_nav_fallback();
}
 
function mytheme_nav_fallback() {
    wp_page_menu( 'show_home=Start&menu_class=pagemenu' );
}

In line 1 we add support for the navigation menus. The mytheme_nav() function is what you will use in the theme to display the menu. Inside that function we check if wp_nav_menu() exists, that means if we’re running WordPress 3.0 (or later). If not we’ll use the fallback function mytheme_nav_fallback().

Notice that the fallback also gets called if no navigation menus have been created in the admin area. That’s what the fallback_cb parameter on line 4 does.

To keep the HTM markup and the CSS consistent you’ll have to use the container_class parameter on wp_nav_menu but the menu_class parameter for wp_page_menu.

In your template use the following code to use your new custom function:

<?php mytheme_nav(); ?>

Resources

• wp_nav_menu() reference
• wp_page_menu() reference
• Informative article on nav menus by Justin Tadlock

Ramblings

What’s good about the new menu system:

• Total control over what appears in the menu
• You can add posts, pages, categories and tags in the menu
• Very nice drag and drop interface

What’s bad:

• You will have to teach your users how to use the system properly.
• If you create new pages they won’t be added to your existing menu (except for top level pages).
• You can not control your page menus through the navigation menus interface. I think it is… very very odd that WordPress doesn’t have a simple drag-and-drop interface to arrange pages.
• The previous point means that the new menu system is useless unless you update your theme.
• The wp_nav_menu() call is inconsistent with the existing wp_page_menu() function.

   $my_query = new WP_Query( "cat=3" );
   if ( $my_query->have_posts() ) {
       while ( $my_query->have_posts() ) {
           $my_query->the_post();
           the_content();
       }
   }
   $GLOBALS['post'] =  $GLOBALS['wp_query']->post;

Restoring $post is necessary because $post->comment_status of the post in the outer loop can be wrong after running the inner loop. That was the only problem I found, by I prefer to restore $post completely just to be sure. WordPress 3.0 has a function wp_reset_postdata() that you can use to restore $post.

I use this technique to show an “excerpt cloud” in a post using a shortcode.

To my surprise wp_list_comments() didn’t output anything inside my custom loop. It turned out that $wp_query->comments was NULL, which I think is rather odd. I would have expected it to be defined like in a normal loop inside WordPress. However, the fix is trivial:

 $post->ID,
        'status' => 'approve',
        'order' => 'ASC'
    );
    $wp_query->comments = get_comments( $args );
    wp_list_comments( );
    comment_form();
}

comment_form() is a WordPress 3.0 feature by the way, so you may not want to use it yet.

If you write WordPress plugins and want them to be published on the WordPress plugins page you have to use svn which can be painful once you’re used to git.

Fortunately, git can interact with svn via git-svn. Here’s a list of the commands you will need to use.

git svn init -s http://svn.wp-plugins.org/your_plugin

Update:
The git svn init + git svn fetch takes forever on the WordPress repository. Instead, use svn log http://svn.wp-plugins.org/your_plugin to get the correct revision number and git svn clone http://svn.wp-plugins.org/your_plugin -rYOURREVISION.

This will initialize a local git repository. Inside the repository, use

git svn fetch
git gc
git branch -a

The first command will take a few minutes and fetch all tags, branches etc. from the svn repository. The second command cleans up your git repository. This will significantly reduce it’s size. The last command will list all branches, local and remote. To track the remote trunk in a local branch use

git checkout -b svn-trunk trunk

svn-trunk is just the name the local branch gets in this example, you can use anything you like.

A normal workflow usually looks like this:

git checkout -b newbranch # create a local branch that you edit
... edit ...
git commit -m "Added awesome new feature" -a
git checkout svn-trunk
git merge newbranch
git svn dcommit

These commands create a local branch where you can try new things. Commit the changes to your local branch. Then check out the local svn-trunk branch that tracks the remote WordPress repository, merge the changes from newbranch. Then rebase the svn branch to the subversion trunk. The last command will update the remote svn trunk, assuming you really named your local trunk branch svn-trunk. As we’re talking about WordPress plugins you’ll want to tag your commit so that older versions of your plugin can still be downloaded.

git svn tag version

This will create the tag in the remote svn repository. It looks like this is only possible since git 1.6.1. For Debian Lenny systems you’ll need git from backports.org for this to work.

This should get you started with git and WordPress plugin development. Please do read the git documentation for more details, as git-svn has some limitations: Only use the described workflow if you’re the only commiter and work with one git repository.

That’s not good. Yes, jquery is lightweigt, CSS files aren’t big, but that’s not a good reason for making every visitor download them. I did some research and it doesn’t look like anybody wrote about a solution yet, so here’s one way. Usually, you would add an action to wp_print_styles or wp_print_scripts that does something like this:

add_action( 'wp_print_styles', 'yourplugin_include_css' );
 
function yourplugin_include_css() {
    echo $csslink;
}

Instead, try this:

add_action( 'wp_print_styles', 'yourplugin_include_css' );
 
function yourplugin_include_css() {
    // Check if shortcode exists in page or post content
    global $post;
    if ( strstr( $post->post_content, '[yourshortcode]' ) ) {
        echo $csslink;
    }
}

That’s it. Please don’t add custom javascript or CSS on each and every page of my blog.

Update: See this excellent post for an improved solution.

Update 2: The best solution for loading JavaScript so far

Another fine document that some developers seem to ignore is the list of plugin API hooks. Please, read that section, and include these hooks in your template! Some plugins need that API hook to work at all. My surprisingly popular snowstorm plugin for example certainly does.

While you’re at it, think about how you want to style, for example, the wp_footer() call. When I visit pages that give me a backlink through that call, sometimes the backlink is displayed in very odd places and with weird colors.

Finally, although it has already been said on the pages I linked to, get the theme unit tests and use them! It’s quite embarassing for a designer to release buggy WordPress templates.

Initialized empty Git repository in /current/path/repository/.git/
ssh: Could not resolve hostname my.host:: Name or service not known
fatal: The remote end hung up unexpectedly

The solution was rather easy, see man 1 git-clone. A valid git URL looks like this:

ssh://[user@]host.xz/path/to/repo.git/

Don’t try to use paths as ports. git isn’t scp.

When the user clicks into the field you’ll want to remove the clue. The obvious way to do this is to add an onclick JavaScript command:

<form>
    <input onclick="this.value=''" type="text" value="Your email" />
</form>

The user can still access the input field through other means than clicking. He can use the tab key for example. That’s why usually the onfocus event is more useful:

<form>
    <input onfocus="this.value=''" type="text" value="Your email" />
</form>

This seems to work nicely. However there’s still a problem. When a user fills in his email address, reads a little more on your site and clicks the input field again, his address will be removed again! So to make sure this doesn’t happen we add a little check for the content of the field:

<form>
    <input type="text" value="Your email" onfocus="if (this.value == 'Your email') {this.value=''}" />
</form>

And here it is:

Restore default value if nothing is entered

Ok, now this is working. However, when your visitor decides not to input any data, the field stays empty. If you have no label for the input he or she might forget what the field was for. We fix this by restoring the default value when the input field is left:

<form>
    <input type="text" value="Your email" onblur="if(this.value == '') { this.value='Your email'}" onfocus="if (this.value == 'Your email') {this.value=''}" />
</form>

Thanks to Ray for his example linked in the comments.

Select onclick

But sometimes this isn’t the best solution. It could be more desirable to highlight the content of the input field if you’re offering some kind of search. The user may not want to start a new search but to modify the existing one.

By highlighting the input field the user can choose to either empy it by starting to type or to modify it by using the arrow keys.

<form>
    <input onfocus="this.select()" type="text" value="Your previous searcj" />
</form>

Dynamic input color

This is a little advanced. Let’s assume you want the default value to be in a different color and change it onclick. This is one working solution:

<form>
    <input style="color: #f00" type="text" value="Your email" onblur="if(this.value == '') { this.style.color='#f00'; this.value='Your email'}" onfocus="if (this.value == 'Your email') {this.style.color='#0f0'; this.value=''}" />
</form>

Keep in mind that this might create problems when you reload the page. Some browsers will remember the value of the input field, and the color will be different even though the field does not contain the default value. Fixing that is beyond the scope of this post. See onload and domready events.