No default Post Type/Create CPT with UI in core

[discobot]

CP is a CMS. The reason why Posts are seen as default content type in the dashboard is because WP was initially created as a blogging platform. Content/Data should be defined by the user. Hence, I propose that there should be no default post type in the fresh install/dashboard, and that a simple UI for registering CPT’s should be included. It can be called “Content”, with a submenu of “Create Content Type”. The reason for still registering as CPT is to adhere to WP ecosystem and database structure. I know… this can be achieved using plugins… But the being a CMS, there should be a way to distinguish one content from another at the core level.

---

Read-only archive: https://petitions.classicpress.net/posts/138/no-default-post-type-create-cpt-with-ui-in-core

Author: Raymund

Vote count: 4

Status: open

---

Comments

Gets my vote, but there are already several similar petitions, you might want to look into those and combine them into one.

~ posted by Pieter Bos

I did find a petition to change posts to articles or make it editable, and no default sample content, like posts. I find it cleaner and leaning towards a CMS if users themselves define their content using a CPT UI built in core. If they want “post” as a content type, they need to create it first as a content type. So if I am working on a healthcare app, and defined content types of patients and admissions, there will be no “post” as a content type… though everything is a post as a CPT…

~ posted by Raymund

This is 2 petitions in one. I would recommend splitting it as such, and closing this one:

• No default post types: If users want “post” or “page” as a content type, they need to create it first as a content type.
• Add a CPT UI to ClassicPress core.

I definitely don’t agree with the first proposal, because people expect WordPress (and by extension ClassicPress) to contain default content types. Internally, the default post_type is post, but in the admin dashboard, it is very clear what kind of object you are editing.

I think making it possible to rename or remove the default post types would be a better idea, but even then, they are deeply baked into many parts of the software (WP_Query, rewrites and permalink resolution, etc).

I think a CPT UI should also be done as a plugin. The way the core software expects post types to be registered is via register_post_type in plugin or theme code. Introducing a UI to do this would create multiple “sources of truth” for this functionality and store even more information about the structure and function of the site in the database instead of the code.

Having said that, it would be great to have a semi-official plugin to do either of these things, especially a CPT UI. This would live at ClassicPress Research · GitHub while it is explored as an experiment.

~ posted by James Nylen

Not including a UI for CPT creation would make core still lean, but it may help ordinary users add content type rather than coding. Maybe a core/semi-official plugin would do.

~ posted by Raymund

I definitely think something like CPT-UI should be limited to a plugin, if created. Post types come along with templates and code that has to match up by slug. Those templates are commonly committed in git and managed there, so the settings that define the post types should be in git too.

Defining in code also allows ClassicPress to be a more pure CMS, by offering a UI to manage content, but not a (core) UI to manage structure. Structure is the job of the dev team, not the job of the client.

I’m a big fan of offering UIs for CPTs and Custom Fields to those who want/need them, but that definitely seems more like a core-supported plugin than core functionality. The registration functions that power these plugins, however, would be core.

~ posted by Greg Schoppe

On the other hand, I also want an app platform that is simple, lean and fast. I don’t have a problem with creating CPTs either by code or UI. Maybe it is also a good thing to examine other UI aspects of WP that can be excluded from core to make the platform leaner and fast.

~ posted by Raymund

Defining in code also allows ClassicPress to be a more pure CMS, by offering a UI to manage content, but not a (core) UI to manage structure. Structure is the job of the dev team, not the job of the client.

Exactly.

~ posted by James Nylen

I agree with everything @James Nylen and @Greg Schoppe have said.

~ posted by Tim Kaye

Leaner, faster and more secured CP is better for me than UI in the core. I think there is no need to add additional UI elements that will slow core. I guess I’d have to unvote my own petition.

~ posted by Raymund

[viktor]

@discobot

Defining in code also allows ClassicPress to be a more pure CMS, by offering a UI to manage content, but not a (core) UI to manage structure. Structure is the job of the dev team, not the job of the client.

As stated above, core UI isn’t necessary for end-users. If they need it, they can use a plugin to create CPTs in admin.