Forum Replies Created

Viewing 15 replies - 1 through 15 (of 2,266 total)
  • Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the details!

    1. If you want to isolate the issue more easily, please check the section in my previous answer where I explain you how to do it.

    2. Have you checked the “Screen Options” as in my screenshot? Maybe the “Advanced Settings” metabox is just hidden?

    Ideally to debug both issues, you should disable all your plugins at the exception of ACF Pro (in plugin mode, not mu, just in case you have custom code in mu) & ACF Extended.

    So you have a setup that is basically “blank”, and the only custom code is in your theme (if that’s where your custom code/hooks are). Then comment big portion of your code in the functions.php with /* */.

    Start big, and comment everything, refresh the “ACF > Settings” page, and the path should be working. Which means the issue is somewhere in your big /* */ in functions.php. Then decomment some big chunk of code, check “ACF > Settings” again… etc. Keep decommenting until you find the code/file that break the path again.

    This way you can isolate it like a funnel.

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the details!

    1. Using ACF Pro as mu-plugin should not remove the path setting on its own. Here is a video showing ACF Pro setup as mu-plugin on a blank WP Install.

    If you want to test it, here is the code I used in the /mu-plugins/acf-pro.php file:

    <?php

    require_once(__DIR__ . '/advanced-custom-fields-pro/acf.php');

    The ACF Pro folder being in /mu-plugins/advanced-custom-fields-pro. You should get the same result, with the path correctly set in the “ACF > Settings” page on a blank WP Install like in the video.

    You can check if your ACF path setting has been removed or not, using the following code in your theme’s functions.php file:

    add_action('acf/init', function(){
    $has_path = isset(acf()->settings['path']) ? 'true' : 'false';
    acf_log('acf path found:', $has_path);
    }, 100);

    This will log the information in your /wp-content/debug.log file with the WP_DEBUG & WP_DEBUG_LOG enabled in the wp-config.php file. You can read more about how to enable the WP_DEBUG_LOG in our guide here.

    In order to isolate the issue on your setup, I would recommend clone your website on a development / staging environment using Duplicator, or with your hosting backup solution. Then try to disable all your plugins one-by-one (at the exception of ACF Pro & ACF Extended) until you find which one cause the issue.

    If the problem persists, try switch to the native WP Twenty Twenty Two theme, to make sure you don’t have any custom code in your theme which would break the feature.

    In all cases you should be able to confirm it works like I did, by setting up a clean WP install with ACF Pro + ACF Extended only.

    2. If you have some custom hooks/code for the ACF Json sync feature, I would recommend to double check the json and the local ACF settings are correctly enabled (they are enabled by default). You will see their status in the “ACF > Settings” page too. Additionally, please make sure that you use available hooks in the ACF documentation here.

    Another thing you could check, is the “Screen options” in your Field Group UI and make sure the “Advanced Settings” checkbox is correctly checked to display the related metabox. See screenshot.

    To debug your custom Json code/hook, you can use the same method as described above, by disabling all plugins and using a blank theme. Then add your Json related hooks one by one until you find which one that seems to be problematic.

    Let me know if you found something!

    Thanks!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the feedback!

    1. The “ACF > Settings” page you see in the WP Admin menu is a page added by ACF Extended. This screen will recap all ACF settings defined in code. You can read more about ACF settings here.

    As you can see in the ACF documentation, the path setting is a default setting that is essential to the functioning of ACF:

    Absolute path to ACF plugin folder including trailing slash. Defaults to plugin_dir_path()

    The error message you shared suggests it has been deleted/removed. Note it seems it hasn’t been updated/changed using existing ACF methods with acf_update_setting(), but completely deleted, which isn’t normal and might break ACF.

    In fact, in order to reproduce this warning message, a code similar to this must be used (which should be avoided, as it doesn’t respect native ACF core logic):

    add_action('acf/init', function(){
    unset(acf()->settings['path']);
    });

    I would suspect some custom code/hook somewhere either in your theme or a third party plugin which remove that setting. Ideally, you should find it and fix it to avoid more issues.

    • Do you have any particular custom ACF Pro setup?
    • Is ACF Pro installed as a plugin?
    • Do you know which version of ACF Pro do you use?

    2. By default, ACF automatically save any Field Group as a json file if there is a folder named /acf-json/ in your theme, everytime you update a Field Group in the ACF UI.

    With ACF Extended, you can control that behavior and define which Field Group should be saved as Json. In the ACF UI, when editing a Field Group, on the right side you’ll find the “AutoSync Settings” with checkboxes that let you choose if the Field Group should be saved as a Json and/or PHP file (See screenshot).

    By default, ACF Extended respects the default ACF behavior and will automatically check the “Json Sync” checkbox if there is a /acf-json/ folder in your theme. So all your Field Groups will behave the same as usual. However, if you unchecked this checkbox and saved the Field Group at some point, it won’t be saved as Json. If you want to keep saving the Json files, please make sure this checkbox is checked.

    Thanks!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the feedback!

    I just tested the Date Picker field on a blank WP install, with ACF Pro 6.3.10 & ACF Extended 0.9.0.9, and it works fine on my end. See video of my test.

    Are you sure you’re using the latest ACF / ACFE version?

    Thanks!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Just a heads up to let you know the latest ACF Extended 0.9.0.9 update fixed this issue.

    Please update your plugin to get the latest bugfixes.

    Have a nice day!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Just a heads up to let you know the latest ACF Extended 0.9.0.9 update fixed this issue.

    Please update your plugin, and also make sure to remove the previous hotfix code I shared from your theme’s functions.php file.

    Have a nice day!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Just a heads up to let you know the latest ACF Extended 0.9.0.9 update fixed this issue.

    Please update your plugin, and also make sure to remove the previous hotfix code I shared from your theme’s functions.php file.

    Have a nice day!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Just a heads up to let you know the latest ACF Extended 0.9.0.9 update fixed this issue.

    Please update your plugin, and also make sure to remove the previous hotfix code I shared from your theme’s functions.php file.

    Have a nice day!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Ah yeah, if the Field key/configuration cannot be found, it makes sense your get_field() return wrong values.

    I’m glad to hear it now works as expected!

    Have a nice day!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the feedback!

    The latest 0.9.0.8 version added some changes in order to make the get_row_index() work with the Flexible Content Dynamic Render in the admin preview.

    After some extensive checks, it looks like these changes broke the usage of get_row() and get_row_layout() in the admin preview. If you’re using these functions in Flexible Content layouts, you might run into problems.

    Here is a quick fix you can add to your theme’s functions.php file in order to fix this issue.

    // ACFE 0.9.0.8: Fix get_row() & get_row_layout() usage in Flexible Content preview
    add_filter('acfe/flexible/render/template', 'acfe_fix_flexible_content_preview_get_row', 0, 4);
    function acfe_fix_flexible_content_preview_get_row($file, $field, $layout, $is_preview){
    
        if($is_preview){
            acf_update_loop('active', 'i', 0);
        }
    
        // return
        return $file;
    
    }

    Note this will revert the changes of the 0.9.0.8 update, and make get_row_index() always return 1 in the WP Admin (just like in the previous version).

    I’m preparing an update which will fix both functions usage.

    Please let me know if that fixed the issue.

    Thanks!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the details!

    Well yeah, it makes sense. In your code $layout is a string region_event_information_layout, but you try to work with it as if it was an array.

    if ($event_fields) :

    $layout = $event_fields[0];
    // $layout is: 'region_event_information_section' here

    $event_title = $layout['event_title']; // this is not possible, it's not an array

    endif

    What is the Field Type of get_field('region_event_information_section', $event->ID)?

    It currently just return some strings, see your logs. I’m not sure if that’s normal.

    [06-Nov-2024 18:53:00 UTC] event fields: Array
    (
    [0] => region_event_information_layout
    )

    I would recommend to enable the Developer Mode (see documentation), and head over your WP Admin and go edit the post 1022925. The Developer Mode will show you all the metadata saved on this post. Look for your region_event_information_section meta, you should get more information.

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the feedback!

    In fact, I was able to reproduce the bug. The issue come from the latest ACF 6.3.10 version which added some additional nonce check for fields ajax requests.

    The latest ACF Extended 0.9.0.8 patch added compatibility fixes regarding this, but the ACFE Taxonomy Terms field wasn’t fixed. It is an oversight. I’m adding a fix in the next patch.

    In the meantime, you can fix the issue by adding the following code in your theme’s functions.php file:

    // ACFE 0.9.0.8: Fix taxonomy terms ajax nonce wih ACF 6.3.10
    add_filter('acf/prepare_field/type=acfe_taxonomy_terms', 'acfe_fix_taxonomy_terms_ajax_nonce');
    function acfe_fix_taxonomy_terms_ajax_nonce($field){

    if($field['ui'] && $field['ajax']){
    $field['nonce'] = wp_create_nonce($field['key']);
    }

    return $field;

    }

    Thanks again for the report, and sorry for the inconvenience.

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the feedback!

    In order to isolate the issue, I would recommend to run your test directly with acf_get_grouped_terms(). You can run the following simple function:

    acf_get_grouped_terms(array(
    'taxonomy' => 'category' // or use your specific taxonomy
    ));

    If you get different results from wp shell and from within the WP Admin, then it might mean you got some custom code either in a third party plugin or in your theme, which would interfere with the returning terms.

    To find the root of the problem, I would recommend clone your website on a development / staging environment using Duplicator, or with your hosting backup solution. Then try to disable all your plugins one-by-one (at the exception of ACF Pro) until you find which one cause the issue.

    If the problem persists, try switch to the native WP Twenty Twenty Two theme, to make sure you don’t have any custom code in your theme which would break the feature.

    I don’t think the issue come from the ACF code itself. This function and its logic has been around for few years now. But if the issue can be reproduced on a clean WP install with ACF Pro only, then yeah it might be a bug that should be reported to ACF.

    Let me know if you found something.

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    Thanks for the feedback!

    I’m glad to hear you enjoy ACF Extended!

    Regarding your problem, it’s hard to tell without having all the context and code structure. I suppose the warning says you cannot retrieve the $layout['event_title']?

    It looks like you have enabled the WP_DEBUG_LOG mode and you have access to the /wp-content/debug.log file, which is great! This will help you to understand where the issue come from.

    I would recommend to add some logs in your code with acf_log(). This function will write the information of your choice in the debug.log file. This will allow you to check that everything is in order.

    I would recommend the following logs:

    $event_fields = get_field('region_event_information_section', $event->ID);

    // --- logs ---
    acf_log('event id:', $event->ID);
    acf_log('event fields:', $event_fields);
    // ------------

    if ($event_fields) :
    $layout = $event_fields[0]; // Get first layout

    // --- logs ---
    acf_log('layout:', $layout);
    // ------------

    $event_title = $layout['event_title'];
    $venue = $layout['venue'];
    endif;

    Once the code is in place, refresh your WP Admin page, and check your wp-content/debug.log file again. You should see the logs and if something is wrong.

    You can read more about how to debug WordPress and ACF in our guide here, if needed.

    Let me know if you found something!

    Regards.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    Hello,

    You most likely have an issue at the location where you set the photo_id = '...' in your acfe_form() function or acfe/load_form hook.

    I would recommend to check the PHP code where you set this photo_id, and log the value there to make sure everything is in order.

    If the photo_id doesn’t return a proper Post ID (number), then your “Post Action” will not be executed, as no post can be updated. And thus, the acfe/form/submit_post/form=photo-add2 hook won’t be executed.

    You can check your Form configuration using Global Form hooks (see documentation).

    On form load with acfe/load_form (see documentation):

    // log form on load
    add_filter('acfe/form/load_form/form=photo-add2', 'my_form_load');
    function my_form_load($form){

    // log
    acf_log('load_form', $form);

    // return normally
    return $form;

    }

    On form submission with acfe/form/submit_form (see documentation):

    // log on submit
    add_action('acfe/form/submit_form/form=photo-add2', 'my_form_submit');
    function my_form_submit($form){

    // log
    acf_log('submit_form', $form);

    }

    Both these logs should show you $form['photo_id'] = 45 (any number, is should be a post id). If there is no post id, then check your PHP code where you set it.

    Hope it helps!

    Regards.

Viewing 15 replies - 1 through 15 (of 2,266 total)