Make WordPress Core

Opened 14 years ago

Closed 11 years ago

#12510 closed feature request (wontfix)

There should be an API to register post_types and post_status

Reported by: ceenz's profile ceenz Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: reporter-feedback
Focuses: Cc:

Description

Presently the available (default) post_types and post_statuses are stored in wp-includes/post.php and called on init.
Shouldn't they be stored in the DB (perhaps in the options table). This would make it much easier / cleaner to add / manage custom post_types.
Essentially as the post_type array contains meta-data about that posts of that type I don't believe that it is good practice to store that statically.

This could be very easily implemented for 3.0 release and clean up a whole lot of hacking / issues and make a uniform way of storing custom post_types.

Change History (8)

#1 @Denis-de-Bernardy
14 years ago

  • Priority changed from high to normal
  • Summary changed from Shouldn't post_types and post_status be stored in DB? to There should be an API to register post_types and post_status

There should be some sort of register() action. I think this was discussed in the custom post type discussions.

#2 @ryan
14 years ago

  • Milestone changed from 3.0 to Future Release

Currently, the lack of storage is by design. We might add it later once some storage issues are worked out.

#3 @ceenz
14 years ago

  • Keywords cck added

The current problem is that now plugins dealing with custom content types all store that data in different places. This means that it is very hard to manage and that when the plugin is removed you loose all the defined custom content. It also means that you have different plugins defining custom content differently and not being able to interact with each other.

If this is by design it seems that the design may need improvement. What are the actual draw backs of storing this small data in table, all custom content plugins are already doing this in their own haphazard way?

#4 @ocean90
13 years ago

  • Component changed from General to Post Types
  • Keywords reporter-feedback added; post_types cck removed

What should be saved in database and why?

#5 @sillybean
11 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

register_post_type() now exists; work on register_post_status() is ongoing in #12706. Closing in favor of that ticket, which has a lot of activity.

#6 @dd32
11 years ago

  • Milestone Future Release deleted

#7 @johnbillion
11 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

This ticket is about storing registered post types and statuses persistently in the database, rather than registering them at runtime. It's not about the functionality in general.

#8 @johnbillion
11 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.