WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 5 months ago

#43003 closed defect (bug) (fixed)

HTML5 "required" attribute in Widget form() fails in ajax-actions.php during save

Reported by: Andy Schmidt Owned by: westonruter
Milestone: 4.9.3 Priority: normal
Severity: normal Version: 4.9
Component: Widgets Keywords: has-patch commit fixed-major
Focuses: Cc:

Description

If a field on a widget settings form uses the HTML5 "required" attribute, then saving the settings will only APPEAR to have "saved" the form content.

In reality, the result is:

Undefined index: widgetbaseid-nn in wp-admin\includes\ajax-actions.php on line 1998
Stack trace:
1. {main}() E:\Hosted Sites\wwwroot\wp-admin\admin-ajax.php:0
2. do_action() E:\Hosted Sites\wwwroot\wp-admin\admin-ajax.php:97
3. WP_Hook->do_action() E:\Hosted Sites\wwwroot\wp-includes\plugin.php:453
4. WP_Hook->apply_filters() E:\Hosted Sites\wwwroot\wp-includes\class-wp-hook.php:310
5. wp_ajax_save_widget() E:\Hosted Sites\wwwroot\wp-includes\class-wp-hook.php:286

Simply removing the "required" attribute from this input field, will circumvent the bug:

<?php
        <input class="widefat" type="text" required="required" id="<?php echo \esc_attr( $this->get_field_id( 'addtlfld' ) ); ?>" name="<?php echo \esc_attr( $this->get_field_name( 'addtlfld' ) ); ?>" value="<?php echo \esc_attr( $old_settings[ 'addtlfld' ] ?? '' ); ?>">

Attached is a plugin with two versions of the widget - one has regular text field, the other has the same text field but uses the "required" attribute. Uses PHP 7.1 syntax.

Attachments (4)

HTML5required.php (4.2 KB) - added by Andy Schmidt 6 months ago.
Plugin with two versions of Widget - one works, one fails.
Result when pressing SAVE.jpg (50.0 KB) - added by Andy Schmidt 5 months ago.
Result when pressing "SAVE" in Widget admin form for this instance.
43003.0.diff (665 bytes) - added by westonruter 5 months ago.
Patch applied to v491.jpg (42.0 KB) - added by Andy Schmidt 5 months ago.
Appach applied to equiv. location of 4.9.1

Download all attachments as: .zip

Change History (17)

@Andy Schmidt
6 months ago

Plugin with two versions of Widget - one works, one fails.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


5 months ago

#2 follow-up: @westonruter
5 months ago

  • Keywords reporter-feedback added
  • Milestone changed from Awaiting Review to 4.9.2
  • Version changed from 4.9.1 to 4.9

@Andy-Schmidt Support for validity constraints was added in [41352]. You can see this in:

		if ( form.prop( 'checkValidity' ) && ! form[0].checkValidity() ) {
			return;
		}

When you say it appears to save, does the Save button become disabled and the dirty state clear? Can you leave the widgets admin screen and not get prompted to save? Is it just that validity reporting isn't happening?

#3 in reply to: ↑ 2 @Andy Schmidt
5 months ago

Replying to westonruter:

When you say it appears to save, does the Save button become disabled and the dirty state clear? <<

If I can figure out how, I'll attach a screen shot what happens when you press Save (with Debug mode on so that you can see the PHP error). The "Save" button will changed to "Saved". You can click "Done" to exit the instance, and the instance will be an item in the list of widgets for that sidebar, as if it had been successfully saved.

However, if you exit the Widget section of the admin, click some other admin function and then RETURN to the Widget admin, that particular Widget instance does NOT appear in that side bar any more. So in reality it was never properly saved/tied into that sidebar.

Is it just that validity reporting isn't happening? <<

The "required" attribute seems to be active as far as HTML. The error will NOT occur as long as I try to save with a required field not yet entered. However, the moment I correctly complete the form with ALL required fields, THEN the "Save" button triggers the PHP error.

Support for validity constraints was added <<

Maybe an error was introduced when it was added. I'm producing this problem with 4.9.1!

@Andy Schmidt
5 months ago

Result when pressing "SAVE" in Widget admin form for this instance.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


5 months ago

@westonruter
5 months ago

#5 @westonruter
5 months ago

  • Keywords has-patch needs-testing added

@Andy-Schmidt please test 43003.0.diff. The problem is that when adding a new widget, the checkValidity call was being made. So this patch disables the check when adding a widget.

#6 @Andy Schmidt
5 months ago

Unfortunately, I am UNABLE to confirm. If the (equivalent) patch is applied to 4.9.1 (see screenshot of code), there is no difference in behavior. I reconfirmed (using browser network trace), that the updated Widgets.js is being served up.

Oddly though, I do NOT find Widgets.js ever having being requested by the browser? I then checked the server's HTTP logs directly - and there too I see no HTTP request for Widgets.js having occurred?

@Andy Schmidt
5 months ago

Appach applied to equiv. location of 4.9.1

#7 follow-up: @westonruter
5 months ago

@Andy-Schmidt In order to test the patch, you must add define( 'SCRIPT_DEBUG', true ); to your wp-config.php. Otherwise, the minified JS will be loaded and concatenated via load-scripts.php. That's why you're not seeing a request to widgets.php.

#8 in reply to: ↑ 7 @Andy Schmidt
5 months ago

Replying to westonruter:

@Andy-Schmidt In order to test the patch, you must add define( 'SCRIPT_DEBUG', true );

Thanks for those instructions. I've now confirmed the problem is fixed.

#9 @dd32
5 months ago

  • Milestone changed from 4.9.2 to 4.9.3

Bumping to 4.9.3 due to 4.9.2s release

#10 @westonruter
5 months ago

  • Keywords commit added; reporter-feedback needs-testing removed
  • Owner set to westonruter
  • Status changed from new to accepted

#11 @westonruter
5 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 42521:

Widgets: Prevent checkValidity from running on a form when widget is first adding to sidebar.

Amends [41352].
See #23120.
Fixes #43003 for trunk.

#12 @westonruter
5 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

#13 @westonruter
5 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 42522:

Widgets: Prevent checkValidity from running on a form when widget is first adding to sidebar.

Amends [41352].
See #23120.
Fixes #43003 for 4.9 branch.

Note: See TracTickets for help on using tickets.