function check_custom_query_param( $query ) {
    if ( isset($query->query_vars['custom_param']) && $query->query_vars['custom_param']) {
        $query->custom_param = true;
add_action( 'pre_get_posts', 'check_custom_query_param' );

function change_where_query( $where, &$wp_query ) {
    global $wpdb;	
    if ( property_exists ( $wp_query , 'custom_query' ) && $wp_query->custom_query ) {
    	// change the where query
    return $where;
add_filter('posts_where', 'change_where_query', 10, 2);

The snippets story

Some weeks ago I wanted to pass a custom parameter to the WP_Query object to change the where-query if the param was true. The problem was, that to extend WP_Query with a parameter, you have to circumvent the filtering of the query options. I solved this by hooking into the pre_get_posts action. There the custom parameter is still available and we can easily add it to the filtered query object.

Update: Simply Related Posts 1.3 comes with a Serbian tanslation! Thanks to Borisa Djuraskovic from!

I’ve just released Simply Related Posts 1.2, a new version of my Simply Related Posts plugin. Now it supports pages, attachment-pages and custom post-types, which makes it a lot more flexible. Additionally I’ve added a filter to the related post-title, so you can add thumbnails, excerpts or anything else you can think of.

Test Simply Related Posts 1.2 now, download it from the plugin directory.

As always, post your questions, feedback etc. here below in the comments section!

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.

WordPress themes are amazing and since WordPress 3.4 there is an inbuilt customizer to make individual changes as easy as possible. One commonly used feature of the customizer is changing the background color or other basic colors of the theme. That is really great, but I like to think that there are a lot of bloggers like me out there, without any talent regarding colors or design. For all of us, manual color customization uses to generate ugly blogs. So think it would be great to have preconfigured WordPress theme color schemes.

My “Color Scheme every Theme” plugin is built to help us to customize the colors of our blogs. It makes it easy to extract the colors of every theme (if it is built with css) and to change them from the admin interface. So, if you want to ask one of your designer friends for help, he or she doesn’t have to go through hundreds of lines of css, it’s enough to change the extracted color scheme via the admininterface, no coding involved.

Embeding preconfigured color schemes in the themes you are selling

I think that’s a really nice feature, but I think even more important is the possibility to embed as many preconfigured color schemes as you want in a theme. So, if you are a themedeveloper, generate some perfectly matching color schemes before you upload your theme to a marketplace of your choice, make a light and dark variant, a greyscaled and colored one or a variant for all four seasons. Then, embed those in your theme and make it even more valuable for your customers.

Color Scheme every Theme 2.0 (read about v1.o here) makes it even more easy to create color schemes for WordPress themes.

Get version 2.0 on

After the release of version 1.0, some bug-fixing and the release of two minor versions I had got so much feedback that I thought it was time to implement the two feature requests most users suggested:

  • Editing color schemes directly in the admin interface, instead of having to add code in the functions.php
  • An option to make the css for all schemes available in the theme, to make it possible to change the scheme not only via the admin interface, but even on the front-end.

This resulted in a completely new options page, see a screenshot below:


Here you got the possibility to edit the scheme directly in the admin interface. Just click on a color and change it in the Change color input field, hit enter, pick the next color you want to change. Don’t forget to save the schemes when you are done.

If you want to use the Dynamic theme colors option and used version 1.0 of the plugin, you have to regenerate the schemes.

There is still the possibility to permanently add a scheme to your theme by copying it to the functions.php of that theme. If you want to do that, just create the new theme via the admin interface, save and click on the < embed in theme > link, which opens an textarea with the code you have to add in it.