WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #35669


Ignore:
Timestamp:
01/31/2016 05:02:25 AM (5 years ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35669 – Description

    initial v1  
    11Widget instances are stored in options. For a multi-widget (`WP_Widget`) the widget instances of a given type (`id_base`) are stored in a serialized array of instance arrays. A widget ID is comprised of a widget's `id_base` followed by a number which is the array index for that widget instance. For example, the third-created Text widget would have the ID `text-4` (note that multi-widget numbering starts at 2). Old single widgets do not include the numeric index after the `id_base`, and technically they could be stored anywhere (see #35656 for suggestion to deprecate old single widgets).
     2
     3== Issues
    24
    35There are several problems with how widgets are currently stored as options.
     
    57'''Scalability:''' For sites with a large number of widget instances, the entire collection of widgets must be unserialized with each request to access only one widget of a given type. (Note #23909 for how all widget instances get registered with every request.) For sites that use Memcached as an external object cache where cache buckets have a 1MB limit, since all widget instances of a given type are stored in a single option, sites with a huge number of widgets will overrun this limit. What's more is that widget options get registered as autoloaded, so all widget options will get combined together in the `alloptions` key, making widgets even more liable to overrun the 1MB cache bucket limit in Memcached.
    68
    7 '''Concurrency:''' Since all widget instances of a given type are stored in a single option, if two users attempt to update two separate widgets at the same time, it is possible that one of the updates will get lost (see #31245). Additionally, the widgets admin page and widgets in the Customizer both get loaded with the max index for each widget type. When a new widget instance is created, this maximum number is incremented in memory and used in the new widget ID which is then passed to the server for saving. If two users have loaded the UI at the same time and they both create a widget of a given type and if they both save their widget changes, the one who saves last will overwrite the other user's widget since the two widgets would have the same ID. (See #32183 for more about the widget ID collisions, and see [https://wordpress.org/plugins/customize-widgets-plus/ Customize Widgets Plus] for a “Widget Number Incrementing” component which uses Ajax to generate new widget IDs in a more concurrency-safe manner.)
     9'''Concurrency:''' Since all widget instances of a given type are stored in a single option, if two users attempt to update two separate widgets at the same time, it is possible that one of the updates will get lost (see #31245). Additionally, the widgets admin page and widgets in the Customizer both get loaded with the max number (array index) for each widget type. When a new widget instance is created, this maximum number is incremented in memory and used in the new widget ID which is then passed to the server for saving. If two users have loaded the UI at the same time, when they both create a widget of a given type and save their widget changes, the one who saves last will overwrite the other user's widget since the two widgets would have the same ID. (See #32183 for more about the widget ID collisions, and see [https://wordpress.org/plugins/customize-widgets-plus/ Customize Widgets Plus] for a “Widget Number Incrementing” component which uses Ajax to generate new widget IDs in a more concurrency-safe manner.)
    810
    911'''Addressability:''' As noted above, widget instance IDs are comprised of the widget type's `id_base` followed by the array index `number`. Two different widget instances can have the same `number`, such as `search-3` and `text-3`, since the `number` is incremented in the scope of the instances of the given type. No other objects in WordPress are identified by strings in this way, that is as of now: taxonomy terms actually used to have to be addressed by a numeric term ID and taxonomy name until term splitting happened in 4.2 (see #5809). Now, however, a term can be uniquely identified by a single integer ID.
    1012
    11 All of the above issues would be resolved by switching to store widget instances in a custom post type, where each widget instance has a single unique auto-incremented post ID. This switch would also necessitate discontinuing to register all widget instances with every request (#23909).
     13All of the above issues would be resolved by switching to store widget instances in a custom post type, where each widget instance has a single unique auto-incremented post ID.
    1214
    13 Migrating widgets from options to a custom post type would involve some tedious data migration to update all references to current `id_base-number` widget IDs to their new integer IDs. The old widget ID could actually be copied directly into the `post_name` field for the `widget_instance` posts. Backwards compatibility for the `sidebars_widgets` option containing the old-style IDs may be necessary. Newly created widget IDs could have `post_name` fields populated with the `id_base` followed by the post ID.
     15== Advantages
     16
     17Storing widgets in custom post type has several benefits beyond fixing the above issues, including:
     18
     19* widget authorship attribution
     20* revision history
     21* import/export
     22* querying
     23* widget drafts
     24* scheduled widgets
     25
     26== Data Migration
     27
     28Migrating widgets from options to a custom post type would involve some tedious data migration to update all references to current `id_base-number` widget IDs to their new integer IDs. The old widget ID could actually be copied directly into the `post_name` field for the `widget_instance` posts. Backwards compatibility for the `sidebars_widgets` option containing the old-style IDs may be necessary. Newly created widget IDs could have `post_name` fields populated with the `id_base` followed by the post ID. This switch would also necessitate discontinuing to register all widget instances with every request (#23909).
     29
     30== Sidebars and Widget Groups
    1431
    1532Perhaps out of scope for this ticket, but the way that widgets get associated with sidebars should also perhaps be changed to follow the pattern of how nav menu items are associated with a nav menu via a taxonomy term. The implementing of widget groups (#19912) could be the right opportunity to do this, where a `widget_grouping` taxonomy could be introduced, and when a grouping is assigned to a sidebar, the backwards-compatible widget IDs could be copied into the existing `sidebars_widgets` option. Otherwise, backwards compatibility might entail adding `pre_option_sidebars_widgets` filter.
    1633
     34== REST API Impacts
     35
    1736For more on widgets and now they relate to nav menu items in the context of a harmonized interface via the REST API, see https://github.com/WP-API/wp-api-menus-widgets-endpoints/issues/10