There’s a never ending discussion about WordPress themes in forums I visit and meetups I attend. Paid vs. free; custom clones vs. child-parent themes; large frameworks like Genesis vs. stand-alone themes like Twenty Eleven. Here are my thoughts:

Large framework themes make me uncomfortable and a little nervous. It’s the curse of knowing how to code PHP, HTML, CSS, JavaScript, etc., that you can see the bad engineering choices made in bringing these large theme frameworks to market. Not to put these products down – any significant and powerful software system will have such flaws yet still provide positive value to their users. My main problem is that they are filled with a lot of code that’s entirely irrelevant and wasteful for any given website or client.

Back in 2006, when I started working with WordPress, I made custom websites by cloning the Kubrick theme (now called “Default” and installed with WordPress.) I’ve pretty much stuck with the WordPress provided themes since then because my focus is on finding the right functionality for a client and making sure it’ll work correctly in most circumstances.

I do parent-child themes now for the obvious reasons: to take advantage of new functionality and bug fixes that come in theme updates. Now that I know how to write plugins, I put the code for custom post types, shortcodes, content filters, etc. into one or more custom plugins to preserve that functionality should a client decide to change to an entirely new theme. It also makes it easier to debug plugin conflicts.

I would prefer that my clients not even know about themes. But every couple of years they get the urge to upgrade their website and they ask whether they need a new theme. My response is to change the subject by  explaining the difference between semantic structure (HTML), visual style (CSS) and element behavior (JavaScript). I tell them any of this can be redone within the existing theme. Alas, many of my clients know only what they see and the options for change are showcased by the various themes we discuss.

Twenty Eleven

by wordpressdotorg

Bouquet

by automattic

Sunspot

by automattic

Twenty Ten

by wordpressdotorg

Next Saturday

by automattic

Sundance

by automattic

Classic

by wordpressdotorg

Esquire

by automattic

Default

by wordpressdotorg

Dusk To Dawn

by automattic

Matala

by matt

Coraline

by automattic

ChaosTheory

by automattic

Pilcrow

by automattic

Mazeld

by matt

Toolbox

by automattic

Parament

by automattic

Pink Touch 2

by automattic

Duster

by automattic

Beach

by automattic

Steira

by automattic

21 Recommend Themes

While I’ve not worked with all 21 of these themes, they are included because of my trust in their authors. There are 4 themes from WordPress.org that’re installed with each instance of WordPress; 15 more themes from Automattic, the company that runs WordPress.com, and 2 themes from Matt Mullenweg, the CEO of Automattic and WordPress’ creator.

What kind of themes do you like to work with?
Please share your thoughts by commenting on this post using the form below.

Larry

WordPress is 9 years old

So far, there’s no sign of a new “TwentyTwelve” theme. However, there is a new theme previewer/activator that allows an administrator to set a number of theme options and see how they look before saving the options and activating the theme. It’s really nifty. I’ll have more on the new version after the weekend.

But, I also wanted to share my excitement on attending a wonderful event last Thursday and getting to meet Matt Mullenweg, the creator of WordPress and CEO of Automattic. The event was the first in a series of monthly “fireside chats” organized by Pandodaily.com. Matt was interviewed by Sarah Lacy, the founder and editor-in-chief of PandoDaily. It was a long, free-wheeling and thoroughly enjoyable interview and Q&A. My thanks to Howard Greenstein for  getting me in to the event.

Happy Memorial Day!
Larry Aronson

When you’re dealing with custom post types you eventually come to the question of what should show up on an archive or search results page (SRP). Say the custom post types are created by a plugin or are built into a special-purpose theme like property listing posts in a real estate theme. How do you know whether or not they’ll show up on an SRP?

The answer is found in the question.
Specifically, the SQL select statement – the request that WordPress sends to the blog’s database. Unfortunately, that statement isn’t readily available to the code in the theme’s template files. The main database query for a WordPress page happens before any of the code in the theme folder is run.

We need to use a WordPress hook to capture the SQL statement before it’s sent to the database. Then we can display it later anywhere we want to; like at the bottom of a Search Results Page. (OK, I’ve read enough; just give me the code.)

/** 
 * debugging tool - display the main sql statement at page bottom
 **/

// comment out the next 2 lines to disable this tool 
add_filter( 'posts_request', 'my_posts_request_filter', 9999 );
add_action( 'wp_footer', 'print_my_sql_statement', 9999 );

// filter function to save the SQL request in a global variable
function my_posts_request_filter( $input ) {
     global $my_sql_statement;
     $my_sql_statement = $input;
     return $input;
}

