[wp-trac] [WordPress Trac] #32474: Facilitate widgets to be stored in posts instead of options

[WordPress Trac]

#32474: Facilitate widgets to be stored in posts instead of options
------------------------------+--------------------------
 Reporter:  westonruter       |       Owner:  westonruter
     Type:  enhancement       |      Status:  closed
 Priority:  normal            |   Milestone:  4.3
Component:  Widgets           |     Version:  2.8
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch commit  |     Focuses:
------------------------------+--------------------------
Changes (by azaozz):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:20 westonruter]:

 > So yes, we could introduce filters in `WP_Widget::get_settings()` and
 `WP_Widget::save_settings()` to be able to short-circuit the normal logic
 and return `ArrayIterator` objects instead of intrinsic arrays. But other
 methods in `WP_Widget` (`_register`, `display_callback`, and
 `form_callback`) also then would have to be patched, as in this ticket's
 patch, to be compatible. And as above, this wouldn't help plugins that
 actually operate at the lower option-level.
 >
 > Instead, without introducing new filters, we can leverage the existing
 `pre_option_widget_{$id_base}` and `pre_update_option_widget_{$id_base}`
 ones.

 I meant that if core stops using options for saving the widgets data, the
 existing `pre_option_widget_*` filters will never run, so all plugins that
 use them will break. And there is no way for core to add backwards
 compatibility to prevent that breakage. Of course the authors of these
 plugins will probably update them if/when that happens, it's just that
 using low-level filters for commonly needed tasks is not a good idea :)

 > ...plugins now have the ''option'' of filtering the `widget_{$id_base}`
 options to return `ArrayIterator` objects instead of intrinsic arrays, and
 `WP_Widget` will handle them successfully.
 > ...
 > The patch is all backwards-compatible because without any plugins
 filtering `pre_option_widget_{$id_base}`, it will continue to work with
 intrinsic arrays as it always has. But then if a plugin does return
 `ArrayIterator` objects here instead, it is still backwards-compatible
 because these objects have the same interface as intrinsic arrays, as they
 are both iterables.

 Right, the patch is backwards compatible with core running only one
 plugin. However if two or more plugins use these filters, one can pass
 `ArrayIterator`, and the other (older) may not handle that successfully.

 What we are doing here is allowing the data type passed by a filter to be
 changed. So an existing plugin that uses the filter and expect simple
 array, may get `ArrayIterator` object instead.

 I agree, the chance of this happening for these filters is really low. I
 suppose we can accept the fact that some plugins will have to be updated
 to avoid conflicts with other similar plugins. Lets close this for now and
 hope any eventual incompatibilities between plugins will get resolved
 quickly.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32474#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform