Wp-calypso: Allow conversion from Post Carousel Block to Blog Posts Block and viceversa

[mrfoxtalbot]

Is your feature request related to a problem? Please describe.

Some users may come across the post carousel block without realizing that the Blog Posts block is in fact a better and more complete solution.

It can be hard for users to learn about our existing blocks and/or alternatives to the blocks they are using, and the problem will become more acute as the list becomes bigger.

Describe the solution you'd like

We should make the most of the "convert to other (similar) block" feature by letting users switch from the Post Carousel Block to the Blog Posts Block, and the other way around.

Additional context

[jeherve]

Transferring this to the Calypso repo, where the Post Carousel block lives as part of the Full Site Editing plugin.

[obenland]

Post Carousel's requirement for feature images makes this a bit harder to achieve than it might be expected.
To make the Carousel -> List switch seamless, we should add a featured image filter to the Blog Posts block to make sure the same posts are being displayed before and after.

I don't know if it's possible to limit the availability of a transformation to certain block attributes being active, but unless the Blog posts block has the above mentioned featured image filter applied, I'd be hesitant to offer a transformation that will result in likely unexpected behavior.

@mrfoxtalbot How would you feel about limiting that transformation to the Carousel block in case conditionally showing a transformation in Blog Posts is not possible?

[mrfoxtalbot]

Hey @obenland! Thank you for looking into this and sorry for the late reply.

Post Carousel's requirement for feature images makes this a bit harder to achieve than it might be expected. To make the Carousel -> List switch seamless, we should add a featured image filter to the Blog Posts block to make sure the same posts are being displayed before and after (..) I'd be hesitant to offer a transformation that will result in likely unexpected behavior.

I am not sure I understand what you mean here. Does the Post Carousel block skip posts which lack a featured image?

[obenland]

Does the Post Carousel block skip posts which lack a featured image?

Correct, yes

[mrfoxtalbot]

Correct, yes

I see! I was not aware of this, but I just found it in the block's docs article, thank you

It is important that you have published at least one post with a featured image. The Post Carousel block slideshow will be empty otherwise.

It is true that having the Blog Posts block converted to the Post Carousel block could be confusing (the posts might not match), I did not realize this. It may be better to just leave it as it is now.

Thanks again, for taking the time to clarify this!

[cpapazoglou]

Hey @mrfoxtalbot, having looked at those two blocks apart from the feature-image that is needed from the posts-carousel block it also seems that blog-posts has 2 more attributes which may refine posts visiblity and don't exist in posts-carousel : tagExclusions and specificPosts

That said, the best way forward (in my mind) is :
1) add tagExclusions and specificPosts to posts-carousel. That should be relatively easy, given the fact we already have that code for blog-posts
2) remove skipping posts without image by default for posts-carousel. Instead create a setting for including / excluding posts without feature image. Add an option for a default background color for posts missing feature image.
3) the same as (2) for blog-posts too.

If we do the above:
1) We will have provided great value to both blocks
2) Transformations will be 100% compatible viceversa
2) Posts will match 100%

What do you think about?

[mrfoxtalbot]

Sounds good, thank you!

I am very much in favour of trying to create consistent interfaces/features for all and any blocks that deal with post loops/listings.

This is certainly outside of the scope of this ticket, but the part of this type of block that deals with block loops/queries should be completely abstracted from the individual block (Blog Posts, Block Carousel, Latest Posts) in a way that makes it easier to reuse across existing blocks and when we create new posts.

Do you know if this is something that perhaps exists already or that is being discussed elsewhere?

Thanks again!

[cpapazoglou]

the part of this type of block that deals with block loops/queries should be completely abstracted from the individual block (Blog Posts, Block Carousel, Latest Posts) in a way that makes it easier to reuse across existing blocks and when we create new posts.

If understand correct what you are saying, we already have QueryControls https://github.com/Automattic/newspack-blocks/blob/master/src/blocks/homepage-articles/edit.js#297 so it is easy adding that kind of filters.

[mrfoxtalbot]

Yes, I mean something along those lines @cpapazoglou, but I was wondering if such a block as being proposed at a Gutenberg core level. Kind of a boilerplate for any future blocks that are used to list post (I came across a similar instance of this issue over at 3431047-zen)

I am really not sold out at all on this block listing only images that have a featured image. We could use a solid color as a fallback, but the fact that post without a featured image are excluded while other blocks do include them, can be rather confusing.

[cpapazoglou]

@mrfoxtalbot, how would you feel firstly opening a separate issue about addressing Carousel Block inconsistencies:

• add tagExclusions and specificPosts to posts-carousel QueryControls
• remove skipping posts without image by default for posts-carousel. Instead create a setting for including / excluding posts without feature image. Add an option for a default background colour for posts missing feature image.
• show sticky posts on top as blog-posts do

The above will bring feature parity with blog-posts block and enable us to revisit this block-conversion issue.

[mrfoxtalbot]

I think you are totally right there @cpapazoglou, this ticket had a very specific and narrow scope, but the conversation has gone considerably off-track and we now have quite a few things on the table.

I will open a new separate ticket addressing those points, add a link and close this issue.

Thanks again!