Comments blocks warnings: Better UX

[ockham]

The Comments Query Loop block (soon to be renamed to just "Comments") and its child blocks currently use the <Warning /> component in a few places, in order to indicate that what the user will see on the frontend might not match their expectations, e.g. if comments are not enabled for the entire site, the current post (or page), or the corresponding post type.

This is probably not how the <Warning /> component was intended to be used: It indicates a more serious, low-level, technical problem (such as a block validation error and the like).

Here's an overview of scenarios where these warnings are encountered (based on #40563):

Post Editor:

• Comments are not enabled for this post:
  • Add the Post Comments Form block to a post.
  • In the Post settings, deselect "Allow Comments".
  • The Post Comments Form block: Comments on this post are not allowed. warning should appear.

• Comments are not enabled on the site:
  • Go to the Discussion settings.
  • Disable the "Allow people to submit comments on new posts" setting.
  • Create a brand new post.
  • Go to the editor and add a Post Comments block.
  • The Post Comments Form block: Comments are not enabled. warning should appear.

(Screenshot TBD)

• Comments are not enabled for this custom post type
  • Make sure that the comments are enabled globally and enable the "Allow people to submit comments on new posts" setting.
  • Create a new custom post type and disable the comments on that post type.
  • Create a new post with that new custom post type.
  • Go to the editor and add a Post Comments block.
  • The Post Comments Form block: Comments for this post type <post type name> are not enabled warning should be visible.

• Comments Pagination block: paging comments is disabled in the Discussion Settings
  • Go to the Discussion settings.
  • Make sure that the comments are enabled globally and enable the "Allow people to submit comments on new posts" setting.
  • Disable the "Break comments into pages with [input] top level comments per page and the [dropdown] page displayed by default" setting.
  • Create a brand new post.
  • Go to the editor and add a Post Comments block.
  • The Comments Pagination block: paging comments is disabled in the Discussion Settings warning should appear.

Site Editor:

• Add the Post Comments Form block to a template.
• Check that no warning is shown regardless of the status of Discussion settings.

---

How should we present these warnings? Our original thinking was that they should be visible in the editor in order to alert the user that things won't look on the frontend as they probably expect them to. Or should we maybe just show something in the Inspector Controls (sidebar)?

Or maybe it's okay to keep the warnings more or less as they are, since they're only shown in the Post Editor (where we have enough context to know whether or not the block will be shown as expected), but not in the Site Editor (which is arguably the more relevant place for these theme-related blocks)?

One piece of the puzzle might be to give the user more agency to easily "fix" the warning (e.g. allow posting comments to a given post or post type); this is a separate issue that's discussed in #40614.

[ockham]

I discussed this with @jameskoster and @priethor today, and @jameskoster brought up an interesting point:

Why are we allowing comments loops in the post editor? 🤔

Essentially, Jay and Héctor referred me to #31830. Jay suggested we might implement this for the Comments Query Loop block (which would essentially bypass problems like this issue or #40614), and later roll it out to other blocks.

I like the idea, but I'm not sure we'll manage to get this change into WP 6.0.

@WordPress/frontend-dx Curious to hear your thoughts on this proposal.

[jameskoster]

In terms of design I don't think this needs to be anything elaborate. Just a simple message informing the user that the block doesn't work accompanied by an action to remove it could be adequate for now:

An alternative approach would be to display a Dialog and remove the block(s) automatically on close. This might be better as it would keep the canvas clean and handle multiple invalid blocks together.

I'm not sure we'll manage to get this change into WP 6.0.

Do you think it would be possible to at least hide the blocks in the UI (inserters)? If we don't intend to allow these blocks in the post editor, it would be good to not encourage their use in the mean time.

[luisherranz]

@WordPress/frontend-dx Curious to hear your thoughts on this proposal.

I'm usually against imposing arbitrary restrictions/constraints on how things can be used/composed. Especially now that users can customize comments texts and styles to almost anything imaginable, I can envision users using classic WP comments to request all sorts of user feedback using carefully crafted per post/page text and styles even in-between the article, not just "blog comments at the end".

But this is a question about UX, not DX. It's less of my competence/expertise, so I may be wrong 🤷‍♂️🙂

[ockham]

As for implementation, here's how the Template Part block is preventing from being rendered inside the post editor. (Thanks @priethor for the pointer!):

gutenberg/packages/block-library/src/template-part/index.js

Lines 57 to 83 in 48e2e83

	// Prevent adding template parts inside post templates.
	const DISALLOWED_PARENTS = [ 'core/post-template', 'core/post-content' ];
	addFilter(
	'blockEditor.__unstableCanInsertBlockType',
	'removeTemplatePartsFromPostTemplates',
	(
	can,
	blockType,
	rootClientId,
	{ getBlock, getBlockParentsByBlockName }
	) => {
	if ( blockType.name !== 'core/template-part' ) {
	return can;
	}
	for ( const disallowedParentType of DISALLOWED_PARENTS ) {
	const hasDisallowedParent =
	getBlock( rootClientId )?.name === disallowedParentType ||
	getBlockParentsByBlockName( rootClientId, disallowedParentType )
	.length;
	if ( hasDisallowedParent ) {
	return false;
	}
	}
	return true;
	}
	);

