Block: Extend curated card collection to support Custom Post Types

[jwold]

Feature description

Currently the Curated Card Collection block allows for creating cards based on posts. We'd like to extend that to include cards from pages, and custom post types.

Inspiration: Hand-picked Products

Sorting: Need to think about that and the accessibility. (And filtering)

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

1. When using Curated Card Collection, I am able to filter by:
   1. Posts and pages
   2. Custom post types
2. As an editor, I am only able to select one content type at a time
3. When displaying filtering options, performance should be considered (See how curated block has a search and scrolling list of posts)
4. Only display the radio buttons for content selection if custom post types are available.
5. By default make posts and pages selected
6. Add ability to sort chosen cards hold for now JNW
7. Extend recent posts block as well. Hold for now JNW

Implementation brief

QA testing instructions

Demo

Changelog entry

[jwold]

• Thinking about leveraging with something like Woo. We cover blocks for post/page.
• If a site has a product, can I leverage other plugin data output
• If I'm using an existing Woo block, maybe on onboarding I have a button that says put the steel hammer on overriding what that looks like.
• Next step is to see if there's any specifics to tackle.
• Products for Woo, Events for Events calendar.
• People may use CPT in interesting ways. Translations and duplicate content.
• From the engineering side if we hotwire block to support any CPT
• New AC: supports any CPT with title, content (such as recipes)
• Create new issue for situation where we want to explore matching other plugin functionality

• Not phase 2, but would like to hear if this is requested

[jwold]

This is useful, but I think it’s ok to wait until a need arises.

[jauyong]

Reopening after discussing with Rody on 12/7

[jauyong]

Next step is to get an IB written

[jauyong]

@jwold to give input on UX and meet with an engineer to validate functionality

[jwold]

@jauyong this is ready for an engineer to review, or for the team to discuss in backlog grooming.

[technosailor]

Leaving this for someone to pickup as I offboard.

Most of this is done (I believe).

• UX update to include post types. (CPTs included are all that have show_in_rest and are not post, page, attachment, or wp_block)
• Enable "state" on the radio button
• Create REST API endpoint for retrieving multiple post types. In practice, this is only needed for "Posts and Pages" because UX is radio button and only one can be selected. Only P&P represents multiple post types. Endpoint is /material-design/v1/post-types/get-posts
• Component for retrieving posts with apiFetch when using the custom end point. Default usage for CPTs is to use core REST API modules that already exists.
• Do the logic modification for which radio is is checked and alter REST API endpoint integration