[wp-trac] [WordPress Trac] #35574: Add REST API JSON schema information to WP_Widget

WordPress Trac noreply at wordpress.org
Wed Apr 12 00:25:58 UTC 2017


#35574: Add REST API JSON schema information to WP_Widget
------------------------------------------+-----------------------------
 Reporter:  westonruter                   |       Owner:
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Widgets                       |     Version:  2.8
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  rest-api
------------------------------------------+-----------------------------

Comment (by westonruter):

 Replying to [comment:27 rmccue]:
 > Also, I haven't mentioned this here previously, but I have in Slack: I
 am -1 on reusing JSON Schema directly for internal usage. Using JSON
 Schema ties the internal behaviour of WordPress to a single serialisation
 formation (JSON) which doesn't have the same semantics as internal PHP
 types. I would rather we design our own type system which matches our
 requirements, which has JSON Schema as an output format.

 Quoting a couple messages from Slack to follow up on this:

 [https://wordpress.slack.com/archives/C02RQC26G/p1491951427447755 From]
 @joehoyle:

 > My thoughts on this: we already do this, so I think it's actually a good
 pattern to follow. Given that we want all of this to be used on the front-
 end too (and expose the schema there for potential rendering, then I don't
 think this is "native only" thing. If anything else, I just see "JSON
 Schema" to be a standardaized naming format (and we should probably stop
 calling is JSON Schema, as noted above, we have modifications)

 And [https://wordpress.slack.com/archives/C02RQC26G/p1491956592108812
 from] me:

 > It makes sense to me. If the REST API provides a standard interface, and
 this standard interface speaks JSON as its transport protocol, then it
 makes sense to limit state data in PHP to being representable as JSON.
 Otherwise, what would have to be done is to have some kind of
 transformation layer built into the system so that the internal PHP value
 can be converted to JS and back again. Incidentally, the customizer
 actually implements the PHP-to-JS value translation in
 `WP_Customize_Setting::js_value()`, with the reverse (JS-to-PHP) being
 essentially handled by `WP_Customize_Setting::sanitize()`. It's somewhat
 awkward and is seldom used, though it did turn out to be essential to
 being able to export widget instances since they aren't currently
 guaranteed to be JSON-serializable since widgets have no schema, so the JS
 value of a widget instance is the PHP-serialized string with an HMAC to
 prevent tampering. If we can move away from having this transformation
 layer, and only pass around `JsonSerializable` values, then it would be
 much simpler to work with.

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


More information about the wp-trac mailing list