Make WordPress Core

Opened 3 months ago

Last modified 4 days ago

#50730 new defect (bug)

_wpCustomizeSettings has invalid data for starter-content widgets

Reported by: alshakero Owned by:
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-patch needs-testing 2nd-opinion
Focuses: Cc:


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:

  1. Create a new WordPress site or reset an existing install
  2. Activate Gutenberg
  3. Activate a theme with starter content, for example Twenty Twenty or Twenty Seventeen.
  4. Go to the Customizer.
  5. Press Publish
  6. 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 (5)

This ticket was mentioned in PR #425 on WordPress/wordpress-develop by alshakero.

3 months ago

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

#2 @dlh
3 months 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.

#3 @dlh
3 months ago

  • Keywords 2nd-opinion added

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

4 days ago

#5 @helen
4 days 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.

Note: See TracTickets for help on using tickets.