Make WordPress Core

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#30280 closed defect (bug) (fixed)

Clearing color in customizer not working

Reported by: sidati's profile sidati Owned by: westonruter's profile westonruter
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.5
Component: Customize Keywords: has-patch needs-testing commit
Focuses: javascript Cc:

Description

HI,
When i set a color using color picker for background for example, it work, but if i clear the color using "clear" button or by deleting the color value the customizer keep the last color or get the default color where i want it to be transparent and because there's no HEX code for transparency, making a background transparent became impossible.

I believe the problem is in :

Wp-includes/class-wp-customize-setting.php - line 440

When the value is "null", the multidimensional_replace() function return the original value which is the default value or the last value.

Attachments (1)

30280.patch (276 bytes) - added by stevehenty 8 years ago.

Download all attachments as: .zip

Change History (12)

#1 @sidati
9 years ago

If we can just delete theses lines :

wp-includes/class-wp-customize-setting.php - line 440
if ( ! isset( $value ) )
    return $root;
elseif ( empty( $keys ) ) // If there are no keys, we're replacing the root.
    return $value;

and replace it with :

if ( empty( $keys ) ) // If there are no keys, we're replacing the root.
     return $value;

so we can save any value entered even the "null" value, about the rest of the function it looks confusing for me, why calculating the $result variable if we gonna return the $root anyway ?!

	final protected function multidimensional_replace( $root, $keys, $value ) {
		if ( ! isset( $value ) )
			return $root;
		elseif ( empty( $keys ) ) // If there are no keys, we're replacing the root.
			return $value;

		$result = $this->multidimensional( $root, $keys, true );

		if ( isset( $result ) )
			$result['node'][ $result['key'] ] = $value;

               //---------------------- SOMETHING MISSING HERE --------------------//

		return $root;
	}
Last edited 9 years ago by sidati (previous) (diff)

#2 follow-up: @westonruter
9 years ago

Thanks for the report, sidati.

I don't think the problem is related to changing the value to null. If you look at the wp.customize.Value.set() method:

// Bail if the sanitized value is null or unchanged.
if ( null === to || this._value === to )
    return this;

So you can't actually set a value to being null. And if you look at the ColorControl you can see that the clear method doesn't set the setting's value to null but to false:

control.setting.set( false );

#3 in reply to: ↑ 2 @sidati
9 years ago

Replying to westonruter,
What i'm saying is the problem is in the PHP code not JS, cause when i comment the lines where the root variable returned where no value entered (null), it works for null value but also affect other customizer functions, i think the same function is used by other functions in a different ways O.o

	/*if ( ! isset( $value ) )
		return $root;
	else*/if ( empty( $keys ) ) // If there are no keys, we're replacing the root.
		return $value;

I know its not good idea for others settings where it have to be a value but for the Color settings i believe we need to consider the empty (transparent) value.

To demonstrate the problem, go the customizer and set a color for a background and try to make it transparent by clearing or deleting the HEX color code, and you'll see that you're stuck with the color and it will be no transparency forever for that bloc/section :(

Last edited 9 years ago by sidati (previous) (diff)

#4 @westonruter
9 years ago

Here's what I see when I try to remove the color by emptying out the HEX color: https://cloudup.com/cIs0tJ3ZMRq

I am testing on trunk. You can see that it does remove the color, but only when you click out of the HEX input box, and then when you return to edit the control it gets populated with "false". Basically, the color picker is not currently designed to support transparent values. I think this is the underlying problem.

#5 @sidati
9 years ago

Thre's no problem about the live preview, JS works great but try to change the background color and SAVE then clear the color and save it again and refresh the customizer page and you'll see that the background keeps the last color and didn't save the empty/false value :(

@stevehenty
8 years ago

#6 @stevehenty
8 years ago

  • Keywords has-patch added

The 'clear' button appears when the default value of the setting is empty. When the 'clear' button is clicked the first time it displays 'false'. A second click clears the input correctly but the saved/previewed value reverts to the previous value instead of saving as an empty string. Forcing the value to an empty string instead of false in customize-controls.js solves both these issues - see patch.

#7 @westonruter
8 years ago

  • Focuses javascript added
  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 4.4
  • Owner set to westonruter
  • Status changed from new to accepted
  • Version changed from 4.0 to 3.5

@stevehenty Great catch! I tested it and it seems to work as advertised. Thanks for sharing how to make the Clear button appear.

@sidati Can you verify that this fixes the issue for you?

This ticket was mentioned in Slack in #core by sergey. View the logs.


8 years ago

#9 @SergeyBiryukov
8 years ago

  • Keywords commit added

#10 @westonruter
8 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 33938:

Customize: Fix clearing of a color control's setting by using proper empty value.

Props stevehenty.
Fixes #30280.

#11 @sidati
8 years ago

Now everything is good, it takes 9 months :P but at least its fixed now forever.
Thank you guys @stevehenty and @westonruter

Last edited 8 years ago by sidati (previous) (diff)
Note: See TracTickets for help on using tickets.