Support

Account

Home Forums Feature Requests 2 very important feature additions (PLEASE!!) Reply To: 2 very important feature additions (PLEASE!!)

  • In copying something like a layout in a flex field, the problem becomes complex. Here is an example. Let’s say that the post where your copying from has 2 layouts and you want to copy the second one and the post you’re copying to has a different number, in this case let’s say it has 3 already and the copy will become the forth. Let’s say for this example, to make it simple, that the flex field is named “flex_field” and it has just one text field in the layout named “text” and let’s say that the field key of the flex field is “field_123” and the field key of the sub field is “field_321”. Let’s say also to make it really simple there is only one layout named “layout_1”

    The database will look something like this for the post you are copying the layout from

    
    meta_key           | meta_value
    flex_field         | a:2:{i:0;s:8:"layout_1";i:1;s:8:"layout_1";}
    _flex_field        | field_123
    flex_field_0_text  | content for first layout text field
    _flex_field_0_text | field_321
    flex_field_1_text  | content for second layout text field
    _flex_field_1_text | field_321
    

    and this would be to db content for the post you want to copy to

    
    meta_key           | meta_value
    flex_field         | a:3:{i:0;s:8:"layout_1";i:1;s:8:"layout_1";i:2;s:8:"layout_1";}
    _flex_field        | field_123
    flex_field_0_text  | content for first layout text field
    _flex_field_0_text | field_321
    flex_field_1_text  | content for second layout text field
    _flex_field_1_text | field_321
    flex_field_2_text  | content for 3rd layout text field
    _flex_field_2_text | field_321
    

    The entry for the flex field is a serialized array containing the names of each layout. Each entry in the db for a field has a corresponding entry that starts with _ to hold the field key of that field. And you can see that each sub field is a concatenation of the flex field name, the index of the row and the sub field name.

    To copy the 2nd layout of the 1st post to the second post you need to get the flex field array from both and append the layout name from the 1st post to the 2nd post. You then need to get the content of the row from the 1st post, figure out how many layouts the second post already has and then substitute the correct index for the current index of all of the field keys.

    The above is the simplest example, but to do this within ACF this is not the only example you need to worry about. What if the flex field is actually a sub field of another repeater type field (repeater, flex or clone) then you’ve also go to take the parent field names and row indexes into consideration as well. Not to mention a possible grand parent repeater. These things may seem unlikely, but they are completely possible since ACF puts no limit on the depth that we can nest repeaters. If this was built into ACF all of the possibilities would need to be accounted for. There is also the possibility that the post that is being copied to does not yet have any entry for the flex field yet (or the parent, or the grand parent, etc). I’m not saying that it’s not possible, but what seems simple to start with becomes an extremely complex problem to solve. This could be a contributing factor for why this has been requested often but has not been built by the developer, not while there’s lower fruit on the tree.

    While it would be great to have something like this built into ACF, for someone that want to provide this functionality to a client it would be much, much easier to build some type of copy function for a specific set of conditions rather than the endless number of conditions that may exist to built it into the core of ACF.