Back in the old days of blogging, my first ever blog (then hosted on Blogger) didn’t even have categories. Posts were just posts, and there was no way of organizing the content, aside from chronological order (by month, by year). When I moved to a Blog:CMS powered blog, I got to appreciate the wonder of taxonomy. The software now allowed me to categorize my content. And I thought it was really powerful.
However, there were limitations. Blog:CMS only supported one category per post. Imagine that! So when I got my first taste of WordPress, one of the things I really liked was how I was no longer constrained by a single choice of category.
So it was cool the way I could assign more than one category to each of my blog posts. However, this was still a plain old taxonomy system, and my category list was growing. A negative side-effect of this was that on my sidebar, the category list had grown too long for comfort, making the sidebar longer than the main content area in most occasions (especially on short posts).
Then tagging systems became popularized by sites like Technorati and del.icio.us. They say tagging is better than categorization because people are free to just attach keywords to their blog posts (or shared links), according to their needs and preferences. You’re no longer constrained to choose a few categories or sub-categories where an item might belong to.
One thing about blogs and bloggers is that link exchange is a popular means of networking with people. And another thing I notice is that most bloggers would love anything free–free services, free software, free hosting, etc.
However, most “free” things on the web aren’t exactly free. Most of the time, something is asked for in return. For instance, a free service might ask you to put up a link or a badge somewhere on your site. Another example, free blog software or plugins might have a condition that you put up a button somewhere on your sidebar.
Even a bigger thing would be widgets that you put up on your blog for various purposes, be they link exchange, RSS feeds, and the like.
Many blogs I visit have a lot of these buttons and badges, and frankly I think they tend to clutter the blog and lead to a bad user experience.
I have yet to come across a blog design that perfectly incorporates buttons and badges. But some of the blog-related services that we run at Splashpress Media ask users to link back, either thru an image or text link. Also, most of the blogs we run have ad buttons and badges. To lessen the visual clutter, what we do is put these in special areas on the blog. For example, a small box on the sidebar might be the best place to put buttons. Or perhaps, somewhere on the footer, below the copyright line.
I think this is one important consideration that a WordPress theme designer (or any blog theme designer for that matter) should consider. Bloggers will tend to add buttons, banners, widgets, and all forms of graphic and links on their blogs. So why not take this in mind when conceptualizing your design? Why not add areas on the footer or on the sidebar specifically to accommodate banners? Better yet, I think designers should package a users’ manual in the theme archive, and include instructions here on how to properly format or insert buttons, banners and text links.
Not everybody blogs in English, and neither should your WordPress theme be exclusively coded that way. With the help of localization plugins you can ensure that the next WordPress theme you’re building has text that can be translated into different languages. Cats Who Code has a great tutorial on it.
The gist is: Whenever you’re writing custom text, be sure to enclose it in the _e('text, 'domain') and __('text', 'domain') functions. Both basically output text as echo normally would, but used with a language file editor it lets you translate text quickly and easily. _e() is for printing text the usual way while __() is for printing text inside of PHP functions.
For more details, check out How to make a translatable WordPress theme.
Peter Westwood writes about two significant changes to the WordPress code that affect WordPress theme development:
get_template_part template tagThe first is a new template tag and feature called get_template_part, which helps recycle oft-used blocks of code like the WordPress loop.
get_template_part takes in two parameters: the first is the name of the generic template while the second is the specific template. For example, this line
get_template_part('nav', 'single')
looks for nav-single.php, then nav.php. If no such files exist in the current theme folder, WordPress will look for it in the parent theme folder.
Themes which use include template tags but do not have the corresponding files (e.g. get_header() and header.php) will no longer work properly unless a parent theme is specified in the style.css file.
The easiest way to fix this is to use the line
Template: default
in the stylesheet and make sure the default WordPress theme—this year it’s Twenty Ten—to be installed.
Keep these two points in mind when creating a WordPress 3.0-compatible WordPress theme.
28 Apr
Posted by Free WordPress Themes in: Blog Design, WordPress
There’s a popular Reddit thread that laments the ambiguous labels used in the pagination links, notably on WordPress:
To me, clicking on ‘next page’ should take me to the next page. Next comes after. Next means later posts, newer stuff, and so on. The ‘previous page’ link should go to the god damned previous posts. It’s simple.
Except many blogs have gone with the delightful ’stack of pages’ paradigm. The ‘next page’ link goes further down the stack, and ‘previous’ goes back up. W.T.F. It’s not a stack of pages, it’s a website.
Of course, this is all moot because everyone knows they should just use ‘older posts’ and ‘newer posts’ as links or simply older and newer instead of this next and previous business. Right? Right?
EDIT: The pagination thing sucks too. It inevitably happens on the bulkiest, slowest loading sites. There is NO reason to ever do it from a usability standpoint, so I suspect it is done for ad revenue.
The terms “older posts” and “newer posts” are much more descriptive, so it’s recommended that when creating a WordPress theme, use them instead.
Unfortunately the function names might still be confusing to use, so remember that it’s next_posts_link() that links to older posts.
Even better, use a pagination plugin so your theme users can more easily navigate through pages of archives. (The pagination the poster mentioned above was about breaking up the content into multiple pages either for extra pageloads or easier reading.)
JavaScript is an important part of creating a WordPress theme, and the jQuery is one of the most popular frameworks already integrated into the WP core, so one basic technique theme developers should know about is making a theme dependent on jQuery play nicely with how WordPress loads it. This crash course should help.
wp_enqueue_script to load WP’s copy of jQuery into your themewp_deregister_script and wp_register_script in addition to use another copy, e.g. from the Google AJAX libraryAll these tips should eliminate loading of unnecessary files that add bloat to your theme and the WordPress install. Now you can focus on making a kickass theme with brilliant effects.
Web Do’s and Don’ts gives the low-down on the right and wrong techniques on website navigation. This essential element, especially WordPress themes, should be given extra care when designed because it’s what visitors will rely on for getting around a website.
Number 5 is something WordPress theme designers should remember, as it is an out-of-the-box feature to keep post titles and menu items linked every time.
op111.net explains how WordPress Child Themes work and what you need to make your own. The crucial line that separates ordinary themes from child themes it the Template declaration in the stylesheet: Template: Kubrick means you’re basing the child theme on the Kubrick theme.
The tutorial even touches Firebug usage and explains what several CSS rules do. Child themes shouldn’t be considered inferior or any different from normal themes: the goal to use good, existing code so you don’t have to reinvent the wheel, and can focus on implementing your custom idea instead. The question, now, is how you can pick a suitable parent theme.
Otto on WordPress has compiled a list of the absolute minimum requirements every WordPress theme should have:
Too often I see themes missing the absolute minimum requirements to make the theme actually work properly. So I figured I’d make a list of things that ALL WordPress themes need to have in them, every time. These are WordPress theme-specific things. I’m not including obvious stuff like HTML and such.
The list covers everything until the not-yet-released version 3.0, which lets you call the default comment form using comment_form() and support the built-in navigation menu.
Oldies include the likes of wp_head() and wp_footer(), and class functions like body_class() and post_class() have been around for several versions now—there’s no excuse not to include these. Meanwhile, trickier features lie in the comments.php template, but once you get the hang of it, you’ll get along fine.
Keep these in mind along with our own FWPT checklist!
WordPress 3.0 is set to introduce a new default theme called 2010, and its development is underway. Konstruktors has a critique of the theme’s underlying code, which has sparked an interesting discussion of dos and don’ts for creating WordPress themes.
One burning debate is whether widgets should be marked up as a list. Check out there rest here. Be sure to read the comments below the post.