Changes between Initial Version and Version 6 of Ticket #35574
- Timestamp:
- 01/28/2016 04:14:18 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35574
- Property Keywords needs-patch needs-unit-tests added
-
Property
Version
changed from
to
2.8
-
Property
Summary
changed from
Add default instance information to WP_Widget
toAdd schema information to WP_Widget
-
Property
Milestone
changed from
Awaiting Review
toFuture Release
-
Ticket #35574 – Description
initial v6 1 1 Widgets often have duplicated logic between the `WP_Widget::widget()`, `WP_Widget::update()`, and `WP_Widget::form()` methods for checking if a given `$instance` property has been set, and if not, supplying a default value. In some cases, these `isset` checks are ''not'' performed resulting in PHP notices if the methods are programmatically invoked with an empty array. I suggest that we introduce a `WP_Widget::$default_instance` property or `WP_Widget::get_default_instance()` method that will return the `$instance` defaults that can be merged on top of with the current `$instance`. 2 3 With the REST API, there is an emerging-established way in WordPress for describing a data structure, such as a widget instance. One aspect of the REST API endpoint schema is the `default` values for given fields on a property. 4 5 Widgets in WordPress are assumed to be arrays, with the applied filters and function return values. With a schema defined, the data type of a widget instance would be guaranteed. Meta in the REST API is a challenge given that it may or may not contain serialized PHP. Widgets are stored in serialized PHP arrays in WP options (though it is possible to store them in posts, per #32474). Additionally, the instance arrays may also contain PHP objects for classes that cannot be cleanly serialized into JSON, and having a REST API JSON schema defined for a widget would guarantee that a widget instance can be represented in JSON. This would, in turn, allow widgets to be exposed as [https://github.com/WP-API/WP-API/issues/19 endpoints] in the REST API, and it would allow widget instances to be completely manipulated with JavaScript (such as in the Customizer, as described in #33507). 6 7 By adding schema information to `WP_Widget`, we get a lot more than having default `$instance` data available. For one, the widget form can be automatically generated based on the schema if one is not defined (i.e. if `noform` is returned from the `WP_Widget::form()` method). (This may actually be focus of the Fields API.)