(This works because IIRC, the Post Editor uses a "virtual" core/post-content that wraps all its editable content.)

[jameskoster]

@luisherranz that does sound like a valid use case. But achieving it with comments seems rather convoluted, especially if you want regular comments and 'feedback' on the same post / page. The backend experience probably isn't the best either. Overall it sounds more like plugin territory?

It's probably easier to hide the blocks for now, and re-enable them later, rather than the other way around. Depending on feedback there may be more creative solutions to elegantly handle these blocks in the post editor (variations).

[luisherranz]

Sure. Sounds good 🙂

[ockham]

I'm overall on board with @jameskoster's rationale -- and it sure would declutter the UI from a ton of (rather ugly) warnings that a user would encounter in those edge cases.

The one thing that's giving me pause is that is has been possible to insert the Post Comments block into the Post Editor -- which we've now deprecated in favor of its successor, the Comments Query Loop block -- so we'd effectively take away the possibility to insert comments into a post 🤔

[jameskoster]

Good catch. Hmm. Iirc that block would only display the comments of the current post. Could there perhaps be a simplified variation of Comments Query Loop which replicates the old Post Comments block? IE it only contains Comments Template and the associated blocks. No title, pagination, form, etc.

There's a case to be made for doing this with the Query block too (#32268).

[ockham]

Hey, sorry for the late reply! 😅

Good catch. Hmm. Iirc that block would only display the comments of the current post. Could there perhaps be a simplified variation of Comments Query Loop which replicates the old Post Comments block? IE it only contains Comments Template and the associated blocks. No title, pagination, form, etc.

The "Query" in "Comments Query Loop" is a bit misleading; the "query" cannot be customized; instead, the block will always show all the post's comments. (This is one reason why we ended up renaming the block to just "Comments".)

OTOH, the Post Comments block does contain pagination links, and a reply form (though you might not encounter them if your post doesn't have enough comments to paginate, or if commenting has been disabled, respectively).

So for the practical purposes of this discussion, the Comments (Query Loop) and Post Comments blocks are pretty much identical already 😅

---

Anyway, as for excluding the Comments blocks from the Post Editor -- I guess that ship has sailed for WP 6.0, thanks to my own indecisiveness. We might revisit this (or, really, all of #31830) for WP 6.1.

For the time being -- and/or assuming that the blocks are here to stay in the Post Editor -- are there any other UX improvements should be made? I find e.g. the multiple warnings per block particularly off-putting:

...but then again, maybe it's a small enough edge case to not deserve further attention 😅

Also wondering if giving agency to the user to "fix" these warnings themselves could be key here: #40614.

Curious to hear your thoughts! 🙂

[jameskoster]

Couldn't we make it so that if you insert the Comments block into a post/post type that does not allow comments, the comments form block is simply omitted? Similarly do not allow the Post Comments Form to be inserted via the inserter. That way the user never needs to see the message on the canvas.

I suppose there's a corner case where you might try and paste the block into the post, but I'm not sure that's something worth prioritising.

[ockham]

Couldn't we make it so that if you insert the Comments block into a post/post type that does not allow comments, the comments form block is simply omitted? Similarly do not allow the Post Comments Form to be inserted via the inserter. That way the user never needs to see the message on the canvas.

That might be a viable solution 🤔 and it would certainly look nicer than the warnings do now 😅 Do we still need some kind of UI to inform the user about the reason why the block isn't present? (To avoid frustration if they're unaware that some kind of setting is preventing the block from being present and/or insertable.)

It does however mean that once the user has changed that setting, they'll have to manually add the Post Comments Form block 🤔 And conversely, it's possible that they start out with settings that allow for a comments form, but then change that setting. I guess we'd still need to show some block-level warning in that case (since we can't just erase it from post content at that point)?

I suppose there's a corner case where you might try and paste the block into the post, but I'm not sure that's something worth prioritising.

👍

[jameskoster]

Do we still need some kind of UI to inform the user about the reason why the block isn't present?

Good question.

You know what, I'm going to go full circle here and suggest we stick with the errors. In addition to the point above, it seems very tricky to reliably handle the exclusion of relevant blocks because there are so many variables at play.

We need the errors as a fallback anyway due the fact that folks can directly paste blocks in. Sorry for the indecision! Maybe we can circle back to the exclusion logic later.

One thing I would add: Incompatible block placement is a universal issue (for example you can currently insert a Post Content block in a post 🥴). So it might be good to build a solution that can be reused by any block. I don't know if that changes the scope of this issue to the point where we need a new one, but I figured I'd mention it regardless.

In terms of the design, I agree it would be nice if there was a simple way to remove the incompatible block. It would also be ideal if multiple errors for a single block could be combined. Because so many themes use a light/white background, it might be better to use the Notice style in order to clearly differentiate notices from actual content. Something like:

What do you think?