Transport : Auto Issue (v 3.1.9)

[scottstanford]

Issue description:

When transport is set to auto, and the add_field name is set to the theme_config_id, the realtime updating of CSS does not work. Changing the name in add field first parameter to match the settings name allows the realtime CSS to work, but then this value is not saved outside the customize view.

Version used:

(Did you try using the develop branch from GitHub? There's a chance your issue has already been addressed there)

YES

Using theme_mods or options?

OPTIONS

Code to reproduce the issue (config + field(s))

Kirki::add_config('gui_theme_manager', array(
                'capability' => 'edit_theme_options',
                'option_type' => 'option',
                'option_name' => 'gui_kirki_array',
            ));

Kirki::add_field('gui_theme_manager', [
                'type' => 'color',
                'settings' => 'gui_Colors_Primary_Background',
                'label' => __('Primary Colour (Background)', 'kirki'),
                'section' => 'gui_Colors_Primary',
                'default' => '#123452',
                'transport' => 'refresh',
                'output' => [
                    [
                        'property' => 'color',
                        'element' => '#gui .gui_btn.gui_btn_plain, #gui .gui_primary .gui_btn.gui_btn_plain,#gui #gui_sub .gui_module_large-list.gui_large-list_features.gui_primary li.gui_item .gui_icon-holder  i:before,#gui .gui_module_tabs .gui_tabs_head ul li.ui-state-active,#gui .gui_module_tabs.gui_tabs_vertical .gui_tabs_head ul li.ui-state-active,#gui table tbody tr:hover td, #gui table tbody tr:hover td p,#gui table.gui_primary tbody tr:hover td, #gui table.gui_primary tbody tr:hover td p,#gui .gui_module_large-list.gui_large-list_sitemap .gui_item:hover .gui_title,/* #gui #gui_sub .gui_title > strong, #gui #gui_sub .h1 > strong, #gui #gui_sub .h2 > strong, #gui #gui_sub .h3 > strong, #gui #gui_sub .h4 > strong, #gui #gui_sub .h5 > strong, #gui #gui_sub .h6 > strong, #gui #gui_sub h1 > strong, #gui #gui_sub h2 > strong, #gui #gui_sub h3 > strong, #gui #gui_sub h4 > strong, #gui #gui_sub h5 > strong, #gui #gui_sub h6 > strong */,#gui .gui_module_large-list.gui_large-list_features.gui_primary li.gui_item,#gui .daterangepicker:before,#gui .daterangepicker:after',
                    ],
                    [
                        'property' => 'background-color',
                        'element' => '#gui .gui_module_accordion .gui_accordion_head.ui-state-active,#gui #gui_sub  .gui_module_large-list.gui_large-list_stats.gui_primary li.gui_item,#gui .gui_module_large-list.gui_large-list_content-summary.gui_primary,#gui .gui_module_countdown .gui_countdown-holder .gui_countdown .gui_countdown_instance > div,#gui .gui_module_countdown.gui_primary  .gui_countdown-holder .gui_countdown .gui_countdown_instance > div,#gui #gui_sub .gui_module_cta.gui_cta_spotlight.gui_primary,#gui #gui_sub .gui_module_cta.gui_cta_spotlight.gui_primary:before,#gui #gui_sub .gui_module_cta.gui_cta_main.gui_primary,#gui #gui_sub .gui_module_cta.gui_cta_main.gui_primary:after,#gui #gui_sub .gui_module_large-list.gui_large-list_skills li.gui_item .gui_custom-holder .gui_custom,#gui table thead,#gui .gui_module_large-list.gui_large-list_staggered.gui_primary li.gui_item > .gui_expander,#gui table.gui_primary thead,#gui .gui_module_large-list.gui_large-list_sitemap > .gui_expander > .gui_body > .gui_expander > .gui_title-holder,#gui .gui_module_large-list.gui_large-list_content-summary.gui_primary,#gui .gui_module.gui_module_large-list.gui_large-list_relations.gui_primary .gui_relations-filter .gui_item.gui_active,#gui .gui_module_large-list.gui_large-list_relations.gui_primary .gui_relations_pod,#gui .gui_module_large-list.gui_large-list_relations.gui_primary .gui_relations_pod .gui_subtext,#gui #gui_sub .gui_module_large-list.gui_large-list_team.gui_primary li.gui_item,#gui .gui_module_generic.gui_generic_pros-cons.gui_primary .pros,#gui .gui_module_generic.gui_generic_pros-cons.gui_primary .cons,#gui .gui_primary_bg,#gui .gui_module_large-list.gui_large-list_simple.gui_primary li.gui_item,#gui .gui_module_large-list.gui_large-list_default .gui_slider .gui_pager > .gui_expander > ul > li.cycle-pager-active,#gui .gui_module_large-list.gui_large-list_slider .gui_slider .gui_pager > .gui_expander > ul > li.slick-active,#gui .gui_module_large-list.gui_large-list_default.gui_primary  .gui_item .gui_module,#gui .ui-dialog .ui-dialog-titlebar,#gui .gui_module_nav.gui_nav_header li[data-gui-nav-depth="0"]:hover:before,#gui .gui_module_nav.gui_nav_header .sub-menu,#gui .gui_module_nav.gui_nav_header.gui_primary li[data-gui-nav-depth="0"]:hover:before,#gui .gui_module_nav.gui_nav_header.gui_primary .sub-menu,#gui .gui_module_nav.gui_nav_mobile-menu .gui_list-holder ul li,#gui .gui_module_nav.gui_nav_mobile-menu.gui_primary .gui_list-holder ul li,#gui .gui_li.gui_primary_bg:before,#gui .ui-datepicker table tbody tr td.ui-datepicker-current-day,#gui .gui_module_form .gf_progressbar_wrapper .gf_progressbar_percentage,#gui .gui_module_nav.gui_nav_header.gui_primary li.current-menu-item[data-gui-nav-depth="0"]:before, #gui .gui_module_nav.gui_nav_header.gui_primary li.current-menu-ancestor[data-gui-nav-depth="0"]:before,#gui #gui_sub .gui_module_cta.gui_cta_spotlight.gui_spotlight_style_boxed-content .gui_body > .gui_expander:before,#gui #gui_sub .gui_module_cta.gui_cta_spotlight.gui_spotlight_style_boxed-content.gui_primary .gui_body > .gui_expander:before,#gui #gui_sub .gui_module_callout.gui_callout_generic.gui_primary .gui_body .gui_title-holder,#gui #gui_sub .gui_module_callout.gui_callout_generic.gui_primary .gui_body .gui_text-holder,#gui #gui_sub .gui_module_callout.gui_callout_generic.gui_primary .gui_body .gui_custom-holder,#gui .gui_module_callout.gui_callout_standalone-image-top.gui_primary .gui_body .gui_title-holder:before,#gui #gui_sub .gui_module_callout.gui_callout_standalone-image-top.gui_primary .gui_body .gui_title-holder,#gui #gui_sub .gui_module_callout.gui_callout_standalone-image-top.gui_primary .gui_body .gui_text-holder,#gui #gui_sub .gui_module_callout.gui_callout_standalone-image-top.gui_primary .gui_body .gui_custom-holder,#gui .gui_module_callout.gui_callout_standalone-image-bottom.gui_primary .gui_body .gui_text-holder:before,#gui #gui_sub .gui_module_callout.gui_callout_standalone-image-bottom.gui_primary .gui_body .gui_title-holder,#gui #gui_sub .gui_module_callout.gui_callout_standalone-image-bottom.gui_primary .gui_body .gui_text-holder,#gui #gui_sub .gui_module_callout.gui_callout_standalone-image-bottom.gui_primary .gui_body .gui_custom-holder,#gui #gui_sub .gui_module_large-list.gui_large-list_default .gui_item:hover .gui_module,#gui .gui_module_accordion.gui_primary .gui_accordion_head,#gui .gui_module_tabs.gui_tabs_filled .gui_tabs_head ul li,#gui .gui_module_tabs.gui_tabs_filled.gui_primary .gui_tabs_head ul li,#gui #gui_sub .gui_module_large-list.gui_large-list_image-overlay.gui_primary li.gui_item .gui_img-holder:after,#gui #gui_sub .gui_module_large-list.gui_large-list_title-overlay.gui_primary li.gui_item .gui_title-holder,#gui #gui_sub .gui_list_location li,#gui .daterangepicker td.start-date, #gui .daterangepicker td.start-date:hover,#gui .daterangepicker td.active.end-date, #gui .daterangepicker td.active.end-date:hover,#gui .daterangepicker .drp-buttons .applyBtn,#gui #gui_sub .gui_module_cta.gui_cta_spotlight.gui_spotlight_style_50-50 .gui_body > .gui_expander:before,#gui #gui_sub .gui_module_cta.gui_cta_spotlight.gui_spotlight_style_50-50.gui_primary .gui_body > .gui_expander:before,#gui .gui_module_large-list.gui_large-list_side-by-side.gui_primary li.gui_item > .gui_expander',
                    ],
                ],

            ]);

[contactjavas]

Hi @scottstanford , thanks for posting the issue :)

Would it be possible if you update your Kirki to v4.0.18? I've tested your code (with some adjustment) and the result is:

• background-color property works but not the color property..
• and then I tested the color property using simple code, and it works.

Download link: v4.0.18

Thank you :)

[scottstanford]

Hi @contactjavas I have tried with the download specified, still no joy and no errors showing in the console.

Strangely, with v4.0.18, despite the option being stored in the wp_options table, only the defaults set are showing (whether testing in the customizer or viewing the actual pages).

Would you be able to share your revised config so that I can test the same from my setup please?

[mapsteps]

Kirki 4 is no longer making use of a config. option_type and option_name must now be passed on a per-control basis like so:

new \Kirki\Field\Checkbox(
	[
		'settings'    => 'checkbox_setting',
		'option_type' => 'your_option_type',
		'option_name' => 'your_option_name',
		'label'       => esc_html__( 'Checkbox Control', 'kirki' ),
		'description' => esc_html__( 'Description', 'kirki' ),
		'section'     => 'section_id',
		'default'     => true,
	]
);

[mapsteps]

Reference - https://kirki.org/docs/setup/config/

[scottstanford]

Thanks @MapSteps for the response - not sure the documentation is entirely clear having looked at https://kirki.org/docs/arguments/option_name/ - it still references that you can use a config

If I include an option name on each field, how do I ensure that they are saved in a single item in wp_options (vs many rows being added to this table)?

[JiveDig]

@scottstanford I'm doing the same. It seems that this is the way that it does put it in a single option. David's example above will get your value via $your_option_name['checkbox_setting'].

[JiveDig]

Nope. Just tested, it seems the option_name forces the saving in 2 places. I get a separate row for the option_name and also an item in my main option.

It looks like I need to do this:

new \Kirki\Field\Checkbox(
	[
		'settings'    => 'your_option_name[checkbox_setting]'
		'option_type' => 'option',
		'label'       => esc_html__( 'Checkbox Control', 'kirki' ),
		'description' => esc_html__( 'Description', 'kirki' ),
		'section'     => 'section_id',
		'default'     => true,
	]
);

[mapsteps]

@scottstanford, the docs are not updated 100% yet but we are on it.

Can you please try and reproduce the issue in v4 & post the entire sample code here again?

@JiveDig, I'm going to do some more testing here on how things are saved if options are used. I think we had this sorted earlier but I need to look back into this.

[mapsteps]

Okay so if I use the same option_name across different options, things will be saved in a single database entry.

new \Kirki\Field\Color(
	[
		'option_type' => 'option',
		'option_name' => 'option_one',
		'settings'    => 'kirki_demo_color_hex',
		'label'       => __( 'Hex-Only Color Picker', 'kirki' ),
		'section'     => 'color_section',
		'transport'   => 'postMessage',
		'default'     => '#0008DC',
	]
);

new \Kirki\Field\Color(
	[
		'option_type' => 'option',
		'option_name' => 'option_one',
		'settings'    => 'kirki_demo_color_alpha',
		'label'       => __( 'Color Picker with Alpha Channel', 'kirki' ),
		'section'     => 'color_section',
		'transport'   => 'postMessage',
		'choices'     => [
			'alpha' => true,
		],
	]
);

new \Kirki\Field\Color(
	[
		'option_type' => 'option',
		'option_name' => 'option_two',
		'settings'    => 'kirki_demo_color_hue',
		'label'       => __( 'Hue-Only Color Picker', 'kirki' ),
		'section'     => 'color_section',
		'transport'   => 'postMessage',
		'default'     => 160,
		'mode'        => 'hue',
	]
);

[mapsteps]

[scottstanford]

Hi all, thanks for so many jumping in on this issue!

@MapSteps - just to check with you on this one (and to confirm this is the correct usage). I am already using v4 as suggested.

If you put the 'option_name' on each field as the same name (as opposed to once on the main config), this will store in the DB as a single serialised entry? Is that the intended behaviour -> I am more than happy to update my setup to reflect this, but there are 4000 lines, so just want to ensure I don't have to revert/change this at a later stage.

Also I notice that your examples include calling Kirki via new \Kirki\Field\XXXX vs Kirki::add_field

Is the Kirki::add_field approach not recommended/due to be deprecated? Again want to refactor my code as few times as possible as there is a lot!

[mapsteps]

Hey @scottstanford,

I've just updated the docs on this :) https://kirki.org/docs/arguments/option_type/

Yes, if they share the same option_name, they will be saved under one single option in the database - just as per my screenshot above.

Kirki::add_field is deprecated. While v4 is backwards compatible, fields should be registered like this:

new \Kirki\Field\Color(
	[
		'settings'    => 'kirki_demo_color_hue',
		'label'       => __( 'Hue-Only Color Picker', 'kirki' ),
		'section'     => 'color_section',
		'transport'   => 'postMessage',
		'default'     => 160,
		'mode'        => 'hue',
	]
);

[JiveDig]

There are a couple scenarios that I'm wondering will still cause issues.

1. When fields are registered to the same option name but on different hooks or priories, eg init, after_setup_theme, etc.

2. Other fields are registered to different option names or remain as theme_mods.

I'll try to test these today.

[mapsteps]

Hi @scottstanford,

I'm just checking if the original issue on here got fixed or if there are still things you want us to look into?

[scottstanford]

Howdy @MapSteps apologies have been away from screens for a short period.

Using 4.0.2 - I am still encountering issues with the option_name/option_type=>option approach

I have updated my code to remove the config, and have applied the new method for creating fields.

It does not seem to be consistent with which field(s) are saved under the single option vs those which are saved under their own unique options (despite all sharing the same option name)

For now I have had to revert to using theme mods (as this approach seems to work without issue), although due to my setup I would prefer to use option if available and working.

You'll see that for each field there is a commented out line(s) /'capability'=>'edit_theme_options','option_type'=>'option','option_name'=>'gui_kirki_array',/

In case you want to quickly find and replace/switch on the option instead.

Please see paste below for the full code set in use:

https://pastebin.com/zr9xTXdd

[mapsteps]

Hey @scottstanford,

thanks. I've tried to replicate this using your code but a lot of functions are missing that seem required for the code to work.

If you get the chance, can you narrow it down to a few controls where this behaviour occurs? That would be great!

Thank you.

[contactjavas]

Hi @scottstanford :) Could you please try to update Kirki to v4..0.22? Let us know if you're still facing the issue.

Thanks

[scottstanford]

Thanks @contactjavas just upgrading now to 4.0.22 and the options seem to be working! Thanks so much for the support there.

There is a small issue when using the typography field with a JS error due to incorrect mimetype matching for CSS (the request for the googleapis fonts needs to be CSS but is returned as text/html). To note this issue only occurs with the customizer/live editing, but works correctly when the template is using it on page load

[scottstanford]

Hi all, sorry to be a nuisance but this issue persists in v4.0.24 (i.e. transport auto does not work when the option_type => option and values are stored under a single array)

Anyone experiencing the same, or either know the cause of the issue/a fix around the same?