"Releases" Template

[shaunandrews]

This PR updates the Releases category template to more closely match the design. It also includes a nifty, new block for displaying a release version number.

[iandunn]

What do you think about a custom block that pulls the x.y out of the title w/ a regex? #38 has the regex worked out already. That seems like less technical debt to me, because it's more straightforward and future-proof.

We could also use it on the homepage to match the design closer, and remove this (see #119):

wporg-news-2021/source/wp-content/themes/wporg-news-2021/functions.php

Lines 376 to 391 in d55bf56

	/**
	* Remove "WordPress" from the release post title.
	*
	* @param string $title The post title.
	* @param int $id The post ID.
	* @return string Filtered post title.
	*/
	function update_the_title( $title, $id ) {
	// Remove "WordPress" from the post title in the Latest Release section on the front page.
	$category_slugs = wp_list_pluck( get_the_category( $id ), 'slug' );
	if ( is_front_page() && in_array( 'releases', $category_slugs ) ) {
	return str_replace( 'WordPress', '', $title );
	}
	return $title;
	}

Something similar would work for the date in the Events template.

Related: #75

[tellyworth]

I pushed a commit to add a custom block. Seems to work ok. @shaunandrews I've only lightly touched your CSS, the rest of it is additions.

To get it to work you'll probably need to:

composer update && wp-env start --update

@iandunn have I added the block plugin in a sane way? I copied the gitignore handling of the theme folder basically.

[iandunn]

🤔 , I'd lean towards putting the code in the blocks/ folder in the mu-plugins repo, so that all sites can use it. I'd guess that future redesigns will have a similar concept, with part of the post title being used as a design element.

I don't feel strongly, though.

[ryelle]

I don't think other sites will need this exact functionality, but if we leave it here that's a third folder we would need to sync into SVN.

[tellyworth]

If I change it to a more specific block like post-title-version, would any other sites have a use for it? It's a pretty obscure use case. Agree that mu-plugins could make sense for a more generally reusable block though.

[iandunn]

Kelly has a good point. I could even seen this being put in functions.php since it's really just a glorified custom template tag. I wouldn't do that for normal blocks, but this is just a workaround for FSE limitations. I don't feel strongly though.

[ryelle]

I'm okay with leaving it in the theme (maybe a blocks folder, in case we need any other workarounds). If we're still going the parent-theme route, they'll be available to any child themes too. I do think we should use a block.json + set it up in JS too, so that it won't break in the site editor (see WordPress/wporg-mu-plugins#26) when we get there.

[iandunn]

I was imagining something much more simple, that would only be used for this purpose, since core/post-title can be used if they want the full title.

register_block_type(
	'wporg/post-title-version',
	array(
		'title'           => 'Post Title Version',
		'render_callback' => function() {
			$full_title = get_the_title();
			preg_match( '/WordPress (\d+[.]\d+)/', $full_title, $matches );
			
			return $matches[1] ?? ''; 
		}
	)
);

That's probably missing a few things, but communicates the jist of it. I don't think we need block.json etc for a small workaround like this. In my mind this is just a temporary thing until Gutenberg solves WordPress/gutenberg#32939.

[ryelle]

Aside from the releaseVersion toggle, how is this different from the Post Title block? Only asking because when I saw "custom block for the version" I thought of making a simple block that only outputs the release version, with no other attributes.

[tellyworth]

Yeah I like that idea. I guess I was preempting other hypothetical uses for the same block, but I don't think we have any other actual use cases right now.

[tellyworth]

I changed the block to wporg/release-version. It just outputs the version number and a wrapper tag, rather than duplicating post title stuff.

It feels like overkill. The alternative to adding the block in a plugin is to register a block from the theme itself, which I think(?) is generally discouraged.

[ryelle]

The alternative to adding the block in a plugin is to register a block from the theme itself, which I think(?) is generally discouraged.

That's true, but that actually was what I was suggesting 😅 I guess it depends on whether you think we'll need this on sites that don't use this theme (itself or as a parent), or if we might want it in the future, whenever this theme is eventually retired. My opinion is that it's decorative in a way that's tied to the theme, so I think keeping it in the theme is fine.

[coreymckrill]

A regex that will work for getting 3rd-level versions is (\d{0,3}(\.\d{1,3})+) (from here)

[iandunn]

👍🏻 It seems important to get .z in there

[shaunandrews]

Right now the "5.8" version number is duplicated many times, since each of the latest posts (from the import) is for 5.8 release candidates. Would it make sense to update these version numbers to include "RCx" to help reduce the repetition? This might require some design thinking, as I think "5.8 RC2" might be too long to fit within the available space.

[beafialho]

Not sure why I'm not seeing the numbers on the left?

[tellyworth]

Not sure why I'm not seeing the numbers on the left?

Did you run this? -

composer update && wp-env start --update

[tellyworth]

I updated the PR to:

• Remove the separate plugin, and register the block from functions.php
• Handle x.y.z and RC n

Do we also want it to understand Beta n? That text is probably too long to fit.

Screenshot (zoomed out to fit more examples):

Make sure you run composer update && wp-env start --update to test it locally.

[beafialho]

Did you run this? -

I hadn't, that worked. Thanks!

Do we also want it to understand Beta n? That text is probably too long to fit.

Let's keep the numbers only as they fit just fine. I like the "RC" alternative.

Overall, this looks great! I have some comments:

Desktop

• The height of each post should ideally be 174px instead of the current 232px:

Currently	Mockups

• Increase spacing down at the bottom of the page (should look the same as on top of posts navigation):

Currently	Intended

• Hover effect missing in Read Post (underline should disappear on hover):

hover.mp4

Mobile

• Let's remove the arrow on mobile:

• Increase spacing between posts (top and bottom spacing should be identical)

Currently	Intended

• Posts navigation off the page:

weird.mp4

[ryelle]

@coreymckrill I made a few changes to the block markup, since we don't need to have this in a heading we can avoid the aria workarounds. The content should still be available to screen reader users (just not as a heading). Feel free to undo anything you don't like :)

I think all of @beafialho's feedback is still relevant - I removed the arrow on small screens while restructuring some of the CSS, but things like the post height & wonky pagination on small screens are still happening.

[coreymckrill]

@beafialho @ryelle Sorry I missed that some of the feedback from earlier hadn't been addressed yet. It has been now, would love to get your review. One thing to note is that I also moved the version numbers for the not-latest release posts down to the bottom edge of the rows on mobile to better match the Figma design.

[beafialho]

Thank you @coreymckrill this looks great!

[ryelle]

Overall this is working great, I just caught a few things while looking through the code.

I also noticed the pagination is missing space between 600-780px: