search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.35k stars 4.13k forks source link

Comments Loop Block: Tracking issue #34994

Closed SantosGuillamot closed 2 years ago

SantosGuillamot commented 3 years ago

Description

The idea of this issue is to end up with a Comments Loop Block (name may change) that loops over the comments of a given post. This would be similar to the Query Loop used for posts. Users should be able to define and change the layout of the post comments directly from the Gutenberg editor, and both the editor and the frontend should match.

This is how the different comment blocks should look like:

Comments Query Loop

https://excalidraw.com/#json=6537760064143360,EgfZIljXt2SI2DTSFebHQQ

Existing Solution / Workaround

Right now, there are two similar blocks:

Tasks

These are the steps we should follow to finish the tracking issue:

Please note that I'll be adding the relevant issues once they are created.

Out of scope

There are some functionalities that could be nice to work on but that won't be covered in this tracking issue, although they may be addressed later in the future:

Questions

Of course, any feedback apart from these questions is more than welcome 🙂

Previous work

There has been already some work done related to the Comments Block that was tracked in this issue → https://github.com/WordPress/gutenberg/issues/24101

mcsf commented 3 years ago

👋 Excited to see these great issues popping up!

We can start with a soft deprecation, i.e. supporting the old block but deprioritising it (e.g. hiding it from the inserter). In other words, we don't need formal deprecation notices yet. The fact that it's a dynamic block means that, later on, we have some flexibility to determine how existing Post Comments blocks should be rendered.

If the old blocks' usesContext: [ 'commentId' ] directive is compatible with the new blocks' intended implementation, I'd say it's worth reusing.

  • It seems to me that, while working on the Block Elements, we should keep in mind that they should also work fine for the Post Comment Block right?

Yes, as I mentioned above — unless supporting both becomes an unreasonable burden!

  • Once the Comments Loop block is finished, should we even deprecate the Post Comment Block and create a setting in the loop to select just an id?

IMO, it depends on what the benefits are, or what the use cases could be for this. It feels lower priority to me.

  • I feel that, as already pointed in other issues, it would be better to have two different blocks for the Comment Author and the Comment Author Avatar. However, right now in the posts, the Avatar is just a setting in the Post Author block. Is there any reason to not create two different blocks?

It's probably the trade-off between the flexibility of more granular blocks (Author + Avatar) vs. the user-friendliness and polish of dedicated multi-functional blocks (Author with integrated Avatar). With the ongoing improvements in layouts and alignments, the balance may soon tip towards granular blocks. I suggest experimenting with both and seeing what feels right. :)

jameskoster commented 3 years ago

@SantosGuillamot One design update we might consider: the new Dimensions and Layout panels will be useful on blocks like Avatar, but potentially all of them.

With the ongoing improvements in layouts and alignments, the balance may soon tip towards granular blocks.

Probably worth getting a theme dev's input here (cc @kjellr), but I suspect that the flexibility afforded by separate blocks for author name and author avatar will be more useful in general.

kjellr commented 3 years ago

Probably worth getting a theme dev's input here (cc @kjellr), but I suspect that the flexibility afforded by separate blocks for author name and author avatar will be more useful in general.

Yeah, the current iteration of the Post Author block is pretty inflexible and limiting for theme authors. There was a lot of talk about its issues (and the idea of splitting it into sub-blocks) in https://github.com/WordPress/gutenberg/issues/24952. This is one of the reasons the block was left out of 5.8.

carolinan commented 3 years ago

Author with integrated Avatar -sounds like a good default block pattern or a block with inner blocks. The post author block is really just waiting for a decision to be made, so that work can start.

luisherranz commented 3 years ago

@SantosGuillamot these three blocks don't have design, so I'm going to label them with Needs Design:

SantosGuillamot commented 3 years ago

@SantosGuillamot One design update we might consider: the new Dimensions and Layout panels will be useful on blocks like Avatar, but potentially all of them.

I agree it makes sense for most of these blocks 🙂 . I can see that the Dimension panel was integrated in this Pull Request and there is another Pull Request to create a unified Layout panel. Do you know which is the best place to understand both panels better and how to integrate them in the blocks?

jameskoster commented 3 years ago

I believe the Group block has already implemented the Dimensions panel, so that might be a good place to look?

To clarify, it probably only makes sense for the Layout panel to be added to container blocks in this context, IE the comment query loop and the comment template. But obviously we can only do that once the feature has been added – my apologies, I thought it already had been.

carolinan commented 2 years ago

The post comment block is in the theme category, but the inner blocks are in the design category, is that correct or should they all be in the theme category?

jameskoster commented 2 years ago

Personally I think the inner blocks are more aligned with the other blocks in the theme category.

But without wanting to open a can of worms, could there be an argument for a dedicated "Comments" section? There are quite a few blocks here...

mtias commented 2 years ago

As we work through these, I'd like to drop all the "Post" prefixes and just settle on "Comment Content", "Comment Author", etc.

michalczaplinski commented 2 years ago

Perhaps this is obvious but I'd like to clarify:

If a user submits a new comment, we would still require a full page reload in order to show that new comment, correct? As opposed to creating a sort of "optimistic update" and showing the just-submitted comment without a reload.

ntsekouras commented 2 years ago

If a user submits a new comment, we would still require a full page reload in order to show that new comment, correct?

Do you mean like creating a comment in the front-end and show the results in the editor?

luisherranz commented 2 years ago

If a user submits a new comment, we would still require a full page reload in order to show that new comment, correct?

That's correct Michal.

Do you mean like creating a comment in the front-end and show the results in the editor?

I think he means rendering the comment in the browser after submission.

michalczaplinski commented 2 years ago

I think he means rendering the comment in the browser after submission.

yup, that's what I meant. Thanks Luis!

SantosGuillamot commented 2 years ago

There has been some progress during the last weeks and I'd like to make a quick summary update. These are the issues we have worked on, and the status of each of them:

Feel free to add anything that I'm missing, and you can find more information in each Pull Request 🙂

SantosGuillamot commented 2 years ago

A new update on the Post Comments blocks. This was the progress made during the last couple of weeks:

For now, we will keep working on the aspects left in the Comment Query Loop block and start working on the blocks related to the Comments pagination. Feel free to add anything missing 🙂

SantosGuillamot commented 2 years ago

There has been some progress during the latest weeks regarding the Comments blocks:

Apart from that, there is a discussion going on about if multi-query comments loops should be provided, the same as the Post Query Loop does. Any feedback/help is highly appreciated as this would probably affect the rest of the Pull Requests.

Feel free to add/correct anything 🙂

SantosGuillamot commented 2 years ago

There are now a few more pull requests opened related to the comments blocks which could make it difficult to keep track of the whole project. Trying to summarize it as much as possible, there is work being done in mainly two areas:

  1. Wrapper blocks (Comment Template Issue & Comments Query Loop Issue).
  2. Pagination.

In the first part, these are the current open Pull Requests:

For the second part, the pagination, these are the relevant Pull Requests:

Apart from that, there is an open conversation to discuss if we should provide multi-query comments loops.

As always, any feedback, clarification or correction is more than welcome 🙂

SantosGuillamot commented 2 years ago

All the blocks defined in the opening comment are already merged 👏.

Now, there is still some work going on on some tweaks and fixes to consider the project finished:

SantosGuillamot commented 2 years ago

This has been the progress in some of the issues/PRs mentioned in the previous comment:

SantosGuillamot commented 2 years ago

A new update about the progress made:

t-pabla commented 2 years ago

Simple question: How would you remove (1) "date" , (2) "at", and (3) "time" from post comments? WP 5.9 twentytwentytwo theme

SantosGuillamot commented 2 years ago

Simple question: How would you remove (1) "date" , (2) "at", and (3) "time" from post comments?

These blocks haven't been included in WP 5.9, so you are probably using the Post Comments block. This block currently renders the comments.php in the frontend, so you would need to change that. I haven't checked it but I assume you would need to do so via filters. Not sure if it is the best way, but making a quick search I found this post that could be helpful.

In case you are using the Comments Loop block (this issue), just removing the Comment date block should be enough.

t-pabla commented 2 years ago

Thanks for your reply , @SantosGuillamot

In 5.9 editor, when I open single.php, I see "Post comments block". But I do NOT see "Comment date block" you referred to.