// action function to print out the global variable
// works only on a SRP but you can change the conditional
function print_my_sql_statement() { 
     global $my_sql_statement; 
     if (is_search()) print_r($my_sql_statement); 
}

The WordPress hook to use is called, posts_request. WordPress passes the main SQL select statement to any filter function registered at that hook. That function can modify the query but, for now, we can just store a copy of it in a global variable. This hack requires editing your theme’s functions file, so make sure you take a backup copy first.

Add the following code to the theme’s functions.php file.

function my_posts_request_filter( $input ) {
     global $my_sql_statement;
     $my_sql_statement = $input;
     return $input;
 }

You can rename the variables and the function itself, if you want; just be consistent when you use the global variable later in your template files.

The function has to be registered to run at the post_request hook. Add the following line to the functions.php file. It can go either before or after the function definition you just entered.

add_filter( 'posts_request', 'my_posts_request_filter', 9999 );

The first argument of the add_filter function is the name of the hook and the second is the name of your function. The third argument is the priority. This we set to a large value because we want our function to run after all other functions registered at that same hook, in case any of them modify the SQL statement.

Save  functions.php and load a page from the site just to make sure you’ve not made any stupid syntax errors. Your site should be unchanged by the new filter function; all it’s doing is saving one more global variable in the WordPress sea of data objects available to the theme.

Now we do the same to instruct WordPress to display the SQL statement at the bottom of a SRP page. Add the following function to the functions.php file:

function print_my_sql_statement() { 
     global $my_sql_statement; 
     if (is_search()) print_r($my_sql_statement); 
}

The first line  makes the global variable, $my_sql_statement available to the function. The second prints the value of the global on the condition that the current page is the result of a search.

To get this code to execute at the end of a page, you add it to the wp_footer hook:

add_action( 'wp_footer', 'print_my_sql_statement', 9999 );

I found this technique very helpful in learning how the WordPress functions, wp_query() and get_posts(), process their arguments, which can get rather complex when trying to include/exclude posts based on the values of custom fields. Understanding that process made it possible to use another WordPress hook, pre_get_posts, to exclude some custom post types from site searches based on their custom field settings. I hope you find this helpful as well.

Happy Hacking,
Larry Aronson

Photo Credit: http://www.flickr.com/photos/widnr/6544914763/

I’ve been working with the beta and release candidates here on this blog and the improvement that has me most excited is the unified drag-n-drop media loader. In version 3.3, the four buttons for image, video, audio and media are gone;  there’s only one Upload/Insert media tool.

Clicking the Upload/Insert button pops up the new loader which defines a space for dragging and droppin one or more files. You can see this in the following screenshot showing me uploading the following screenshot into this post following this sentence.

The uploader then smartly figures out what type each file is and displays them in the familiar show/hide popup panel. But, it keeps the drag-n-drop window available for more quick uploads into the gallery. Editors will appreciate this thoughtful touch.

The second new feature I like is the Welcome to WordPress 3.x dashboard page that you’re returned to after automatically upgrading to a new version. It describes the new features. It’s the version’s README file located in your blog at /wp-admin/about.php. It’s very friendly.

It part of a package of new features that make the dashboard a more friendly place for the millions of non-technical, website owner/operators who are using WordPress as personal publishing platforms (like many of my clients.) In the same manner, version 3.3 pops up a tip window the first time you try a dashboard feature or visit an admin page.  And, throughout the dashboard, there are improvements and added touches that’ll make it more application-like. According to the about page, these are:

• Combined toolbar and admin bar — They’ve finally gotten it right and it can be customized by theme developers
• Fly-out dashboard menus — No more accordions. The sub-menu extend out horizontally
• Screen design fixes — To take into account tablets and other non-pc devices and screens
• Better  help information — A frame open at the top of the page with tabbed sections and related links

For theme developers, WordPress version 3.3 adds new APIs for the editor and dashboard admin screens supposedly making it easier to customize the back end for special themes and applications. It also include the complete jQuery UI stack and makes good use of it. This more or less standardizes WordPress’ JavaScript framework. It’s a good move, in my opinion. Other JavaScript frameworks such as MooTools, Prototype and Scriptaculous may have richer behaviors to attach to page elements, but they are also prone to causing plugin conflicts.

Anyway, Based on my first impressions and a few hours spent with it, I con recommend updating your WordPress to version 3.3 soon, especially if you regularly write posts with images and other media attachments. As always, back up your WordPress files and database before you upgrade your website. If you’re using non-standard plugins or customizations, ask your web developer if they are compatible with the new version. And, don’t forget that you can aways get answers from the WordPress Support Forums.

