Complex WordPress IA part 3: WordPress Parent – Child Pages

This is part 3 of a 3 part series looking at how to achieve less straight forward relationships between data on WordPress.  Read Part 1 and Part 2 here.

For our last part we’re going to extend something that WordPress does have, namely, hierarchical pages.

In this example, we’ve got a Parent Page and each Parent has multiple Child Pages.  We want to do two things; first, use WP Query to display the children on the parent page, and when we’re on a child page,  to show a menu of the Child’s sibling pages (that is, other pages with the same parent).

List Child Pages

Before we actually write our query, we need to tell WordPress to use this page’s unique ID in order to only show this Parent’s children. We could just get the integer, but we’re going to create a variable so we can use this for other parent pages with out manually updating our code for each id.  This is also really important when you’re thinking about developing locally and pushing your changes up to a development environment (and from there, a production site).  Fortunately, this is really simple. The WordPress function get_the_id gets the ID, and we’ll store it in a variable $postid.

The next step should look familiar to you by now. In to our $args variable, we’re going to pass these options: 'post_type' => 'page', and 'post_parent' => $postid.  We pass args in to a new query like so: $query = new WP_Query( $args ); and then we’ll pass our $query in to the WordPress Loop, like so: if ( $query->have_posts() ) : while( $query->have_posts() ) : $query->the_post(); .

Don’t forget to close your loop with endwhile and endif,  and if you have other loops you need to account for, wp_reset_postdata never hurts. Inside your loop, write any markup that pleases you. Generally for this purpose, I prefer to use an unordered list and list items.  That’ll do for your parent template.

Sibling menu

But once we’re on a child page, it’s not a bad idea to show a user what else is on this heterarchical level. On the child template (or wrapped in a conditional on what ever template you plan on using for children), let’s define our $children variable.

We’ll use the WordPress function wp_list_pages and set the child_of option to post->post_parent.  When you’re done setting the rest of the options the way you’d like, we’ll pass that variable to echo in a separate unordered list.  Simple, right?  Here’s the full code:

if ($post->post_parent) { $children = wp_list_pages( array( 'title_li' => '', 'child_of' => $post >post_parent, 'echo' => 0, ));} else { $children = wp_list_pages( array( 'title_li' => '', 'child_of' => $post >ID, 'echo' => 0, ) ); }if($children) : ?><ul class="nav-list"><?php echo $children;?></ul><?php endif;?>

Styling the Sibling Menu

We’re going to base our styling around this responsive pattern. Although it has a small javascript dependency, it allows to keep our menu present in the flow of the content and allows a user to use the native tools on their smartphone.  For screens over your typical mobile device, we’ll just situate it inside of our container as a list like other navigation. Easy and robust!

Conclusion

Information Architecture is just making sense of your mess.  It’s a subtle craft and on good sites and applications, a user will never see the IA at work.  Unfortunately for you and me as Front End Designers, we have to understand the intent of the IA, be aware of the limitations of the platforms we use, and discern the best methods of building out the site based on both. Now, at least, you’re armed with a tool kit to tackle more complex information structures in WordPress.