Custom Post Types database persistance. Why not?

Question

My background is .NET/C#/Laravel e.t.c

I am beginning to like very much WP and i started educating myself on using WordPress as a development framework.

I tried something very simple. Create an entity and have a basic CRUD on this entity and then show it up in my frontend. Nothing tricky right?

So after reading i found out that one way to do this is to create the entity (aka Custom Post Type) , create custom fields (aka my entity properties) and let WP backend do the CRUD.

Then i could use various techniques to show the data in the frontend.

To my great surprise i found out that the CPT are not persisted in any wp table, and that when i disable my plugin i loos ethe CPT but i do NOT loose the underlying data!!

Imagine my surprise , due to the fact that i am used in having absolute db integrity.

And i wonder , why was it decided that CPTs are working in this way?

Answer 1

I don't think there is definitive answer (there might be old discussion buried in some ticket), but I can offer some historical perspective.

WordPress didn't start with Custom Post Types. They were relatively late addition. While they were modeled after native post types, those still remain kind of special case.

So the concept of such split was kind of already in place — post data was stored in database and logic governing it was stored in runtime code, before CPTs even existed.

In addition WP hooks system and plugin activation/deactivation favor runtime code approach as well. Implementing activation/deactivation in plugins is kind of clunky and most plugins simply don't bother with those routines. For a long time themes didn't even have a way to run activation/deactivation logic without some creative hacks.

Additionally post registrations contain localized strings and WP localization workflow works by extracting strings from source code. Storing those in database would require having two different workflows for compiling list of localized strings. As well as hugely complicate their changes on updates.

In a nutshell — the implementation is simply consistent with WP history and typical practices.