Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An unknown field is used in condition #1064

Open
duncanarrow opened this issue Dec 1, 2021 · 5 comments
Open

An unknown field is used in condition #1064

duncanarrow opened this issue Dec 1, 2021 · 5 comments

Comments

@duncanarrow
Copy link

Version

  • Carbon Fields: 3.3.2
  • WordPress: 5.8.2
  • PHP: 7.4

Expected Behavior

To be able to add and remove rows within WordPress posts/pages without the fields disappearing or creating errors within Web Developer Tools.

Actual Behavior

I've done quite a bit of testing on this and can reliably recreate this issue.

I have a complex field with multiple groups of fields within (basically I'm creating a draggable page builder) e.g.

  • Complex field
    • header_full_width
    • header_two_blocks
    • google_map
    • video
    • spacer
    • etc etc...

It seems that if I use conditional logic to show/hide fields within any of the field sets, then I have to create that same conditional field within every other group of fields (even if I don't need it).

So in its simplest form, see my code below. You'll see I've got two groups of fields within my complex field set called header_full_width and spacer. Within header_full_width I'm conditionally showing/hiding some other fields based on whether the content_options field is ticked or not.

Within spacer I don't need a content_options field as I don't need to show/hide any further fields within this block.

However if I don't create the content_options field within spacer, then when I come to add spacer and drag it up or down the list of rows within WordPress (or indeed delete it), then Web Developer Tools reports An unknown field is used in condition - "content_options"

Why is this a problem? Well, firstly the error is confusing. But also I've found that when creating lots of rows (remember this is just a subset of my field groups - I've got 10+ different field groups within my complex field so far), it can suddenly cause weirdness such as all the fields disappearing from the post/page screen. Like there's some memory issue or buffer overrun within the browser for instance.

So in order to fix the issue, it seems I have to ensure that all fields referenced from any of the conditional logic within the complex field set are added to all the other field groups regardless of if I need them. I then hide them in the interface where I don't need them by adding a suitable class e.g.

               Field::make( 'checkbox', 'content_options', 'Content options' )
		    ->set_classes( 'hide-field' )
		    ->set_option_value( 'yes' ),

Container definition

->add_fields('header_full_width', 'Header: full width', array (
               Field:make('rich_text', 'left_text', 'Content'),

               Field::make( 'checkbox', 'content_options', 'Content options' )
		    ->set_classes( 'fluidal_divider' )
		    ->set_option_value( 'yes' ),

               Field::make( 'color', 'content_text_colour', 'Primary font colour' )
		    ->set_conditional_logic( array( array( 'field' => 'content_options', 'value' => true )))			            	
		    ->set_width( 20 )
		    ->set_classes( 'join fluidal_divider_child' )
		    ->set_palette( $set_palette ),

               Field::make( 'select', 'text_inset', 'Text inset' )
		    ->set_conditional_logic( array( array( 'field' => 'content_options', 'value' => true )))			            	
		    ->set_width( 20 )
		    ->set_classes( 'join fluidal_divider_child' )
		    ->set_help_text( $inset_help_text )
		    ->add_options( $yes_no )
		    ->set_default_value( 'no' ),
		
               Field::make( 'select', 'content_vertical_align', 'Vertical align' )
		    ->set_conditional_logic( array( array( 'field' => 'content_options', 'value' => true )))			            	
		    ->add_options( $content_vertical_align )
		    ->set_default_value( 'align-items-centre' )
		    ->set_help_text( 'Set vertical align of the content' )
		    ->set_classes( 'join fluidal_divider_child' )
		    ->set_width( 20 )
		    ->set_required( true ),
		
               Field::make( 'select', 'block_min_height', 'Min height' )
		    ->set_conditional_logic( array( array( 'field' => 'content_options', 'value' => true )))			            	
		    ->add_options( $block_height )
		    ->set_default_value( 'thin_height' )
		    ->set_classes( 'join fluidal_divider_child' )
		    ->set_help_text( 'Set a minimum height on the block' )
		    ->set_width( 20 )
		    ->set_required( true ),
))

->add_fields( 'content_spacer', 'Spacer', array (
               Field::make( 'html', 'spacer_info' )

               Field::make( 'text', 'height_desktop', 'Desktop height (px)' )
		    ->set_default_value( '200' )
		    ->set_attribute( 'type', 'number' )
		    ->set_width( 40 ),

               Field::make( 'text', 'height_mobile', 'Mobile height (px)' )
		    ->set_default_value( '50' )
		    ->set_attribute( 'type', 'number' )
		    ->set_width( 40 ),

               Field::make( 'text', '__unique', 'Unique ID' )
		    ->set_width( 20 )
		    ->set_attribute( 'readOnly', 'readonly' ),
))

Steps to Reproduce the Problem

Detailed above!

@ghost
Copy link

ghost commented Apr 19, 2023

Experiencing the same problem. Thought it was something occurring since the newest 3.6.0 version, but seems a much older issue.

@siaeb
Copy link

siaeb commented Aug 18, 2023

Me too.
Experiencing the same problem. Thought it was something occurring since the newest 3.6.0 version, but seems a much older issue.

@mrdarrengriffin
Copy link

I think I have found the problem but can't figure out the fix.

There are 2 things I have found

A field has the same starting value as the complex

You have a field in a complex with a value matching the start of the complex field name. E.g. I have a complex called 'extras' and inside a field called 'extra'. If I rename the field inside to 'other_extra'. It works fine.

This is the relevant logic: https://github.com/htmlburger/carbon-fields/blob/master/packages/metaboxes/hocs/with-conditional-logic/index.js#L107

Nested complex depth calculation

It might be related to the discovery above but it seems that the reduce on the depth logic removes the innermost complex field. I am at a loss here but here is where I have been debugging locally:

It's might be an issue in one of these references:

let depth = path.reduce( ( accumulator, chunk ) => {
return isNaN( chunk )
? accumulator + 1
: accumulator;
}, 0 );

siblingFields = getFieldsFromFieldsHolder( container, fields, [ rootField.id ] );
siblingFields = mapParentPrefix( siblingFields, depth + 1 );

I can't make head or tail as to what's going on any why. These look like universal functions that handle multiple scenarios and can't be sure that a fix won't break something else.

I would love if someone can help diagnose this.

My fix

Was to ensure that when I have nested fields, the names don't match and of the start of any of the parent field names.

@mrdarrengriffin
Copy link

I can't really dedicate any more time to this. Took me a few hours to even figure out what I did. I'd really need to dedicate a chunk of time to really break this down and I just can't at the moment.

Hopefully someone reading this has a better idea of how it work and my insights can help with finding a solution

@tcj-rocks
Copy link
Contributor

I've also come across this. Had two fields in the same tab. One was a checkbox, the other was a complex field containing several fields and conditional logic. The checkbox field's name was the same as the start of the complex field's name. I'd get the console errors and the conditional logic in the complex field would fail to execute. After renaming the checkbox field to something different, everything was okay. I went into the code like @mrdarrengriffin but eventually gave up since it takes too long to get through the abstraction to make it worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants