Support

Account

Register Login

Home › Forums › General Issues › Over 90 layouts in a flexible content field causing MAJOR slowdowns

Solving

Over 90 layouts in a flexible content field causing MAJOR slowdowns

  • We build all the pages on our sites using layouts within a flexible content field. We have over 90 layouts in a single flex field and each of these layouts have lots of settings.

    When we try to edit this flexible content field in the WordPress admin, it takes forever to load and usually freezes the browser. Thus, it’s not really possible for us to edit/add/remove layouts.

    Is there any way to split out the layouts for a single flexible content field so we don’t run into this performance issue? I tried using a clone field which included individual flexible content fields but the layouts in each of these fields couldn’t be mixed together.

    Any help on this would be much appreciated! Thanks.

  • Are you having issues saving the field groups? or saving content when editing a page?

  • The issue is when I am editing and saving changes to the field group in the wp-admin. Since it has 90+ layouts each with several fields, it takes forever to load in the browser and is very difficult to make any changes to.

  • The best way to work around this is to use clone fields. You create a field group for each layout, then move all the fields in the layout to the new field group. Once that is done you create a single field in the layout to seamlessly clone all the fields in the new group in the layout.

  • @hube2 I’m facing a similar challenge so I am posting my question here rather than opening a new thread.

    I am building a new using Flexible Content + Repeater Field. This is an example of the edit screen: https://share.cleanshot.com/5cWX8j. So we have a repeater field that holds the flexible content. The reason for using the repeater field is to act as a container wrapper in case the client wants to customize colors, backgrounds, etc. Then each of the sub section also has those similar options.

    I am also extensively using “clone” field so all the layouts in flexible content are cloned in different groups like this: https://share.cleanshot.com/FWZjcI

    While this is working perfectly in terms of functionality, I am facing a performance issue on the edit screen. It takes around 20 to 40 seconds to load the fields. However, once it’s loaded, I can easily edit the fields. The problem with this is that it becomes hard for me as well as the client to be able to edit something quickly.

    Is there anything I can do to improve the performance in some way? In the past, I know that when I didn’t wrap the repeater field around the flexible content, it worked better. However, that repeater field is quite important for styling and functionality part.

    Any help or right direction would be appreciated.

  • @hube2 update, I just copied the HTML being generated for these fields https://share.cleanshot.com/5cWX8j is over 134000 lines (see: https://share.cleanshot.com/W3uG3X) – could that be the main reason of the problem?

    UPDATE:

    I also see that the clone fields HTML is actually being generated on the page here: https://share.cleanshot.com/b0hqeA – is that normal? Isn’t there a way that this HTML is only generated when you actually add the layout?

  • With huge numbers of fields there will be performance issues. If you have a lot of wysiwyg fields then you can set them to delayed init.

    All layouts will be generated at least once, even when not used. These are hidden and used when inserting a layout. The hidden “clone” layout is copied to the new instance.

  • @hube2 I have already set the WYSIWYG fields to delayed init.

    Yes, that’s what I noticed the hidden clone layout is being copied multiple times which makes the HTML so big.

    What are your suggestions here? Is there any alternative to the repeater field that is better performance-wise?

  • More than likely, yes, the flex field inside the repeater is part of your problem. I would eliminate that. When I build with flex fields these are my “sections”. Each row of the flex field has it’s own design fields. I use bootstrap when building this type of thing where each row of the flex field = a bs container.

    Your issue is that sections can have design elements for the section and each section can have multiple flex rows. I don’t know how you can resolve that, I’ve have not done anything similar.

  • @hube2 hmm, I hoped there would be a default better alternative to this situation. But apparently, there doesn’t seem to be.

    In this situation, I do have an alternative which I used in the past to create tabs. It’s not ideal but for the sake of performance, I think it’s better.

    Will share my solution here after implementing it.

  • Thanks @hube2 for your response. Your solution of using the clone field to bring the fields into the flexible layouts works great!

    My problem now is that I have over 500 live pages which use the old, bloated flexible layout field. I can rebuild them using the clone fields method but how do I get the data from the old field into the new one so I don’t have to rebuild and repopulate the whole site? Any shortcuts or tips?

    Thanks for any help anyone can offer!

  • @damontribble sorry for hijacking your thread. While @hube2 might be able to give better advice, I would also like to share my experience:

    I had to do exactly the same on one of the client’s sites where I had over 30+ layouts and growing. The saving of the ACF field group was painful and continuously breaking.

    I simply created 30 new field groups for each layout and moved the fields from each layout to their respective field group without changing their keys and names.

    This way, the actual ACF in the backend wasn’t touched and all the existing pages (over 300+) remained intact.

    I can provide more info if you need.

  • @damontribble

    as @zeshanshani if you move the fields and keep the field keys and names the same then no coding changes should be needed. You start by creating an empty field group and then use the “move” option for each field you want to move. Then you need to go into the group you moved them to and clean things up. They could be in the wrong order and any conditional logic could be broken. If you have complex groups you will probably want to move a few at a time.

    If you’ve already done the work and the field keys have changed, well then you have a problem. All of the field key references in the DB will be wrong. You will need to do a search and replace on the DB to change the “meta_value” from the old field key to the new field key. There is no easy way to do that.

  • Hi

    Sorry for dragging up an old thread, but I’m having the issue mentioned above with a Flexible Content group with about 30 fields.)

    I’m interested in how @zeshanshani and @hube2 say creating a new group and moving the fields can help. I’m confused though as I don’t have the ‘move’ option on the fields.

    I’m using the pro version (6.2.0)

  • Ignore the above. It must be something thats happened (the slow down) in a recent update as I’ve downgraded to a v5 (as a test) and its back to saving instantly. I’ll now keeping updating until it slows again to find the version thats the issue.

  • @flightcreative that’s interesting. I haven’t checked it with latest version but might be something buggy. Hopefully not though or if it is, ACF team will fix it asap. They’re pretty quick with bugfixes

  • After testing on my dev build this weekend 6.1.5 is quick on saving and 6.1.6 onwards is really slow (5 mins on saving). I’ll contact their support and see what they say.

    There’s been a few security fixes since 6.1.5 so I won’t use it on the live site, but I could leave it on my dev build which should quicken things a bit.

  • Hi

    Incase anyone is viewing this with a similar issue. After contacting their support, we found doing this sorted the issue;

    https://www.advancedcustomfields.com/resources/acf-field_group-disable_field_settings_tabs/

  • It would be great if flexible blocks could be loaded using AJAX. Clicked on the desired block and it loaded. But not like it is now. The entire pack is loaded at once and this causes a performance problem.

  • We are facing the same issue here. All of a sudden our flexible content fields within the ACF admin are now almost unworkable and have started to time out the browsers and also its timing out trying to upload or save json files as well.

    We have tried everything including loading from PHP and also using Redis to see if that helps but all have failed. The only one that seems to make a small difference is adding the following to the functions.php:

    //Disable ACF field group settings
    add_filter( ‘acf/field_group/disable_field_settings_tabs’, ‘__return_true’ );

    Any help would be greatly appreciated.

Viewing 20 posts - 1 through 20 (of 20 total)

You must be logged in to reply to this topic.