I cannot tell that posts table is large − it’s very fat…
Please optimize it:
Don’t create revisions for all posts. At least add option for enabling or disabling this. This will reduce size of posts table in some times.
Why images and other multimedia content are stored in
posts table? Please move this to separate table. When I click on «Add post» link Wordpress creates empty record in posts table. Why?! And if I’ll press Cancel button this record will leave in table. And user cannot delete it using native Wordpress tools.
Read-only archive: https://petitions.classicpress.net/posts/166/optimize-content-table
Vote count: 3
@Vitalij: It would have been better to create three separate petitions because these are really three different issues.
(1) Don’t create revisions for all posts.
As Tim says, you can already do this. I think
wp-config.php is the right place to turn off post revisions.
(2) Why images and other multimedia content are stored in posts table? Please move this to separate table.
This has a number of unexpected implications. If I want post ID 123 in today’s schema, I know it lives in
wp_posts. However, if there are multiple post tables then ID 123 could refer to any of them. This would require a major refactoring to be able to handle correctly.
Also, a petition for the same thing already exists. Read the discussion there for details:
(3) When I click on «Add post» link Wordpress creates empty record in posts table. Why?! And if I’ll press Cancel button this record will leave in table. And user cannot delete it using native Wordpress tools.
I think the “why” is so that the first autosave works properly. That’s not really a great reason though, so this bugfix would have my vote.
I’d be happy to have this issue fixed, but it would require a pretty deep understanding of how revisions and autosaves work.
~ posted by James Nylen
This is confusing petition as
@James stated but I guess his main idea is to reduce database bloat, at least in terms of his #3 item here.
One thing WordPress Core used to do well was focus on avoiding data loss, which I think is how a CMS should work. Of course, this is before they started adding things like automated trash empty, automatic image compression, etc.
Database cleanup is something that should not exist in Core, ever, I believe, because its adding the risk of data loss. By default, any CMS should avoid any risk to data loss or quality loss. This forces advanced users to take responsibility for any data loss during their optimization work…
The database structure in WordPress Core is far from perfect, but things like orphan data, revisions, auto saves, auto drafts, should be discussed very carefully because there’s so many implications re: data loss.
~ posted by Jesse
This should all be closed as wont fix.
#1 is already something that can be done, while #2 and #3 would cause far more problems than they solve.
It’s time to stop such threads re-appearing because they simply confuse everyone about what we should be working on.
For reasons stated above, petition will be closed.