I’m building a site for a client with ACF, but there’s so much content on their homepage that it’s going to require around 250+ fields. Headlines, paragraphs, one-liners, images, icons, featured blog posts with a custom field for each, all that jazz.
I’m wondering if this is fine and still “best practice”, or what better alternative would you recommend when dealing with long sites that would require a lot of DB queries.
Caching will set up, but I’m still wondering what’s your go-to solution in these cases?
250+ fields sounds like there might be better ways to do what you want to do, but it would hard to be specific.
But one example. You mention that you’re going to have “Featured Blog Posts”. I would not create a box for choosing what blog posts to show. I would create a field group for blog posts that had a true/false field to set each blog post as featured or not. Then I would add code to the template to show blog posts that were set to featured using some criteria like the most recent 3 or 5 posts or whatever. I would probably also modify the admin list of posts and add a column to show if each post is featured or not to make it easy for the client to find the ones that are featured and edit them to change it.
As far as the rest goes, I would likely use Flexible Content for a lot of it and create layouts that meet the needs of their design. In fact, the “Featured Blog Posts” would likely be one of these layouts to let them choose some things about what “Featued Posts” to show. Or even, if the situation warranted, make it something that can be used for more than just featured posts, allowing them to adjust the content to suit their needs because with a little mortification it could be used for any realtionshp like “Related Posts”, “Related Pages”, etc.
Thanks! Makes sense.
Would using flexible content actually reduce the number of database queries? Or is this advice coming from the user-experience and developer-experience standpoint rather than a performance oriented one?
When a post is set up WP does (or should) a single query to get and cache all of the postmeta fields for the post. These queries are based on the Post ID which is an indexed column in the DB. The number of queries should not be increased by the number of fields unless there is something else going on.
Additional fields will increase the time it takes to do this one query but that time should not effect a single query more than a few milliseconds depending on what kind of content is being returned. It is possible, but it would be an extreme case. For an example of something that could effect performance here think about a page with 250 WYSIWYG fields with several paragraphs of content in every one of those fields. Let’s say that fields average of 1000 characters that equates to 250 X 1000 = 250,000 characters being returned by the DB and this can mean anywhere from 250K to almost 1MB of UTF8 data. Of course this is an exaggeration to make a point.
There are things in ACF that will increase the number of queries, but this has to do with the formatting of the returned values. For example returning an array from image fields and galleries. Or returning post objects from relationship type fields.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
After @keithdevon mentioned building out an accessible @wp_acf accordion block I went through my starter theme, setup a new site and just tabbed through it... try it, you'll end looking at your websites in a completely different light! Fully accessible navigation and content now.— Paul Jackson (@pixelsnthings) April 5, 2021
© 2021 Advanced Custom Fields. Subscribe