This tutorial uses ACF and Blocks for ACF Fields.

What is ACF?

Advanced Custom Fields (ACF) is a popular plugin that helps users (mainly developers) add extra fields to Posts. To understand the value of this, think of WordPress as a database of Posts; each one has “content” (the body text), and fields for a Title, Author, Attachments, etc. ACF makes it easy to add additional fields. The most common use case is to turn posts into a product catalog, like in an ecommerce store.

What is a Custom Post Type?

WordPress has a feature called “custom post types” (CPTs) which creates a variation on the post, extending it. The CPT typically has custom fields, and shows up in the Admin nav bar as a different thing. The most common use case is a CPT for products in a product catalog.

The difference between simply adding extra fields to a regular Post, and making a new CPT, is that the CPT feels entirely separate from the Post. Searches won’t find the CPT. The normal query loop doesn’t show the CPT.

CPTs and custom fields move WordPress toward being a public database publishing platform. The main differences: WordPress is easier to edit, it’s usually online, and it supports a write-edit-publish cycle. The main WordPress weaknesses: integration with a relational database is hard, WP is relatively slow.

A common WordPress + CPT + ACF use case is real estate. Many real estate businesses have an inventory in the tens to hundreds per year – a small number of records, with a lot of detail per record (many custom fields), and outlier situations that may require some tricky layouts. There’s little need to keep the listings secret, no larger database (except the industry-wide MLS), and speed isn’t that important (meaning, web pages are hit many times per minute if you’re lucky, and there’ no need for 100+ transactions per second).

What is a Taxonomy?

Taxonomy is like the Categories feature for Posts. It’s a hierarchy of terms that you can define for a custom post type (or for Posts). Taxonomies are used to get subsets of posts, and are typically used as a kind of grouping or sorting. ACF allows you to define new Taxonomies.

This video explains ACF and it’s current direction.

This video explains how to show custom fields in a list of CPTs, using a plugin called Blocks for ACF Fields.

This begs the question I’ve wondered: why can’t I show the field values without this extra plugin?

(They are also wondering why this plugin doesn’t seem to allow fields to be shown on posts.)

ACF was designed for WordPress programmers who created CPTs, and who wrote Themes, back when making these two things together required PHP programming.

ACF’s product direction has been to support PHP programmers. So the PRO version of the product makes it easy to create new blocks… using PHP code.

So, into this gap, some products have entered to display custom fields in the Gutenberg environment.

Meta Field Blocks is a popular one: https://wordpress.org/plugins/display-a-meta-field-as-block/. It’s pretty full-featured.

Blocks for Advanced Custom Fields is another popular one: https://wordpress.org/plugins/acf-field-blocks/

I was having some trouble with Blocks for ACF, specifically, showing the fields on a post. It worked in query loops, but not on single posts.

• I could add the fields within a Query Loop, like in the video example above.
• I was unable to add these fields to a Template for a Post.

The fix was to do the following:

1. Go to the Post, and then click “Edit Post”. (Yes, the post, not the site.)
2. Use Blocks for ACF to add the fields for this specific post.
3. Shift-select all these blocks, and then Group them. (Use the Group action from the three-dots menu.)
4. Create a Pattern for this group. When you do this, make sure it’s not a “synced” pattern.
5. Create a new Template. The easiest way is to select “Create New Template” when you click on the Template field in the Post properties. This should create a template for a Post.
6. Within the template, add the Pattern you just created. Save the template, and check that it works.
7. (After this, you can remove the pattern block from the Post you edited. The pattern should appear on all Posts using the new template.)

This problem doesn’t happen with Meta Field Blocks.

Should we even be using custom fields?

Once I was using Patterns, I started to wonder if ACF was even worth it. My site had < 50 items.

I didn’t really benefit from having a database-like schema for the items. In fact, it was as much of a hindrance as a help, because special cases were common. My data didn’t really fit the schema well.

I could easily use an un-synced pattern as a small template for the extra fields.

Whenever I need to display a thumbnail and a couple links, I can insert the pattern, and fill in the blanks.

There you go: instant database, without the need to create custom fields.

So why did I have custom fields?

Back when I created the custom fields, the balance of complexity was different, because Gutenberg was still in development, and I thought I’d need a lot items. The technical debt incurred by making the fields, was paid off by the effort saved in creating item pages. Coding up templates in PHP was easy for me, too.

So are custom fields and CPTs dead?

I think it’s still a good way to build websites that are like databases.

The issue is fit. If the number of items is small, and you have only one person editing the database, there’s no point.

If you have multiple editors, then the uniformity that fields impose will be a huge benefit.

If you have many items, then the uniformity the template layout imposes will be a benefit.

If you have a complex database, with many items, then, you will probably need to get ACF PRO, and skip past these field-display blocks (or use them selectively). A developer seat costs $$, but wages will cost 100X or more than the software license.

A non-programmer site builder can be far less expensive than a developer, but if the data gets complex, you have to look at the risks of relying on two different plugins, and having configuration spread across templates and patterns.

The main savings from using ACF will come from the fact you are hiring WordPress talent, rather than database or web app talent, and using the WordPress environment, which comes with the user reg, publishing, layout, themes, etc. for a lower price. (Thousands to tens of thousands of dollars, versus hundreds of thousands of dollars.)

How big is big?

ACF and WordPress won’t scale up to the hundreds of thousands of records. I’d even argue that it starts to creak after it’s near a thousand posts. The content on this site and related ones went up into the 800 post range, and it just got hard to find and edit articles. I was often resorting to searching for posts from the front end rather than back, and sometimes resorted to using Google or Bing to find articles.¹

The admin page tools were just inadequate, and slow.

On a regular database-backed website, you would do things like write custom searches, custom scripts to check for data consistency and completeness, and other “clean up” tools. With WordPress, it’s more effort to do this kind of work, and the resulting code is confusing as heck. (In contrast, a normal DB maintenance script centers on SQL queries, which are easier to read.)

Most database-publishing isn’t really even about making the website: the database has a more central business use, and the website is an appendage to the database.

For example, the App stores and Streaming sites all have huge websites, but they aren’t running app stores to create pages: the app store is the software economy of a platform. Its website is a promotional tool or an alternative access tool.

1. In fact, after I started using the search engines to find articles, I started to delete some posts, because, I started to realize that the central databases that mattered were the search engine indexes. ↩︎