Add an Object-Relationship Table

The ID is stored in the database. The interpretation of it is added through code at load time, when registering post types and taxonomies.

If so, that’s a terrible design.

This plugin has 801 lines and it doesn’t even register any taxonomies, just “makes registering user taxonomies work” [testing needed]. And the code is extremely hacky. This is a good example of something that is outside the scope of taxonomies as currently implemented.

That’s how it evolved. The posts table contains the post_type column, but if it isn’t registered, it is ignored as if it doesn’t exist.
The term_taxonomy table contains the taxonomy name and description, but unless it is registered, it is ignored.
Edit: that description is for the term, and the taxonomy is the slug.

1 Like

Could be that the reason WP never (wanted) to adopt the idea of universal object relations is that there are too many relational relationships and unless you use Redis and serious local storage callbacks for the db results, you will never get something as large as WP [CP] to load pages very well.

IMO: This is what CPT (Custom Post Types) are for. You need a custom setting to function 100%; you will only achieve 99% using a direct schema to the simplest query possible. If you need a user relation to your post_meta, make the CPT call the least number of joins and never go any deeper than two or three tables.

If you need a one-size-fits-all query (obj-engine) or you need a query anything relative to my CMS tool; you won’t use post_metas nor will you use WP existing tables. CPT and custom tables is your only truly effecient solution.

This isn’t so much about an alternative to CPTs as an alternative to relying on custom taxonomies and term meta.

Yes, @timkaye the scope of this thread is about taxonomies, so this is why CPTs are really the sound answer. Using a WP post type and then expecting the World of WP or CP to build into the core something that would be robust and fool proof, would take way more time and effort than one making their own CPT with associated terms and taxomonies, unlimited to the relationships you could use.

Point/case would be building custom tax and terms via a database table which is designed to allow open end joins and meta queries to any degree needed to accomplish one’s task. You could build several tables, just for a single query if you needed to. Although less is better, as far as creating tables, as long as the CPT plugin was built to remove all tables on request, this would still beat trying to reinvent the wheel for something—that very few people would really ever need to use with WP/CP.

So basically that was my talking point on the above CPT used as a deep query model.

No, that won’t (and doesn’t) do the job. This proposal is about, for example, enabling connections between taxonomies.

I have a current project where making one taxonomy a child of a different taxonomy, which would itself be a child of another taxonomy, would be the sensible way to go. And this is for user objects, not post objects. But WP/CP just can’t cope with that, so it currently has to be accomplished with parallel taxonomies instead, while linking them using term and user meta. Which is a bit of a nightmare really, because both the bi-directional relationships and the UIs that taxonomies create automatically have to be built (and ensure they will be kept in sync) manually when using meta data.

The project I mentioned above has led to me creating a plugin that adds an object-relationship table to the database. The code, which is inspired by the above discussion between Greg Schoppe and Mike Schinkel (though they are not responsible for how I have implemented it), can be inspected at

Full details of how the plugin works are in the README file. As I say there, pull requests are welcome.


The plugin at now also includes a meta table and related helper functions.

The approach is deliberately simple. Any CP/WP object can be connected to any other object by specifying an ID and object type for each.

All relationships are treated as bidirectional, because that’s what relationships are. The nature of each relationship is not specified. It could be stored as meta data if desired, or just be a matter of code. (I have found that, so long as I know which objects are related, I know what I want to do with them, so trying to specify in the database what relationships are appropriate seems unnecessary and even counter-productive.)

Similarly, there is no attempt to differentiate between one-to-one, one-to-many, and many-to-one relationships. Whatever is applicable in any given case is simply a matter of what is returned when the database is queried; in a one-to-many relationship, for example, more than one ID may be returned.

1 Like

Trying to clean up petitions, do you think your approach/plugin can be the basis for core implementation or does it mean this can be left for plugins to figure it out and petition can be closed?

I think it’s the basis for core implementation. The reasons are (a) it’s very flexible, (b) it works in a very similar way to current tables, and (c) most importantly, putting it in core would mean devs could rely on its existence and use standardized functions to make use of it.

Others should, of course, review it first.

1 Like