Color picker fields are getting broken when selecting valid color to replace invalid color
surajkrsingh opened this issue · 3 comments
Site Health Report
Version | 4.4.0.2 |
---|---|
Installation | in_theme |
Data directory | /Users/surajsingh/Local Sites/reduxframework/app/public/wp-content/themes/twentytwentyone/redux-framework/redux-core/ |
Browser | Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36Browser: ChromeVersion: 112.0.0.0Platform: Apple |
opt_name | redux_demo |
---|---|
global_variable | redux_demo |
dev_mode | true |
ajax_save | true |
page_slug | redux_demo |
page_permissions | manage_options |
menu_type | menu |
page_parent | themes.php |
compiler | true |
output | true |
output_tag | true |
templates_path | |
extensions | Accordion: 1.0.1Custom Fonts: 2.0.0Customizer: 4.0.0Datetime: 2.0.0Google Maps: 2.0.0Import Export: 4.0.0Js Button: 2.0.0Metaboxes: 4.0.0Multi Media: 4.4.1Options Object: 4.0.0Repeater: 4.3.7Search: 3.4.5Shortcodes: 4.3.5Social Profiles: 4.3.17Users: 4.4.1Widget Areas: 1.0.0 |
Steps to reproduce
- Add 2 or more color fields
- Like this :-
Redux::set_section(
$opt_name,
array(
'title' => esc_html__( 'Color', 'your-textdomain-here' ),
'id' => 'opt-color',
'desc' => esc_html__( 'For full documentation on this field, visit: ', 'your-textdomain-here' ) . '<a href="https://devs.redux.io/core-fields/color.html" target="_blank">https://devs.redux.io/core-fields/color.html</a>',
'subsection' => true,
'fields' => array(
array(
'id' => 'opt-color-title',
'type' => 'color',
'output' => array(
'color' => '.site-title, .wp-block-site-title a',
'important' => true,
),
'title' => esc_html__( 'Site Title Color', 'your-textdomain-here' ),
'subtitle' => esc_html__( 'Pick a title color for the theme (default: #000).', 'your-textdomain-here' ),
'default' => '#000000',
'validate' => 'color',
'transparent' => false,
),
array(
'id' => 'opt-color-footer',
'type' => 'color',
'title' => esc_html__( 'Footer Background Color', 'your-textdomain-here' ),
'subtitle' => esc_html__( 'Pick a background color for the footer (default: #dd9933).', 'your-textdomain-here' ),
'default' => '#dd9933',
'validate' => 'color',
'transparent' => false,
'output' => array(
'background-color' => '.footer, #site-footer, .site-footer, footer',
),
),
),
)
);
- Make sure 2 param
validate
andtransparent
should be added as above. - Now try to test invalid color hex code like -
- Now try to update a color of any one field without updating a page.
like -
- Then you will notice that your other color picker select button is broken and that field is not working.
Please watch the video for entire scenario - https://drive.google.com/file/d/1U_WNLda1tFRaOAjauFLamJ3vu0qwn-Cx/view?usp=sharing
Expected Behavior
It shouldn't break any color picker button and it must update the number of warnings here -
Actual Behavior
Adding color validate
param for color field breaking the color button when we try to change the color from invalid to valid and save them.
Color select button text is getting updated with no of warning.
Any Error Details (PHP/JavaScript)
Getting console errors when I am trying to click on broken button
required data was not provided
Sorry, I didn't mean to close the ticket.
First, unless you have a legitimate reason to embed Redux, please don't. It's a legacy feature and causes more problems than not. It is strongly recommended to use the plugin, this way, your users get the benefits of updates, which are usually monthly.
Second, I am unable to reproduce any of this. Whether it's the embed or not, I don't know. Replicating your setup is impossible as the data was not included, along with the entire health screen. It appears the issue stems from the JavaScript revolving around Iris, the source of the WordPress color pickers. There is no line in the stack trace that originates from Redux, but clearly, there's an issue with it initializing too soon. Most times, it's because those who embed are calling Redux too early, and why the plugin is recommended. It's my best guess.
I'd try getting rid of the embed by deleting it, running the plugin, and seeing if the issue still exists.
Well, it only took me most of the day, but I finally reproduced this and fixed it. Rare use case. Never came up once in ten years. See if the v4.4.0.3 beta solves it. The notices should also close on save upon correct data.