Add Block: Curated Dynamic Content

[celloexpressions]

Over the past year or so, there have been several attempts to create an improved experience for curating dynamic content in pages. Some of the notable efforts include:

• The Twenty Seventeen theme, on the front page (featured pages and recent posts)
• https://core.trac.wordpress.org/ticket/37974 (multi-part pages for 4.7)
• http://celloexpressions.com/blog/building-and-managing-dynamic-multi-part-pages-with-wordpress/ (an approach for dynamic multi-part pages via menus)
• The Dynamic Seventeen child theme for Twenty Seventeen (making the homepage more dynamic and customizable)
• Iterations on "Latest Posts" Block #1594 (comment) (the ability to feature specific posts in addition to latest posts)

There are many benefits to highlighting selections of existing content in particular areas of a site (most frequently on homepages). And while a block-based editor inherently addresses the idea of multi-part pages, additional effort is required to create a way to dynamically curate site-wide content embedded within pages.

Providing a block similar to latest posts, but with the ability to curate the specific posts shown and their order, would go a long way toward improving the ability to curate content discovery throughout a site. In addition to individual posts, a curated content block should facilitate featuring terms, perhaps with more-abbreviated mention of recent posts within them. Hierarchy is also worth considering.

Core already features a robust system for curating content: menus. Shifting the idea of a menu and menu widgets only slightly, a curated content block would allow users to select specific posts and terms to feature from all content on the site, offer an easy way to organize the order (and possibly hierarchy) of the content, and provide a variety of display options (similar to those in #1594). This is perhaps the most logical approach for bringing menus together with widgets and blocks and would replace the menu widget with the ability to directly select curated content in an editor block or widget.

In addition to serving as a precedent for content-curation, the existing menus system should be retained and used as the technical foundation for the curated content block. The underlying API would continue using nav_menu_item posts to represent curated item representations and nav_menu terms to organize them for display . Post meta and term meta would store context-specific information and the block itself would store a reference to the distinct menu term to maximize flexibility in reusing the underlying menu objects in other contexts.

In summary, a dynamic curated content block should:

• Function similarly to the latest posts block
• Be an extension of the existing core menus API
• Include a robust selector to add posts of any type and terms of any taxonomies, reusing the existing show_in_nav_menus post type support (customize add-menu-item
• Offer similar display options to the latest posts block within the editor context
• Use the existing menus API for data display and only stores references to the specific display options and appropriate nav_menu term within the_content, leveraging a custom nav menu walker for full rendering
• Replace the menu widget

[westonruter]

Thanks for the summary. I think this is good, but I'm concerned with the degree to which the core nav menu API is re-used.

The JS APIs wouldn't be able to be re-used in this context, for example, since it isn't written in a componentized way (it was hard enough to get it to work in the Customizer). I think we really just need a multi-select box with autocomplete for picking the posts to show and their order, so similar in some ways to the Customize Object Selector component.

On the PHP/data side, I don't know if we'd want to use the nav_menu to store the items being curated since then (which is a the same issue with the nav menus and the Custom Menu widget) we could end up with lots of menus listed on the nav menus admin screen which could be deleted out from under the blocks (and widgets) that use them.

On the frontend rendering side of things, using a nav menu walker doesn't seem the most appropriate either since the curated items being discussed here are not nested: also, multiple plugins/themes attempting to extend the same nav menu walker is a challenge. To me it seems like the frontend should just be a straight WP_Query with The Loop™ iterating over the IDs for the posts that had been curated. The theme can then override template parts, for example, to handle the rendering of a given curated item.

[karmatosed]

I may be reducing this too much, but why can't we just use a post block? I think I am understanding the suggestion to want a block that can contain a range of posts. I keep coming back to this being achieved by a single block being used as many times as you want. That feels more like a good mental model - to encourage block by block page building.

[westonruter]

@karmatosed using the post block could work for curation, but only once we have nested blocks. Also, I think one of the benefits of having a block for curation is that all of the blocks could get the same styles applied (e.g. show excerpt, show image, show date, etc). Maybe this would be addressed by an eventual ability to select multiple blocks at once, and if they are all of the same type, show the toolbar and inspector for all of them and have the changes made then be propagated across all of the selected blocks. @jasmussen is this being planned for?

[jasmussen]

Was about to ask how this block was different from #1466, as the "curation" confused me. But upon a little further digesting, I understand that it's about highlighting posts or pages or whatever content you might have? If that is correct, then the followup question might be — is this a separate block, or is this an attribute of other blocks? Like, would there be a "Featured Content Block"?

The more I think about this the more I see the complexity. Feels like it might not be a separate block, but rather a collection that can be invoked from other blocks, that simply then display it. Tricky stuff to get right for the UI. CC: @mtias @melchoyce

Maybe this would be addressed by an eventual ability to select multiple blocks at once, and if they are all of the same type, show the toolbar and inspector for all of them and have the changes made then be propagated across all of the selected blocks. @jasmussen is this being planned for?

So, I think the purpose of #1516 is, in part, to be able to do something in this vein. How often have you had to put an image on the left, a headline and bit of text on the right, then a separator, and then you have an "employee card" where every block inside can be filled out on their own.

How we get from that idea, to dynamically filling out the content based on a query, is an interesting UI challenge.

[westonruter]

@jasmussen I think the thinking behind this issue is that it is essentially identical in appearance as the Latest Posts block (#1594), but the posts that appear in the list are manually curated as opposed to being populated by a query (as the “Latest” Posts block does).

[davidakennedy]

I could also see this replacing something like Featured Content, created via Jetpack.

[gorgoglionemeister]

To me it seems like the frontend should just be a straight WP_Query with The Loop™ iterating over the IDs for the posts that had been curated.

For each URL, WordPress associates a query. For example, on the home page, WordPress associates a page post type. Now a page post type is a part of the HTTP response (web page). To get more posts and build an HTTP response (web page) made up of multiple posts (as in a multi panel page), you have to do other queries. In the future, will Gutenberg (or its evolution) and WordPress be more flexible? How Gutenberg (or its evolution) will relate to the primary query? Are there any ideas on that?

[karmatosed]

As the project moves towards merge proposal, we are moving issues that aren't needed for that to projects. This doesn't mean they won't get done, they totally can and that's why we're moving to projects. This allows us to focus on the issues that have to happen to Gutenberg. I am closing this but it will live in projects.

[celloexpressions]

To clarify the earlier confusion, this is intended to be the same thing as a "Featured Content" block. Noting, however, that featured content should be able to support both posts and taxonomies, including of custom post types. These are concepts of data/content structure that cannot be replaced with blocks.

A well-executed navigation menu block that includes excerpting functionality could serve the same purpose as this block. However, the presentation would typically be much different. The suggestion to leverage the existing menus API demonstrates the similarities in intent. This would be used relatively commonly, and as such needs to be considered more carefully before an initial version of the navigation menu block is shipped in core.

[celloexpressions]

I would like to request that this issue be reopened to revisit the concept of a curated dynamic content (featured content) block. This would essentially be a "manual" query block. Instead of showing posts from a specific query, users could select specific posts to show in a post list. Ideally this would include UI that allows users to select posts without having to find the post ID. This is a way to feature specific site content on front pages, in a header/footer, or even within certain posts. An existing workaround is to use extra taxonomy terms (such as featured) to dynamically group curated content.

The main technical change from the initial proposal is to reuse elements of the query loop and post template blocks instead of the core nav menus API. However, it should still leverage the show_in_nav_menus post type support to determine what content to let users select from.

Noting that this was closed during the initial plugin merge phase and is now more relevant with the inclusion of site editing and the query loop/post template blocks.

[mtias]

Maybe the thing that makes more sense is to have a "Post" block and you could stack them.

[celloexpressions]

Noting that the issue referenced above is identical to this issue in purpose/goal. It correctly identifies that the best workaround is to create a taxonomy term containing the desired posts, and filtering a query block to that term. That causes real frontend side effects depending on the taxonomy that you use. It also doesn't make sense in terms of content structure if that term only exists to filter a single query loop. I just had to create a new hidden taxonomy with several terms that are each mapped to a single query loop blocks to achieve this effect on one of my sites.

Based on the current (generally useful) state of the query loop block, I would also suggest that "curated dynamic content" (functional, not actual proposed name, maybe "featured content" is easier to grasp) should be a variation of that block (or an option within it). Adding a "featured" tag to curate dynamic content is clunky and feels outdated (Twenty Fourteen, anyone?).