Support

Account

Register Login

Forum Replies Created

  • @robjs yes “traditionally” it’s been robust… but Elliott sold the plugin this summer and I’m not really sure the new team can be trusted.

    Apparently the somehow managed to ignore that people are using ACF to run mission critical settings : SEO, sitewide settings, plugin behavior settings, etc…

    This change is really an example of “developer making what he thinks make sense (whereas I totally agree with @robwent comment on the dubious security issue it really created) without considering everything it can breaks”.

    Personally if they screw up again, I’ll go somewhere else, despite having been a raving fan of Elliott’s plugin for years.

  • @John I’ve been able to replicate my issue on a blank site and I’ve sent this site as an All in One WP Migration backup for the support to investigate.

    I can send it to you too if you want, you seem more responsive than the acf support 😉

    Funny enough the ACF team sent an email this morning about 5.11… not stating that we should check our installation because of the numerous issues reported here… just to announce some news…

    People here are in emergency mode but the ACF team isn’t.

  • Nope we have to wait for the Dev to fix this. I sent them extensive videos of the setup that doesn’t work.

    It’s definitely get_field() from json and inside a plugin that doesn’t work (it works for example if you call get_field() from a PHP widget for example).

    I too MUST keep json field definition for version control and to be sure that the definitions of fields are the same across multiple sites…

  • Yes John it’s on purpose that I use unset($paths[0]);

    I solely rely on JSON loaded from my plugin.

    It’s never been an issue.

  • No news from support yet… in the meantime I’ve discovered more details about that bug (which could explain why @dany0 didn’t always get the same results as I did)

    So with a custom Settings Option page loaded only from a JSON file (NOT SYNC’ed) and for example an option called “goshow_blabla_percent”

    – From a sidebar PHP widget, this WORKS :

    
<?php

echo "get_field value is:" . get_field('goshow_blabla_percent', 'option') . "END";

?>

    But from my plugin, using this :

    
add_filter('acf/settings/save_json', 'gowf_acf_json_save_point');
function gowf_acf_json_save_point( $path ) {
// update path
$path = BJAWF_PLUGIN_PATH . 'acf-config';
// return
return $path;
}

add_filter('acf/settings/load_json', 'gowf_acf_json_load_point');
function gowf_acf_json_load_point( $paths ) {
// remove original path (optional)
unset($paths[0]);
// append path
$paths[] = BJAWF_PLUGIN_PATH . 'acf-config';
// return
return $paths;
}

$value = get_field('goshow_blabla_percent', 'option');

    => Will set $value to NULL…

    it has been working for years but it doesn’t work with 5.11 !!

  • @dany0 are you sure that you didn’t sync your fields ?

  • The docs say it’s singular “option”:

    https://www.advancedcustomfields.com/resources/get-values-from-an-options-page/

    I’ve tried adding 1 as the third parameter but it didn’t solve anything.

    Honestly when I see the remarks by the Dev, it’s obvious that they screw up with this update.

  • Also (maybe it makes a difference), my custom fields are for a site Option Page, not custom post fields…

    https://www.advancedcustomfields.com/resources/options-page/

    so I’m calling their values this way:

    $variable = get_field(‘field_name’, ‘option’);

  • It has always worked for me. Of course I’m loading local json ACF fields before any call.

    But I’m using ONLY json, i.e. I do NOT SYNC from json.

    Here is the code I’m using:

    
// 1.9 Now support LOCAL ACF JSON FIELD DEFINITION
//https://www.advancedcustomfields.com/resources/local-json/
//https://awesomeacf.com/how-to-avoid-conflicts-when-using-the-acf-local-json-feature/
// ON PRODUCTION, DON'T SYNC AND NEVER EDIT THE FIELD SETTINGS IN ACF
add_filter('acf/settings/save_json', 'bja_wf_acf_json_save_point');
function ben_wf_acf_json_save_point( $path ) {
	// update path
	$path = BENWF_PLUGIN_PATH . 'acf-config';
	// return
	return $path;
}

add_filter('acf/settings/load_json', 'ben_wf_acf_json_load_point');
function ben_wf_acf_json_load_point( $paths ) {
	// remove original path (optional)
	unset($paths[0]);
	// append path
	$paths[] = BENWF_PLUGIN_PATH . 'acf-config';
	// return
	return $paths;
}

    e.g. like as described in this article here:
    https://www.awesomeacf.com/how-to-avoid-conflicts-when-using-the-acf-local-json-feature/
    see chapter “The preventative workflow” -> I’m using option 1 described in that paragraph.

  • Oh and I forgot to say but the fields inside the JSON were made with ACF, so the argument “get_field for fields created with ACF work” is false, because if it was created by ACF but exported in JSON (which is the way local json ACF feature works), the update will now ignore these fields !!

    Please fix this, it’s just unacceptable.

  • It’s totally NOT professional.

    Does the new developer REALLY forgot that ACF supports loading local fields from a JSON file, i.e. the fields definition will NOT exist per se, but will exist in a json that ACF loads.

    https://www.advancedcustomfields.com/resources/local-json/

    In my case all my :

    get_field(‘blabla_option_definition_that_should_be_loaded_from_json’, ‘option’)

    are now returning NULL instead of something, breaking all logic based on that.

    In case the new developer didn’t know that too : ACF is also used to generate Options page that have sitewide effects: https://www.advancedcustomfields.com/resources/options-page/

    As a result I have stored ACF field definitions in a JSON file that is totally ignored and thus all sitewide settings stored are ignored.

    And this has been reported on the 10th but you let everyone discover your error, losing money for 3 days wondering what was going on…

    What the hell are you waiting for AT LEAST inform every pro users that there is a glitch and that they should check everything is working fine???

    Very very upset to see this plugin has been acquired and how it’s now being developed.

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