Where can this "Comment date block" be found?

I use 5.9 and twentytwentytwo theme.

thanks again.

SantosGuillamot commented 2 years ago

Sorry, I believe I didn’t explain myself correctly. The “Comments date block” hasn’t been included in WordPress 5.9 because the blocks mentioned in this particular issue aren’t finished yet.

You are probably using this other Post Comments block, which calls the traditional function comment_template() and renders the comments.php file. So, if you want to remove the date, you would need to do something similar to this post, although I haven’t tested it. Hopefully, once these new blocks are released, it gets easier to make these changes.

t-pabla commented 2 years ago

Thanks Santos.

The “Comments date block” hasn’t been included in WordPress 5.9 because the blocks mentioned in this particular issue aren’t finished yet.

That's what I suspected.

Thanks again.

SantosGuillamot commented 2 years ago

I wanted to share a new update on the tracking issue and also what, in my opinion, is left to consider this project finished.

Status of the issues/PRs mentioned in the last update

What is left to consider the tracking issue finished

There are a few more issues in the GitHub project, but I believe not all of them have to be addressed right now to consider this tracking issue finished. I’ve tried to sum up which ones, in my opinion, are needed before closing the project:

As I've said, this is just my opinion, so any feedback is welcome 🙂

SantosGuillamot commented 2 years ago

New update on the issues that are left:

Apart from that, this other issue was discovered, Cannot select inner blocks in the Comments Query Loop block, and it is already being fix in this Pull Request.

Moreover, as shared in this Pull Request, there are some issues if the Comments Query Loop settings aren’t inherited from the Discussion settings. This means that, initially, this option will be disabled until it is clearer how to approach it.

jasmussen commented 2 years ago

I took a quick look at the inspector for the comments query loop:

Comments Query Loop, before

I think we can do some small things here to refresh it a little bit:

Comments Query Loop i2

Some of the newer components that are shown are being developed separately, so that's not specifically an action item (the range slider for Items Per page), but I included the design targets in the mockups above for posterity! Is this helpful?

michalczaplinski commented 2 years ago

Thanks for the mockups @jasmussen ! 🙂 They definitely make for a better UI/UX!

That said, we have (for now) removed the "inherit discussion settings" option altogether. The Comments Query Loop is now going to always inherit the settings from the core Discussion Settings.

The main reason for this change is explained in https://github.com/WordPress/gutenberg/pull/39227#issuecomment-1061996417 but, in short, the main reason was that when the core Discussion and block settings have different perPage values, the user will likely get redirected to an incorrect /{post}/comment-page-X page after having submitted a new comment.

So, unfortunately, at least for now, we're not going to implement those UI improvements until there is a clear path forward that includes fixing this problem. @SantosGuillamot is going to make a longer write-up (I think in a new issue) that includes more details so that further work can be picked up by any contributor.

jasmussen commented 2 years ago

That said, we have (for now) https://github.com/WordPress/gutenberg/pull/39664 altogether. The Comments Query Loop is now going to always inherit the settings from the core Discussion Settings.

Even better!

gziolo commented 2 years ago

How does this functionality look in the terms of intent to ship in the upcoming WordPress 6.0 release? My understanding is that the development is almost finished and it's only a few final touches necessary. All blocks are still behind the experimental flag in the Gutenberg plugin: https://github.com/WordPress/gutenberg/blob/1223f9309f48b3165427d1b3afbcc9f233de0e6f/packages/block-library/src/index.js#L262-L273

There is also an open question what should happen to the Post Comments block shipped with WordPress 5.9 which covers nearly the same functionality but with a completely different approach: https://github.com/WordPress/gutenberg/blob/1223f9309f48b3165427d1b3afbcc9f233de0e6f/packages/block-library/src/index.js#L207

Beta 1 for WordPress 6.0 is planned for April 12th according to https://make.wordpress.org/core/6-0/. It means that Gutenberg v13.0 RC1 (planned for April 6th) is the last version where we can promote the Comments Query Loop block to shippable in WordPress 6.0.

luisherranz commented 2 years ago

I experimented with calling it just "Comments Loop". It seems fine to keep calling it "Comments Query Loop" if you prefer?

