If you are using WordPress as a blog, organizing your content is quite straight forward. You categorize and tag your posts, create nav-menus, to link the most important categories, use archive or calender widgets and order your posts by publishing date (which is the default). Using WordPress as a CMS for a common website and building the navigation, often requires a bit more structural planning. The thing is that there are multiple strategies, which might be right or wrong depending on your demands. In this article I want to present a list of the approaches I use.

Inbuilt and custom post types

But first some words about the standard post types build into WordPress. When I build a website with WordPress, I naturally use pages for all static content, but in the beginning I even tried to use the standard posts post type for all continuously updated content like news sections, upcoming events and so on.

However, after some time I realized that posts really only should be used for blog content and nothing else. All the other stuff should be implemented as custom post type. There are two simple reasons: Your client might decide to integrate a blog with the website in the future and by that time the posts section is bloated with other content. Secondly is my experience that custom post types for events or newsfeeds are just more usable and intentional, than the standard posts, especially when there is some extra functionality needed, like start/end-date for an event.

So, when you are implementing one of the following strategies, make sure that you choose your post types well.

One-level menu

The easiest variant of content structure is just a bunch of pages without any hierarchy. Typically you would create a menu, under Appearance->Menus in the admin interface, and add all relevant pages to it. Here an example how to embed a simple menu into a theme:

wp_nav_menu( array( 'theme_location' => 'main-menu' ) );

For many small businesses this content structure is appropriate. Often it is quite easy to determine the few sections of content the wesite’s user will be interested in, e.g. “General information”, “References” and “Contact information”. You will both get a easily navigated site and a very simple backend.

When not to use it: There aren’t any drawbacks. If the content structure stays as simple as described above, there will be no problems.

Multi-level menu

Now, not every website works with a simple structure and not every client is satisfied with only telling the stuff visitors want to know. Sometimes clients want there websites to present the whole company structure and in these cases you need a hierarchical navigation, perhaps with a dropdown menu.

The good thing is, that there is support for multi-level menus in WordPress and implementing them, can be quite simple. In the back-end it is as easy doing some drag&drop actions to create a hierarchical menu of your pages and the simplest way to implement it in your theme is just the same as with one-level menus. You might add a depth parameter, to limit the count of levels your for the navigation.

wp_nav_menu( array(
    'theme_location' => 'main-menu',
    'depth' => 2
) );

This would print a nested list representing your hierarchical menu and with some suckerfish magic you make it a dropdown in minutes. You can even build a nested navigation where every page contains a submenu with pages on the same level, by printing the whole menu on every page and hiding the irrelevant portions of the menu with CSS.

But there are drawbacks. The big problem I see with multi-level menus is, that your menu, doesn’t organize your content. Even if you have built a well structured menu, your pages section in the admin-interface isn’t organized at all, it’s just a very long list of pages. I see this as a real usability issue for our clients and there are only two (suboptimal) solutions I can see. The first is telling your client to use the search field, because the structure showed on the website is not represented in the pages section. The other is to hierarchically organize your pages the same way you did it with the menu and mirroring all changes in future, which could be a big amount of extra work.

When not to use it: If there are many pages and you don’t want your client to do the extra work of organizing both menus and pages. Or if you want to implement submenus/breadcrumbs without printing the irrelevant parts and hiding them with CSS.

Multi-level pages

If multi-level menus don’t work for you, you could abandon menus and only organize by page hierarchy. Compared to the really easy way you drag and drop menus, it is a somewhat clumsy method, to enter the editor of every page and choose a parent, but it works. Here is how to create a menu just from the page structure:

        wp_list_pages( array(
            'title_li' => null
        ) );

The advantage over menus is that you directly can access the pages parents and child’s and thus know on which menu level you are operating with your page template. This makes it possible to build all kinds of custom navigation elements like submenus or breadcrumbs. Following the code to print a submenu with links to pages on the same level as the current page.

        wp_list_pages( array(
            'title_li' => null,
            'child_of' => get_post( get_the_ID() )->post_parent
        ) );

One thing to remember is that you can’t add one page in multiple places like you can with menus, because you are generating the menu directly from the page hierarchy. In case you need, say a contact page, in two places on the menu you have to create two contact pages.