Happy Blogging!
Larry Aronson

Good News Everyone! The post/page editor is getting an upgrade with the soon-to-be-released version 3.2 of WordPress. This solves the problem of disappearing Google maps and YouTube videos. Both rely on iframe elements to embed the contents of one webpage into another. Unfortunately, the current version of WordPress’ built-in editor doesn’t like iframes* and you have to limit yourself to working in the editor’s HTML mode. Once you switch to Visual mode, the iframe elements are stripped out of your post or page and the map or video disappears.

In WordPress 3.2RC1 (aka: Release Candidate 1) currently running on this blog, iframe elements are saved as I switch between the editor’s Visual and HTML modes. So are most of the new HTML5 tags including: the canvas and video elements – but not the audio element! This has been reported as a bug.

In the discussions on blogs and WordPress forums, one of the solutions for working with iframes was to use a general purpose shortcode to work around the editor’s restrictions. This approach is worth a second look because it gives authors the capability to embed anything they damn well please in a post without ever having to use the editor’s HTML mode – a big plus for some of my clients who go totally cross-eyed whenever they look at HTML.

The Macro Shortcode

Say you want to show a Google map in a post about an event happening in your neighborhood park. Getting the map is easy:

The idea behind the Macro Shortcode is that the embed code from Google (an iframe element) is pasted into a custom field for the post. The name of the custom field can be something descriptive, like “google-map”. In the WordPress editor, inside the Custom Fields box, click on the “Enter New” link to create a new custom field with the name, “google-map”.

[macro name="g00gle-map"]

To make this work, you need to define the macro shortcode and add it to your theme. The following PHP code added to your theme’s functions.php file does the trick.

// macro shortcode — a function to insert the value of a custom field into a post
// [macro page=<page_id> name="post-custom-field-key"]

function my_macro( $atts, $content = null ) {
    extract(shortcode_atts(array( 'page'=>'', 'name'=>'' ), $atts));
    global $post;
    if (!is_numeric($page)) $page = $post->ID;
    return get_post_meta($page, $name, true);
}

add_shortcode('macro', 'my_macro');

Make sure you first backup the file. See the WordPress Codex for more information on the get_post_meta() and add_shortcode() functions.

The macro shortcode will also accept a post or page id parameter which gets a custom field from some other page or post. This is handy when a small block of marked up content is needed in more than one place on the site. For example, to create a customized signature macro that can be added to the ends of posts (like you do with emails,) you could add a custom field to your bio page. Let’s say this bio page has an id of  3 and you’ve created a custom field attached to that page, named it “signature” and gave it the following value:

<p style="text-align: right; color: red;">That's All Folks! 
&mdash;<a href="http://loonytunes.fun/bios/bugs"><em>B.Bunny</em></a></p>

Now, all you have to do is insert this shortcode at the end of your posts:

[macro page=3 name="signature"]

and it will be replaced with your red, right-aligned sign-off message.

WordPress has introduced a new “default” theme, Twentyeleven. It’s a variation of the Twentyten theme introduced with version 3.0, with a slightly cleaner look. I put default in quotes because neither theme is really a default. Both Twentyten and Twentyeleven are better characterized as showcase themes. Both override several of WordPress’ built-in default settings and demonstrate how to use some of the newer features for specific design objectives such as featured images for custom page headers. [Note: this blog is using the theme, Tabula Rosa by Leo Newball, Jr. Click the thumbnail above to see what it would look like in Twentyeleven.]

WordPress Dashboard

A welcome addition to Twentyeleven is a Theme Options dashboard page that provides control over link colors and whether to display the sidebar on the right, left or not at all. The Custom Headers and Background Colors option pages from Twentyten have be duplicated in Twentyeleven.

One new feature all WordPress authors should welcome in the revamped, full-screen editing mode. It’s has full editing features including a field for the title, a save/update button, tabs to switch from visual to HTML mode and an abbreviated toolbar with icons for bold and italic, ordered and unordered lists, blockquotes, images and links. Strangely, the post editor toolbar has new icons that appear duller and less interesting then before:

Post Formats

Twentyeleven adds big-time support for post formats, which were introduced in version 3.1. Post formats are like categories except that they refer to the content’s format rather than its subject matter. A post can be in only one format chosen from the predefined list. Where Twentyten moved much of the post processing to template files based on post type: loop.php, loop-page.php, loop-single.php and loop-attachment.php, Twentyeleven has template files specific to post formats: content.php, content-aside.php, content-gallery.php, content-link.php, etc.

HTML5

Twentyeleven is an HTML5 theme. So is Twentyten but, whereas Twentyten just has an HTML5 Doctype declaration, Twentyeleven goes further by using the new HTML5 sectioning elements: nav, header, hgroup, article and footer. A conditional statement loads in an HTML5 shim for people using versions of Internet Explorer before IE9. It would be nice to add these new document elements to the paragraph menu on the editor’s toolbar.

Speaking of IE, the announcement states that WordPress 3.2 will not support IE6 — Yippie! I’m guessing that this means the Dashboard will not work well in IE6 but, if you make the effort and construct a good CSS stylesheet, the public front end should work. To help, Twentyeleven ids the html element so that you can construct specific CSS rules for IE6 users, such as:

#ie6 div.content { ... }

The Dashboard’s been given a facelift. Everything works the same but looks prettier due to new fonts and some CSS3 goodies used to great effect—background gradients, box shadows, rounded corners and text highlights. The little AJAX wrinkles have been smoothed out and the interface elements respond quickly.

I find the small changes made in the Dashboard pleasing and send kudos out to the designers who keep making a good user experience better. One disappointment is that they haven’t yet addressed the shortcomings in the way WordPress manages media attachments. Instead of having a separate database table, media files are represented by attachment posts in the main post table, reusing post fields for image caption and alternate text information. A rebuilt media manager was supposedly slated for a 2.9.x release but kept getting put back. I look forward to progress in this area.

The upgrade was simple and straightforward, as is usual with WordPress. Since there’s no automatic install for beta releases, it requires an FTP program to upload the new files. I highly recommend backing up everything first. While not ready for important production websites, this first beta of version 3.2 is worth installing on a test blog just to get an early look at the Twentyeleven theme and begin testing the functionality of post formats.

Overall, editing this post under WordPress 3.2 has been solid. I’ve not encountered any bugs or glitches. WordPress.org states that 3.2 is a performance upgrade. This is only one post and on a new blog so I can’t measure or verify any improvement based on my experience so far. I’ll take their word for it. Thanks WordPress.

A client wanted to list the blog’s most popular posts in the sidebar. There are many plugins available that will provide a widget for this task. Most are based on comment count as this is the metric that WordPress stores with each post record in its database. Some of the more sophisticated plugins make API calls to other services, such as Twitter and Google, to gather ranking data.

But nothing worked quite right for this client who had become a proficient Google Analytics user as well as a ardent Twitter user. I couldn’t find a popular posts plugin that would reliably match her subjective sense of popularity. I finally sent an email saying: “You want your readers to see your best stuff, in that respect, the numbers can provide guidance but your own judgement is the best metric.” I promised to figure something out that would allow the management of a Top-Ten Posts lists.

Rather than write a new sidebar widget, I decided to write a shortcode which could be used in a sidebar text widget to display the content from a specific page. Then my client could simply edit a page containing an ordered list of permalinks to the most popular posts and it would appear in the sidebar widget. It could also be used in other posts or pages on the site.

How to Build a Sidebar Page Widget

To start, create a new static page with a title like, “Popular Posts”. Enter an ordered list of permalinks to other posts for testing.

You need to add a function to your theme’s function file, functions.php, that will output the contents of a page when called from the shortcode. Make sure you backup functions.php before you make any changes! WordPress has built-in functions for getting the contents of a page. Use get_page_by_title( ) to fetch the page by its title. Here’s the code for the function:
function my_show_page( $atts, $content = null ) {
extract(shortcode_atts(array( 'title'=>'' ), $atts));
if ($title != '') {
$page_data = get_page_by_title( $title );
return $page_data->post_content;
}
else {
return '';
}
}

The first two lines are the standard setup for a shortcode. The parameter, $atts, will contain the shortcode’s parameters. In our case there is only one parameter, the page’s title which is extracted by the second line of the code. Setting the variable $content to null allows us to place the simple shortcode:

[showpage title="Popular Posts"]

wherever we want to display the content of the page “Popular Posts” .

The body of the function is a simple if statement that makes sure a title is provided, then goes and gets the content of that page and returns it. The content is returned unfiltered. That is, it’s unaffected by any plugins (e.g: ShareThis) or other code that modifies content.

The shortcode must be registered to make it available for use. This is just a short command that also goes in the theme’s function file:

add_shortcode('showpage', 'my_show_page');

It can go either before or after the definition of the my_show_page function. I usually place it after the function along with comments to guide any future programmers who may work on my clients’ sites.

