WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 2 days ago

#44975 new feature request

REST API support switching draft to unscheduled

Reported by: mnelson4 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: REST API Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Ticket #39953 allows REST API clients to send a post's date in a POST request, and either leave the post as "date floating" (draft that says 'Publish immediately') switch it to be "non-date-floating" (draft that says 'Schedule for...').

However, REST API clients cannot make a request to switch the post BACK to being "date floating" (mentioned on https://core.trac.wordpress.org/ticket/39953#comment:25 and https://core.trac.wordpress.org/ticket/39953#comment:34).

This option isn't available in WordPress' default editor either (see https://core.trac.wordpress.org/ticket/8368#comment:20). However, from my testing, WordPress.com's Calypso editor DOES allow this. Also there's a very old ticket suggesting it be added: #8368, so it seems reasonable that the REST API should support this (and maybe Gutenberg too someday).

So how should a REST API client specify they want to switch a post back to date floating (say "Publish immediately" in the classic editor)?

Should they provide a post's date set to null, false, '', or maybe even to the same value as modified? (I suggest that last one because that's how you leave a currently-"date floating" post as-is, see https://core.trac.wordpress.org/ticket/39953#comment:25)

Change History (13)

#1 @SergeyBiryukov
10 months ago

  • Description modified (diff)

#2 @jnylen0
10 months ago

  • Keywords close added

Should they provide a post's date set to null, false, '', or maybe even to the same value as modified?

No, the API and its clients should use a separate field for this purpose.

If you were writing a new piece of code today that manipulates various date values, and also has a flag to control a specific date-related behavior, independent of the actual values of the dates, would you re-use a special value of one of the date variables to control this independent and separate flag, or use a different variable?

The correct answer is a different variable. Except that in this case, the decision made will end up affecting the design and implementation of any project that uses the REST API.

This same mistake was made 10 years ago, but please don't let that confuse the issue, and please don't perpetuate the mistake further. I suggest closing this ticket as a duplicate of #39953.

#3 @mnelson4
10 months ago

No, the API and its clients should use a separate field for this purpose.

Thanks for the feedback @jnylen0 and I mostly agreed, but you can see on #39953 that there's been quite a bit of resistance to adding a new field (not from me! See https://core.trac.wordpress.org/ticket/39953#comment:16. But I'm pretty un-opinionated and just want to help find a solution most people are happy with).

I suggest closing this ticket as a duplicate of #39953.

I opened this as a branch off of that ticket (see https://core.trac.wordpress.org/ticket/39953#comment:39) so that the currently-requested part of the feature (the ability to leave posts as "date-floating") can proceed un-impeded by this related-but-IMO-separate discussion. I'm pretty sure @kadamwhite ok'd this approach: https://wordpress.slack.com/archives/C02RQC26G/p1537482913000100.

Having said that, if there's a complete reversal on #39953, and we do end up using a date_floating field, and we support this functionality using that field, then ya, we should close this ticket.

#4 @jnylen0
10 months ago

The most convincing argument against a new field that I've seen so far is "feels like we shouldn't need it".

In principle I agree, but the way WP has worked for years is different. The task is then one of choosing the least ugly solution, with a design that makes things easier for API clients and encourages them to write clean, straightforward code themselves.

#5 @kadamwhite
10 months ago

  • Keywords close removed

Respectfully, adding a field for the sole purpose of changing one piece of UI state in client interfaces is tremendous overkill. To springboard off your argument, the way WP has worked for years to my mind has been to embrace contextual solutions to historical inconsistencies, not force additional data and properties into classes, databases or API responses to perpetuate those inconsistencies. The intent of the REST API is to provide a consistent facade layer over those historical inconsistencies, not to expose those inconsistencies to clients through strange new response properties.

I do not regard this as perpetuating the mistakes of the past; I think we have already perpetuated those mistakes by returning a "false" date when a post is floating, rather than providing null in that instance. That's an inconsistency we can address with v3 of the REST API, but I hold the ship has sailed for v2, and my goal therefore is to ensure that things work as consistently and predictably as possible when consuming the existing data.

I am in favor of this ticket, and believe the appropriate response to accept to restore floating date status would be null, as that has the most explicit meaning of "unset this" in other APIs. However @danielbachhuber has requested that we validate whether we accept '' or false for unsetting values elsewhere in the API, to ensure internal consistency.

#6 @kadamwhite
10 months ago

If you were writing a new piece of code today that manipulates various date values, and also has a flag to control a specific date-related behavior, independent of the actual values of the dates, would you re-use a special value of one of the date variables to control this independent and separate flag, or use a different variable?

Put another way, as I understand the existing behavior, this argument inaccurate; the value of the date in the database, namely 0000-00-00T00:00:00, _is_ the actual value that represents date floating. The presence of that zeroed-out value is a placeholder for a specific publish date's non-existence, i.e. the state of having floating date. That state is not stored as a separate flag in the data model, and representing it as such would further confuse the situation. Better, then, to do what is proposed in this ticket, and accept a null value when writing a post, which will be converted to the zeroed-out placeholder on save.

#7 @jnylen0
9 months ago

the way WP has worked for years to my mind has been to embrace contextual solutions to historical inconsistencies

When this involves encouraging API clients to write convoluted code, that's where I stop being convinced that it's the right solution.

I originally changed the behavior of the date_gmt field in the API because posts should always have a usable UTC date field. I did that because working with UTC and possibly a timezone is the only provably correct way to handle dates, and so the date_gmt field should always mean the UTC date and nothing else.

I think we have already perpetuated those mistakes by returning a "false" date when a post is floating, rather than providing null in that instance

It's not a null date, though, because you still have the creation date of the draft. The root problem here is the lack of a clearly designed data model from the start. Some more thoughts on that here.


Anyway, I'm not going to be spending any further time on this. It's a tricky issue, and I trust y'all to come up with a solution that works.

#8 @kadamwhite
6 months ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by aldavigdis. View the logs.


4 days ago

This ticket was mentioned in Slack in #core-editor by aldavigdis. View the logs.


4 days ago

This ticket was mentioned in Slack in #core-restapi by aldavigdis. View the logs.


4 days ago

#13 @aldavigdis
2 days ago

There is a discussion about the same topic for Gutenberg over at https://github.com/WordPress/gutenberg/issues/12048. Perhaps it would be a good idea to coordinate on this and prioritise?

Note: See TracTickets for help on using tickets.