[wp-trac] [WordPress Trac] #14558: Separate Database Table Support for Custom Post Types
noreply at wordpress.org
Sun Feb 9 14:31:06 UTC 2020
#14558: Separate Database Table Support for Custom Post Types
Reporter: rahul286 | Owner: (none)
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: Posts, Post Types | Version:
Severity: normal | Resolution: wontfix
Keywords: | Focuses:
Comment (by ReneHermi):
> The post_type column is indexed, so I don't see unsolvable problems with
Export/Import not but as you probably know we can not migrate and merge
data from one site just in time to another due to shared data that should
> Definitely plugin territory.
> I can't see why core should support this, given the complexity with
unique IDs that have to be solved.
That's the point: Due to the given complexity with the unique UID
we need to have a - preferably fully backward-compatible - API for CPT's
for custom tables that can be used by every plugin. This should start with
a plugin but it needs to get the full power and support of the core team
like the Gutenberg project has.
It's the core responsibility to show plugin developers the correct ways
how to store data in a table.
As the core was and as far as I know still recommends the use of CPT it's
core responsibility to fix what it has been caused by this short-sighted
implementation to denormalize the wp_posts table in such a heavy way.
We need to work on this together and WordPress core needs to include the
solution for storing custom post types in separate tables.
Core and plugin developers need to pull the same strings and work on a
common concept for reaching this. Otherwise, we will never be successful
with storing data the right way as it is much too complex to solve without
breaking millions of other sites.
First of all we need to stop recommending the use of CPT's as they are
immediate. WooCommerce is the best example: If they had foreseen that
storing orders and customer data in _post/_postmeta makes it impossible to
migrate staging/development sites they would never have done this.
Now they are locked in technical dept as many other plugin developers as
Having plugin developers storing all of their plugin data in CPT's in one
table indexed by a global unifier was never the right decision in terms of
good database design. It was a curse and a blessing. In the first years,
we thought it was a good decision as it made storing data just simply for
hobbyist developers and helped growing the WordPress ecosystem. Then it
turned out that it led to the technical debt that we have today.
Professional companies have a hard time to use WordPress because they are
not able to easily migrate data from one test environment another.
It should be especially in WooCommerce/Automatic intentions to get this
solved as their users would benefit heavily from this. This issue can not
be solved by a single person.
Ticket URL: <https://core.trac.wordpress.org/ticket/14558#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac