Hi john,
I have had contact with Elliot and he is aware of the situation.
Cheers,
-lite
It seems i was able to identify the source of this issue for (at least) my situation. This pertains to multisite installations running ACF PRO 5.7.4. The bug lies in the fact that the update procedure erroneously checks the last blog in the multisite for update and license information, instead of the primary blog. The bug can be circumvented by either:
1) Activate ACF PRO and enter the license key on the last blog of the multisite, then run the updater.
or
2) Manually download and install ACF PRO 5.7.5 or newer from advancedcustomfields.com.
Any multisites running ACF PRO 5.7.4 may suffer from this issue, and will not be able to upgrade to newer versions without taking any of the two steps above. There should generally be no need to re-install WordPress or edit the database for this process.
Thanks John, message sent.
@hube2 As i described in my previous comment those were the two entries i had deleted from the database in my last attempt.
@John Huebner:
Your last suggestions don’t work for me unfortunately. I have been unable to update ACF Pro for about 3 weeks now on 2 separate multisite installations, they always produce a ‘bad request’. I have removed the update transients in both the multite sitemeta table and the options table of the primary blog to no avail.
I’m also receiving a Bad Request error trying to update from 5.7.4 to 5.7.5 (multisite):
Plugin Advanced Custom Fields PRO bijwerken (1/1)
Update downloaden van https://connect.advancedcustomfields.com/v2/plugins/download?token=eyJwIjoicHJvIiwiayI6ImIzSmtaWEpmYVdROU5USXpOako4ZEhsd1pUMWtaWFpsYkc5d1pYSjhaR0YwWlQweU1ERTFMVEF6TFRFNUlERTFPakkyT2pBMCIsIndwX3VybCI6Imh0dHBzOlwvXC9ieWxpZW4uY29uc3VsdGluZyJ9…
Er is een fout opgetreden bij het bijwerken van Advanced Custom Fields PRO: Download mislukt. Bad Request.
1) extra_information (subfields: tab_title, tab_contents)
2) teachers
3) no
4) not applicable
@John Huebner you’re right, thanks for your reply! I make daily backups so restoring any missing data shouldn’t be a problem.
Some extra information, the field object appears empty, so it doesn’t know it’s a repeater (in the frontend). First get the field key:
meta_id post_id meta_key meta_value
367 62 _my_repeater field_56e045f278755
Then get the object:
$field = get_field_object('field_56e045f278755');
var_dump($field);
output: bool(false)
I am experiencing the same problem with ACF Pro 5.5.0. At first a specific repeater showed no data anymore in the admin, recreating the repeater made the data visible again. Currently however, the data is visible in the admin but the frontend doesn’t show it anymore, it outputs the number of rows (meta_value) instead.
For instance, this is a repeater group in the database with two rows:
meta_id post_id meta_key meta_value
366 62 my_repeater 2
Calling this repeater from the frontend gives back the meta_value, instead of the actual rows:
$test = get_field('my_repeater');
print_r($test);
output: 2
@nterry: that does look interesting! Getting the linebreaks back in the html view would certainly be nice, perhaps @elliot can look into this.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.