Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #39953, comment 11


Ignore:
Timestamp:
08/16/2018 05:22:53 PM (6 years ago)
Author:
mnelson4
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #39953, comment 11

    initial v1  
    88-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.
    99
    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.
    1111
    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`).
    1313
    1414== The possible solutions, and their PROs/CONs:
    1515
    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.
    1717
    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 drafts
     18-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
    1919
    2020-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.
    2121
    2222== 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.
     23It 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.