Tag: themes (page 1 of 2)

Rocking the Twenty Eleven Theme

With WordPress 3.2 out the door it seemed like a good time to try out the the Twenty Eleven theme. A few minor tweaks later and I’m pretty happy with the look.

I’m still on the look out for a good header image, any suggestions?

Learning By Reviewing

Joining the Reviewers Team is simple, just a matter of getting your environment setup (4-6 minutes) and grabbing a theme for review. The most interesting and valuable part is not that you’re helping out the community, but that you’re learning yourself. I personally reviewed a little less than 20 themes (and still counting) but I learned so much about them and the best practices of developing them, the Settings API, coding standards, and damn I learned two functions i had no clue about (checked() and selected()) — hope that doesn’t make me a rookie ;)

Konstantin Kovshenin from Introducing Minimal Georgia for WordPress, emphasis mine.

The WordPress.org Themes are reviewed by community members. As Konstantin points out, not only does this help the community as a whole, he also learned something new as part of the process.

Why WordPress Themes are Derivative of WordPress

Mark Jaquith has an excellent post describing Why WordPress Themes are Derivative of WordPress. Mark is one of the lead developers of WordPress and makes a living by doing freelance WordPress consulting (Covered Web Services).

What Mark points out is that WordPress and themes “run as one cohesive unit”. It’s a good read, I highly recommend it.

WordCamp SF 2010 Presentation Video

From WordPress.TV.

I’ll never get used to watching myself on video.

Database Powered CSS in WordPress Themes

A popular ability in WordPress themes is to add custom CSS driven by options. This brings up a common question, how should the theme inject custom CSS? I’ll outline three different approaches on how to do this. These aren’t new, many people have written about these; forums, blog posts, email lists and IRC. I’m still seeing questions about this though, so I wanted to address this specific question with specific solutions.

For the purposes of code examples I’ll assume that you have an option called my_background_color and that you want to do something like this:

body {
    background-color: <?php echo $theme_opt['my_background_color']; ?>
}

We’ll start with the simplest method.

header.php

Most themes have a header.php file that contains template code for the top of the HTML output. This makes it easy to add custom CSS with options, just echo it out inside the HEAD section of the HTML:

<style type='text/css'>
body {
    background-color: <?php echo $theme_opt['my_background_color']; ?>
}
</style>

The advantages to this approach is that it’s very simple, you already have a header.php so adding a few more lines doesn’t take much work. The disadvantage is that this solution isn’t very flexible, if you have complex rules about when and how to include the CSS then your header.php file gets a lot extra “stuff” that may not need for every page.

If your needs are simple then this works great. If not, I suggest using either wp_head or parse_request.

wp_head

Each theme calls a WordPress action at the end of the HTML HEAD section – wp_head – that can be used to include the custom CSS:

<?php
add_action( 'wp_head', 'my_custom_css_hook' );
function my_custom_css_hook( ) {
    # get theme options
?>

<style type='text/css'>
body {
    background-color: <?php echo $theme_opt['my_background_color']; ?>
}
</style>

<?php
}

The only real difference between this approach and the previous one is that it’s less clutter in header.php. Instead of having all that code in header.php it can be moved out to a separate file and WordPress will include it at runtime whenever the wp_head action fires.

parse_request

WordPress can provide your theme with custom URLs, these can turn around and serve up what ever you want, including CSS. This technique takes a little bit more work, but provides the maximum degree of flexibility. There are a couple steps to this one, first what you’ll need to have in header.php:

<link rel='stylesheet' type='text/css' href="<?php bloginfo( 'url' ); ?>/?my-custom-content=css" />

The my-custom-content=css just needs to be something unique to your theme so that it doesn’t conflict with plugins that might be using parse_request as well.

Next we need to tell WordPress how we want to handle this request:

