Show "Publish: Immediately" as date for new drafts without a date#8395
Show "Publish: Immediately" as date for new drafts without a date#8395
Conversation
|
I'm having second thoughts about this method, as modifying the response here might break back compatibility. An alternative proposed to core is a The other possibility is to check if the |
|
Updated to use a |
desrosj
left a comment
There was a problem hiding this comment.
I think the addition of flag makes sense over filtering the response here. Few points:
- There is a closure being used that should become a regular function definition.
- Not sure that
get_post()->post_date_gmtwill always return a properWP_Postobject.
|
Removed the closure, wasn't thinking there. 🙈 The Quick SummaryPosts that have a status of WordPress core traditionally uses a saved value of About 18 months ago, we added a shim to force the REST API to return a value for the This essentially means there is no way to know for certain that a post has a floating date. Based on some discussions in trac ticket #39953 it seems like adding a |
|
I'm not sure why Travis won't update here. I manually re-ran the build and all checks passed: https://travis-ci.org/WordPress/gutenberg/builds/412776921 |
|
@danielbachhuber When you have a minute, can I get your thoughts on this approach since it will require a change to the REST API? See my last comment above for a quick summary and related links to trac. |
Ugh, what an awful issue. I've read the Trac ticket and will give it some thought. I think @joehoyle might be at WC Pub contributor day on Friday too. |
|
Thanks. I don't like the solution for sure, but I'm struggling to come up with a better alternative. |
| */ | ||
| function gutenberg_add_date_floating_flag() { | ||
| $post_types = get_post_types( array( 'show_in_rest' => true ), 'names' ); | ||
| register_rest_field( $post_types, 'date_floating', array( 'get_callback' => 'gutenberg_get_date_floating_flag' ) ); |
There was a problem hiding this comment.
Should this be flagged as a read-only field?
danielbachhuber
left a comment
There was a problem hiding this comment.
I don't love the date_floating attribute name, but I don't see a way around it at this point.
Could we get PHPUnit tests added for the behavior of date_floating, so we have explicit usage described?
|
Based on the most recent conversation in https://core.trac.wordpress.org/ticket/39953 I would prefer we move forward with the solution of inferring this flag when the modified date is the same as the post date, and update the |
|
I propose #9967 as an alternative approach which should supersede this PR. |
|
Closing this in favor of #9967 |
Description
This fixes the issue with the post date label discovered on #7195.
Need some feedback/discussion on the REST API portion. See my comment on #7195 for reasons on needing the modification. It's a bit hackish to use a
nullvalue fordate_gmt, but that's the way that WordPress has traditionally handled it, so it's just a continuation of that.How has this been tested?
Create a new post and look at the date label
Screenshots
Look at the publish panel on the side. This is immediately on creation of a new post right now. It sets the date the draft was first created. This is not the date that will be used when publishing.

Fixed version. When no date has been set, it shows "Immediately" instead.

Types of changes
Filters the REST API response to check the post for a
post_date_gmtvalue of0000-00-00 00:00:00and setsdate_gmtvalue tonullif soBug fix on
PostScheduleLabelcomponentChecklist: