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!


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.

Responsive Images

Update 2: this technique – the padding box aspect ratio – is featured in Ethan Marcotte’s excellent book Responsive Design: Patterns & Principles.

Update: My good friend Russ made a JS Fiddle of this. Check it out!

More than any other single problem,  Responsive images illustrate *why* front end design is so difficult.

Responsive Images have too many solutions

There are a ton of solutions to responsive images, and this is one of the giant problems with figuring out how to solve them.

Here are some of the common approaches:

  1. width: 100%; height: auto;
  2. Interchange – swapping out images based on media queries (either via show/hide css,  javascript or using the picture element and a polyfill)
  3. Cropping
  4. background images (which have long had better support for some features)

These all have use cases and none are “better” than the other.  When making front end design decisions, it always comes back to what’s right for this project, which always starts with understanding the content of the project.

It is also important to understand that each has trade-offs too. For instance, if you’re going to use interchange, you’re going to need multiple files that have to be sized, optimized, maintained, and figure out how you want them to load, and really wonky markup, and or a javascript dependency. On the plus side, you also have much more control over the art direction on various devices.

However, an approach that enjoys a lot of support and solves a lot of problems is one we use a bunch at Spry.

We call this an aspect-ratio first approach.

Aspect Ratio

Just to refresh you: aspect-ratio is the width of an image over the height of an image.  All screens have an aspect ratio, and the math of a ratio is easy to communicate across disciplines. The Creative Director, Art Director, or Designer and I will talk through picking the aspect ratios we want to maintain in the design. Some of the common ratios out there are:

 Square – 1:1 (or 100%)
Panoramic – 21:9 (42.857%)
Widescreen – 16:9 (or 4:3, 56.25%)
Thirds – 3:2 (66.667%)
Landscape – 8:5 (62.5%)

The code

The coding here is pretty simple (another benefit). For markup, we’re going to start with the figure element This tells any screen readers that there’s a visual element here, and also gives us the option to pass in whatever we want. Inside of the figure element, we’ll have a wrapper div and for this example we’ll have a div with a background-image. Like I said, background images have wide support and really good features like background size, background position, background blend mode, repeat, and more. It also lets us do things like add text over the image without extra markup.

Next, we’ll create a few classes in our .css to achieve the effect.

First, we’ll set a width of 100% on the wrapper, and we’ll set the position of this wrapper to relative.

For the div inside of the wrapper, we’re going to set it position: absolute, and top:0; left:0; bottom:0;, and right:0;. To make our lives easy, we’ll set background size to cover too – this will pull the image to “cover” the div, which is now absolutely sized to the 4 sides of the wrapper. If we need to add text styles, like, making it white text so it will show up on a dark background, we can do that here too, but if it’s just the image, it’s not necessary.

Here’s the trick: padding is always calculated based on the width of the element. Which means we can set a % value of padding-top or padding-bottom, and this will always set the height relative to the width. Which is *exactly* the concept of the aspect ratio. Because we might be using different aspect ratios, I like to set classes for each of the aspects I noted above.  Which means adding an aspect ratio is as simple as adding a class to this display pattern.  This is more code up front but better scalability later because I don’t have to reinvent the wheel or come up with a new clever name.  It’s treating the job like a prep chef instead of a diva.

 .aspect-wrapper {
.aspect-image {
background-size: cover;
.square-aspect {
.pan-aspect {
padding-bottom: 42.857%;
.wide-aspect {
.thirds-aspect {
padding-bottom: 66.667%;
.landscape-aspect {
padding-bottom: 62.5%;
<div class=”aspect-wrapper landscape-aspect” >
<div class=”aspect-image” style=”background-image:url(insert the url of the image here);”></div>

I like to write this with the background image styled inline, because then I can pass it’s url in as a variable using php or whatever the templating language is, or just because I’m probably not using the same image for each instance of this pattern.

This allows our image to always maintain the same aspect ratio (e.g. no weird cropping, no losing focus, etc) no matter what.  As solutions go it is robust, reusable from project to project, and allows lots of control over art direction.

Hope it helps!