Kevin Shenk

Feature request: It would seem much more ideal if the plugin had explicit detection and reporting on the frontend whenever relevant token permissions have not been granted correctly, rather than forcing users to sleuth through log files.

You can use a script like the following in WP Console:

<?php

$args = [
    'post_type' => 'dealers', // Replace with your post type
    'posts_per_page' => -1,
    'fields' => 'ids',
];

$posts = get_posts($args);

// replace with your ACF field keys and names
$fields_to_update = [
    'field_658f34acfa8b1' => 'dealer_type',
    'field_63e2523c7b2a8' => 'netsuite_id',
    'field_63bc663415a82' => 'phone',
    'field_63e16cc724134' => 'fax',
    'field_63bc664f15a83' => 'website',
    'field_63e252187b2a7' => 'website_domain',
    'field_63bc67275b5ea' => 'open_hours',
    'field_63bc7f1f02a3b' => 'location',
];

$acf_cpt = new Acf_ct_register_hooks();

$_POST['_acf_changed'] = "1";

foreach ($posts as $post_id) {
    $_POST['acf'] = [];

    foreach ($fields_to_update as $field_key => $field_name) {
        $field_value = get_field($field_name, $post_id);
        if ($field_value !== false) {
            $_POST['acf'][$field_key] = $field_value;
        }
    }

    // Call the function to handle saving the post
    $acf_cpt->acf_ct_handle_save_post($post_id);

    // Output for confirmation
    echo "Processed post ID: {$post_id}\n";
}

You can find the field keys for your scenario by enabling ‘key’ under ‘Screen elements’ in the field group edit screen.

• This reply was modified 10 months, 4 weeks ago by Kevin Shenk.

You can use a custom action hook like the following. This example is for a specific post type and field group, which helps to keep it performant. Obviously, you would need to adapt it to your use-case:

<?php

add_action('save_post', 'update_custom_dealers_table', 10, 3);
function update_custom_dealers_table($post_id, $post, $update)
{
    // If this isn't a 'dealer' post, don't update it.
    if ($post->post_type != 'dealers') {
        return;
    }
    // update custom fields
    $fields_to_update = [
        'field_658f34acfa8b1' => 'dealer_type',
        'field_63e2523c7b2a8' => 'netsuite_id',
        'field_63bc663415a82' => 'phone',
        'field_63e16cc724134' => 'fax',
        'field_63bc664f15a83' => 'website',
        'field_63e252187b2a7' => 'website_domain',
        'field_63bc67275b5ea' => 'open_hours',
        'field_63bc7f1f02a3b' => 'location',
    ];

    $acf_cpt = new Acf_ct_register_hooks();

    $_POST['_acf_changed'] = "1";
    $_POST['acf'] = [];

    foreach ($fields_to_update as $field_key => $field_name) {
        $field_value = get_metadata_raw('post', $post_id, $field_name, true);
        if ($field_value !== false) {
            if (ctype_digit($field_value)) {
                $field_value = (int) $field_value;
            }
            $_POST['acf'][$field_key] = $field_value;
        }
    }

    // Call the function to handle saving the post
    $acf_cpt->acf_ct_handle_save_post($post_id);
}

You can find the field keys for your scenario by enabling ‘key’ under ‘Screen elements’ in the field group edit screen.

Same issue here, effecting a slew of my client sites! Many of them are not displaying anything but:

You do not have sufficient permissions to access this page.

I had the same issue and can confirm that the above fix works ??

Yeah, I am using FSE, with the Cwicly toolkit. Because I have full control of the template in FSE, I created an identical block ID in every template that I use for swapping out the page contents. That part worked, but some other quirks remain.

I’m glad to have clarity on this, though. I was really hopeful about AP, and hope there’s some kind of resolution to this over-arching objective in the future.

Best!

Well, here’s the website, but I’ll need to spin up a staging site so I can enable this for development purposes. I just turned it on for a minute or so to verify that the issue still exists. If you’re willing to take a look at a staging site, I’ll get that set up.

Here’s what I entered:

a:not(.cc-lightbox)

Woot! I’ll give this a try and report back!

In this scenario, I was installing docket cache on a “placeholder” site before migrating other sites into/ontop it. Once I removed all the docket cache data before migrate, it worked.

Upon further diagnosis, this seems to be related to my backup/restore/migrate mechanism. Apparently stale and misplaced cache can be lethal. I’ll keep you posted.

I should have mentioned, here’s my Docket Cache configuration:

define('DOCKET_CACHE_ADVCPOST', true);
define('DOCKET_CACHE_ADVPOST_POSTTYPE_ALL', true);
define('DOCKET_CACHE_AUTOUPDATE', false);
define('DOCKET_CACHE_CHECKVERSION', false);
define('DOCKET_CACHE_CRONBOT', false);
define('DOCKET_CACHE_CRONOPTMZDB', 'weekly');
define('DOCKET_CACHE_FLUSHACTION', true);
define('DOCKET_CACHE_GCACTION', true);
define('DOCKET_CACHE_HEADERJUNK', true);
define('DOCKET_CACHE_LIMITHTTPREQUEST', true);
define('DOCKET_CACHE_LOG', false);
define('DOCKET_CACHE_LOG_ALL', false);
define('DOCKET_CACHE_MENUCACHE', true);
define('DOCKET_CACHE_MISC_TWEAKS', true);
define('DOCKET_CACHE_MOCACHE', true);
define('DOCKET_CACHE_OPCSHUTDOWN', true);
define('DOCKET_CACHE_OPTERMCOUNT', true);
define('DOCKET_CACHE_OPTWPQUERY', true);
define('DOCKET_CACHE_PAGELOADER', false);
define('DOCKET_CACHE_PINGBACK', true);
define('DOCKET_CACHE_POSTMISSEDSCHEDULE', true);
define('DOCKET_CACHE_PRECACHE', false);
define('DOCKET_CACHE_PRELOAD', true);
define('DOCKET_CACHE_RTIMAGEOVERWRITE', true);
define('DOCKET_CACHE_SIGNATURE', true);
define('DOCKET_CACHE_STATS', false);
define('DOCKET_CACHE_WOOTWEAKS', true);
define('DOCKET_CACHE_WPAPPPASSWORD', true);
define('DOCKET_CACHE_WPBROWSEHAPPY', true);
define('DOCKET_CACHE_WPDASHBOARDNEWS', true);
define('DOCKET_CACHE_WPEMOJI', true);
define('DOCKET_CACHE_WPFEED', true);
define('DOCKET_CACHE_WPLAZYLOAD', false);
define('DOCKET_CACHE_WPOPTALOAD', false);
define('DOCKET_CACHE_WPSERVEHAPPY', true);
define('DOCKET_CACHE_WPSITEMAP', true);

As it turns out, the issue was a conflict with the “Suspend WP Options Autoload” option in Docket Cache. I’m not sure that’s you’re problem, and perhaps its just inadvisable to enable that setting…

FYI, I believe that recognizing existing custom post types and taxonomies is a different issue/request vs the ability to import others from CPT UI specifically. “Recognize” seems to imply the ability to modify existing custom post types, which could be nice, but would certainly require a whole different set of functionality.

Agreed! This is a major feature request for me!