Yeah, we’ve hit big performance issues in the edit screens using flexible content and repeaters for allowing clients to build their own layouts.
I wonder how easy it would be to add a setting to a field group “save as a single row”, which would save everything in that field group to 1 row. For most of our needs, we don’t need to query against the postmeta fields, so that would work fine and dramatically reduce the time spent in loading / updating pages in the back end
If you have page with fixed layouts, then it might be better to not use the flexible content fields. Instead just create a new field group with the specific ACF fields that you want, a new page template name, and assign this new field group to the page template you created.
I agree, this would be a great little feature
I’d also really like to know how to do this. Spent some time trying to force WP to recognise that the post had changed, but still no revision.
Yup, we’re experiencing a bit of this as well, although not as extreme
– A flexible content canvas that contains multiple flexible content blocks, each of which can have 20 – 30 ACF fields of all types (checkboxes, repeaters, wysiwyg, taxonomy choice, etc)
On the more complex pages (15 or so content blocks), it can take up to 20 or 30 seconds to update. Would really like to get a handle on this as we’re right on the line between tolerable and intolerable.
Being able to define shared fields for all the layouts for a particular flexible content ACF would really be useful – it would save a lot of UI repetition.
I don’t think duplicating the fields and then dragging them to the new layout helps that much – you need to edit them to remove ‘_copy’ each time.
However, adding this feature would make it hard to order fields, unless shared fields automatically got copied into each new layout.
Anyway, I still think this would be very useful – would save me needing to edit 10 layouts to add a new boolean field to each of them!
I’ve implemented this – be interested to get your opinion or is there’s a better way of doing it
This function returns an associative array given a Field Group title. The array keys are the field name slugs, and the array values are the field keys.
function get_acf_field_keys($field_group_title) {
global $wpdb;
// get the post id for this field group
$sql = $wpdb->prepare( "SELECT ID FROM $wpdb->posts WHERE post_title = '%s' AND post_type = 'acf'", $field_group_title );
$field_group_id = $wpdb->get_var($sql);
// now get all postmeta items (the fields in the fieldgroup) for that postid
$sql = $wpdb->prepare(" SELECT meta_value from $wpdb->postmeta
WHERE post_id = '%d' AND meta_key LIKE 'field%%'",$field_group_id);
$acf_postmeta_fields = $wpdb->get_results($sql);
$fields = array();
foreach ($acf_postmeta_fields as $acf_postmeta_field) {
$unserialized = unserialize($acf_postmeta_field->meta_value);
$fields[$unserialized['name']] = $unserialized['key'];
}
return $fields;
}
Hey Elliot,
Thanks for the quick reply. Quick followup.
How does ACF hook into the back end save/update users process? Obviously, if I click “Update” on the edit user screen, ACF is creating the necessary rows.
Alternatively, is there an easy way of getting all field keys and field names for a field group?
Thanks Elliot – quick follow up, is there an easy way to test what field group a particular field belongs to?
Yeah, this is a bit of a pain point for us as well.
We have local / test / production environments, version control with multiple developers, and managing ACF custom fields is a bit of a pain.
– Using the PHP export is ok, but means that other developers can’t easily add fields without changing the export file directly. We can get round this by using the XML export, but then we have to take steps to not include the PHP field definition file.
– If the local development instance where we used the UI to create the custom fields is lost, then we lose the ability to change the fields in the UI without working through the PHP export file and recreating the fields in the UI.
– We get weird issues when we have UI defined fields and the same PHP defined fields: sometimes fields get doubled up, sometimes they don’t.
It would be fantastic to fix some of these issues, we’d certainly pay for an add-on that sorted out these issues and made ACF even more developer friendly.
Hey, just wanted to let you know that this works great – was able to add this line:
$args['depth'] = 1;
to the filter function and only show the top level taxonomy terms in the edit screen
🙂 fantastic, will test this out in the next couple of days, thanks
