Opened 4 years ago
Last modified 4 years ago
#50730 new defect (bug)
_wpCustomizeSettings has invalid data for starter-content widgets
Reported by: | alshakero | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Customize | Keywords: | has-patch 2nd-opinion reporter-feedback |
Focuses: | Cc: |
Description
Copying from https://github.com/WordPress/gutenberg/issues/20827.
When Gutenberg is installed, and a site is set to "fresh", error messages are shown in the customizer for widgets included in a theme's starter content. The site with the starter content can not be published until the widgets are edited. In my tests, changing the widget title or content removed the error.
It does not seem to be theme dependent, I tested different themes that includes starter content. It's reproducible on 5.4.2.
To reproduce
Steps to reproduce the behavior:
- Create a new WordPress site or reset an existing install
- Activate Gutenberg
- Activate a theme with starter content, for example Twenty Twenty or Twenty Seventeen.
- Go to the Customizer.
- Press Publish
- See the error: Unable to save due to 2 invalid settings.
Expected behavior
I expect the starter content to be saved without errors.
Additional info
I investigated the forementioned GitHub issue and it seems that _wpCustomizeSettings
has invalid widget data when customizer is used on a fresh site with starter content. By invalid, I mean it fails the check in this line.
I'll send a PR on GitHub.
Change History (8)
This ticket was mentioned in PR #425 on WordPress/wordpress-develop by alshakero.
4 years ago
#1
#2
@
4 years ago
- Keywords needs-testing added; 2nd-opinion removed
- Milestone changed from Awaiting Review to 5.6
- Version 5.4.2 deleted
Hi @alshakero, and welcome to WordPress Trac! Thanks for the ticket and for the PR. This will definitely need some testing. As you say, there might be more going on to cause the problem.
I'll add this ticket to the 5.6 milestone so we can try to get some more eyes on it and assist with block editor integration.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#5
@
4 years ago
I would love if somebody with a better understanding of the customizer's internals could take a look at this for 5.6. I also agree with the assessment that there's something deeper going on here and we shouldn't paper over it.
However, I think it's okay if we do need to punt it after all because fresh site + activating Gutenberg isn't the most common scenario as far as I know (happy to be given data showing that I'm wrong), and there aren't going to be block widgets in 5.6 now.
#6
@
4 years ago
- Keywords reporter-feedback added; needs-testing removed
I reset my environment using wp db reset
and followed the provided steps against trunk
and wasn't able to see any error after clicking Publish. @alshakero: Are you still seeing this bug in WP 5.6 beta 3?
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#8
@
4 years ago
- Milestone changed from 5.6 to Awaiting Review
As this ticket is awaiting reporter-feedback
, moving it out of the 5.6 milestone and back to Awaiting Review
.
If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.
Hi there!
#### The issue
I explain the issue thoroughly in the Trac ticket.
#### The proposed solution
I'm not entirely confident about this solution. But it does fix the issue. I think that it's masking a deeper problem that I can't put my finger on.
To hydrate the client state, the server echos a JavaScript object that has all the state that the Customizer needs to render. Part of this state is the widgets state, and it seems to be invalid when the site is fresh and the starter content is rendered. The JS object I mention is shaped like a map of
setting_id => setting_value
. When you try to publish the site, this same data is sent back to the server, and it fails the check in `validate_setting_values`.My proposed solution is to call
sanitize_widget_js_instance
on the data before echoing it to the browser. So that it's valid when it is sent back on save. This satisfies the `validate_setting_values` and all works as expected.My gut feeling is that
$setting->js_value()
should return an already valid value. But I couldn't find where$setting->js_value()
gets its information from to fix that.This fix, if invalid, I think it would still be of some help to the next person.
Trac ticket: https://core.trac.wordpress.org/ticket/50730