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

Implement control and preview for post_date #56

Closed
westonruter opened this Issue Mar 10, 2016 · 20 comments

Comments

Projects
None yet
5 participants
@westonruter
Contributor

westonruter commented Mar 10, 2016

To start, this can be a simple text field containing the date. For specifics regarding the UI, see #53.

Care will need to be taken when modifying the date time so that the post will continue to appear in the preview when the date is in the future. Also, it would seem logical that changing the date should result in the order of the posts changing in the preview.

There may need to be a partial registered for the display of a post date. If not, then the entire content part will need to be refreshed (#36).

@aristath

This comment has been minimized.

Show comment
Hide comment
@aristath

aristath Mar 10, 2016

We could also use jquery-ui-datepicker since WP already includes it... of course we'll have to theme it and make it flat like the rest of the customizer

aristath commented Mar 10, 2016

We could also use jquery-ui-datepicker since WP already includes it... of course we'll have to theme it and make it flat like the rest of the customizer

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 10, 2016

Contributor

There is this: https://github.com/xwp/wp-jquery-ui-datepicker-skins

However, a problem is that there is no time selection as part of the date picker.

Contributor

westonruter commented Mar 10, 2016

There is this: https://github.com/xwp/wp-jquery-ui-datepicker-skins

However, a problem is that there is no time selection as part of the date picker.

@westonruter westonruter added the control label Mar 10, 2016

@aristath

This comment has been minimized.

Show comment
Hide comment
@aristath

aristath Mar 10, 2016

nice! I hadn't seen those styles...
How about something like this? http://jsfiddle.net/arunu/5qkt8e06/
both date &time combined.

aristath commented Mar 10, 2016

nice! I hadn't seen those styles...
How about something like this? http://jsfiddle.net/arunu/5qkt8e06/
both date &time combined.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 11, 2016

Contributor

Yeah, that could work. It would need to validate that the time is in the valid format, and it would also need to keep track of the time that was set before the update to prevent clobbering it with each change to the date.

Contributor

westonruter commented Mar 11, 2016

Yeah, that could work. It would need to validate that the time is in the valid format, and it would also need to keep track of the time that was set before the update to prevent clobbering it with each change to the date.

@aristath

This comment has been minimized.

Show comment
Hide comment
@aristath

aristath Mar 26, 2016

I started working on a datetime control for the customizer.
I got the datepicker to work fine, no issues there.
Now the dilemma is this:
Should we have both date & time in the same input element?
Or would it be better to have an input for the date and then a separate input element for the time?

If we have them both in the same input field, the result will be similar to http://jsfiddle.net/arunu/5qkt8e06/
pros: easier to develop
cons: not that pretty, harder to sanitize.

If we have them as 2 separate fields, we can use the datepicker for the date, and then next to it or below it have a smaller textfield to select the time.
We can even use jQuery spinner (also included in WP Core) and do something like this: https://jqueryui.com/spinner/#time
We can then sanitize/validate their values separately via JS and then combine them the way we want them internally from the control's JS.
pros: easier to sanitize, prettier
cons: harder to develop but if we want it I'd be more than happy to do it. I'm halfway there anyway...

Thoughts?

aristath commented Mar 26, 2016

I started working on a datetime control for the customizer.
I got the datepicker to work fine, no issues there.
Now the dilemma is this:
Should we have both date & time in the same input element?
Or would it be better to have an input for the date and then a separate input element for the time?

If we have them both in the same input field, the result will be similar to http://jsfiddle.net/arunu/5qkt8e06/
pros: easier to develop
cons: not that pretty, harder to sanitize.

If we have them as 2 separate fields, we can use the datepicker for the date, and then next to it or below it have a smaller textfield to select the time.
We can even use jQuery spinner (also included in WP Core) and do something like this: https://jqueryui.com/spinner/#time
We can then sanitize/validate their values separately via JS and then combine them the way we want them internally from the control's JS.
pros: easier to sanitize, prettier
cons: harder to develop but if we want it I'd be more than happy to do it. I'm halfway there anyway...

Thoughts?

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 28, 2016

Contributor

I really like it when the date and time are in the same input field for one big reason: pasteability. It is annoying to have a date/time that you try to copy/paste but have to enter each separate date/time component separately. I think ideally you could just paste in any datetime string into the text field and it would get parsed and re-formatted in the standard format on change. I've done this before where I have an input field that has a datetime that gets submitted to the server and it is then read-in via PHP's strtotime(). This makes it nice to enter a string like +1 minute. True, this would be a power user feature. We also should be fully parsing the datetime strings in JS without any server-side round trips.

Contributor

westonruter commented Mar 28, 2016

I really like it when the date and time are in the same input field for one big reason: pasteability. It is annoying to have a date/time that you try to copy/paste but have to enter each separate date/time component separately. I think ideally you could just paste in any datetime string into the text field and it would get parsed and re-formatted in the standard format on change. I've done this before where I have an input field that has a datetime that gets submitted to the server and it is then read-in via PHP's strtotime(). This makes it nice to enter a string like +1 minute. True, this would be a power user feature. We also should be fully parsing the datetime strings in JS without any server-side round trips.

@aristath

This comment has been minimized.

Show comment
Hide comment
@aristath

aristath Mar 29, 2016

I really like it when the date and time are in the same input field for one big reason: pasteability. It is annoying to have a date/time that you try to copy/paste but have to enter each separate date/time component separately.

huh... I hadn't thought about pasteability... Good point.

I think ideally you could just paste in any datetime string into the text field and it would get parsed and re-formatted in the standard format on change

I suppose that's possible, but again there are 2 ways to handle this:

  • Client-side: We'd have to use JS by including a library like https://github.com/jquery/globalize (IMO WP Core should include it anyway, but I understand the need to properly screen and scrutinize everything that goes in core, so I'm thinking that perhaps not everyone would be open to an idea like that).
  • Server-side: Using PHP this is going to be pretty simpler that if we use JS. The downside is that postMessage is probably out of the question if we do that, unless we use partial refreshes for the preview.

