We’ll show you how to display any type of ACF field on the front-end of your website without coding (and without visual page builders), very fast and without turning your theme code into spaghetti code.

The Advanced Custom Fields (ACF) plugin is used on most WordPress websites, throughout my career I’ve seen only a few websites that didn’t use ACF (very specific websites). It has many fields types, good UI for admins, extensive docs for developers so it’s easy to get to grips with.

It may look like there’s nothing as simple as displaying fields on the front-end of a website but in-practice it’s usually done crudely and takes much more time than expected.

Code issues

This very simple example below — displaying a field. At a glance it appears to be straight forward, right? But while developing some issues start to “appear”.

<p><?php the_field('some_field'); ?></p>

Issue №1. Constantly visiting ACF groups in wp-admin

Firstly, it’s a field name. With only the field label it’s nearly impossible to know the field name and every time you’ll need to visit the list of field groups, find the relevant one and check the field name.

Okay, with that sorted. What about the return type?
It’s fine if we’re talking about a text field but what if it’s an image, select or post? And here we’ve got a whole zoo. Besides the fact that there are many field types (which is good), but every type has different return-types, this means that in the same group we need to also check the settings of the specific field. It’s okay if ID or Object (WP_Post) is returned, but what if it’s an array? (E.g. an image option), what keys does it have? For sure, when you’re displaying ACF fields on a daily basis the names are always top of mind, but what if you’ve been busy with something else?

Issue №2. Always having to visit ACF docs

We’ve now reached the second issue. How to get details about the return-format, keys of the returning array or how to get a label along with a value, in all such cases we need to visit ACF docs for the related field type. The up side is that the documentation is very good, the down side is that time is still wasted.

Issue №3. Syncing changes

Practice shows that existed fields is amended much more often then you’d expect. For example, a field return-type has changed (not to mention field name and type, as that also happens) and it’s necessary to make a search through all the theme code to find the exact code pieces that get and display the field, and it becomes a real nightmare. Someone could use double quotes in one case, another person could use single quotes somewhere else and the field name can be short and perhaps not unique, now try to find them all. Not much fun and very time consuming.

Issue №4. (Optional). Spaghetti code

What haven’t I seen? Especially in cases where changes are being made and when not creating a page from scratch, then there’s just heaps of spaghetti code in templates, it’s unclear (even with a big wish) how do you find the beginning and where does it end? I just can’t seem to find it.

In the best case scenario a developer writes something in the functions.php file by declaring a new shortcode and using that to display fields, it’s done by pasting the shortcode in the target place. (And to be honest, when you’re amending such “strange” themes there’s neither the time nor the will to change something, you just create another one there and then try to forget what you’ve seen as soon as possible) The issue with these functions.php snippets are that in a single day it could become a file with six or seven thousands lines of code, without structure, without beginning or end and no clarity at all. What’s the goal of this piece of code? Where is it being used? Who really knows.

I simply keep quiet about the outcomes of using these methods as I believe that the nightmares will popup when they’re editing or debugging and optimizing, it’s the same for everyone who’s had to deal with it.

Issue №5. Styles and CSS conflicts

Field markup is usually done off the cuff, and classes in the markup are derived from that, so they first appear in the mind. (Unfortunately only a few have heard about BEM, and even less use it).

In the worst case, styles for the fields are added globally and in the best case, for the target page only. In the first case there’ll be an issue with unused CSS code (hello zero Google Page Speed) and conflicts with other elements (class names are too common), in the second case — an issue with reusing on other pages.

Summary of the above

These issues slow down development time, and suddenly to display 4 fields a developer doesn’t spend only a minute on it but ten! This is besides the fact that the created output now also has many issues with it. Who is going to amend or support it? Very few.

Solution. Displaying fields without coding, using shortcodes

So how can you get around these issues? BTW below I’ll be talking about other shortcodes not about the built-in ACF shortcodes. Unfortunately they’re only fit for use with the primitive types of fields like string or number and furthermore they display only values, it’s still necessary to add markup.

Let me introduce the New (and Free) ACF Views plugin, that provides shortcodes to display fields. …and if your first thought was “a shortcode for displaying a value by a field name” — then you’re wrong.

The ACF Views plugin allows you to create Views (are ordinary CPT items inside) with which you can:

1. Choose ACF field(s) to display (Single or multiple fields and the fields can be from different field groups. Chosen from a dropdown)
2. Save the View, copy a shortcode (it looks like this [acf_views view-id="2221" name="Car"])
3. Use the shortcode everywhere (Chosen fields must be filled on a target object, where the shortcode is pasted, like a page or CPT item. Or you must use the object-id argument of the shortcode to define the id of the object that contains the data)

During execution, the shortcode will be processed by the plugin and replaced with HTML markup that’s automatically generated, this also depends on a fields’ type and fields’ value. (ACF Views plugin supports all field types, including images and select type). This makes the task much easier, saving you time and solves all the issues mentioned above:

№1. Constantly visiting ACF groups in wp-admin

You select the fields from a dropdown, no need to worry about the fields’ name or return-format.

№2. Always having to visit ACF docs

The plugin automatically generates markup depending on field type and return-format of selected fields, and there’s no need to write HTML markup.

№3. Syncing changes

The ACF Views plugin stores the field ID’s and gets information about the fields dynamically from ACF. This means we can change the fields’ as we’d like, including the fields’ name and type, not to mention the return-format and no other updates will be necessary from our side. The markup will be always up to date.

№4. (Optionally). Spaghetti code

No chaos in function.php anymore. A separate item is available in the WordPress dashboard with a list of all Views (you can define a name and short description for every View) or even search if the list is long.

№5. Styles and CSS conflicts

Now we come to my favourite item. The HTML Markup is generated using the BEM method, so there’s no more conflicts. Furthermore, every View has its own CSS code field where you can write styles for these fields. This CSS; a) never creates CSS conflicts (BEM style + ID of the View is used) and b) it’s loaded only on pages where the current View is used, so no global styles.

Summary

Using the ACF Views plugin (free) it’s possible to display any ACF fields on website frontend quickly and without creating issues for who those who will need to amend/support it.

You can get more information about the plugin on the official website, where you can also find a link to the YouTube channel, that showcases usage of the plugin and tutorials.

For Developers

Experienced developers will most likely ask, what about overhead? It’s a wrapper and most likely it’s much slower than ordinary coding. But that’s actually wrong for a few reasons. The plugin’s authors have paid special attention to the performance (for example used JSON instead of meta fields for storing data in Views) and even published a test, that shows the difference in using of the code way and the plugin way with shortcodes, it’s impossible to notice this with the naked eye.

User Interface

Below I’ve put several screenshots of the plugin I took, so you can see how the plugin’s user interface looks. Simple, Intuiative and Familiar.

P.S. Other features and functionality of the plugin is outside the scope of this article. But if you're interested then I'll take a look at how to display posts with their ACF fields and even to display 4 latest WooCommerce products without having to write code.

I hope the article was useful for you.