add_action( 'parse_request', 'my_custom_wp_request' );
function my_custom_wp_request( $wp ) {
    if (
        !empty( $_GET['my-custom-content'] )
        && $_GET['my-custom-content'] == 'css'
    ) {
        # get theme options
        header( 'Content-Type: text/css' );
?>

body {
    background-color: <?php echo $theme_opt['my_background_color']; ?>
}

<?php
        exit;
    }
}

A few things in there that I want to point out. Pay attention to line 8, this tells the browser what sort of content we are sending back. In this case it was CSS, but it could have been JavaScript or anything else. Also note that I didn’t add any cache related headers, it’s worth reading up on cache control in HTTP headers so that you know how that works. Line 16 is also important, we don’t want WordPress attempting to do any further processing after we return the CSS so the right thing to do is exit as soon as possible.

And if you wanted to keep the CSS in a separate file ( custom-css.php for our example ) that looked more like a normal CSS file then the my_custom_wp_request function could look like:

function my_custom_wp_request( $wp ) {
    if (
        !empty( $_GET['my-custom-content'] )
        && $_GET['my-custom-content'] == 'css'
    ) {
        # get theme options
        header( 'Content-Type: text/css' );
        require dirname( __FILE__ ) . '/custom-css.php';
        exit;
    }
}

allowing your custom-css.php to look like:

body {
    background-color: <?php echo $theme_opt['my_background_color']; ?>
}

basically just enough PHP to fill in the option blanks, other wise a normal looking CSS file. I rather like this approach, it provides a nice degree of separation and control.

Conclusion

Now you have three methods for including database powered CSS in your WordPress theme. I like using parse_request with the CSS in a separate file ( the last example ), for a little bit of extra work you get lots of flexibility and a nice layer of separation that makes managing the CSS portion easier.

Having any tips on how to improve on this? Leave a comment below!

WordPress Theme Authors, Don’t Forget The wp_head() Function

When creating a WordPress theme don’t forget to include a wp_head(); call in the HTML HEAD section of your theme. It’s very simple to do, just include:

wp_head();

Before the closing HEAD tag (</head>) in your HTML.

Why make such a fuss over a single function call? Because it does a fair bit of work behind the scenes and without it some WordPress features will not work properly. Take a look at the wp_head section of the wp-includes/default-filters.php file in WordPress, you’ll see a number of events that are tied to the wp_head action.

One area where this is a particular problem is for offline blog clients that make use of the XML-RPC and AtomPub APIs in WordPress. The “Really Simple Discoverability” (RSD) link that WordPress inserts instructs these clients on where to find the RSD URL, which contains information on how the clients can send XML-RPC and AtomPub requests. We’ve seen a number of times now where an error reported by a WordPress iPhone App user is caused because there is no RSD link in their WordPress blog. Looking a little deeper reveals that there was no RSD link because the theme they were using didn’t include a call to wp_head().

If you are writing a WordPress theme here is your reminder, make sure that the wp_head() function is being called at the end of your HEAD section.

Theme Directory Interview

Ian Stewart has an interview up about the WordPress Theme Directory: Matt Mullenweg & Joseph Scott Discuss The WordPress Themes Directory.

WordPress > Theme Directory

Bringing the new theme directory under the WordPress “extend” umbrella allowed us to take advantage of all the infrastructure that has already been built up to support WordPress.org. If you’ve browsed through the plugin directory, you’ll feel right at home in the new theme directory.

WordPress Theme Directory.

Since announcing this last night we’ve had a lot of new theme submissions. So far the responses I’ve seen have been very positive and excited about having a new central home for WordPress themes.

Looking for WordPress Themes Authors to try out a WordPress.org feature

There’s a new feature at WordPress.org in the works. We’ll be
providing to theme authors what wordpress.org/extend/plugins/ has for
plugin authors.

The core features are there and now I’m looking for some theme
authors to test it out and provide some feed back. If you are
interested and willing to provide feedback please contact me and let me know what your wordpress.org username is.

Links for Tue 29 Jan 2008

Older posts

© 2014 Joseph Scott

Theme by Anders NorenUp ↑