When building custom blocks for the WordPress editor, sometimes we want to make them only available on specific post types.
The WordPress block editor supports a link picker that we can add to our custom blocks. The best bit is we can restrict its searches to a post type of our choosing.
Ever needed to search for a post by something other than the title or post content? If you've built a website with custom post types that have additional fields, it's a good chance that admins will need to search on your custom meta.
WordPress custom post types can be very useful for storing all sorts of different types of data in WordPress -- and I should really write a post about that some time. But the date a post was published, i.e. its post_date, isn't important for many custom post types. So why have a drop-down list of dates to filter your custom posts types by if you don't need it?
When you create a custom post type in WordPress, you can ask register_post_type to generate a default UI for managing your post type in the admin. When you edit your post type, WordPress generates the familiar post editor, just for your post type. You can change it through a variety of hooks, e.g. if you want to add some new meta boxes. But what if you don't want any meta boxes, not even the standard ones?
In my quest to bring an object oriented separation of concerns to my WordPress plugins, I tend to separate the administration of each custom post type into its own class. I do this by looking at the global variable $typenow after the admin_init action is fired. But $typenow isn't always set after admin_init, so I have to improvise a little.
When you edit a new post, page, or an object of a custom post type, WordPress generates a slug or post name that will be used in its permalink. It derives the post name from the title you gave it. Sometimes, however, you want the post name to have a little more information in it.