Home Forums Feature Requests Better management of flexible layouts


Better management of flexible layouts

  • On the site I’m currently building I make extensive use of ACF flexible layouts. Every page on the site is built using them. I have 26 layouts so far and managing them all has quickly become a bit of a nightmare.

    Aside from the field ordering bug I experience every time I or my co-developer update the fields, opening the custom fields page that includes all these layouts has become slow because there’s just so many subfields.

    I have an idea of how this could be better managed. I don’t know how this would work in code; I’m more of a front-end dev and my PHP knowledge is limited. But this is what I propose:

    Treat flexible layouts more like Field Groups.

    The way I’m thinking about this, there’d be a new admin page from which you could create and manage layouts. Each layout would have its own page for editing, just like Field Groups do now. That way no matter how many layouts you have, when you just want to edit one layout you can easily zero in on the fields you need to look at without loading up dozens of them. Plus, if each layout had its own local JSON file, syncing layout changes may be more robust (and less likely to trigger bugs like the reordering one linked above).

    Then, when you want to add a flexible content field to a page, you add it just like you do now. But instead of a full field management interface for the layouts, you’d see an interface that would allow you to choose which existing layouts would be available to this particular flexible content field. I imagine the UI from the current Relationship Field edit screen would work well for this.

    A system like this could potentially even open up more flexible layout options using nesting. You could have a series of layouts like ‘one column block’ ‘two column block’ etc, and each column within those layouts could be flexible content fields that can then have different layouts added within them.

    I know I’m not great at explaining this kind of thing, so if it would help I’d be happy to make a visual mockup of how it could work. I also realise this would involve quite a significant amount of work.

    So, ACF devs, what do you think?


  • A suggestion like this would go here

    However, this can already be accomplished using the clone field. The main issue with the clone field would be the same as this idea, you won’t be able to use conditional logic on the fields in layout that refer to fields outside of the layout.

  • Hi @hube2, thanks for the reply! I’ll look into using clone fields while definitely submitting my idea as you suggested.

    It did occur to me that conditional logic would be effected, though honestly, in layout setups like mine conditional logic is difficult to manage anyway – it’s difficult to find the field you want even if you’re looking for fields in the same layout.

    Based on that (see the attached gif) I’d suggest the current state of the conditional logic UX may need to be rethought. Perhaps something like a two-column chooser UI where you first choose the layout you want to use, and then it shows you the fields within that layout.

  • Thanks for the reply @hube2! I’ll definitely submit my ideas as you suggest.

    WRT conditional fields, I agree that would be an issue but I put forward that conditional logic management is also something that needs to be rethought.

    Take a huge flexible content layout setup like mine. Opening up the field selector box presents you with a list of dozens of fields, without any indication as to which layout they sit under.

    Conditional field example with too many layouts

    Even if you’re just looking to reference a field in the current layout, you have to scroll past dozens of other ones to find the one you want.

    My solution to this would be to have two dropdowns – the first to select the layout you want to look in, then the second to select the field/s you want from that layout (something like the current relationship field UI could work too). This would solve the complexity issues, and should be compatible with an implementation of flexible layouts like what I’ve suggested above!

  • @ohnojono that’s indeed a great idea! We are facing exactly the same problems while handling a project with 40 different layouts.

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

The topic ‘Better management of flexible layouts’ is closed to new replies.