#40484 closed feature request (wontfix)
Create Custom Post Types directly in WP-Admin and Customizer
Reported by: | lukecavanagh | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7.3 |
Component: | Posts, Post Types | Keywords: | |
Focuses: | ui, administration | Cc: |
Description
Being able to add a new custom post type, is a fairly complex process for end-users, being able to add custom post types, custom taxonomies, custom metaboxes and custom edit column screen should all be achievable in the WP-Admin or possibly within the Customizer.
https://developer.wordpress.org/plugins/post-types/registering-custom-post-types/
https://developer.wordpress.org/reference/functions/register_post_type/
Change History (14)
#1
@
8 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
#3
@
8 years ago
Not that would warrant creating a UI inside of WordPress for people to generate CPTs. If you know what a CPT is, you're generally savvy enough to figure out how to install a plugin that creates the CPT for you, or make it yourself. I'd recommend non-technical users (like myself) use something like https://generatewp.com/post-type/ instead — and even a tool as straightforward as that, I find hard to wrap my head around. Adding that kind of complexity to core will add unnecessary complexity.
#4
@
8 years ago
But a easy to use UI could be created for WP core, for being able to manage or extend existing post types, taxonomies or create custom post types etc. I know other plugin solutions exist like
https://github.com/WebDevStudios/custom-post-type-ui
https://github.com/pods-framework/pods
Which both have easy to use UIs and achieve the same thing, but if using GenerateWP and then adding the code generated to a code snippet plugin or site specific plugin, is too complex for a number of end-users. Then something should exist in WP core.
#6
@
8 years ago
I feel you are talking about 2 different things @lukecavanagh. I can agree that adding a new CPT is difficult but thats not an end-user issue, or even a usual task for them. I absolutely agree what @melchoyce is saying, to use CPT is a very high user level.
When thinking about this I would encourage you to think outside what you want, what you think a developer wants and observe end users. In my testing not once has someone said about CPT.. most don't care or know what they are. They work through a theme or plugin and to a end user thats just that.
If you yourself wanted a plugin to do this, or you get enough interest with other developers - ace, do that. I do not think this is something that should be a core feature.
#7
@
8 years ago
I think it should be a core feature, the same reason why the Fields API, Forms API and Content API should all be features as well. Since it will help end-users be able to create and extend something that should be easy to use and makes WP more powerful.
#8
@
8 years ago
Creating a CPT is an end-user issue, if you explain what a custom post type is and using it with some metaboxes, how powerful that can be, without having to just install another WP plugin, then something like that should be in WP core.
#9
@
8 years ago
I'd recommend non-technical users (like myself) use something like https://generatewp.com/post-type/ instead
Surely this backwards logic was apparent the moment Submit was pressed. I couldn't agree more with the purpose of this ticket, though.
Since WordPress have tried so hard to become a legitimate CMS all these years, it would only be logical to finally include CMS-like features in core... even if I don't fully agree that Customizer should even exist in its present state.
#10
follow-up:
↓ 12
@
8 years ago
Drupal already has custom content creation in its core.
https://www.drupal.org/docs/7/understanding-drupal/content-types
This point explains it the best, for why end-users would care if it was explained and in core.
There are two main reasons for creating your own content type. First, content types lets you organize your site more efficiently. For instance, you might have "Info" and "News flash" as two simple content types on your site, rather than just using "Article" for both. Additionally, creating your own content type means that you can create custom fields. These fields can appear as text boxes, select lists, check boxes, etc., providing extensive functionality to content on your site.
#11
@
8 years ago
I agree with Luke that CPTs should be handled in core, but not in Customizer.
But my thought is that core should do it differently than it is done today. Today, every page load runs through the registration of the core post types and filters and actions. One the way, plugins can register their post types and actions and filters. So the post types are "known" for that page load, and it could be different for the next page load. That means that if the plugin is deactivated, that post type is not known (registered), so there could be CPTs in the posts table that don't have a known way to interact with everything else. But what if instead of registering on every page load, the registration is done once, and stored in the options table? Then the registration code doesn't have to run each page load. Instead the post types would be loaded from the options, and the data in the posts table is known regardless of the plugin running or not. With this sort of change, I could see core as the proper place for showing which post types are known and deleting them.
I think suggesting that CPTs be handled in all respects by core is a bit of a stretch to start with. But I think small things such as what the plugin "Custom Post Archives" does is entirely to be expected to be part of core. (it shows a list of post types and user can choose which to show archives and rss for)
#12
in reply to:
↑ 10
@
8 years ago
Shut. This. Down.
Drupal and Wordpress are often compared apples-to-apples, but, in practice, it's more apples-to-pears. The Wordpress platform/ecosystem supports a much broader range of end-user types than Drupal. Drupal's Content Types are great for developers that need a ready-to-fire content creation system, but I've seen some really poor Content Type implementations that muss up the Drupal admin interface and make creating content confusing and difficult to maintain or update.
If you've a large number of your users asking for custom content type creation as a part of the base Wordpress installation, then you should seriously consider engaging them in deeper conversation/research and developing a plugin to fit those specific needs. I appreciate that custom content creation is in the critical path of satisfying user requirements and I strongly believe that the Wordpress plugin community is delivering on those requirements by offering a multitude of options.
If you're a Wordpress end user and you need custom content creation, you're likely smart enough to navigate ACF/Types/PODS/register_post_type/etc to find the solution that matches your specific needs. If you're not, you're probably equally as unlikely to be able to light up a Drupal install and find your way through through Content Types.
Replying to lukecavanagh:
Drupal already has custom content creation in its core.
https://www.drupal.org/docs/7/understanding-drupal/content-types
This point explains it the best, for why end-users would care if it was explained and in core.
There are two main reasons for creating your own content type. First, content types lets you organize your site more efficiently. For instance, you might have "Info" and "News flash" as two simple content types on your site, rather than just using "Article" for both. Additionally, creating your own content type means that you can create custom fields. These fields can appear as text boxes, select lists, check boxes, etc., providing extensive functionality to content on your site.
#13
@
8 years ago
But ACF, Pods and Toolset are WP plugins and not something already in core. Also ACF is just for custom field creation with a UI and not for custom post types etc.
Closing this. I don't think anything's changed since Nacin closed the previous ticket (#12617):