Shortcodes are not enabled by default in text widgets because of security concerns. Sidebar text widgets are places where people often embed code clipped from outside sources. The concern is that such embedded code might contain a shortcode that could cause a conflict. This is usually not a problem for smaller, personal blogs. Here’s the command to enable shortcodes in text widgets:

add_filter('widget_text', 'do_shortcode');

Add the above to your functions file, save it and test the blog in a separate browser window to be sure it’s still working. Errors in a theme’s functions file will usually crash the public portion of a WordPress blog, but will leave the admin dashboard in working order.

Lastly, add a text widget with the shortcode to your sidebar. Here’s a screenshot from my client’s site illustrating this.

For your convenience, here’s the entire block of commented code that I added to my client’s function file:
/**
* Create a shortcode to display a page's content */
//
// [showpage title="page_title"]
//
function my_show_page( $atts, $content = null ) {
extract(shortcode_atts(array( 'title'=>'' ), $atts));
if ($title != '') {
$page_data = get_page_by_title( $title );
return $page_data->post_content;
}
else {
return '';
}
}
// register the shortcode
add_shortcode('showpage', 'my_show_page');
//
// Enable the use of shortcodes in text widgets.
add_filter('widget_text', 'do_shortcode');

Now that we see how easy it is to get formatted content into a sidebar widget, perhaps you have some ideas on what can be done with custom shortcodes in sidebar widgets. If so, please share them by leaving a comment below. Thanks.

Most everything described in this post can be done using only WordPress’ built-in template editor available to admin level users.

One client wanted to display a Twitter stream in a sidebar widget showing all tweets mentioning his company. His designer provided this nice graphic to use as the background to the widget’s title:

with the text to appear in white, shifted over enough to give the bird some room to fly. In the Widgets manager (under the Appearance menu,) I added a new text widget to the the sidebar and gave it the title: “Our Company on Twitter.” I left the body of the text widget empty for now and saved it.

I reloaded the site’s front page and inspected the source code to see how this particular theme marked up the title with HTML. It was in a level three heading (h3,) enclosed inside of a division with id="sidebar". With no unique identifier for the widget, I couldn’t simply code a CSS rule, such as:

#sidebar h3 {
  color: white;
  background: url(images/twitter_widget_background.png) no-repeat;
}

as that would put the twitter background behind all sidebar titles and headings.

jQuery to the rescue. It has a method for adding a CSS class to an HTML element and can select document elements by searching their content. jQuery is not loaded by default in WordPress but many themes load it automatically at initialization. See the WordPress Codex page on enqueing scripts for information on safely loading jQuery from various sources.

Using an FTP program, I uploaded the image to the images directory inside of the theme directory. If you don’t have FTP, you can use the file manager in your hosting account’s control panel. Alternatively, you can upload a graphic to your Media Library using WordPress’s media manager and then use the full URL in the CSS below.  The CSS class is needed to establish the background element. It goes in the stylesheet template (style.css ) which can be edited using the Appearance Editor.

#sidebar h3.twitter {
  color: white;
  background: url(images/Twitter_widget_background.png) no-repeat;
  height: 36px;
  padding-left: 60px;
 }

Some simple jQuery is added to the header template (header.php.) It can go anywhere after the script tag for the jQuery library.

<script type="text/javascript">
   jQuery(document).ready(function() {
     jQuery("#sidebar h3:contains('Our Company on Twitter')").addClass('twitter');
   });
</script>

When the document is ready and all elements have been defined, the above code will attach the CSS class, twitter, to any level three heading in the sidebar that contains the string: “Our Company on Twitter”.

The Twitter search feed comes directly from Twitter’s goodies page. One of the goodies is an interactive wizard that will generate the code to copy-paste into the sidebar text widget’s content.

You can do more than just change how the title looks. Want to make a widget title link to something? In the same way that a CSS class can be given an element based on its content, the element’s behavior can be changed. Working with the code above, a click handler can be added to the selected widget title.

<script type="text/javascript">
  jQuery(document).ready(function() {
    twitterWidget = jQuery("#sidebar h3:contains('Our Company on Twitter')");
    twitterWidget.addClass('twitter');
    twitterWidget.click( function () {
      document.location = 'http://twitter.com/OurCompany';
    });
  });
</script>

Adding the following CSS style rules to the theme’s stylesheet will make the title look and act more like a link:

#sidebar h3.twitter:hover {
  color: blue;
  text-decoration: underline;
  cursor: pointer;
}

Resources:

• jQuery documentation
• CSS background images