Okay, just give me a minute while I roll up my sleeves. It’s been a bit since I checked in here. Funnily enough, I forgot exactly how I had built this blog, and it took me a while to deconstruct and reconstruct things. But here we are, apparently, this time with the hopes that I can impart some knowledge upon you that I’ve been accumulating lately.
Since I started doing contract work in July, almost all of the work I’ve done has been building custom WordPress websites. I think there’s actually been only one non-WordPress project since I’ve gotten back into business for myself. I think that says a lot on its own, but that is a topic for another day. Today I want to talk about a plugin that I have found indispensible for WordPress development since I first started building custom themes back in 2011. Advanced Custom Fields enables you to replace WordPress’s default data fields (such as the title and body of a post) with whatever you like, from plain text fields to WYSIWYG editors, custom taxonomies, select fields, images (and galleries), and even more. WordPress is primarily a blogging platform but Advanced Custom Fields aims to transform WordPress into a full-fledged CMS (content management system) and it succeeds easily.
Too much of a good thing, however, can sometimes cause heartache. Over my career, I have made it a point to avoid heartache whenever possible, and so whenever I can employ a tool such as ACF, I do so. One time that I experienced heartache recently was while working on a client’s site. They had already begun development, and they were using ACF to manage their post content. Unfortunately, the project had so many custom fields defined that I found myself scrolling through large lists of paginated fields, constantly trying (and sometimes failing) to find the field I wanted to work with. Sometimes we discovered that some fields were inadvertently duplicated simply because the original got lost in the haystack. I discovered after a while that there were some programming paradigms that I could apply to this problem, if not now then certainly in the future.
ACF offers a great field type called Clone which lets you make a copy of any other field or field group from your project. So why not use that to reduce the number of fields you need to maintain? For example, I often create a field group called “Module - Title” which is simply a representation of a header tag in html. It usually consists of three fields - the title text itself, the level of the header (1-6, of course) and its alignment. Now, wherever I want a title, I can create a new field called Title and set its type to Clone. Then I choose “Module - Title” as the field in which to clone. The fields are cloned but not their content, so you can use these all over the place if you like.
You’ll notice that I prepended “Module - “ to my Title field group. I like to maintain a few different “types” of Field Groups in ACF. Some groups are specific to a certain post type or page. Those groups get prepended with a “Post Type - “ or a “Page - “ followed by the name of the element it applies to. Some examples that you might end up making would be “Post Type - Feature” or “Page - Home”. This makes finding field groups easier, even if you aren’t sure of its name. If you’re at least aware of the type, that will get you half way.
Other groups are repeatable - things that I would expect to want to use on more than one page such as a modal window or media box. These groups get prepended with “Module - “ like we did with our Title field group previously. This lets me know that whatever has this prepended to its name is meant to be used in more than one place. If it doesn’t, it isn’t. Groovy.
There is another Field Group that I use which is called “Layout Master” and employs the Flexible Content field. Let’s take a look at that now.
When I first started using Advanced Custom Fields, I would simply create a different field group for each page in the website that I was building. Some common groups would be “Contact Page”, “About Page”, “Home Page” and so on. Sometimes this will be all you’ll need, especially for smaller or very low budget projects that you need to just get done right away. This is okay, but you may find that when the client needs you to make changes in the future you could be spending a lot of time undoing your own work instead of building upon it. We programmers, being lazy as we are, would prefer to move forward whenever possible.
Sometimes, though, the client wants the content on their pages to change - that’s why they are paying for a WordPress site after all - Or they want to rearrange it. Using the method described above, you’re stuck with your templates that include hard-coded field names all over them. Oof. Looks like you’ve got some work to do. What you probably should have done is used the Flexible Content field. It took me a bit to get my mind wrapped around how this field works, but once I did it improved the way that I build WordPress websites exponentially. Seriously!
With the Flexible Content field, you can define a list of reusable content blocks that your client can place, edit, rearrange or remove from their pages to their heart’s content. These content blocks are populated with fields that you define, allowing the client to customize them with their own content. These content blocks are known as “layouts”.
Once you’ve defined some layouts for the client to use, they will see the following when they edit a page or post:
As you might already realize, this gives you and the client a lot of flexibility that does not come with WordPress by default. This field enables the client to choose which content blocks appear on their pages, and in what order.
There are a few more things that I like to do to keep things as clean and concise as possible.
In order to prevent our ACF modules from appearing on edit pages that we don’t intend them to, I disable them for all post types when I define them.
I like to create one single Flexible Content field group and title it “Layout Master”. This field group is made available only to the areas that I want it to be, such as page, posts, or both. Then, I create one layout for each module that I’ve defined with ACF. Each layout has only one field, titled “Content” which is of type “clone”. I then choose the module that I want to add to this layout. Lastly, I set the “Display” attribute of this field to “Seamless (replaces this field with selected fields)” which gives us a bit easier API to work with in our templates as well as a cleaner UI for our client.
This Flexible Content field is your new container for all of the modules that your client should have access to and will populate the “add row” menu that is shown earlier in this post.
And that’s about it, at least for now. I hope this post made sense to you and was helpful. If you’re so inclined, shoot me an email at firstname.lastname@example.org and let me know if there’s something I could be doing better. Thanks for your time!