Block: Recent Posts

[jwold]

Feature description

Displays a list of the most recent posts from your site. The posts are ordered inside of cards, and have styles to change the display order.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

Adding the block

• The block can be added from the block library, and should appear under Material Blocks
• The icon should be "description" from: material.io/resources/icons
• The description for the block: Display a list of your most recent posts.
• Block preview in the block library: None

Previewing the block

• The posts will appear as cards, which default to a Masonry style, 3 columns, and text above media
• Within the block preview you may not interact with the preview, other than testing the ripple effect.
• From the block toolbar you may change the width of the block between Normal Width, Wide Width, and Full Width

Block settings

• From the block sidebar you may set the styles between Masonry, List, and Grid
• On list mode images should be cropped to square
• Columns may be adjusted from 2-4
• Content layout may be adjusted between text above media, text over media, text under media. These will adjust the placement of the headline and subtitle in relation to the post image. These variants should be matched in the web component demo. https://material-components.github.io/material-components-web-catalog/#/component/card?type=basic
• Number of posts defaults to a max of 12, and can be set as low as 1
• The block elevation can be changed from outlined to elevated The post meta settings can be enabled or disabled: post date, post content, featured image, comments count, post author. The excerpt is controlled by a slider input, with a default value of 20 words, a min of 10, and a max of 30.
• Category defaults to all, but can be changed via a select menu
• The fonts, radius, colors, and icon type can be changed from the Customizer

Prototype:

Figma link

Styles SVGs.zip

Icon description-24px.svg.zip

Implementation brief

