-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_gmt
will always return a properWP_Post
object.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be flagged as a read-only field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
null
value 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_gmt
value of0000-00-00 00:00:00
and setsdate_gmt
value tonull
if soBug fix on
PostScheduleLabel
componentChecklist: