#56152 closed defect (bug) (maybelater)
REST JSON schema "readonly" prop does not match capitalization of JSON Schema standard (which uses "readOnly")
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7 |
Component: | REST API | Keywords: | |
Focuses: | rest-api | Cc: |
Description
The WordPress implementation of JSON schema for the REST API supports a "readonly" prop. But in the actual JSON Schema standard, this prop is supposed to use camelCase like so: "readOnly".
https://json-schema.org/draft/2019-09/json-schema-validation.html#rfc.section.9.4
I assume the best way to fix this without breaking backwards compatibility would be to support both variants and deprecate usage of the all-lowercase one.
Change History (2)
#1
@
2 years ago
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from new to closed
- Version changed from 6.0 to 4.7
#2
@
2 years ago
I think simply supporting readOnly
would help a lot in cases where you use a 3rd-party PHP library that works with JSON schemas. For example:
I've been trying to share/standardize types between my PHP and TypeScript code in a WP plugin project I've been working on. I figured it would make the most sense to define schemas in JSON files imported in both sides of the code, using something like https://github.com/bcherny/json-schema-to-typescript ...unfortunately, WP doesn't actually use standard JSON schema, so to do something like this, you have to pass the schema through a converter.
I was hoping that between this ticket and a future solution to https://core.trac.wordpress.org/ticket/51757#comment:5, we could gradually push WP in the direction of actually complying with a subset of the JSON schema specification.
Thanks for the ticket @zebulan!
I think the only function we'd have to update in Core would be `rest_get_endpoint_args_for_schema.
One issue with moving to
readOnly
is that it means that 3rd party developers will also have to account for both variations. Since a 3rd party developer letting a field that was marked asreadOnly
instead ofreadonly
be updated could be a security or data integrity issue, I'm cautious about implementing such a change.We could potentially make sure
readonly
is also populated wheneverreadOnly
is set, but I think that detracts from the value of the change in the first place.I'm going to go ahead and closed this as "maybe later" for now. But feel free to continue discussing!