Home/ Questions/Q 8079433
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T16:05:54+00:00

WordPress’s datamodel provides extensibility through it’s meta tables (aka, wp_postmeta, wp_commentmeta, wp_usermeta). This name/value

  • 0

WordPress’s datamodel provides extensibility through it’s “meta” tables (aka, wp_postmeta, wp_commentmeta, wp_usermeta). This name/value pair linking is extremely flexible and supported by WordPress’s API. All good reasons to celebrate it but it also can get quite non-performant if you have lots of extension attributes hanging off of your transactions. Let’s say, for instance, that I have a Custom Post Type called “Blood Test” and I want it to be able to capture 30-40 different measurements coming out of the blood analysis. Is it practical to use this wp_postmeta joining for each test? Probably not.

I could go completely bespoke and build tables left and right but what I’m wondering is, is there not a way to at least build an “80/20 rule” and have a generic extension table that provides a static number of additional columns to put SQL-searchable attributes and then end with a column for a JSON object that would allow for non-SQL searchable attributes to extend to an almost unlimited amount? Something like what is diagrammed below:

comparing the two models

I was thinking that by doing this one could also extend the WordPress API so that most development could largely be ignorant of this structural difference. Something like this:

EXAMPLE OF REGISTRATION API:

$my_meta_ext = new WP_Meta_Extension( 'post' );
$my_meta_ext->add_tran_type( 'blood-measurement' , ( 'col1' => 'total-cholesterol' , 'col2' => 
'triglycerides', 'col3' => 'etc');

EXAMPLE OF USAGE API:

add_ext_meta ( $term_id, 'blood-measurement.total-cholesterol', $meta_value );

Ok, so here are my explicit questions for the group:

  1. Does this make sense? Do you see value in this? Does anything like this already exist in a ‘plugin’ form (or otherwise)?
  2. If you were to use one extension table across all types (aka, posts, comments, users, etc.) would you be able to build an index in mySQL that was efficient? Is it better just to have a table per type?
  3. Does anyone have any metrics — even if they’re not fully proven out — on when the default wordpress extension model starts to degrade in performance?
  4. If you’ve done something like this already … any key lessons learned when extending the model? How complicated of a task is this?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I brought this topic into a specialist WordPress working group in London and while we didn’t arrive on an answer there was pretty clear agreement that this type of solution would be highly valuable. Furthermore, I have decided to start a GIT repository with the intent of developing a plugin to address this (hopefully with the generous support of the group in London or any of you who are reading this and feel you could help).

    The repository can be found here:

    https://bitbucket.org/ksnyder/wp-database-extension/

    Please understand that at this moment there is really just an idea, a high-level design, an interface spec, but no real code. That will change of course and it will change more quickly if you’re willing to help us with this endeavour (mind you I have no personal experience running distributed development but you have to learn somewhere).

    • 0