When not to use it: If your client doesn’t feel comfortable with the way you structure pages or you want to link pages in multiple places in your menu this approach isn’t the best.

Integrate categories with pages and menus

You can even use categories to organize your pages. You could use the built in categories, but I think it’s better to create an own taxonomy, mostly because of the reasons discussed above, why you shouldn’t use posts for something else than blogging. Following some code to add a custom taxonomy to categorize pages, to include in the functions.php:

add_action( 'init', 'add_page_categories' );

function add_page_categories() {
         'label' => 'Page Category',
         'rewrite' => array( 'slug' => 'page_cat' ),
         'hierarchical' => true

Now you can select the categories for every page and add them to a (multi-level) menu. The advantage over simple multi-level menus is that the categories add some structure to the pages section, even if you don’t get the whole hierarchy. In my opinion the checkbox to select the category is slightly more usable than the child/parent selection lists, which are building the page hierarchy.

And there is another thing about this way of building a menu: you can list multiple pages under one menu-item, which is kind of sabotaging the static content thought. However, it can make sense in some situations, for example a contact page which is intended to list all employees and you add one page for everyone instead of listing them in one pages content block.

When not to use it: If your client isn’t familiar with the WordPress UI it might be one more hurdle to learn not only page editing and building menus, but also using the category checkboxes.

One-level menu plus page-hierarchy

This last approach to multi-level navigation uses both menus and page hierarchy. The idea is to only use a menu for the first navigation level, so you can easily rearrange and fully control your main menu. Then, all the pages linked in your main menu are used as parents for subpages, so the multiple levels get implemented by the page hierarchy. The next two pieces of code show how to print the main navigation with the wp_nav_menu function and how to output a submenu by using wp_list_pages.

<!-- main-menu, only add parents -->
    wp_nav_menu( array(
        'theme_location' => 'main-menu',
        'depth' => 1
    ) );
<!-- end main-menu -->
<!-- sub-menu -->
        wp_list_pages( array(
            'title_li' => null,
            'child_of' => get_post( get_the_ID() )->post_parent
        ) );
<!-- end sub-menu -->

This solution I use very much because it solves a whole bunch of problems I discussed earlier in this article:

  • you get the flexibility of menus for your main navigation
  • you get the structural advantages of hierarchical pages
  • you don’t have to build the hierarchy two times
  • you can present a clean and logical structure to your clients

When not to use it: If you want to build a simple dropdown-menu and can be sure that there wont be any more complicated navigation requirements, multi-level menus would be the better choice.

Bottom line

WordPress as CMS has quite a few possibilities to organize your content and build a navigation. Of all approaches I’ve shown I think I would prefer the last one, mainmenu plus page hierarchy, in the most cases where a multi-level navigation is needed. It uses both the strengths of menus and page hierarchy, is easy to implement with the WordPress API and extendable if new navigation functionality is needed. From a usability point of view it makes use of the WordPress UI in the most common and intuitive way.

if (function_exists('add_image_size')) {
   add_image_size( 'dummy-1', 940, 450, true );
   add_image_size( 'dummy-2', 480, 0 );

global $_wp_additional_image_sizes;
foreach ( $_wp_additional_image_sizes as $name => $image_size ){
    update_option( $name."_size_w", $image_size['width'] );
    update_option( $name."_size_h", $image_size['height'] );
    update_option( $name."_crop", $image_size['crop'] );

add_filter( 'intermediate_image_sizes', 'regenerate_custom_image_sizes' );
function regenerate_custom_image_sizes( $sizes ){
    global $_wp_additional_image_sizes;
    foreach ( $_wp_additional_image_sizes as $name => $size ){
        $sizes[] = $name;
    return $sizes;

WordPress custom image size crop: The snippets Story

If you are using custom image sizes in your WordPress theme you likely know the problem. Cropping, rotating or flipping an image via the WordPress image editor, works just on the original. After editing the image is not available in your custom sizes anymore, all you get in your theme is the edited version in original size.

I thought that there has to be a simple solution to this problem, because it is pretty basic after all. But a quick google search just got me not working code. Finally I found some code on pastebin that pointed me in the right direction.

Copy and paste the above code into your functions.php, adjust the image sizes and even your cropped images should be available in your custom sizes.

$menuParameters = array(
    'echo' => false,
    'items_wrap' => '<nav>%3$s</nav>',
echo strip_tags(wp_nav_menu( $menuParameters ), '<a><nav>' );


    <a href="...">...</a>
    <a href="...">...</a>
    <a href="...">...</a>

Source: Remove LI Elements From Output of wp_nav_menu

HTML5 wp_nav_menu: The Snippets Story

This is how you build a HTML5-navigation without lists in WordPress. I slightly changed the code I found on CSS-Tricks. Had to post this after todays reading of “Navigation in Lists: To Be or Not To Be” by Chris Coyier.

“A man must have a code” – Bunk in The Wire

I recently uploaded my first plugin to the WordPress Plugin Directory, wrote some plugins at work and most importantly used a lot of the plugins out there. So I thought the time has come, to step back and think of what I’ve learned about plugin development and I came up with my personal WordPress plugin best practices, my three golden rules:

WordPress plugin best practices no. 1: Do not try to improve the UI

First rule is simple, don’t touch the standard WordPress UI. There might be ways of doing things better, there might be nicer looking checkboxes and coloring up things would surely give the admin interface a friendlier touch. But, there are better ways to communicate your ideas than just making up new UI-styles in your plugin. I think one reason why WordPress is as big as it is, is consistent UI-design, don’t mess with it.

WordPress plugin best practices no. 2: Leave theme developers in controll

Whatever your plugin is doing, it is most probably impacting the current theme in some way. And that makes you the theme developers friend – or most hated enemy. Theme developers want to control all of their theme, HTML output, css-classes, javascripts, language and so on. They don’t want a plugin to inject uncontrollable bits of code into their theme.

So treat them as grown-ups and let them be responsible for their theme. Give them hooks, filters and functions to control the output, admin options to let them deactivate automatically enqueued scripts and styles, prepare for localization and what else you can think of.

WordPress plugin best practices no. 3: A plugin does what it has to do, nothing more

Keep your plugin as simple as possible, do not bloat it with functionality just because you can. Every plugin adds complexity to the admin interface and every plugin has to get along with other plugins. Therefore “as simple as possible” even means fewer bugs, less confused users and less support.

Ask yourself questions like these: Does my nice little Widget really needs an own stats section or global settings? Are custom database tables really necessary? Am I using the plugin API as much as possible? Is there really no way around these custom database queries? And so on …

Have these WordPress plugin best practices in mind, when writing your next plugin and I’m sure it will be a success.

I know, there are a lot of widgets out there, to print related posts, but none of them I tested really suited my needs. First of all I think  a widget shouldn’t have a whole bunch of global settings, rather no global settings at all, I mean, it’s just a widget. But, even if I don’t like a huge settings page, just to run a little widget, there has to be some flexibility to let me adjust every widget-instance to my needs.

The Simply Related Posts Widget

In the case of related posts I couldn’t find a widget that really did what I wanted so I build my own. There are no global settings, but every widget instance has four options:

  1. The title of the widget (default: Related Posts). It is similar to all other widget titles and gets printed before the widget-content.
  2. The taxonomy by which terms the posts are related (default: Tags). A post is related to another post, as soon it they share one or more terms of a taxonomy. This can be the standard taxonomies Tags and Categories, or Custom taxonomies. Here youchoose which taxonomy is the relating one.
  3. How many related posts to show (default 5). Quite simple, put the maximal number of related posts you want to be visible here.
  4. Terms to exclude (default: none). Sometimes there are terms in a taxonomy, which are related to almost every post. The tag wordpress in my blog is such an example. If you have such tags you should exclude them, because they relate basically all posts, which would make the widget quite uselessscreenshot-1


  1. Download the plugin from the directory: Simply Related Posts
  2. Unpack and upload the simply-related-posts folder to the /wp-content/plugins/directory
  3. Activate the plugin through the ‘Plugins’ menu in WordPress
  4. Go to the ‘Apearance/Widgets’ area, add the ‘Simply Related Posts’ widget to a widget area.
  5. Make your settings


Of course I want your feedback: Bugs or feature requests are welcome in the comments of this post or via twitter and I appreciate every review.

For now the code is available via svn from the plugin directory:

Now, there is even a github repository: