#30280 closed defect (bug) (fixed)
Clearing color in customizer not working
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (12)
#2
follow-up:
↓ 3
@
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
@
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 :(
#4
@
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
@
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 :(
#6
@
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
@
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?
If we can just delete theses lines :
and replace it with :
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 ?!