• In JavaScript:
  • Register a new Gutenberg block called "Recent Posts" under the "material" category
  • Implement the block edit property breaking down the rendering of the block into separate components:
    • Inspector Controls for the block custom settings:
      • Block style implemented using the ImageRadioControl component (see #46) which will get an array of styles. Each style will have a src attribute which will be an SVG icon component.
      • Content settings:
        • Columns range as a RangeControl core component only visible when the style attribute value is Masonry or Grid .
        • Number of posts range as a RangeControl core component only visible when the style attribute value is Masonry or Grid.
        • Outlined toggle as a ToggleControl core component.
      • Post meta settings:
        • Post date toggle as a ToggleControl core component.
        • Post content toggle as a ToggleControl core component.
        • Max number of post content words range as a RangeControl core component, only visible when the Post content attribute is selected.
        • Feature image toggle as a ToggleControl core component.
        • Image size select as a SelectControl core component, only visible when the Feature image attribute is selected.
        • Comments count toggle as a ToggleControl core component.
        • Post author toggle as a ToggleControl core component.
      • Filtering settings (Category select) as a QueryControls. This component will have a categories list as a prop. The categories list will be fetch using the useEffect hook.
    • No posts found/ posts loading component as a Placeholder component. It will show a Spinner core component until the recents posts are being successfully fetched. If no posts are found it will show a textual information
    • Posts list component (supporting 3 layout: masonry, grid, list) and 2 single card layouts (vertical, horizontal). For the Masonry style, this component will make use of a Masonry component provided by the react-masonry-css external library. Otherwise it will be a custom component. This component will have a SinglePost custom component as a child called in a loop going through the recent posts array.
    • Augment the Edit rendering using withSelect to fetch the most recents posts.
• Implement CCS styles
• In PHP, implement a Recent Posts block class which will:
  • Register the Recent Posts block, its default settings and callback for rendering
  • Implement the backend rendering (See issue #43)
  • Add a filter to augment the response of the Posts REST API to add comment counts, post author display name and url only when the endpoint is requested in the Gutenberg editor. This will allow to fetch the extra post information in the Javascript code.

QA testing instructions

Note 1: With most of these changes you'll also want to see if the frontend is working, and not just the Gutenberg preview. It's possible there are discrepancies.

Note 2: For now we're just testing with the theme set in the staging env

Adding the block

• Add a new block

Previewing the block

• Ensure the ripple effect works as expected

• Verify that posts function in all 3 styles and all 3 content layouts with and without images

• Test against the card component to validate whether the block overall follows the card guidelines https://material.io/develop/web/components/cards/

• Ensure that the 3 styles appear as expected

• Ensure that columns work as expected

• Ensure that the width options in the block toolbar function correctly

• Ensure that each of the post meta settings appear as expected

• Test the post orders, may require adding comments to a few posts, and verifying the post publish dates

• Test whether the block changes when the font, radius, colors, and icon type are changed in the Customizer

Demo

• Video demo of i1

• Recent Posts Block Full Demo

Changelog entry

[jwold]

AC and prototype have both been updated.

[davidlonjon]

@jwold

I think that similarly to the Latest Post core block we will need a rendering for the when there are no posts found such as shown in the screenshot below from the Latest Post core block: .

Also note that while the post are fetched in the backend, instead of the "No post found" message, the Latest Post core block is showing a spinner.

[jwold]

@davidlonjon if I'm understanding correctly you need two statuses to show for this block. Please let me know if any changes are needed. Thanks!

Screenshots

Figma https://www.figma.com/file/cNKMIkWy3I0YQBZ6GpSpNG/MDC-Web?node-id=536%3A10931

Dashicon https://developer.wordpress.org/resource/dashicons/#sticky

[jwold]

@davidlonjon here are the new SVGs for the masonry/list/grid styles.

Thanks!

SVG Styles.zip

[jwold]

@davidlonjon can you write the implementation brief for this? Thanks!

[davidlonjon]

@jwold, I have now added the implementation brief

[jwold]

Great work on the demo David! Got some feedback from the team.

• Links in new window: I’m torn on this. We could definitely add an option in the block settings, but I don’t know if it’s needed for now.

• Links on frontend: In the Video David asked what actions a user could take with links on the fronted. Any buttons in action bar should go to their pages (author to author page, comments to bottom of page with comment section highlighted)

• Author and comments: In the video David asked whether these should stay in the action bar for Masonry/Grid. I agree that they should.

• List option: In the video David mentioned removing Post Content for List, I agree.

• Grid option: I’d suggest we can keep it for now, and get user feedback.

• Featured image size: There’s a new dropdown for changing the featured image size. My concern is that, since it doesn’t change the actual image dimensions, but rather selects a different image to fit within the same dimensions, that it could cause confusion. My suggestion would be to choose a smart default (perhaps a larger size for now), and then programmatically adjust based on viewport size in the future. Would love feedback on this though.

• Style of rendering: In the video David talked about the CSS styling for the block, and whether it should adhere more to the WordPress Material Theme in all cases, or whether it should adopt another theme (Twenty Twenty for example), when that theme is activated. The general consensus was to stay with Material theme properties for now, and then we can get user feedback after going live.

• Width: In the video David asked whether the width should be fluid/fixed. I’m inclined to stick to the block contextual toolbar defaults, if they’ll work: https://d.pr/i/sZhMGf

• Text placement: We discussed in the demo video about adding some variants as options. Is this something that could be done for the initial MVP? https://d.pr/i/sVKJo4. Thinking for Grid and Masonry.

[davidlonjon]

Hi @jwold ,

Thank you for the feedback. Let me address them:

Links in new window: I’m torn on this. We could definitely add an option in the block settings, but I don’t know if it’s needed for now.

Yes i think we can chose later on adding a control. For the time being we can open in same window by default.

Links on frontend: In the Video David asked what actions a user could take with links on the fronted. Any buttons in action bar should go to their pages (author to author page, comments to bottom of page with comment section highlighted)

@ravichdev, since you have been working on the frontend, you can make sure of the implementation mentioned by Joshua?

Author and comments: In the video David asked whether these should stay in the action bar for Masonry/Grid. I agree that they should.

Great no changes here then.

List option: In the video David mentioned removing Post Content for List, I agree.

Great no changes here then

Grid option: I’d suggest we can keep it for now, and get user feedback.

Great no changes here then

Featured image size: There’s a new dropdown for changing the featured image size. My concern is that, since it doesn’t change the actual image dimensions, but rather selects a different image to fit within the same dimensions, that it could cause confusion. My suggestion would be to choose a smart default (perhaps a larger size for now), and then programmatically adjust based on viewport size in the future. Would love feedback on this though.

Ravi implemented smart default on the frontend rendering. I have also done it now on the editor and removed the control from the panel. The default are the medium image size for the list layout and the large image size for the masonry and grid layout. We can later think about image size based on viewport size.

Style of rendering: In the video David talked about the CSS styling for the block, and whether it should adhere more to the WordPress Material Theme in all cases, or whether it should adopt another theme (Twenty Twenty for example), when that theme is activated. The general consensus was to stay with Material theme properties for now, and then we can get user feedback after going live.

Agreed. We have done some tweaking to ensure Material theme enforcement for the blocks. @ravichdev, I have changed the font to emin the styles on my PR as well as adding a base size (16px) for the parent of single post cards.

Width: In the video David asked whether the width should be fluid/fixed. I’m inclined to stick to the block contextual toolbar defaults, if they’ll work: https://d.pr/i/sZhMGf

I have implemented it. See the video demo https://cloudup.com/c4yfEHTlifj @ravichdev, I have added the alignment control in the toolbar. It means that the block should inherit of a class to allow control alignment on the frontend.

Text placement: We discussed in the demo video about adding some variants as options. Is this something that could be done for the initial MVP? https://d.pr/i/sVKJo4. Thinking for Grid and Masonry.

I have implemented it. See the video demo https://cloudup.com/c4yfEHTlifj

[jwold]

Great work. This looks amazing! So excited when I saw this demo 😀

I spotted just one thing, can you add a gray border to the styles?

[davidlonjon]

@ravichdev, The change mentioned above is touching the ImageRadioControl component. Should we do create another issue for it or implement here?

[ravichdev]

@davidlonjon As this is a minor change I think we can implement that as part of this issue.

[davidlonjon]

@jwold , I have now implemented your latest feedback regarding adding the border to the styles.

cc @ravichdev

[jwold]

Great work! This looks good 😀

[jwold]

Quick question. Is this the expected behavior when I go to align-center with a single post? https://d.pr/i/xyOjV1. cc @ravichdev and @davidlonjon

[davidlonjon]

Hi @jwold,

We did not defined the expectation and we overlooked this feature from Gutenberg in the editor.

• In the Gutenberg editor, the core align feature seems to do the following:
  • left alignment will make the whole block to float left. It does not affect the text alignment
  • right alignment will make the whole block to float right. It does not affect the text alignment
  • center alignment will make the whole block center inside the editor default block container (having a min width of 600px). It will also center the text inside the block.
  • wide alignment will increase the width of the editor default block container to about 1200px.
  • full alignment will make the block container to extend its width to the full page width or I guess its parent container.

It seems to me there is a bit of inconsistency with this feature as the center alignment has 2 behaviour, it does center the block itself and apply centering to the text inside the block.

We can decide how we want to handle each scenario above. We might not want to do the text centering for example.

• In the frontend, i think the alignment support is a theme feature (cc @emeaguiar as the theme may need to support alignment options)

Finally there is the other issue when having only 1 posts in a multi column layout. would we want in the case of a center align, the single post to center? In my view no as the single post should be in its column even though there are no other posts.

My view I think the behaviour inside the editor we should only support wide and full width alignment for this block (and the hand picked posts block)

On the frontend this would be up to the theme how to handle the alignment that the editor defines.

Finally I think this is an issue which will be impacting all the block supporting the alignment feature and we might want to create a new issue for it. We should decide which block will support or not alignment and it they do, which type of alignments should be allowed from the 5 default options (left, right, center, wide, full).

Does it make sense?

cc @ravichdev, @emeaguiar , @dugajean

[jwold]

We might not want to do the text centering for example.

I think you're right. Unless there is a precedent where Material supports a center aligned card. I haven't seen that yet though.

Finally there is the other issue when having only 1 posts in a multi column layout. would we want in the case of a center align, the single post to center? In my view no as the single post should be in its column even though there are no other posts.

In looking over this again I agree, you're right. If someone has 2-3 columns it wouldn't make sense to stretch a single card across those columns.

My view I think the behaviour inside the editor we should only support wide and full width alignment for this block (and the hand picked posts block)

Agreed.

Finally I think this is an issue which will be impacting all the block supporting the alignment feature and we might want to create a new issue for it.

I'm happy to do that.

[davidlonjon]

Hi @jwold, specifically for the Recent Posts and Hand-picked Posts blocks, I have created the following issue #134 for these 2 blocks to support only the wide and full alignment. I am also proposing to make wide the default alignment. Finally for implementation I created this PR #135

[jwold]

@csossi this is ready for QA testing. Note that the width of the block is still in progress, per David's comment above ^

[davidlonjon]

Hi @jwold , @csossi ,

Please note that the PR for the alignment issue has been merged and deployed, however it will still not show on the test environment because our material theme may not support the core alignment controls yet. Here is a demo demonstrating the issue on my local https://cloudup.com/cI6_CGe7QT4

We discussed it on Monday with @emeaguiar who created a new issue on Github to fix it. Mario please let me know if there will be anything I'll need to do on the block itself.

[jwold]

Thanks for the update David!

[emeaguiar]

I have a PR in the theme repo to enable alignment support: xwp/material-theme-wp#44 it'll be visible in the testing site once it's merged.

[csossi]

@jwold - alignment seems to offer only Full and Wide widths (nothing for Normal):

Further, as in the image above, Wide is "Active". It appears I can get to Normal if I click Wide (behaves as a toggle turned "off"). Now, it looks like I'm seeing a Normal layout:

The prob I'm having here is that the Block toolbar has disappeared. For it to return, I have to click outside of the block and then back in.

[davidlonjon]

Hi @csossi,

Thank you for the feedback.

We took a decision for this block (As well the Hand-picked posts and Card collections blocks) to only have the Wide and Full Screen alignment. I believe that with WordPress there is no "normal" alignment and only by toggling off the selected alignment, it will just no set any alignment. There is left/right/center alignments but they did not really make sense in the context of these blocks because they were impacting the content of the individual cards themselves rather than the container. Surely we can revisit them if there are some expectations from a UX point of view.

Also the second issue (the Block toolbar disappears after unselecting the alignment), it seems to be a core WordPress feature (or bug ?) as it seems to behave the same with the core blocks such as the Image block for example. Is anybody else seeing the same?

cc @jwold @ravichdev

[jwold]

Issue one: Just wanted to followup on this wide/normal/full width discsusion. I may have written the AC incorrectly, but as far as I can tell the block is functioning as expected.

When you first add the block it defaults to wide view, then you can switch back to "normal" view by de-selecting it: https://v.usetapes.com/JptEFTS7u1. This has always been confusing to me that Gutenberg has three options hidden in two buttons, but I think it's ok to leave as is since this is Core functionality.

Issue two: I tried finding another Core block to compare against, but can't verify if this is working as expected. It feels like a bug, but I'm not sure. Ha!

[csossi]

@davidlonjon @jwold

Thanks for this, guys. I checked another WP installation and saw that the Core blocks seem to have the "dissapear" happening there as well, so it seems to behave the same in Core

Ticket verified here