Support

Account

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

Solving

2 very important feature additions (PLEASE!!)

  • Hello All!

    I humbly request the addition of 2 pieces of functionality to ACF that WP developers have been coveting for some time:

    1) Years ago somebody made a “Duplicate Post” plugin and it works fine, but it doesn’t include ACF content. You guys need to get your own “Duplicate Post w/ ACF” plugin.

    2) In that same vein, there should be some way to duplicate flexible field content either on the page you’re editing, or to another page. This could be some kind of UI provided in the admin, or just additional functions in the API that developers could incorporate in their own code. Obviously both would be preferable.

    I can’t overstate how much the ACF developer community needs these features. The result of providing those features may very well be partying in the streets, a cure for cancer, and world peace. Or just a lot of happy people.

    Thanks!
    Mark

  • Mark, I’d be surprised to learn that Duplicate Post (https://co.wordpress.org/plugins/duplicate-post/) doesn’t copy the ACF field content, because it is meta data and I’d expect it to support any meta data attached? In my plugin QuizMaster (which uses ACF5 Pro for all fields) we wanted to provide a copy feature for quizzes and questions, which are both custom post types. I just looked over the class we adapted from a tutorial on copying posts, and although it never specifically handles ACF, it loops over all metadata and creates a perfect copy. Newly copied posts have all the same field settings as the original. Here is a gist of that class which is a helper in QuizMaster: https://gist.github.com/goldhat/dbe670097922d3cfd6dac2630f1d19a8

    I’d imagine ACF developers might take the view this is beyond the scope of ACF, because it’s more about posts/copying than it is about fields/data. I’d tend to agree with that, because I think if you’re building a plugin with CPT’s (or a site that uses CPT’s) you can make a class that handles copying, that gist is the full extent of our copy feature and it’s only 129-lines. If ACF provided that feature, it would have to include various options, because for instance we only want to apply the copy option to our own CPT’s, not to all the post types.

  • Well, bust my buttons!! You’re right! Duplicate Post does include all custom fields (I just tested it on a site). Sometimes it’s sweet to be wrong.

    Regarding the other issue, I checked out the code for the QuizMaster plugin and the method for copying all custom fields for the CPT’s is very succinct, just 2 queries. What would be the method, however, for targeting a specific field group, like a flex field group, and copying only those contents to another post?

    By the way, I understand that this isn’t necessarily an ACF issue, but a WordPress custom fields issue. However, doing such a duplication would most likely happen in the context of ACF, making it the more practical arbiter of the situation. Does that make sense?

    Thanks, goldhat!

  • If we call that feature say “selective copying of field data” meaning you can select specific fieldtype, or fieldgroup, then yes I’d agree that’s more of an ACF-specific feature.

    I think there might be a couple of different ways to do that but something like the process below would be needed:

    1. Pass in the selection of fieldtypes, fieldgroups to the class, perhaps an arguments array like $args = array(‘fieldtypes’ => array( ‘repeater’ ));. Or a setter like $copyPost->setAcfFieldTypes( array(‘image’, ‘flex’) );

    2. When looping over all meta data, load the field associated using the meta name to find the key. Then check if the fieldtype matches that array of fieldtypes to copy. Similar idea for fieldgroups, essentially find out if they that meta data item should be copied. Use continue to skip over meta that doesn’t match the criteria.

    3. When matches are found, copy it the same as shown in that snippet using the queries.

    Having to handle the data one item at a time might not be very efficient in terms of queries but it’s probably possible to delay the query until all the data has been organized.

  • 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.

  • Good points John. It makes my head hurt just thinking about the variations that can exist with those complex fields and nesting. I’ve seen similar situations discussed involving a range of other features as well. It makes me wonder if there is some better system for handling nested field data to avoid the use of indexes in the meta key names… not sure if I’m describing that clearly enough but I’m referring to ‘flex_field_1_text’ where as you mentioned we often need to “figure out how many layouts the second post already has and then substitute the correct index”.

    I think the approach I might prefer (of course I understand I may not be thinking of all the requirements here) is to have nested field data assigned a unique id and then referenced by json. Essentially so that if you could access that main reference data, you would then be able to track down it’s rows.

    If I were to tackle something like this I this I’d try to utilize the loading and storage native to the ACF API as much as possible. Meaning first try to identify if the fields/types/groups are used for the given post. Don’t try to copy or get the data at that point, just organize the results of that test. Then use the get_field() and save_field(). It seems more likely that we could deal with the various complexities by loading the data with get_field(), but I think processing that before using save_field() would still be a massive undertaking.

  • Sometimes I wonder as well about the choice to use multiple fields rather than just store the entire repeater as an array, but then that would not really help with the copying of layout. The current storage method does make it easier to use a recursive function to save sub fields. I don’t know all of the history, but it think it had something to do with using the standard format for saving fields and the indexes arose out of the need to keep the sub fields of each row associated with each other. I can’t say for sure and the developer rarely posts here any more and leave it up to users like me to help so that he can work on ACF. If you look in the github repo for ACF 4 you can see some references to why values are stored the way they are but nothing specific, here’s an example https://github.com/elliotcondon/acf/issues/68

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

The topic ‘2 very important feature additions (PLEASE!!)’ is closed to new replies.