-
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
Add calendar block v1 #13772
Add calendar block v1 #13772
Conversation
getServerSideAttributes( attributes, date ) { | ||
return { | ||
...attributes, | ||
...this.getYearMonth( date ), |
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.
Why not set it on the server using WP functions?
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.
When the user changes the publish date, even if the post is not yet saved we want the user to see the calendar of that publish date so we need a way to pass that information to the server, that exactly what we are doing here.
The attributes month and year are never saved, they are just transient attributes used by the server side render mechanism.
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 still think it isn't a good approach. Let me explain on the post from my personal website:
https://gziolo.pl/2017/11/07/starter-kit-and-reusable-scripts/
If I visit it as of today you will see that the calendar in the sidebar renders the same month as when this post was published:
it behaves differently for the pages as it simply renders the current month:
There are also archive pages which follow the URL path:
This should also be the case when I want to edit my post in Gutenberg. That's why I suggested that we build logic on PHP side which tries the following:
- if it is a post type get the publish date from the post metadata
- if it is a page or custom CPT get the current month
@melchoyce does it make sense?
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.
Thinking a bit more about it. I'm coming to the conclusion that it might be nice to explore the following UI improvement around month and date. What if we allow the author to pick what calendar would display, some options to consider:
- inherit the post's date (this is what we have at the moment)
- use the current date
- let the author pick any date
/cc @mapk and @youknowriad for feedback
761c864
to
e25812d
Compare
Seeing a gap here where the header area doesn't totally extend the width of the block: I can't click this arrow, and with it's position + no label, I don't think it's clear what it does: It's more obvious in the date picker component because of proximity: Where are the styles coming from? Are they the default calendar widget styles? |
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.
This is looking pretty cool! 😎
Can't wait to get this in! I think Mel brought up an interesting correlation above between this block and the DatePicker component. Is it possible to get the Calendar to match the styles of the DatePicker? Also noticed I can't interact with the arrow in the calendar to switch months, and when I tried to interact with it on the frontend, it took me to a different post completely. |
d80dfa2
to
0c6309f
Compare
Hi @melchoyce, @noisysocks, and @mapk thank you for the reviews most of the points raized were addressed.
The styles are specific to this block they were created without changing the original markup using this image as referential: Unfortunately, without changing the markup, I don't think it is possible to get the arrows in the right position. I think this version is possible to achieve with the current markup: As a reference the default calendar styles look like this:
Yes, it is possible to get the same look on the editor. In that case, probably it would be worth it to use the DatePicker component directly and create a JS UI instead of relying on ServerSide render, which is probably going to be useful anyway if we want to follow more advanced use cases. I have some questions about the way calendar block should work on the frontend and what differences should exist when compared with the calendar widget. Currently, the calendar widget renders the calendar of the month the current post was published, if the widget is an archives page it renders the calendar of that month, and if it is a neutral non-date specific page (homepage, taxonomy, author) it renders the calendar of the current month. The current calendar block implementation tries to follow the same approach. The blocks show the calendar of the month associated with the post publish date. When we update the month/year of publish date, we can see on the editor the block also gets updated. If we allow the user to scroll between months what is the practical effect of the scroll? Should we start showing the calendar of the month chosen by the user instead of relying on the publish date? On the frontend of the website should the calendar also look like the DatePicker component or should different styles be used? Regarding interactivity should the frontend also be interactive? |
0c6309f
to
4a98d8a
Compare
How does the widget work, we should just do the same thing for the moment. |
That's the current state we have exactly the same thing as the calendar widget on the frontend just with some styles changes (that can be reverted). |
Ah, yes. The styles came from my mockups. 🤦♂️
If we can't change the markup, let's do either that, or the default calendar styles — they're actually not that bad. (@mapk, what do you think?) Since you can't interact with the calendar months (I forgot about that part), can we do While the default calendar behavior doesn't make much sense, I agree we should probably just stick with it for this v1. |
9b88fbb
to
98ee7fb
Compare
All points being made are good. Let's avoid any markup changes and keep the current widget interaction model. I definitely don't want this getting out of hand. But as Mel mentioned above, let's avoid any confusion in the arrows. |
Here we go 🎉 |
Yes, this is a very unfortunate side effect of using Great work @jorgefilipecosta! |
Thank you for the reviews! If someone finds any additional improvement feel free to comment and I will iterate on follow up PR's. |
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 left some more thoughts about the way we select year and month to consider for the future. I didn't see them as the blocker for the initial version of the PR. It's more my wishful thinking on how to mirror frontend and the editor :)
* @return string Returns the block content. | ||
*/ | ||
function render_block_core_calendar( $attributes ) { | ||
global $monthnum, $year, $post; |
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.
Interesting, $post
is never used. Any reason why phpcs
doesn't scream?
getServerSideAttributes( attributes, date ) { | ||
return { | ||
...attributes, | ||
...this.getYearMonth( date ), |
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 still think it isn't a good approach. Let me explain on the post from my personal website:
https://gziolo.pl/2017/11/07/starter-kit-and-reusable-scripts/
If I visit it as of today you will see that the calendar in the sidebar renders the same month as when this post was published:
it behaves differently for the pages as it simply renders the current month:
There are also archive pages which follow the URL path:
This should also be the case when I want to edit my post in Gutenberg. That's why I suggested that we build logic on PHP side which tries the following:
- if it is a post type get the publish date from the post metadata
- if it is a page or custom CPT get the current month
@melchoyce does it make sense?
The first version of the calendar block. The design tries to follow the mockup proposed.
The first version of the calendar block. The design tries to follow the mockup proposed.
Description
Closes #1462.
The first version of the calendar block.
The design tries to follow the mockup proposed but is not exactly equal as getting the desired result would need a change of markup while this version is a pure CSS solution.
If we decide to change the markup to get to the desired design I think we will not be able to use get_calendar as it is right now and the best option seems to be using a custom version of get_calendar creating a new function in core that abstracts get_calendar logic and allows both get_calendar and the version we use in this block to be created in a simple way.
We can also use current filters on get_calenger plus some regex replaces to get the markup in the desired state, but that is very hacky and probably not a long term solution.
How has this been tested?
Verify the calendar block works as expected in the editor and in the front end.
Verify that when we change the publish date month and/or year the calendar updates.
Screenshots