Feature/php post type and taxonomy scaffold

[darylldoyle]

Description of the Change

This adds a PHP Scaffold for adding Post Types and Taxonomies to the scaffold.

Whilst this isn't needed, it means that implementation would be very similar across projects, reducing cognitive load when context switching. It would also allow engineers to pick up newer projects much quicker.

Below is a screencast of me using this to create a new post type and taxonomy.
https://capture.dropbox.com/L7fP0jGYEvLobArN

Closes #175

How to test the Change

Check out the branch and try it out

Changelog Entry

Added - New PHP scaffolding for post types and taxonomies

Credits

Props @darylldoyle

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.

[fabiankaegy]

Thanks for adding this :) I left some thoughts inline.

Also just so you are aware, I've been working on a similar PR in the UI KIt Scaffold. https://github.com/10up/ui-kit-scaffold/pull/8

Whatever we come up with should be shared between the two

[darylldoyle]

@fabiankaegy I've updated this PR and added a first-draft of the docs for adding post types. Can you please review?

[fabiankaegy]

This is great :)

Let's ship this as is. Long term I would love to remove the Demo.php file from the scaffold and instead have some code generators that allow you to add them.

[dsawardekar]

Great job on this, @darylldoyle! Thanks for putting it together.

A point that might need further clarification is the inclusion of the Post & Page classes. This has been a frequent area of confusion, given the existing Post and Page post types in core. The addition here might seem redundant to some, so expanding on their purpose and functionality could help clear up any misunderstandings.

The class hierarchy for these classes seems incorrect. Maybe we should extend the AbstractPostType, and add no-op with comment(s). That way it is clearer that these are not stub classes, and customization to Core Page / Post post types should go here.

[nicholasio]

@darylldoyle Could we add a more structured way for registering custom fields? I'd love to use register_rest_field and/register_meta registering custom fields in this way where you also declare the "schema" makes things easier for headless projects. I'm thinking mostly from a REST API standpoint and not really thinking about us creating a wrapper around rendering the custom fields in the editor.

The end goal here is to make sure we're consistent in how we are exposing custom fields through the REST API. There are lots of ways to do it and it doesn't always get added to the REST API schema.

See this for example: https://github.com/10up/headstartwp/blob/develop/wp/headless-wp/includes/classes/Preview/PreviewLink.php#L36

[darylldoyle]

@dsawardekar I'd love your eyes on the latest update I've pushed. It introduces an AbstractCorePostType class that extends AbstractPostType and kills any methods not needed by the core post types. That allows us to maintain the same interface for taxonomy registration and the after_register() method.

@nicholasio I've spoken about this topic at length with @ivanlopez on our 1:1's. There are a bunch of ways to do it, we just need to find a way to handle it in a way that's both flexible and as simple as possible for smaller projects. Can we continue this discussion in #227, please? I want to keep this PR solely to the registration of post types and taxonomies 🙂

[dsawardekar]

@darylldoyle I like the after_register, it will make things a lot more predictable across projects. Looks good to me.

This might be on your radar. This PR opens the door for integrating scaffolding commands that can rapidly bootstrap new Post Types and Taxonomies. :)

[theskinnyghost]

I'm here after reading the internal blog post and I was wondering if you were aware of the "Extended CPTs" library created by the core committer John Blackbourn.
Basically it extends the default WP functions to register CPTs and Taxonomies to include additional parameters to make things like adding custom admin columns, filters, etc.. much easier. I've used it in a few projects in the past and it works great!
I thought I would share it here in case you'd be interested in using it in these abstract classes.

[darylldoyle]

Thanks for flagging that @theskinnyghost; I'd not seen that before.

Whilst I think it's a great concept, I think it does too much to be a core part of the scaffold. However, I would love to see us provide ways to pull in parts of what it does. It'll definitely be a great source of inspiration.

@dsawardekar that scaffold command is definitely on my radar and is something that @fabiankaegy has already been working on for blocks. I'd love to see us have something akin to artisan in Laravel:

wp 10up create post-type report --hierarchical