CoreListItem return sublist html in attributes.content

[MKlblangenois]

When I create a list with sublist inside <li>, the query in attributes.content of parent <li> return all HTML content, and duplicate the content at the end of content:

�

[theodesp]

Hey @MKlblangenois. Looking at the core/list-item block.json spec it looks like this is the expected behavior. The content attribute for this is located here:

https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/list-item/block.json

		"content": {
			"type": "rich-text",
			"source": "rich-text",
			"selector": "li",
			"__experimentalRole": "content"
		}

the selector targets a single li element so it will grab the content of the <li/> HTML node which will contain innerHTML. So the result will be HTML

[jasonbahl]

@MKlblangenois @theodesp I have 2 thoughts on this.

My first thought was:

Any field that returns HTML should return valid HTML. i.e. this field should return the HTML and include the opening and closing <li> tag so the client doesn't need to to this.

Since this field returns invalid HTML, it requires the user to wrap the field in an <li>{field.value}</li> which is confusing for users to consume and render.

However, the __typename of the Block does indicate what Type of block it is and core/list-item does declare that it is indeed a "list item" which is represnted by <li> so as a client consuming this block, it's not entirely uncalled for do to something like:

(pseudo)

switch ( block.__typename ) {
  case: 'core/list-item':
     return <li>{block.attributes.content}</li>
}

I think long-term it would be nice to see fields that return HTML return valid HTML though. If core WPGraphQL were to introduce an HTML Scalar, this field would fail validation as-is, for example.

[jan-clockworkwp]

I can confirm that this is still happening as of

• "wpengine/wp-graphql-content-blocks": "4.3.2"
• "wpackagist-plugin/wp-graphql": "1.29.3"

and

• "@faustwp/block-editor-utils": "0.3.0",
• "@faustwp/blocks": "^5.0.0",
• "@faustwp/cli": "3.1.1",
• "@faustwp/core": "3.1.0",

if accroding to @theodesp core/list-item works as expected and the Faust CoreList block implementation uses correctly values attribute when page content is rendered with faust WordPressBlocksViewer for a simple list with nested item like this:

• list item 1
• list item 2
  • list item 2 nested item

returned graphQL block object is:

{
      "__typename": "CoreList",
      "id": "676175143efb3",
      "name": "core/list",
      "parentId": null,
      "renderedHtml": "<ul class=\"wp-block-list\">\n<li>list item 1</li>\n\n\n\n<li>list item 2\n<ul class=\"wp-block-list\">\n<li>list item 2 nested item</li>\n</ul>\n</li>\n</ul>\n",
      "attributes": {
        "anchor": null,
        "backgroundColor": null,
        "className": null,
        "fontFamily": null,
        "fontSize": null,
        "gradient": null,
        "lock": null,
        "ordered": false,
        "reversed": null,
        "start": null,
        "style": null,
        "textColor": null,
        "type": null,
        "values": "<li>list item 1</li><li>list item 2\n<ul class=\"wp-block-list\">\n<li>list item 2 nested item</li>\n</ul>\n</li><li>list item 2 nested item</li><li>list item 2 nested item</li>",
        "cssClassName": "wp-block-list"
      }
}

causing that list rendered on the FE is instead of the expected nested list looking like:

• list item 1
• list item 2
  • list item 2 nested item
• list item 2 nested item
• list item 2 nested item

Should GraphQL blocks plugin deals with core/list-item block in different way and provide already proper HTML markup so it can be parsed by the Faust application on the front end or should that be dealt with on the FE? How to solve it and where would be the best to solve it, is probably the question for @jasonbahl and/or @theodesp. Thank you in advance for any progress on this one.

Note: Current workaround for this issue is to created custom CoreList block for the faust application and use renderedHtml attributed for react component content instead of the attribute values. This is just a workaround, as I believe the issue #253 (comment) should be addressed either in the wp-graphql-content-blocks plugin or @faustwp/blocks npm package.

[justlevine]

The real answer is that the frontend CoreList component needs to be refactored and a CoreListItem component created. The CoreList.content and .values fields are a) artifacts and more importantly b) attributes and therefore not meant to proxy an actual child block.

Take a look at the respective save.js files in the WordPress/Gutenberg repo if you're looking to do this locally.