Skip to main content

ACF Tips

Be smart with your field choices​

Think ahead about if the field choice you've selected is the most suitable - in terms of how the client will interact with it and how it will be managed in the codebase e.g. a select is a better choice than multiple boolean toggles.

Use of tabs and groups​

To improve UX in the CMS use groups and tabs to break up large groups of fields on a component and split them into suitable sections e.g. a component that requires an image and content could have 3 tabs - image, content and options. Be mindful however of setting up too many tabs and nesting too many groups as this can be confusing for the client.

Use of accordions​

To improve UX in the CMS add accordion components to your repeater fields - it's not necessary for repeaters with a small number of fields on each item but for large numbers of fields it should be added so the user can shrink/expand each item when editing.

ACF field descriptions​

Field descriptions can be added via the presentation tab on a field - add descriptions for more advanced components to guide the user.

Use WYSIWYG (or equivalent fields for the CMS) for content instead of text fields​

For content that could be variable (text, links, lists) use WYSIWYG (WP ACF) fields (or equivalent for the CMS e.g. richtext in Storyblok) as opposed to text fields - even if in the design only paragraphs are present the client may want to add links etc. in the future.

Copying and pasting components on sections​

Components can be copied and posted across pages for quick reuse.

Adding new flexible components to layout-components​

Always use the clone field to clone a separately defined ACF field component onto a new layout. Don't define fields directly onto the layout. This makes them a lot less flexible and harder to work with.

Adding landing pages on section​

Similar to the above clone a separately defined ACF field component onto a new layout for landing pages. Don't define landing page fields directly onto the layout for the new landing page. This makes them a lot less flexible and harder to work with.

Helper fields​

Define and use helper fields where suitable to be more efficient e.g. a 'helper - colors field' of type select with all color options for the site can be defined and used for color customisation in components (instead of having to define select fields with color options in every component). This makes them all easily editable and identifiable as the definition is in one place.

Page options​

Conditional cloned fields​

Fields of type clone can only be conditionally set if they are set to 'display - group' not 'display - seamless'

Cloned fields overwriting each other​

Multiple cloned fields using the same cloned instance cannot exist at the same level as on save the populated data of one will be the same on all. To avoid this you need to add each cloned field inside its own group.

Cloned fields - 'display - group' vs 'display - seamless' vs 'prefix field labels & prefix field names'​

I generally use 'display - group' now as it gives more context for the user as to what the field their populating is for - however it does add another level of nesting to the interface.

Decide on standard?

Post type fields - use groups​

Use groups on post type fields so only these have to be added to API settings initially - otherwise you'll have to add every newly added field going forward to API settings which can become cumbersome.

Refactoring existing ACF fields​

Always think about how your refactoring may affect existing populated fields across all components e.g. something as simple as a field name change will lead to the wiping of that field across all existing instances. If in doubt make a back up of the CMS in WPEngine and warn fellow devs/the client beforehand.

Component variants design pattern​

e.g. 5 different mastheads - all with unique fields.

Create one 'masthead' component with layout options on it and conditional fields related to each?

5 different components - unique to each variant?

Decide on standard? I lean towards the latter - the least layout and options the client has to manage the better.

CMS mindset​

Lastly think how the client will be the one to the use CMS and users may not be the most technical - build your components and define your fields in a way that makes the client experience easiest as opposed to making it in a way that allows us to develop the pages easiest.