One Page WordPress Theme Workflows

So you want to build a one page WordPress theme from scratch and you’re not sure how to tackle it. WordPress is pretty flexible so let’s consider a few ways we can accomplish this goal along with the advantages and disadvantages of each approach.

1. Make Each Section a Page

This was my chosen workflow for quite some time and it’s still viable. Basically, you create a handful of WordPress Pages to act as your sections and assign each a unique Page Template which you develop and style according to your requirements. Additionally, you create a Page Template for your Front Page and inside that template you load the content from the other constituent Pages. This is probably the simplest option in terms of tweaking WordPress because you’re using 100% native functionality without the need for any plugins. However, you will need to write some code…

With this structure you need to:

1. Ensure your sections are not visible individually; and
2. Ensure you (or a client) can effectively manage section order or even repetition if you decide to reuse and repurpose a section’s Page Template

Your sections are simply WordPress Pages, which means they will be viewable individually by default. That’s not ideal and my advice is to make template_redirect your friend in this scenario. This will involve checking the Page Template of the current query against several values and redirecting visitors back to the home page. Overall this tweak is not complex… yet.

Now, you probably won’t want to go digging through template files and PHP each time you want to change the layout of your sections, and you certainly don’t want clients doing that. I’ve always embraced the native WordPress Menu system for effective section management with its drag-and-drop ease of use. It won’t be immediately intuitive from a development standpoint because this scenario doesn’t use menus strictly as navigation areas, but rather as a de facto ordered list of how your sections will appear. It also means you’ll need to write the code in your Front Page Template to actually traverse a particular menu’s sections and load their content. This could add some complexity.

If we want to ensure our sections are not visible individually, then a more effective way might be to add a catch-all that determines whether a particular Page is present in the specific menu we’re using for our section layout and simply run our template_redirect on those matching pages. This is optional and depending on your layout and requirements (e.g., whether your site is truly one page or if it’s multi page with a home page that contains several sections) you may just need a redirect for something like if(!is_front_page()) which will work just fine.

Make Each Section a Page – Advantages

1. The method of section management I described above is relatively flexible and should be safe in even the most cavalier clients’ hands
2. We’re using 100% native WordPress features (albeit with some custom code), so the chances of something going haywire are low

Make Each Section a Page – Disadvantages

1. Section management may not be intuitive because you’ll need to ensure new sections (i.e. Pages) are added to the menu you use, and while you could use the “Auto add pages” feature, that may have some unintended consequences
2. Redirecting the Pages you plan to use as your sections could end up being a headache, especially if your site isn’t truly one page but rather a multi page site with a home page that displays multiple sections
3. You’re using WordPress Pages as sections within another Page (your Front Page) and some developers may be uncomfortable with that non-semantic structure

2. One Page with Advanced Custom Fields Tabs

This workflow utilizes Advanced Custom Fields and its Tab fields. ACF tabs allow you to group certain fields together into… you guessed it, tabs! What’s great about this feature is that instead of having one long list of custom fields you can place each relevant field inside a tab named for the section it belongs in:

This structure won’t employ the native WordPress Menu system to easily rearrange sections, but you could create a field within each tab to allow an admin to enter a number—similar to the Order box in Page Attributes—which determines the section order numerically. You’ll need to build in some logic to ensure sections with the same number are handled appropriately and include that logic in your documentation, especially for clients. You might even consider a dynamically populated Select field to cut down on the risk of error.

@joelwarren pointed out that this structure presents some data portability issues if you or a client decide to abandon Advanced Custom Fields or if the plugin becomes inadvertently deactivated or deleted. You could include ACF directly in your theme if plugin management is a concern, but then you won’t have dashboard notifications of plugin updates and switching themes would effectively deactivate the plugin. A great alternative I’ve used is to restrict specific plugin deactivation. Consider running a check within that filter for certain users though; the ability to troubleshoot conflicts by quickly deactivating plugins is important.

One Page with Advanced Custom Fields Tabs – Advantages

1. This is semantic zen, no longer is content spread across multiple faux Pages because everything visible on the Front Page will be managed from that Page’s edit screen
2. No redirects necessary (and as @NateWr pointed out there are no superfluous pages/posts generated to impact your SEO)
3. No fumbling with Menu management

One Page with Advanced Custom Fields Tabs – Disadvantages

1. Tricky section order management with the potential need for a good bit of additional code
2. Server and memory issues can impact your admin area depending on the number of ACF fields you need—it could be a lot to fit into one Page’s edit screen
3. This structure makes it difficult to clone or create new sections, though not necessarily more difficult than method #1
4. Relies critically on the Advanced Custom Fields plugin

3. Advanced Custom Fields’ Flexible Content Field

If, like me, you are an avid ACF user who never got around to investigating the Flexible Content Field (“FCF”) then watch this video. Now.

The FCF “acts as a blank canvas to which you can add an unlimited number of layouts with full control over the order.” Sounds like exactly what we need, right? Well, it is and it isn’t. It’s definitely a great solution, but it’s far from perfect.

First, if your FCF fields have many fields then your edit screen could become unwieldy. You could experience server memory issues or just a lack of real estate which may make rearranging fields via drag-and-drop a bit difficult.

@TiborP also brought up navigation. His question is specific to Roots but the solution is universal, as @chriscarr pointed out. Simply create a sub field within each FCF that allows users to enter a title for each section, then loop through them as your nav menu and completely bypass the WordPress Menu system. See here for a working example.

This method also means you’ll be creating some de facto templates to display specific FCF types accordingly so you might consider loading them into your loop via include(locate_template()).

Advanced Custom Fields’ Flexible Content Field – Advantages

1. Again we experience semantic zen—all content that appears on the Front Page is controlled through that Page’s edit screen
2. Again, no redirects necessary and no superfluous URLs are generated

Advanced Custom Fields’ Flexible Content Field – Disadvantages

1. Potential for memory issues with large FCFs that contain many sub fields
2. Unwieldy rearranging of large FCFs
3. Definitely some coding overhead to load the correct field template; this can get very convoluted if you’re a relative novice

4. Custom Post Types with Advanced Custom Fields

After trying all of the above I’m still not completely satisfied. This is an untested technique I hope to experiment with soon.

Register a Custom Post Type called “Sections” and set it to 'public' => false and 'publicly_queryable' => true. Superfluous URLs solved.

Create an ACF Select field in each Section which determines that Section’s “template” (because currently hierarchical CPTs can’t take advantage of Page Templates).

Create an ACF Repeater field with Post Object Select fields on your Front Page which allows admin users to add, remove, or rearrange the Sections displayed on the Front Page. You would loop through this same Repeater field to create your navigation as in the FCF method.

Custom Post Types with Advanced Custom Fields – Advantages

1. Some semantic zen, still not as bad as method #1
2. No need for redirects

Custom Post Types with Advanced Custom Fields – Disadvantages

1. Admins will need to bounce back and forth between Sections and the Front Page for section management
2. Still potential for memory issues if you use a lot of ACF fields in a Section
3. Still needs custom functions in a few places

Conclusion

So which way is the right way? That I cannot say because there is no one “right way.” Based on your skill level and project requirements though, there is most definitely a “right way for you,” and I hope this breakdown helps you figure that out. If you have anything to add on any of these methods or if you devised a method of your own then please share by leaving a comment!