Building a Better WFPL with WordPress

Like many news sites, WFPL was faced with the challenges of keeping readers engaged and showing advertising in a noticeable but non-intrusive way. With WordPress as our base, we collaborated to build a writing flow tailored to how they work.

While Emilee & I worked together to implement WFPL’s new design, we set up a system for customizing featured content on their front page and built extensions to WordPress’ post editor to suit their writing process. These extensions enable authors to curate related content on their new posts and control where WFPL’s new in-stream advertising appears.

Featured Posts

WFPL needed more rich featured posts capabilities than WordPress sticky posts provided. Specifically, we wanted to give WFPL control over the visual hierarchy of their featured stories. We took inspiration from INN’s Project Largo theme’s post prominence features and implemented featured post slots as a custom taxonomy.

Editors can add stories to these prominence slots to feature them on the home page. The home page always shows the newest stories in each slot which reduces manual curation work. These slots didn’t need to be editable by anyone (as they’re built with a very specific purpose) so configuring this taxonomy was a little different than usual. These settings create the prominence taxonomy but don’t allow users to do anything with it but assign stories to our pre-configured prominence slots.

Post Relationships

One goal of the redesign was to keep users reading WFPL content after their initial visit. Many sites do this through showing related stories below or around the current story, but automated related content feeds are never perfect as they often rely on crude metadata like post popularity or categorization. The same related posts can show up across the entire site due to high page views and an algorithm is only so good at connecting the dots between different stories.

We instead opted for a hybrid of manual curation and automation. Authors are encouraged to select stories that relate to their new story and we automatically fill in stories from the same category if necessary.

We used the Posts to Posts plugin to display a box in WordPress’ admin where the post author can curate related content. Once we installed the plugin this function call set up our relationship.

Make sure you set 'cardinality' => 'many-to-one' and 'show' => 'to', or the relationship will get set up backwards.

We also provide a shortcode to allow authors to manually call out posts inline with content. This can be used to provide context for information presented in the current story alongside it instead of at the end with other related posts.

A related story callout

Handling Ads in Dynamic Content

The single column layout of the new single story page challenged us to integrate advertising inline with the content in a way that drew attention but didn’t detract from the reading experience.

Each story has two ad units: Primary and Secondary. The primary ad unit appears in the middle of the content while the secondary unit displays at the very end. We briefly explored the idea of implementing a user-controllable shortcode to display the primary unit, but that would’ve required every author to remember to place an ad in their story. There are a few plugins that handle inline ad placement, but none offered the level of control WFPL’s content required.

Instead, we implemented both ad units as sidebars and added a theme option to set how many paragraphs into each story it should display. A custom post field was added to allow that default position to be overriden at the post level so the author can make sure the ad doesn’t appear in an awkward position in their story.

We initially tried implementing this using simple find & replace within a filter on the_content. Unfortunately for us HTML is fairly complicated to parse, so we turned to PHP’s built-in DOM library to do the heavy lifting. We also ran into issues where other plugins didn’t play nice with the_content and broke our ad placement, so we’re inserting our ads right before the content is rendered to the template instead of in a filter.

This function parses a post’s HTML into a DOM tree so we can accurately count block-level elements and insert ads according to author preference. As we iterate over a collection of DOM nodes we render each to an HTML string and the ad sidebar is rendered into that string where necessary. WordPress doesn’t provide a way to render sidebar HTML to a string without also echoing it to the browser, so we use output buffering to get what we need.

You can adapt this to your theme by changing the call to get_sidebar to your sidebar’s name, 'theme_option_ad_p_count_txt_input' to your theme option key, and 'wfpl_ad_override' to the name of a custom post field of your choice. If you’re not planning on giving WP authors control of placement, you can set these values in code.