Plugins, Themes

WordPress Plugin Integration with Custom Theme Development

Plugin Integration with Custom Theme Development

(Warning: this article contains heavy usage of the word “custom”, and it may or may not be surrounded in quotations)

I just built a custom WordPress theme that relies heavily on the Advanced Custom Fields (ACF) plugin. This is the first time I’ve ever done this, and I was reluctant to do so. I didn’t want to have a theme hinged upon this one plugin.

But it doesn’t have to be …

When you are building custom WordPress themes for clients you are usually doing so because they couldn’t (or you couldn’t) find an appropriately suited theme for their content. Or perhaps they just wanted to pay you to build something tailored to their content. This is where ACF really makes a difference with your content. These “custom fields” or “custom meta” can be more precise when dealing with “custom content”. It’s harder to do this with out of the box WordPress. Posts and Pages are great but many times you need more custom content.

So how do we go about doing this? More importantly, how do we try our best to do this the right way, the WordPress way. Ultimately we want this to be easier on the development side of things and for our clients to walk away with a great product that will not have serious repercussions down the road. Specifically we can talk about content portability here. If we create tons of custom meta, custom post types or custom fields and bake that into our theme the client is stuck with that theme. If they switch themes they loose all of that data.

It was brought up in the Asheville WordPress Meetup last night that if someone is paying you to build a custom theme than they will also pay someone down the road to maintain that content. Their content will be portable because they will pay someone to port that content to their new, probably custom, theme. There is an argument for that, but…

The problem with baking in custom fields, custom slides, custom widgets, custom functionality in a custom theme is arguably two main things, maintenance and organization. What I mean by this is simply that it will be much easier for you to maintain and organize your code if you separate functionality from presentation. Put your custom fields, custom meta, etc.. in a portable plugin, and have your theme handle the display or presentation. For the developer this will be much easier to debug and find problems. Plus, your code will be well organized. Your slider will be in a plugin folder, and your custom widget will be in another. If there are conflicts with a plugin from the wild and your plugin you can appropriately deactivate/activate to debug. This is a separation of concerns with regards to your WP “custom” setup. This will save you a huge amount of time and a lot of headache.

Why would your developer preferences benefit your client?

So what does the business owner get? What does the client get? Why would your developer preferences benefit your client? My argument would be that when they do decide to switch themes or perhaps they have an awkward error message displaying on their site, it will take a developer, someone they hired, less time to debug therefore costing the client less. If they are building a new theme. Porting their custom content will be a snap, all you have to do is call the custom content in the theme and style it. Less digging!

The main point is that trying your best to do things the right way will have a cost benefit for the client. Way too often I have seen companies, agencies taking an easy route by purchasing a theme and modifying it with custom features. I have also spent a lot of time fixing those problems. That time is money to the client.

SO, how do we do this? In the case of building a site with the Advanced Custom Fields plugin I suggest that you create a plugin to output the custom fields and markup in a way that can be easily ported into a theme. The theme then decides how to style that markup. Alternatively, if you are going to be using the functions specific to ACF directly in your theme such as get_field then I suggest wrapping that snippet in php’s function_exists like so:

<?php // if Advanced Custom Fields function exists and the field is not empty display the field 

if ( function_exists( 'get_field' )  ) { 	
	if( get_field(  'some_custom_field' )  ) { 		
		the_field( 'some_custom_field' ); 	


This will enable you to disable ACF and debug if necessary without your theme throwing a bunch of php errors. Sure without having the plugin installed your theme may look like poo poo without all your cool custom fields, but at it’s base it is still a theme. This can be applied to all plugin / theme integrations.

I think this is a safe and responsible way to approach custom theme development and I believe in the long run it will also save the client some $$.


  1. I know your main point here is to separate custom content from the theme, and I fully agree. But I too recently created a site that uses Advanced Custom Fields and was also reluctant about tying the site to a specific plugin…

    My normal modus would be to put this type of content in a custom functions plugin, and toss it into the mu-plugins folder so the client can’t deactivate it. This solves the portability issue as well as the ‘Ooops I turned something off and now my site is broken’ scenario.

    But… I found ACF to be pretty amazing, extending meta content and relations in such a powerful way. It’s so far beyond my own custom-functions plugin coding skills, that I’m letting go of any reluctance on using it. My clients pay me to build custom sites, and to maintain. The issue of a client inadvertently deactivating the plugin is minimal.

    Developing the ‘right’ way is something I continually try to improve. That’s how I found this, thanks for well written post.

    1. Hey Bryan, I agree, Advanced Custom Fields is pretty amazing! So much so that the WordPress custom meta API could take lessons from it.

      I think one of the main points I was trying to make was that separating out the functions into a separate plugin would help with debugging and maintenance. But, you could still bake in advanced custom fields into a theme and deactivate it without throwing errors. This is essential. I agree that a client deactivating the plugin is minimal.

      Thanks for your comment!

Comments are closed.