Skip to content
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

Closed
wants to merge 10 commits into from

Conversation

earnjam
Copy link
Contributor

@earnjam earnjam commented Aug 2, 2018

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 for date_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.
screen shot 2018-08-02 at 11 06 58 am

Fixed version. When no date has been set, it shows "Immediately" instead.
screen shot 2018-08-02 at 11 07 43 am

Types of changes

Filters the REST API response to check the post for a post_date_gmt value of 0000-00-00 00:00:00 and sets date_gmt value to null if so
Bug fix on PostScheduleLabel component

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@earnjam earnjam changed the title Show I Show "Publish: Immediately" as date for new drafts without a date Aug 2, 2018
@earnjam earnjam added the REST API Interaction Related to REST API label Aug 2, 2018
@earnjam
Copy link
Contributor Author

earnjam commented Aug 3, 2018

I'm having second thoughts about this method, as modifying the response here might break back compatibility.

An alternative proposed to core is a date_floating flag.

The other possibility is to check if the date and modified values are identical on a draft or auto-draft. They should likely only be identical when a true post date hasn't been set yet, but that feels like a potentially invalid assumption (though with very low risk if wrong)

@earnjam earnjam added the [Status] In Progress Tracking issues with work in progress label Aug 4, 2018
@earnjam
Copy link
Contributor Author

earnjam commented Aug 6, 2018

Updated to use a date_floating flag on the REST API response based on discussions on https://core.trac.wordpress.org/ticket/39953

@earnjam earnjam removed the [Status] In Progress Tracking issues with work in progress label Aug 6, 2018
Copy link
Contributor

@desrosj desrosj left a 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 proper WP_Post object.

@earnjam
Copy link
Contributor Author

earnjam commented Aug 6, 2018

Removed the closure, wasn't thinking there. 🙈

The get_callback function can take a parameter that is an array of values of the post in the REST API response. I used that to pass an ID to the get_post() call. That seems safer because if there isn't a post with that ID, then it would have erred out before it got to that point.

Quick Summary

Posts that have a status of draft or auto-draft and do not have a date explicitly set by the user, have a date that is considered floating. Essentially this means a true post date hasn't been set, and will either be set automatically when the post is published or can be set manually by the user. When the date is floating, we should be showing "Publish: Immediately" instead of a date that may not be accurate once published.

WordPress core traditionally uses a saved value of 0000-00-00 00:00:00 for post_date_gmt to determine if the post has a floating date.

About 18 months ago, we added a shim to force the REST API to return a value for the date_gmt because its easier to work with than the localized date. See https://core.trac.wordpress.org/changeset/40108

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 date_floating flag is the best solution for backwards compatibility. That's what I've done here.

@earnjam earnjam added the Core REST API Task Task for Core REST API efforts label Aug 6, 2018
@earnjam
Copy link
Contributor Author

earnjam commented Aug 7, 2018

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

@earnjam earnjam requested a review from desrosj August 7, 2018 15:45
@earnjam
Copy link
Contributor Author

earnjam commented Aug 7, 2018

@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.

@danielbachhuber
Copy link
Member

When you have a minute, can I get your thoughts on this approach

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.

@danielbachhuber danielbachhuber self-assigned this Aug 7, 2018
@earnjam
Copy link
Contributor Author

earnjam commented Aug 7, 2018

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' ) );
Copy link
Member

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?

Copy link
Member

@danielbachhuber danielbachhuber left a 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?

@danielbachhuber danielbachhuber added the [Status] In Progress Tracking issues with work in progress label Aug 17, 2018
@kadamwhite
Copy link
Contributor

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 PostScheduleLabel component accordingly. I have proposed a small patch for the Gutenberg side of things in that ticket, which I will prepare as a separate PR.

@kadamwhite
Copy link
Contributor

I propose #9967 as an alternative approach which should supersede this PR.

tofumatt added a commit that referenced this pull request Sep 26, 2018
* Close #7195
* Close #8395
* Close #9030
* Close #9967
* Fix #10182
@earnjam
Copy link
Contributor Author

earnjam commented Sep 26, 2018

Closing this in favor of #9967

@earnjam earnjam closed this Sep 26, 2018
@earnjam earnjam removed the [Status] In Progress Tracking issues with work in progress label Sep 26, 2018
@earnjam earnjam deleted the fix/7195-floating-publish-date-label branch September 26, 2018 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core REST API Task Task for Core REST API efforts REST API Interaction Related to REST API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants