ACF Pro 101 and advanced use?

• sahil89

• December 15, 2017 at 12:40 am

Hi,

I am looking for some tutorials/blogs and tips & tricks. I have been using ACF only recently and I am able to use all the fields without any confusion or problems. Though I feel like I need some guidance for using it on more complex layouts.

I came across ACF Pro when I asked a question whether everybody uses page builder or there are other approaches. In response everybody in that particular forum suggested me to go for ACF. Though I am slightly confused about two things

1. Is there anything like too many ACF fields? Or you always recommend to use ACF.
2. When certain layout becomes too complex with tiny fields for everything, do you still use ACF or you look for page builder options in such scenarios?
3. Finally, lets say you are working on a blog. And at some point you want some custom structures in the middle of article, maybe a table or some other layout. How do you approach it? Do you create ACF templates and split up content area with repeater field so you can use these custom structures in the middle of articles? Or again do you take some other approach?

I know my question is vague and there might not be a straight forward answer. Still any suggestions will be great. If not, it will be awesome if you can point me to some blogs/articles that will demonstrate some advanced approaches to complex layouts.

Thanks.

• John Huebner

• December 15, 2017 at 3:01 am

You probably saw this coming, but the answer to all your questions is “It depends”.

I have been using ACF for so long that I do not remember a site I’ve built without it. Every site I build for a client is custom based on their needs.

1. Is there anything like too many ACF fields? Or you always recommend to use ACF.

The answer to this one is Yes. But mostly this has to do with repeaters and flexible content and saving the post. The number of ACF fields will rarely impact the performance of the front end of the site.

When you have a lot of repeaters and flex fields, and depending on what types of fields you are using, the number of fields can impact the performance of the admin in 2 ways.

The first is that the loading of the post editor could be slow when there are a lot of fields that depend on JavaScript, like any of the jQuery fields, this also includes WYSIWYG fields that depend on tinyMCE. When building complex field groups it is important to take advantage of the “Delayed Initialization” provided by some of the ACF fields.

The second way that it effect the performance of the admin is when saving a post. There is a point where the save process can time out.

I’ll give you an example of this. I once built a site for a client that had a repeater. Each row of the repeater had 7 WYSIWYG fields. The content of the page required specific formatting for layout out these content fields in a very structured way to meed the client’s requirements. All went well until the client decided to add 30… let’s call them “Panels” to one page of the site. This meant that ACF needed to save 210 WYSIWYG fields and related fields for determining other options. What happened was that the save took longer that 30 seconds, which meant the the browser timed out and it appeared that it crashed the site. (In reality, it was just the browser timing out. The update went merrily on it’s way in the background and completed successfully. When this happens you can wait a minute or 3, use the browser back button and then refresh the editor and all of the changes would appear.) It was because of this that I built this https://github.com/Hube2/acf-prevent-timeouts.

When building something for a client using ACF it is important to think about how the client can abuse your masterpiece. I did not know that this problem existed when I built this site, but knowing it now I would not build another one the same way. I would likely use a post type using a parent page/post and child pages/posts in order to break things up and therefore avoiding the issue.

2. When certain layout becomes too complex with tiny fields for everything, do you still use ACF or you look for page builder options in such scenarios?

I have never used a page builder. I’ve found that they are too generic. They also rarely meet the specific requirements of my clients. Like I said, I build custom sites to exactly match the client’s needs. ACF allows me to do this without trying to shoehorn them into something that may not be exactly what they wanted. I also find that most page builders are bloated and also give the client too many options that allow them to break things easily. When using ACF I can give them only the options that they need. It makes my life easier because it’s harder for them to break things. And it makes their life easier because there is less for them to learn in order to manage their own site. My goal, when building a site is to turn it over to the client and for them to be able to do everything they need. The last thing I ever want to do is manage the content of a client’s site or need to make changes because they cannot understand how to do it themselves.

3. Finally, lets say you are working on a blog. And at some point you want some custom structures in the middle of article, maybe a table or some other layout. How do you approach it? Do you create ACF templates and split up content area with repeater field so you can use these custom structures in the middle of articles? Or again do you take some other approach?

The answer to this one is the biggest “It Depends” answer.

For a blog… meaning “Blog Posts”. for this they usually get just the standard WP editor. Blogs are free form and all content and formatting inside of “The Content” area is up to the client. I may provide other options on the blog, for example a way to allow them to specify a banner image for the page, or some special feature. However, I will never build a way that requires special formatting and layout within this area.

For the rest of the site. For example, page layouts and custom post types. These are almost always formatted specifically. Meaning that every page must look the same as every other page with set features. These features may be optional on each page, but when they appear they will always be shown in the same place and always appear the same when shown. These pages, templates and post types will have fields for everything that the client should be able to control. Outside of the blog, almost all of my clients require that the structure of specific pages be the same and meets there companies style guide. I may need to build them many specific templates for different page layouts. On occasion I also have included a generic page where the content is just a basic content field where they can control the layout, but this is rare and the client that wants this is usually familiar with WP and the use of things like shortcodes and editing HTML directly.

In the case you mentioned about a “blog” with custom structures in the middle of the content. If this was a requirement given to me by the client I would likely give them 2 content editors, one for the beginning of the blog and one for the end and the other fields in the middle and it would be up to them do decide where this special feature would be inserted. The other option would be to build a custom shortcode so that they can insert the special features into their page. But like I keep saying, that would depend on the client’s specific needs.

• sahil89

• December 15, 2017 at 3:29 am

Thanks John for your time and response. Ya I am used to “it depends” answers.

I think I poorly wrote my third question. Instead of saying layout I wanted to say some structure inside the blog itself, but I think should stop being paranoid of unknown scenarios here. Like you said I guess correct approach would be to let them use shortcodes. Any such custom structures can come from extra fields and can be inserted using shortcode.

The crazy scenario of 210 fields you mentioned, how did that page perform on front end? BTW how much do you bother to make backend presentable and well structured? So far I have only structured fields as table never tried to do more than that.

Again, thanks a lot for the detailed answer.

• John Huebner

• December 15, 2017 at 3:53 am

The font end performance of these huge pages was and is still good and there is no performance issues with them because of some optimization, for example ensuring that WP gets all of the post meta values in a single DB query (get_post_meta($post_id)). And in many cases, all of the content is not displayed. In the scenario given, the client wanted to be able to create “Pages” where each page could be shown independently but also wanted to allow site visitors to “Show All” pages. 90% of the time only 1 row of the repeater is ever needed. However, the display of all pages only takes a few millisecond more than showing a single page. This was a case of solving the problem bass ackwards. I created a editor to hold all of the pages and then split them up into single pages where I should have created a separate editor for each page and then combined them for the “Show All” option. It was a learning experience. My goal was to make the site easier for the client to edit because I thought (knew) that having to edit multiple documents and set the correct display order would confuse them. Also, there were SEO considerations since we wanted the “Full Article” page to be indexed and not the individual pages and this was easier for me to do if all the content was associated with a single page.

As far as back end, I usually use “block” display on repeaters, and I try to make it look as presentable as possible working within what ACF provides, I have not tried the new “Group” field yet. I have done some customization to ACF when I think it’s necessary and to make it less confusing when I thing it’s needed, but this is rare. Going back to the same example. The 7 WYSIWYG fields could be laid out is several specific ways, I provided a radio button to select the “Layout” and using conditional logic showed an image that represented that layout. I could have gone further and actually set the content fields to be positioned as they would be on the site, but they weren’t paying me enough to go that far.

• sahil89

• December 15, 2017 at 4:12 am

Thanks. I guess I should occasionally keep visiting this forum so I will come across some interesting topics and your great answers.