@gziolo also mentioned dropping the "Query" word from the name here.

If you think that it should be named "Comments Loop" even if the non-inherited options are added in the future (which is the "query" part), then I think we should do the renaming before this gets public in WP 6.0 👍

jasmussen commented 2 years ago

If you think that it should be named "Comments Loop" even if the non-inherited options are added in the future (which is the "query" part), then I think we should do the renaming before this gets public in WP 6.0 👍

I don't have a strong opinion to be honest. Happy to defer!

jameskoster commented 2 years ago

If we're omitting custom queries, might we call it "Post Comments" to be consistent with other blocks like "Post Content", "Post Title", etc?

luisherranz commented 2 years ago

I don't have a strong opinion, but @mtias suggested the opposite in this comment: https://github.com/WordPress/gutenberg/issues/34994#issuecomment-929291106

gziolo commented 2 years ago

If we're omitting custom queries, might we call it "Post Comments" to be consistent with other blocks like "Post Content", "Post Title", etc?

The challenge is that there is already "Post Comments" block in WordPress core (and Gutenberg plugin):

https://github.com/WordPress/wordpress-develop/blob/921d2805a0ebaf4db9f75ea9f5af46e48d6f68ac/src/wp-includes/blocks/post-comments/block.json#L4

That's is the biggest question what do we do about that legacy version that is a single block mostly based on PHP function calls and can't be customized in the UI.

jameskoster commented 2 years ago

I don't have a strong opinion, but @mtias suggested the opposite in this comment: https://github.com/WordPress/gutenberg/issues/34994#issuecomment-929291106

I think he was referring specifically to the children. I've suggested removing the Post prefix from all of these blocks before (IE "Post Date" becomes "Date") and there wasn't much appetite.

The challenge is that there is already "Post Comments" block in WordPress core (and Gutenberg plugin):

I don't know if it's possible, but shouldn't this block replace that one? It seems to serve the same purpose.

cbravobernal commented 2 years ago

The only issue is that the legacy version works fine with non-FSE themes, applying the styles defined on themes, using the default PHP functions. I guess we cannot replace it until we upgrade some WordPress versions.

The new Comments block still requires some configuration in order to have a nice design, now seems pretty raw when you insert it.

Is it possible to add some default styling? Should we create some patterns once we can use Rows and Columns inside Comment Template?

That way could be ready for 6.0 I guess.

jameskoster commented 2 years ago

I suppose the other problem is backwards compatibility for block themes that are using the existing Post Comments block in their templates.

luisherranz commented 2 years ago

the other problem is backwards compatibility

I believe the pattern that has been used in situations like this is to hide the block (instead of deleting it), so it keeps working if it already exists, but new users/themes can't add it.

@gziolo: is that correct?

gziolo commented 2 years ago

the other problem is backwards compatibility

I believe the pattern that has been used in situations like this is to hide the block (instead of deleting it), so it keeps working if it already exists, but new users/themes can't add it.

Yes, there are a few blocks that no longer show up in the inserter with supports.inserter set to false:

https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/#inserter

SantosGuillamot commented 2 years ago

After receiving a lot of great feedback in the Help Test the Comments Blocks for WordPress 6.0 post, there is some work needed to include the Comments blocks in WordPress 6.0. This is a summary of the issues/PRs that are currently considered (thanks @ockham for the help here 🙂 ):

List of blockers

As Justin shared in this comment on the CfT, these three issues could be considered blockers:

As a follow-up to item 1, it could be considered:

Moreover, @peterwilsoncc also fixed:

Stabilizing the Post Comments Form block.

It seems that the Post Comments Form should be added to the Comments Query Loop block’s default template (#40256), as people get confused by the missing comment submission form if they only insert the Comments Query Loop, which many may think of as a 1:1 replacement for the Post Comments block.

Unfortunately, this is blocked by the Post Comments Form currently being experimental. In order to stabilize it, it seems that at a minimum, this would be needed:

And finally:

Retaining a fallback: The Post Comments block

It seems too late to include a block transform from Post Comments to Post Query Loop. Since the Comments Query Loop block will have a few rough edges, it should be considered to keep the Post Comments block in the inserter (i.e. by removing this line; no GH issue filed).

What do you think about this? Should we keep the current Post Comments block?

If so, although this block is already included in core, it may be needed to:

Moreover, there is also this other PR:

Renaming the Comments Query Loop block

@ockham has suggested that at this point – especially if the Post Comment Form is included, and potentially a Comments Title block – the block isn’t really a Comments Query Loop block, but more than that. As a user looking for “a block to display the comments”, they probably wouldn’t click on “Comments Query Loop” as their first choice in the inserter (especially if the Post Comments block is still available as a fallback).

So, what do you think about renaming the Comments Query Loop block to something that better captures what it is for, and what it does? Should it be called just “Comments”? Any other ideas?

Please, feel free to share anything else not considered here or any comments you have 🙂

mtias commented 2 years ago

Transforming the monolithic Post Comments block into a block made of blocks is the equivalent of the work that occurred on Galleries, Quote, etc. We should aim to replace the block as transparently as possible. For example, can we have a default template (inner blocks setup) that mimics the layout of the current post comments block? What if it just works as a fallback when no children are passed and when loaded in the editor you can pick a different pattern and that would transform into child blocks?

ockham commented 2 years ago

Thanks @mtias! A few thoughts (in different order):

We should aim to replace the block as transparently as possible. For example, can we have a default template (inner blocks setup) that mimics the layout of the current post comments block?

We're kind of doing that already. This is what you get after inserting a Comments Query Loop block:

image (1)

Transforming the monolithic Post Comments block into a block made of blocks is the equivalent of the work that occurred on Galleries, Quote, etc.

There's one difference: Post Comments is (fortunately!) a pretty basic dynamic block, unlike those (rather complex) static blocks you mentioned. So while I first thought that adding a transform would be too complex for now, maybe it could actually be pretty straight-forward 🤔 (@amustaque97 actually started work on this already and later closed it after seeing my comment.)

What if it just works as a fallback when no children are passed and when loaded in the editor you can pick a different pattern and that would transform into child blocks?

IIUC, the underlying assumption here is that Post Comments and Comments Query Loop are basically merged into one block, right? Well given the above, how would you feel about keeping them separate, with a block transform added? (My major concern is that adding the UI for picking a pattern is more complex than a block transform and would make it more unlikely for the blocks to land in WP 6.0.)

ockham commented 2 years ago

Adding a list of PRs that we’ll also want to include in WP 6.0 (which aren’t in my post because I missed them, or they were filed later as follow-up bugfixes):

(I’ll update this comment with more PRs if needed.)

ockham commented 2 years ago

For example, can we have a default template (inner blocks setup) that mimics the layout of the current post comments block? What if it just works as a fallback when no children are passed and when loaded in the editor you can pick a different pattern and that would transform into child blocks?

For reference, this is what inserting a (posts) Query Loop block looks like:

With pattern Start blank
post-query-loop post-query-loop-pattern

I imagine you're suggesting to do something like this for the Comments Query Loop block.

To me, what we have now -- which is basically

a default template (inner blocks setup) that mimics the layout of the current post comments block

seems good as a baseline for WP 6.0. (Since users can customize those inner blocks by moving them around and/or styling them.) The pattern selection mechanism seems like a good feature to add later.

ockham commented 2 years ago

Update: Matías clarified via DM how he wants the Comments Query Loop logic to be merged into Post Comments, and how they should behave. I've filed #40521 with the details.

ockham commented 2 years ago

Update: Matías clarified via DM how he wants the Comments Query Loop logic to be merged into Post Comments, and how they should behave. I've filed #40521 with the details.

Per discussion on the issue, and due to the problems we've encountered, we've decided not to attempt having the Comments Query Loop merged into the Post Comments block for WP 6.0. We'll revisit after it's released.

ockham commented 2 years ago

As a corollary to the above, and per Slack discussion with @priethor:

The Post Comments block has been deprecated and removed from the inserter for a while, so people won’t be able to newly insert it. UX-wise, this is not so different from what the block merge would’ve achieved (where we would’ve retained the childless/monolithic version of the block for backwards compat, but upon newly inserting it, users would’ve gotten the modular version).

We still would like to rename Comments Query Loop (to Comments) though, as per our original plan.