Changes between Initial Version and Version 1 of Ticket #39953, comment 11
- Timestamp:
- 08/16/2018 05:22:53 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #39953, comment 11
initial v1 8 8 -https://core.trac.wordpress.org/ticket/38883 did some magic so the REST API's `date_gmt` field for drafts, which should have been `0000-00-00T00:00:00` according to the `post_date_gmt` column, is calculated to the `post_date` column plus timezone offset. Ie, in the REST API, we never show `0000-00-00T00:00:00` for draft GMT dates, we show the actual time the draft was last updated in GMT. 9 9 10 -however, it's also possible for a draft post to a scheduled date. In that case, its `post_date_gmt` column is set to a real time.10 -however, it's also possible for a draft post to a fixed date. In that case, its `post_date_gmt` column is set to a real time. 11 11 12 -that means, over the REST API, it's impossible to know if a draft post's column is `0000-00-00 00:00:00`, indicating "whenever it gets published" aka unscheduled, or if it has a scheduled date. In the REST API, they all look like they're scheduled(because none have `0000-00-00T00:00:00`).12 -that means, over the REST API, it's impossible to know if a draft post's column is `0000-00-00 00:00:00`, indicating "whenever it gets published" aka "date floating", or if it has a fixed date. In the REST API, they all look like they all have a fixed date (because none have `0000-00-00T00:00:00`). 13 13 14 14 == The possible solutions, and their PROs/CONs: 15 15 16 -leave it as-is. It's up to REST API clients to keep track of whether the draft was scheduled or unscheduled. But that only works when the REST API client created the draft. If the draft was created in the wp-admin, the REST API client has no way of knowing if it scheduled or unscheduled. But it does keep the REST API simpler.16 -leave it as-is. It's up to REST API clients to keep track of whether the draft had a floating date or a fixed one. But that only works when the REST API client created the draft. If the draft was created in the wp-admin, the REST API client has no way of knowing if has a floating date or a fixed one. But it does keep the REST API simpler. 17 17 18 -add a new field, called something like `date_floating`, which would indicate if the draft internally has a scheduled date or is unscheduled. The downside to this is it's a bit messy deciding what to do when a draft is submitted with a `date_gmt` AND `date_float=true`, because `date_floating=true` means we should totally ignore whatever is submitted for `date_gmt`. Also, this adds yet another field. Also, it's inconsistent with the database (although we're already inconsistent). But it seems backwards compatible and makes it easy to distinguish between scheduled/unscheduled drafts18 -add a new field, called something like `date_floating`, which would indicate if the draft internally has a floating date or is fixed. The downside to this is it's a bit messy deciding what to do when a draft is submitted with a `date_gmt` AND `date_float=true`, because `date_floating=true` means we should totally ignore whatever is submitted for `date_gmt`. Also, this adds yet another field. Also, it's inconsistent with the database (although we're already inconsistent). But it seems backwards compatible and makes it easy to distinguish between drafts with a floating date or a fixed date 19 19 20 20 -when requesting a post in the "edit" context, don't do the magic from https://core.trac.wordpress.org/ticket/38883 (that makes it so the REST API field `date_gmt` is calculated from the column `post_date` plus timezone offset) and instead leave `date_gmt` be null, like it was before that ticket. This is quite consistent with the database, but might be backwards incompatible for REST API clients that didn't expect `null` for `date_gmt` (I think that would be neglegible, as before https://core.trac.wordpress.org/ticket/38883 it often had `null` in it). Also, it's a bit strange having `date_gmt`'s value be dependent on the request context. 21 21 22 22 == Mike's Opinion 23 It feels like we're putting more paint over a crack in the foundation- it won't ever be pretty. But I like adding a new field or using `null` for unscheduled drafts in the `edit` context equally. Both add a bit of complexity to understanding the REST API, but provide the needed feature.23 It feels like we're putting more paint over a crack in the foundation- it won't ever be pretty. But I like adding a new field or using `null` for drafts with floating dates in the `edit` context equally. Both add a bit of complexity to understanding the REST API, but provide the needed feature.