[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