Translated from 日本語 • View original I was a little worried that the WordPressCodex database structure page was difficult to see and the specifications were outdated, so I was thinking of rewriting the database specification myself, but the work of developing systems in WordPress has increased rapidly, and I need to understand the mechanism of the multisite system. It has become difficult to design a system without transcribing the WordPress database specification in the form of a cheat sheet. So, I wrote my own database specification (table definition).
Basically, I looked at the Japanese version of Codex and the original WordPress.org site and compared it with the actual database structure, but there are still many unclear parts of the multi-site table (especially the wp_sitecategories table... Has this table been dropped since WP 3.0? … Like).
Well, I've written it all down, so I thought I'd share it here.
- PDF format: WordPress3.4.xDataBase (655KB)
Version: 0.1
Now, on a different page (... However, the new stable version of WordPress 3.5 was released on 12/11 this month, so I immediately upgraded this developer to 3.5.
I was hesitant to upgrade because the automatic update from the admin panel didn't work well (it timed out while fetching and deploying package data), but it was too much of a hassle to review the PHP settings, so I ended up updating it manually. After the update, it seems that the theme and plugins are working without any problems so far, but the admin panel is constantly notified that WordPress automatic update failed... (It doesn't seem to have much of an impact, so I'll fix it soon).
That's why WP is now 3.5, so I took a look at the version 3.5 database to try to match the configuration with the database specification I wrote.
I took a quick look at the structure, and there were no changes to the database in 3.4.x → 3.5 (although I haven't matched the multisite side...).
This article is likely to be the last devlab post of the year.
Have a good year, everyone.