WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 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: needs-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 (5)

#1 @westonruter
2 years ago

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

#2 @tellyworth
2 years 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
2 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from 4.3 to Future Release

#4 @westonruter
2 months ago

I think this should be handled as part of storing widgets in a custom post type (#35669). When adding a new widget in the customizer, it should create an auto-draft widget post which then gets transitioned to publish when the customizer is saved. This is what was done for adding page/post stubs to the customizer, and it is also what is proposed for nav menus in #38072.

#5 @westonruter
2 months ago

  • Keywords needs-patch added; has-patch removed
Note: See TracTickets for help on using tickets.