WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 13 months ago

Last modified 9 days ago

#14558 closed enhancement (wontfix)

Separate Database Table Support for Custom Post Types

Reported by: rahul286 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: Cc:

Description

While working on custom post types, I felt need for this enhancements.

This can be achieved by adding an extra argument to the register_post_type function like below...

register_post_type( 'acme_product',
    array(
      'labels' => array(
        'name' => __( 'Products' ),
        'singular_name' => __( 'Product' )
      ),
      'public' => true,

      /* Database separation */
     'db_tables' => array(
        'prefix' => '', //by default, value of $table_prefix will be used. If user sets this value to something, it will be used as prefix for both of following tables
        'base_prefix' => '' , //this will control it tables are to be kept sitewide or per blog 
        'posts_name' => 'acme',
        'postmeta_name' => 'acmemeta',
      ),
  );

This small enhancement (not from coding perspective) will help more plugins authors go for custom post type.
Reasons are - first they will get option to have separate data storage.
Second - if some other badly coded plugin manipulates wp_posts table in some wrong way, it won't have sideeffect on third-party data.
Third - Plugin authors will get more space to experiment as at any time they will be dealing with their own plugin's data.

Of course, one of the goal of this nice feature must be to abstract database layer, but as a developer I feel it would be better if I can have some control over database without loosing power of this new (custom post type) feature.

Change History (8)

comment:1 follow-up: @westi5 years ago

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

This is not something we would likely consider.

We are happy with storing the custom post types in the existing table structures.

We don't recommend on adding extra tables - in some installation scenarios it isn't even possible.

comment:2 in reply to: ↑ 1 @rahul2865 years ago

@Peter (westi)

Of course you know better and I respect ur opinion.

But can register_post_type be extended (as a class) or atleast changed to have enough actions and filter so experienced developers can take some extra efforts where this kind of requirement is critical for this.

I really do not believe in copying lots of codes from core and then patching them up to get desired results. It becomes harder to maintain.

Anyway, thanks for being so quick to reply. :-)

comment:3 @nacin5 years ago

  • Milestone Awaiting Review deleted

comment:4 @martin.krcho13 months ago

  • Keywords changed from post type, database to post type database
  • Resolution wontfix deleted
  • Status changed from closed to reopened

This is something I would like to see in the future versions of WordPress as well. I am currently deciding between custom post types and something completely separate.

comment:5 @dd3213 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Re-closing due to the first comment still holding true.

Storing the posts in a different table will ultimately make very little difference, future WP_Post child classes will handle the requirements devs need with easier access to a different set of fields.

comment:6 @danieliser8 months ago

This may not be the best place but what we really need isn't CPT in a CT, but rather an API to easily generate the post type editor page with custom data feeds.

The CPT UI, Permalinks, Taxonomy Integration etc are the factors we are struggling to keep, but the data constraints make things like e-commerce or any other data that requires reporting very difficult without Custom Tables.

I am considering the implications at this point of a Hybrid option. Use CPT to store the primary info & ID, then modify the query to JOIN the CT data. It's definately not the way I would prefer to do it but even with the extended query it should be fast, and easily searchable using a JOIN in the other direction.

comment:7 @SergeyBiryukov8 months ago

  • Keywords post type database removed

comment:8 @DrewAPicture9 days ago

#28519 was marked as a duplicate.

Note: See TracTickets for help on using tickets.