0
  1. In looking through the code for Pippin Williamson's Easy Digital Downloads, I notice that he uses custom tables AND custom post types.
    1. I also see (roughly) the same Tables/Custom Post Types config in Gravity Forms, GiveWP and so many other popular plugins.

Note: On the "Should You Do Custom Tables" argument, Pippin provides his rational for Custom Tables in this excellent post.

There used to be a mentality among WordPress plugin developers that you should never use custom tables in your plugin because it wasn’t the “WordPress” way. Let’s start by throwing that attitude out the window.

When it comes to storing large amounts of data that does not very closely mimic existing WordPress database schemas, you should absolutely use custom tables. Choosing not to use a custom table will likely cause more harm than good. While it’s possible to store almost anything you want as a custom post type in the wp_posts table, that does not mean you should or that it is even a remotely good idea.

Given these realities, I'd like to skip the usual "You should never do this" argument for now. This thing is happening :) What I need to know is how is it done?

Problem: I do not understand how the relationship(s) between the Custom Post Type and the Custom Table are established and maintained.

  1. Should I store the Custom Post Type data in the Custom Table (vs. wp_posts)?
  2. Should I store the Custom Post Type's metabox data only in the Custom Table?
  3. Do I use the save_posts hook to handle DB Crud?

Please advise.

Thanks

3
  • Lots of abstractions and custom SQL! One of the reasons it's better to structure things to use CPT is because it saves a huge amount of time, and brings a huge number of freebies and benefits, including performance benefits most people are unawares of, such as WP_Cache and object caching. All of that needs rebuilding from scratch for tables. Having said that, just because a popular plugin does it doesn't mean it's a good example to follow. The decision to use a custom table is almost entirely determined by the kinds of query you plan to make, else data should just use post meta
    – Tom J Nowell
    Commented May 2, 2018 at 1:01
  • @Tom J Nowell - "The decision to use a custom table is almost entirely determined by the kinds of query you plan to make". So true. I feel that I have a proper use-case for using a table as outlined in Pippin's article (i.e. I'm storing multiple data that needs to support calculation queries). So i just wanted to get right to the "HowTo".
    – sleeper
    Commented May 2, 2018 at 1:10
  • Just keep in mind that would mean slowness of some kind and scalability restrictions regardless due to the need for table scans. Precompute when you can and store approximations that can be queried fast. It might be that what you're trying to do would be faster if you stored buckets and precalculated values in terms
    – Tom J Nowell
    Commented May 2, 2018 at 20:05

1 Answer 1

2

Should I store the Custom Post Type data in the Custom Table (vs. wp_posts)?

Yes, wp_posts has really no space for custom data. The only place would be wp_postmeta. Since we're throwing the argument out of the window, you'd store any additional info tied to a post in your custom table.

Should I store the Custom Post Type's metabox data only in the Custom Table?

That entirely depends on you. You can use a combination of the two, too. You can store simple things in wp_postmeta if you like, and the rest in your custom table, or everything in your custom table. If you're greatly extending what the custom post is, you can store that in your custom table, but for meta data like yes/no values, you can keep storing them in wp_postmeta.

Do I use the save_posts hook to handle DB Crud?

Yes, you would. Keep in mind that it gets fired for everything all the time. So a few checks, such as whether you're saving the post type you're interested in and whether this is a manual or auto-save, are required, but with save_post you're guaranteed to always catch every save (incl. when something is newly added).

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.