Support

Account

Forum Replies Created

  • Hi John,

    The challenge was that it needed to have a location rule for the post type of landing page (easily done) and a location rule for the template ID used on that post. The developers from Inboundnow were able to make a update to their plugin in their GitHub dev branch that adds the filter for ACF where the template ID is exposed in their code, and we were able to get it working!

    Thanks again for all the help!

  • Looks like all I need to do now is add a custom location rule for “template_id” and I’m done. So now I just need to find out how to access that.

    The examples provided at http://www.advancedcustomfields.com/resources/custom-location-rules/ are great. I just need to figure out how to reference “template_id” and load values for existing templates. I’m a bit stumped there for the moment.

    I’m guessing something like this?

    
    add_filter('acf/location/rule_types', 'acf_location_rules_types');
    function acf_location_rules_types( $choices )
    {
        $choices['Basic']['template_id'] = 'Template ID';
    
        return $choices;
    }
    
    add_filter('acf/location/rule_values/template_id', 'acf_location_rules_values_template_id');
    function acf_location_rules_values_template_id( $choices )
    {
        $template_ids = /* somehow get template IDs here */
    
        if( $template_ids )
        {
            foreach( $template_ids as $template_id )
            {
                /* template ID by template name here */
            }
        }
    
        return $choices;
    }
    

    Thanks so much for all the help. It looks like I’m nearly there!

  • I’m confused… what’s the point of exporting the PHP of a field group if using that php on the site causes problems?

    As you mentioned, those steps will not recreate the issue, now that we know the issue is caused by exporting the fields to PHP and then implementing that PHP in a config.php for a template.

    I’m fine with having to re-export the php if I make changes to the field group in ACF. But I don’t understand why the exported PHP running on the site would cause the fields in ACF to vanish.

    In my case I have a template for a landing page that has 2 standard components. a config.php that is used to define the fields for the page, and an index.php that reads those fields.

    All I’m doing is exporting the field group and adding it to the config.php for my template so when I create a page that uses that template the proper fields show up for building the page.

    As far as my customization to the theme, there really isn’t any. The only real PHP contents of the config.php are what I pasted above. (the register_field_group array)

    The only real change to the array is the addition of template_id to the location array:

            'location' => array (
                array (
                    array (
                        'param' => 'post_type',
                        'operator' => '==',
                        'value' => 'landing-page',
                    ),
                    array (
                        'param' => 'template_id',
                        'operator' => '==',
                        'value' => $key,
                    )
                ),
            ),
    

    That is used so the fields are only show up for that specific template.

    I could potentially avoid implementing the exported fields PHP in config.php if there were a way in ACF to add template_id == XXX in locations, but that does not appear to be an option.

    I was able to get things to ALMOST work by removing the register_field_group content form the config.php and then having the ACF field group location target a specific landing page post. The problem there is a single post can implement any number of templates. So I need to target a post that uses a specific template_id, otherwise these fields show up for all landing page posts regardless of template.

    So post_type == landing page is supported, but targeting a specific template is not. (see screenshot)

    So very very close!

  • OK, I just exported the 10 test fields to PHP and copied the ‘fields’ portion of the array (and not the ‘locations’ part) into my theme config.php

    The second I uploaded that PHP file I hit update on the fields group and BOOM, 1 field left.

    So I can create fields, just not use them?

    Here is the code:

    
    if(function_exists("register_field_group")){
        register_field_group(array (
            'id' => 'acf_template-one-a',
            'title' => 'Template One: A',
            'fields' => array (
                array (
                    'key' => 'field_56a2ce14c3f0d',
                    'label' => 'one',
                    'name' => 'main_content_text_color',
                    'type' => 'color_picker',
                    'required' => 1,
                    'default_value' => '#000000',
                ),
                array (
                    'key' => 'field_56a2ce42c3f0e',
                    'label' => 'two',
                    'name' => 'conversion_text_color',
                    'type' => 'color_picker',
                    'required' => 1,
                    'default_value' => '#000000',
                ),
                array (
                    'key' => 'field_56a2f4376cc20',
                    'label' => 'three',
                    'name' => 'another_damn_field',
                    'type' => 'text',
                    'instructions' => 'blah blah blah',
                    'default_value' => '',
                    'placeholder' => '',
                    'prepend' => '',
                    'append' => '',
                    'formatting' => 'html',
                    'maxlength' => '',
                ),
                array (
                    'key' => 'field_56a2f4d283faa',
                    'label' => 'four',
                    'name' => 'four',
                    'type' => 'text',
                    'instructions' => 'grrrrr',
                    'default_value' => '',
                    'placeholder' => '',
                    'prepend' => '',
                    'append' => '',
                    'formatting' => 'html',
                    'maxlength' => '',
                ),
                array (
                    'key' => 'field_56a30600484a1',
                    'label' => 'five',
                    'name' => 'five',
                    'type' => 'image',
                    'save_format' => 'object',
                    'preview_size' => 'thumbnail',
                    'library' => 'all',
                ),
                array (
                    'key' => 'field_56a3061ef00f1',
                    'label' => 'six',
                    'name' => 'six',
                    'type' => 'image',
                    'save_format' => 'object',
                    'preview_size' => 'thumbnail',
                    'library' => 'all',
                ),
                array (
                    'key' => 'field_56a30657f81a1',
                    'label' => 'sevin',
                    'name' => 'sevin',
                    'type' => 'wysiwyg',
                    'required' => 1,
                    'default_value' => 'foo',
                    'toolbar' => 'full',
                    'media_upload' => 'yes',
                ),
                array (
                    'key' => 'field_56a3066fdf65c',
                    'label' => 'eight',
                    'name' => 'eight',
                    'type' => 'wysiwyg',
                    'default_value' => '',
                    'toolbar' => 'full',
                    'media_upload' => 'yes',
                ),
                array (
                    'key' => 'field_56a306cdc3924',
                    'label' => 'nine',
                    'name' => 'nine',
                    'type' => 'color_picker',
                    'required' => 1,
                    'default_value' => '#ff0000',
                ),
                array (
                    'key' => 'field_56a306ea011a1',
                    'label' => 'ten',
                    'name' => 'ten',
                    'type' => 'color_picker',
                    'required' => 1,
                    'default_value' => '#00ff00',
                ),
            ),
            'location' => array (
                array (
                    array (
                        'param' => 'post_type',
                        'operator' => '==',
                        'value' => 'landing-page',
                    ),
                    array (
                        'param' => 'template_id',
                        'operator' => '==',
                        'value' => $key,
                    )
                ),
            ),
            'options' => array (
                'position' => 'normal',
                'layout' => 'no_box',
                'hide_on_screen' => array (
                ),
            ),
            'menu_order' => 0,
        ));
    }
    
  • The fields are not actually there. The stored sort order values for the fields that were not deleted are just never updated. And the count for the total number of fields that shows at the “Field Groups” root level is also not updated.

    I originally did view the source to see if they were just hidden in the UI, but they are gone. And if I touch any of them to change the sort order they update to the proper 1, 2, 3, 4.

    It’s like they are being removed by some process that does not trigger any UI or DB updates for the stored sort and total fields values.

    I currently have a test going with 10 fields. 4 color pickers, 2 text, 2 WYSIWYG, and 2 images. (to see if somehow a specific field type is being removed) or if modifying a specific field type somehow triggers the series of events that ends up with random deletions.

    So far I’ve done everything I can think to do… update values change sort orders, exit the page, export to PHP, click the dreaded update button, and all 10 fields remain.

    That said, I don’t feel even remotely safe as fields have been randomly deleted on no fewer than 6 occasions so far.

    The only difference so far is that this field group has not been exported and used in my template config.php for the Landing Pages plugin. I wonder if somehow the config.php accessing these fields is deleting some of them?

    This is maddening.

  • I’m using the 2016 theme. The site has no pages, and no posts. Only a single test “landing page” using the Landin Pages plugin.

    I’ve attached 2 screenshots showing the one UI falsely showing 10 fields (which were once there) and the actual fields that remain after 6 were randomly deleted.

    Deactivating the other 3 plugins is not really an option, as those are all needed.

    It’s hard to determine what user-flow is causing the issue so it can be easily replicated.

    I just clicked “update” while viewing my 4 fields and one of them vanished.

    I then hit update a few more times, exited and returned to that section and hit update a few more times but it never removed more.

    I’ve since added another field (bringing me back to 4) and clicking update has not yet removed one of those.

    Not being able to consistently reproduce the bug will make this difficult. It’s entirely possible your test environment has the same bug but has not triggered it yet.

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