Opened 3 years ago
#54184 new defect (bug)
HTML entities get decoded in Customizer text fields
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.8.1 |
Component: | Customize | Keywords: | |
Focuses: | ui, administration, coding-standards | Cc: |
Description
Part 1
- Use
WP_Customize_Manager::add_setting()
andWP_Customize_Manager::add_control()
to create atext
setting/control with the default value©
; - Navigate to the newly added setting in the Customizer.
Expected Result
The literal text ©
is in the edit box (as specified for the default value).
Actual Result
A copyright symbol (©
) is in the edit box.
Part 2
- Enter the text
&
in the above edit box (replacing what was there); - Publish (save) settings;
- Reload the page and navigate to the setting once again.
Expected Result
The literal text &
is in the edit box (as originally entered).
Actual Result
Only a single ampersand symbol (&
) is in the edit box.
Note
Same results if the setting is given type textarea
.
Whatever is entered into text controls, or provided for a default value, should be preserved as is. The WordPress Customizer has no knowledge of how it is going to be used and should not make presumptions that it is going to be used in HTML output.
Note: See
TracTickets for help on using
tickets.