Undefined index: description in [...]/plugins/gutenberg/lib/widgets.php on line 98

[strarsis]

Describe the bug
Notice is shown, also obstructing the editor area.

Notice: Undefined index: description in [...]/plugins/gutenberg/lib/widgets.php on line 98

Call Stack
include( '/srv/www/web/wp/wp-admin/edit-form-blocks.php' )	.../post.php:178
apply_filters( )	.../edit-form-blocks.php:373
WP_Hook->apply_filters( )	.../plugin.php:208
gutenberg_legacy_widget_settings( )	.../class-wp-hook.php:288

To Reproduce
Steps to reproduce the behavior:

1. Open page in Gutenberg editor

Expected behavior
No notice (notices + warnings enabled on dev server).

Additional context
This appeared after updating Gutenberg to latest release (5.3.0).

[nextgenthemes]

Describe the bug

See anspress/anspress#515 but I think it might be something in GB rather then a anspress bug.

I see this when trying to edit a page (with no content on it at all). The error only appear when Gutenberg 5.3.0 plugin and anspress are active. The version of GB that comes with WP 5.1.1 does not have this problem.

I have only GB and Anspress plugins active.

WARNING: wp-admin/admin-header.php:9 - Cannot modify header information - headers already sent by (output started at /srv/www/hidden.com/current/web/app/plugins/gutenberg/lib/widgets.php:98)
include('wp-admin/edit-form-blocks.php'), require_once('wp-admin/admin-header.php'), header

NOTICE: /srv/www/hidden.com/current/web/app/plugins/gutenberg/lib/widgets.php:98 - Undefined index: description
include('wp-admin/edit-form-blocks.php'), apply_filters('block_editor_settings'), WP_Hook->apply_filters, gutenberg_legacy_widget_settings

To Reproduce
Steps to reproduce the behavior:

1. Install Anspress.
2. Install GB plugin (5.3.0)
3. Open the page edit screen.

Expected behavior
No errors. Suppressing it on production is no problem but it fucks up my debugging env.

[youknowriad]

Seems related to this PR somehow #13569 cc @aduth @jorgefilipecosta

[chapterjason]

@nextgenthemes I do not have anspress. I think it's something with GB.

I also got this issue, after update GB plugin.
Downgrade to 5.2 works. https://downloads.wordpress.org/plugin/gutenberg.5.2.0.zip

[aduth]

Seems related to this PR somehow #13569 cc @aduth @jorgefilipecosta

I suspect this line as the likely culprit:

gutenberg/lib/widgets.php

Line 98 in 9bcf036

'description' => html_entity_decode( $widget_obj->widget_options['description'] ),

Specifically the property reference $widget_obj->widget_options['description'].

This was adapted in #13569 from #13511 .

The obvious fix may be to consider isset before copying it into the new constructed array. However, I'm not entirely clear on the purpose of the new array, nor whether we should be expecting that description can be unset. I'd defer to @jorgefilipecosta on that point.

Noting also that depending on E2E coverage, this may have been discovered if something like #13452 were introduced into our test workflow.

[aduth]

whether we should be expecting that description can be unset

Based on the following, it appears that it's not guaranteed to be set:

• The implementation of core's wp_widget_description performs an isset check
• The assigned value of widget_options in WP_Widget's constructor does apply default options, but not for description

Given the availability of wp_widget_description, I'd suggest we consider using it as a safer alternative to direct property access.

[jorgefilipecosta]

Hi @strarsis, @nextgenthemes, @chapterjason thank you for sharing details about this issue, and for the referencing anspress which easily allowed me to reproduce the bug.
I'm sorry for the problems caused a fix is available at #14587 and should be merged soon.

Hi @aduth thank you for your explorations and around this problem, and the insights you provided.

Noting also that depending on E2E coverage, this may have been discovered if something like #13452 were introduced into our test workflow.

I think introducing this type of tests would be a nice improvement to our coverage, but unfortunately, I think this bug would still not be caught because we need a class widget without a description installed.

Given the availability of wp_widget_description, I'd suggest we consider using it as a safer alternative to direct property access.

Unfortunately, in this specific case, I was not able to use the function wp_widget_description. The function receives a widget id. The widget only exists for widget specific widget instances. In part of the code, we are interacting on all widget classes even if no widget instance (and id) exists at all. We need this logic because the user may have just installed a plugin, did not add/created any widget using it, but may still want to use it in a legacy widget block.