@tatof THANKS!
Problem still exists! April, 26th 2024 latest release.
Thanks for the tip – it works!
@stefen Nice job.
Just note the missing ); at the end of the add_action() call.
And it is advised to generate endpoints with version number and vendor like
{{site}}/wp-json/wp/v1/myacf/options/all
@robpl1 Your issue seems simple. use get_field() and display ONLY the fields with values. Just note that get_fields() will return all fields, each will be diaplyed as in the former.
I think that what you want at the end is:
$total = array_sum($all_posts); // sum of all numbers in array
you can try
print_r($total);
Thanks for quick response with full answer.
On WP 6.0.1 pagination works fine – BUT no drag & drop.
Can they coexist?
Hi @john
Thanks. Your answer is clear.
Most likely, my acf design can be improved.
I have an array with 26 flags – can you think of single field
that will contain the 26 fields?
The simplest will be text field with format:
01:DD,02:DD,03:DD – vector of tuples in the form of field-name:field-value.
Not fun to handle, but replaces 26 fields with a single one.
Is there a more elegant and cost effective way?
Hi @john
Thanks for quick super informative answer.
I did follow the code… upon upadte_field(‘table’,…) ACF simply updates: rewrites
all the table – RENUMBER rows: 1..count(new table).
Thus, all remaining rows can be deleted.
Clearly, delete the table prior to update is redundant.
The algorithm is clear.
My next test will be with (my) “large” tables – to detect whether there is a timeout.
BUT, A simple potential optimization on line 844 can be:
Only if (new_row != old_row)
Perform $this->update_row( $row, $i, $field, $post_id );
And you can go even further, treating the case of row renumbering.
Currently, even row number change will result with compete row rewrite.
Am I missing something?
Hi @jarvis
Thanks for your answer.
If you are correct (I believe you do!), there is a bug either in documentation, or in the code.
Either way, I am looking for an official confirmation, as you can see above.
To decide on my future actions. I am using repeater massively (more then 100 in a single large app)
And if this is so, what is the repeater development roadmap for the future?
Currently, performance update is also an issue.
I need answers…
Hi @john
The $new table is a repeater of “basic” fields, no additional sub components.
In my tests, the only way to delete row was:
1. delete the whole table
2. update_field(with new values)
I cannot use it becuasse repeater performance is poor.
An update of a repeater: 15 rows by 27 fields in each row > 40 seconds!
Unacceptible for my clients.
PLEASE let me know if update_field (on a repeater) will NOT remove rows.
I can calculate the diff(oldtable, newtable) and perform “micro-repeater-update-calls’
But I would like to know before that this is my only workaround.
THANKS!
Hi @jarvis
My focus is on update_field().
I want an elegant simple & single call without the need to analyze the data in my code.
Therefore, I expect update_field() to do the work for me.
MorningGnu, I do not see how acf blocks can help?
Please note that every acf block has acf group and wp-postmeta will grow since the problem above persists.
As you said: “using ACF blocks instead of Custom Fields” will shring the database, while this may be true – it does not solev the issue of huge wp-postmeta.
Am I mising something?
I have the same issue: sync is not working, not showing – unreliable.
Found that – export/import works!
Fortunately – it does rewrite (update) exiting FG’s.
@nobby get_fields returns fields with values only.
get_field_objects() – “Returns the settings of all fields saved on a specific post.”.
For your purposes I suggest to use the definition in acf-json.
The only issue is that there is no API, meaning that if the structure changes,
your solution need to adapt to it.
@vanian , @p-j-albuquerque Thanks for sharing!
I used acf/load_field/type=repeater for new post & form generation (ie. not for edit)
Realizing that ALL repeaters are affected.
// Upon *new* post only
add_filter('acf/load_value/key=field_5ff3a123b5198', 'build_participants_table', 20, 3);
....
function build_participants_table($value, $post_id, $field){
//error_log('build_participants_table field='. print_r($field, true));
$ptypes = array(/* participants segments*/ 'men', 'women', 'children'); // etc...
foreach ($ptypes as $ptype){
$value[] = array(
'field_5ff3c5f44a5d1' => $ptype,
'field_5ff3c4debd753' => 0,
'field_5ff3c514bd754' => 0,
'field_5ff3c52abd755' => 0,
'field_5ff3c543bd756' => 0,
);
}
return $value;
}
WordPress 5.6, ACF PRO 5.9.3 – repeater suddenly missing.
Just to say thanks to @James for pointing this hook. Its Jan, 2021 now…
WP 5.6, ACF PRO 5.9.3
ACF pro stopped showing the keys… with “display:none”.
I went a little further, but this is the idea:
function my_acf_admin_head() {
?>
<style type="text/css">
#acf-field-group-fields .li-field-key {
display: block;
width: 15%;
}
#acf-field-group-fields .li-field-type {
width: 10%;
}
#acf-field-group-fields .li-field-name {
width: 20%;
}
</style>
<?php
}
add_action('acf/input/admin_head', 'my_acf_admin_head');
Its Oct, 2020 now…
I wish to have the date set to today ONLY upon creation.
BUT, ACF pro latest (5.9.1) seems to ignore it.
Even when I modify the date – it will DISPLAY today date
And will retain the original in the database (ie. not updating…)
Here is my code:
add_filter('acf/load_field/name=YOUR_FILED_NAME', 'my_acf_default_date');
function my_acf_default_date($field) {
if (isset($field['default_value']) && $field['default_value'] != "")
return $field; // do not change...
$field['default_value'] = date('Ymd');
return $field;
}
Any idea how to manage this behavior is highly appreciated. Thanks!