I've done this before where I have an input field that has a datetime that gets submitted to the server and it is then read-in via PHP's strtotime(). This makes it nice to enter a string like +1 minute.

Agreed, that would be pretty awesome! but that would be easier to do using PHP that using JS

We also should be fully parsing the datetime strings in JS without any server-side round trips.

And this is where things get a bit complicated... We'd either have to write our own implementation for parsing date/time, or include something like http://momentjs.com/ or globalize.

aristath commented Mar 29, 2016

I really like it when the date and time are in the same input field for one big reason: pasteability. It is annoying to have a date/time that you try to copy/paste but have to enter each separate date/time component separately.

huh... I hadn't thought about pasteability... Good point.

I think ideally you could just paste in any datetime string into the text field and it would get parsed and re-formatted in the standard format on change

I suppose that's possible, but again there are 2 ways to handle this:

  • Client-side: We'd have to use JS by including a library like https://github.com/jquery/globalize (IMO WP Core should include it anyway, but I understand the need to properly screen and scrutinize everything that goes in core, so I'm thinking that perhaps not everyone would be open to an idea like that).
  • Server-side: Using PHP this is going to be pretty simpler that if we use JS. The downside is that postMessage is probably out of the question if we do that, unless we use partial refreshes for the preview.

I've done this before where I have an input field that has a datetime that gets submitted to the server and it is then read-in via PHP's strtotime(). This makes it nice to enter a string like +1 minute.

Agreed, that would be pretty awesome! but that would be easier to do using PHP that using JS

We also should be fully parsing the datetime strings in JS without any server-side round trips.

And this is where things get a bit complicated... We'd either have to write our own implementation for parsing date/time, or include something like http://momentjs.com/ or globalize.

@valendesigns

This comment has been minimized.

Show comment
Hide comment
@valendesigns

valendesigns Mar 29, 2016

Member

Shouldn't we not reinvent the wheel here and simply use the same UI WordPress already has, which fits into our size constraints?

change-post-date-expanded

Member

valendesigns commented Mar 29, 2016

Shouldn't we not reinvent the wheel here and simply use the same UI WordPress already has, which fits into our size constraints?

change-post-date-expanded

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 29, 2016

Contributor

I really dislike the Core UI 😦 But I realize that is a subjective statement.

Contributor

westonruter commented Mar 29, 2016

I really dislike the Core UI 😦 But I realize that is a subjective statement.

@valendesigns

This comment has been minimized.

Show comment
Hide comment
@valendesigns

valendesigns Mar 29, 2016

Member

I don't like it either. However, for numerous reasons it would be much simpler to implement a consistent UI rather than baking our own.

Member

valendesigns commented Mar 29, 2016

I don't like it either. However, for numerous reasons it would be much simpler to implement a consistent UI rather than baking our own.

@aristath

This comment has been minimized.

Show comment
Hide comment
@aristath

aristath Mar 29, 2016

On the other hand, this is an opportunity to improve things... If the objective is to simply get it done then yeah, this discussion is completely unnecessary and meaningless. We can do it using a dropdown and 4 textfields like core.
But shouldn't we try to improve things? Who knows, maybe if we do it right, core will change. It's not easy, but not impossible either.
And since everyone agrees that core is ugly, change is inevitable. Maybe not now, but it will definitely happen.

aristath commented Mar 29, 2016

On the other hand, this is an opportunity to improve things... If the objective is to simply get it done then yeah, this discussion is completely unnecessary and meaningless. We can do it using a dropdown and 4 textfields like core.
But shouldn't we try to improve things? Who knows, maybe if we do it right, core will change. It's not easy, but not impossible either.
And since everyone agrees that core is ugly, change is inevitable. Maybe not now, but it will definitely happen.

@valendesigns

This comment has been minimized.

Show comment
Hide comment
@valendesigns

valendesigns Mar 29, 2016

Member

I think it's a lot of effort for a UI enhancement that has many gotchas. Shouldn't we first focus on making it work like Core before we make it pretty?

Member

valendesigns commented Mar 29, 2016

I think it's a lot of effort for a UI enhancement that has many gotchas. Shouldn't we first focus on making it work like Core before we make it pretty?

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 29, 2016

Contributor
Contributor

westonruter commented Mar 29, 2016

@valendesigns

This comment has been minimized.

Show comment
Hide comment
@valendesigns

valendesigns Mar 30, 2016

Member

I fully agree! I'm not here to end the discussion of potential paths forward, rather to focus us on making strides towards an MVP. I fully want there to be a date and time picker, I just also want to be pragmatic with what we have resources for and limit our exposure to 3rd party scripts not already in Core since historically Core does not like adding them.

Member

valendesigns commented Mar 30, 2016

I fully agree! I'm not here to end the discussion of potential paths forward, rather to focus us on making strides towards an MVP. I fully want there to be a date and time picker, I just also want to be pragmatic with what we have resources for and limit our exposure to 3rd party scripts not already in Core since historically Core does not like adding them.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 30, 2016

Contributor

So let's settle on using the Core UI for picking a date as presented on the post edit screen for the initial implementation.

How should we go about previewing? At the simplest, a preview could result in the preview reloading with the post_date/post_date_gmt overridden. This should ensure the post date appears as expected in the template. However, this isn't probably very helpful in terms of what a user would want to preview for a date change. I think normally a date is changed to cause a post to appear in a different order in a post list. That being the case, perhaps any WP_Query instances that could apply to the post should have their the_posts filtered to re-sort if the query vars would apply to the post being edited? This should result in the post being re-ordered as expected, as if MySQL had returned that ordered result. As such, implementing selective refresh seems impractical for date changes.

Contributor

westonruter commented Mar 30, 2016

So let's settle on using the Core UI for picking a date as presented on the post edit screen for the initial implementation.

How should we go about previewing? At the simplest, a preview could result in the preview reloading with the post_date/post_date_gmt overridden. This should ensure the post date appears as expected in the template. However, this isn't probably very helpful in terms of what a user would want to preview for a date change. I think normally a date is changed to cause a post to appear in a different order in a post list. That being the case, perhaps any WP_Query instances that could apply to the post should have their the_posts filtered to re-sort if the query vars would apply to the post being edited? This should result in the post being re-ordered as expected, as if MySQL had returned that ordered result. As such, implementing selective refresh seems impractical for date changes.

@valendesigns

This comment has been minimized.

Show comment
Hide comment
@valendesigns

valendesigns Mar 30, 2016

Member

That sounds very similar to what I was doing for future posts in the Customizer for News and I agree selecting refresh would be impractical here. It does require a reflow of the post order in the archive. However, we could do selective refresh in the context of a single post to update the UI only.

Member

valendesigns commented Mar 30, 2016

That sounds very similar to what I was doing for future posts in the Customizer for News and I agree selecting refresh would be impractical here. It does require a reflow of the post order in the archive. However, we could do selective refresh in the context of a single post to update the UI only.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Mar 30, 2016

Contributor

@valendesigns Great point. If is_singular() and get_queried_object_id() matches the post being edited, then a partial could be refreshed, specifically the content part identified by the post_class(), per #36.

Contributor

westonruter commented Mar 30, 2016

@valendesigns Great point. If is_singular() and get_queried_object_id() matches the post being edited, then a partial could be refreshed, specifically the content part identified by the post_class(), per #36.

@valendesigns valendesigns added this to the 1.0.0-alpha milestone Mar 30, 2016

@valendesigns valendesigns modified the milestones: 0.6, 0.5 Apr 27, 2016

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter May 18, 2016

Contributor

Implementation here is closely related to #40. Changes to the post date should trigger a full refresh.

Contributor

westonruter commented May 18, 2016

Implementation here is closely related to #40. Changes to the post date should trigger a full refresh.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter May 31, 2016

Contributor

Important to note how the post date and modified dates relate here, and in the context of inserted auto-drafts: d154e22

It may be desired that a post date for an inserted post always have NOW as the publish time, as opposed to the time that the auto-draft was created.

Contributor

westonruter commented May 31, 2016

Important to note how the post date and modified dates relate here, and in the context of inserted auto-drafts: d154e22

It may be desired that a post date for an inserted post always have NOW as the publish time, as opposed to the time that the auto-draft was created.

@valendesigns valendesigns modified the milestones: 0.7, 0.6 Jun 1, 2016

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Jun 22, 2016

Contributor

In \WP_Customize_Posts_Preview::get_post_field_partial_schema(), the post_date should be added with just 'fallback_refresh' => true

Contributor

westonruter commented Jun 22, 2016

In \WP_Customize_Posts_Preview::get_post_field_partial_schema(), the post_date should be added with just 'fallback_refresh' => true

@kienstra kienstra self-assigned this Jun 26, 2016

westonruter added a commit that referenced this issue Jul 11, 2016

@kienstra kienstra removed their assignment Jul 12, 2016

@johnregan3 johnregan3 referenced this issue Jul 25, 2016

Merged

Add post date control and preview #202

15 of 17 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment