Changes between Version 1 and Version 5 of Ticket #31436
- 04/29/15 09:22:17 (2 years ago)
- Property Owner set to westonruter
- Property Status changed from new to accepted
- Property Milestone changed from Future Release to 4.3
v1 v5 5 5 This also should apply when a setting is modified by some means other than the Customizer: if someone is in the Customizer and another user changes a setting via an admin page or via XML-RPC or REST API, then this setting update should also be illustrated in the Customizer to note that the settings are stale and should be refreshed. This refresh could be done inline, without having to reload the entire page. 6 6 7 Another special consideration needs to be made for Widgets in the Customizer. 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. 8 9 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. 7 For the issue of conflicting auto-incremented widget IDs across user sessions, see #32183. 10 8 11 9 Some enhancements for a feature plugin: The Customizer UI would benefit from having a list of users currently in the Customizer appearing somewhere, with a list of the changes each user has made. If someone left their Customizer session open, this list would also allow an administrator to sign the user out, using something like the [https://wordpress.org/plugins/user-session-control/ User Session Control] plugin; or the Customizer UI could provide a way to boot a user from the Customizer.