WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 23 months ago

#32183 accepted defect (bug)

Widget ID auto-increments conflict for concurrent users

Reported by: westonruter Owned by: westonruter
Milestone: Future Release Priority: normal
Severity: normal Version: 2.8
Component: Widgets Keywords: has-patch
Focuses: Cc:

Description

Each WP_Widget 2.0 “multi-widget” gets an index number associated with each instance of a give type. When you add a widget, this number gets incremented (widget.set( 'multi_number', widget.get( 'multi_number' ) + 1 );). The initial multi-number is calculated from the next_widget_id_number() function which takes the max number currently used, and increments it by one. The same approach is used in the widgets admin page and the Widget Customizer.

For frequently-used widgets, the above problem will happen frequently where two users will try to add the same widget at the same time, and thus they will start out with the same initial multi_number, resulting in the same widget ID. When they both save their changes, one user's widget will override the other user's widget: whoever saves last. Likewise, it is possible for multiple widgets to be deleted in one session (from the widgets admin page, since Customizer only removes widgets by moving them to the Inactive Widgets sidebar) then new ones added back in other sessions and the initial multi_number will not be consistent. In other words, the multi_number for each widget type needs to be synced across each Customizer session along with the actual setting values.

For concurrent editing of widgets, see:

#31436: Handle conflicts in concurrent Customizer sessions
#12722: Concurrent editing of widgets (on admin page)

Change History (3)

#1 @westonruter
2 years ago

  • Owner set to westonruter
  • Status changed from new to accepted

#2 @tellyworth
23 months ago

One approach to solving this would be to have wp_ajax_save_widget() and (I think) WP_Customize_Widgets::wp_ajax_update_widget() check for a conflicting multi_number when add_new is set; if it is, return an incremented number, and have the controls switch to that. wp_ajax_save_widget doesn't currently return data though.

That'd make it transparent to the user, but I'm not yet sure if the broader approaches to concurrent widget editing might fix this in a general way.

Does that sound like a sane solution?

#3 @westonruter
23 months ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from 4.3 to Future Release
Note: See TracTickets for help on using tickets.