This is the 11th day of my participation in Gwen Challenge
WordPress: Understanding and Working with Data in WordPress WordPress: Understanding and Working with Data in WordPress WordPress: Understanding and Working with Data in WordPress It’s no exaggeration to say that this is something every WordPress developer should learn.
The series is also available in translation on the WordPress university website. But still not as deep as their own translation learning understanding, so I decided to translate again, at the same time will add their own understanding and expansion.
Understanding and using data in WordPress – Introduction
This article is part of a series on Understanding and Working with Data in WordPress
A WordPress site consists of three main elements:
- WordPress itself
wp-contentContents of the directory, including themes, plugins and uploads (Themes, plugins and Uploads)- Database, where all the content is stored
Most WordPress users never use databases directly, and may not even know that databases constantly populate their sites.
When WordPress provides any type of page (whether it’s a home page, a single post or page, or an archive archive), access the database to display what editors and administrators have added to the site.
In this series of tutorials, I’ll cover different aspects of a WordPress database in detail. The series will be divided into nine parts as follows:
- introduce
- Relationships between data
- Content type
- User data
- metadata
- [custom] taxonomy (
Taxonomies), categories [contents], labels and category items (terms) - The taxonomy (
Taxonomies) and post metadata - The options table
- WordPress multi-site data
In this introduction, I’ll give you an overview of database tables, how they relate to the types of content you might use in WordPress, and where to store them.
Content types in WordPress (Content Types)
Because database tables are used to store content, you need to understand the content first. There are several types of content in WordPress:
- Posts – the article
- Pages – page
- Custom Post types — Custom post types
- Attachments, accessories
- The links, links
- Navigation menu items — Navigation menu items (Navigation menu items as separate articles
postsThe store, or navigation menu item, is also a post, but of a different post type.
Each of these content types can attach some data:
- Categories — Categories
- Tags, labels
- Custom Taxonomies and terms — Custom taxonomies and items
- Post metadata — Post metadata
To avoid confusion with articles you see in WordPress, in most cases, the broad original English words of post will be retained
In addition to these, there are other types of content that are stored differently:
- Widgets – small tools
- The options – options
- The users – the user
- Sites – Sites (for multiple sites)
- Hardcoded Content — Hardcoded content (added to your theme or plugin)
- Sourced from elsewhere (via feedback
feedsAnd flowstreamingOr third-party content accessed by other technologies)
All of these types of content are stored somewhere in the database (or occasionally displayed in themes or plug-in files). They may have their own entries or be part of other entries (for example, streaming content encoded into a POST). They can also be linked to data in other tables. For example, data about articles will be linked to user data so WordPress knows who wrote which articles.
WordPress Database Structure
WordPress uses a series of database tables and their relationships to minimize the amount of data that must be stored — this creates a one-to-many relationship.
This means, for example, that a user can have many articles related to their user history. It saves space — if WordPress stored all user data for each user for each post written, that would mean a lot of duplicate data and a lot of space.
The following image is taken from the WordPress Codex and shows the relationship between the database tables and their links:
The following figure shows the latest entity relationship diagram of the database provided by WordPress Codex in WordPress 4.4.2. The relationships between the tables are basically unchanged
As shown in the figure above, the database table relationships and structure have been adjusted, but overall there are no major changes. A few points to note:
- The only thing that matters is that there’s one more
wp_termmetaTable that stores metadata for WP_TERM.wp_postsandwp_commentsPass between tablescomment_post_IDField association, which for some reason is not shown in the official website diagram.- The relationships between tables are no longer implemented through primary foreign keys (which WP3.3 seems to have done from the start), i.e. the maintenance of referential integrity relationships between tables is implemented through code. This seems to be the trend in modern database relationship maintenance, implemented by system functionality (code).
wp_linksSince the Links feature is rarely used, changes are largely obsolete. Therefore, the table can be regarded as an isolated table in practice, and it is not impossible to delete it completely in future versions. butwp_linksandwp_term_relationshipsThere is association, realize the relationship maintenance of links and corresponding classification items.
Most tables are linked to one or more other tables by a single field. This field is the unique identifier of the record, for example, post_id. The following table shows this in more detail:
| Table | Data stored | Linked to |
|---|---|---|
wp_posts |
Article, page, attachment, version (the version of the article modified) and menu navigation items | wp_postmeta (via post_id) wp_term_relationships(via post_id) |
wp_postmeta |
Metadata for each post | wp_posts (via post_id) |
wp_comments |
comments | wp_posts (via post_id) |
wp_commentmeta |
Metadata for each comment | wp_comments (via comment_id) |
wp_term_relationships |
The relationship between taxonomy and POST | wp_posts (via post_id) wp_term_taxonomy (via term_taxonomy_id) |
wp_term_taxonomy |
Taxonomy (including categories and labels) | wp_term_relationships (via term_taxonomy_id) |
wp_terms |
Your category items, label items, and items assigned to custom taxonomies | wp_term_taxonomy (via term_id) |
wp_termmeta |
Metadata for taxonomy items | wp_terms (via term_id) |
wp_links |
Links in blogroll (if you have one) | n/a |
wp_users |
The user | wp_posts (via post_author) |
wp_user_meta |
Metadata for each user | wp_users (via user_id) |
wp_options |
Site Settings and options (via the Settings screen and via themes and plug-ins) | n/a |
N/A is an abbreviation for the English word ‘Not applicable’ and similar words, often seen in charts.
Blogroll is a collection of blog feeds, and most bloggers offer blogroll on their personal blogs. This allows readers to connect to the blogs of others with similar interests and writing styles. Most blogging engines manage blogroll themselves, generating their own XML format each time a reader requests a blogroll. Similarly, most aggregators can import blogroll and automatically preorder the contained summaries
A few things to note:
- The default database table has
wp_Prefix. You can change this setting when configuring your site, but it doesn’t have much value. - The core is
wp_postsTable, where most of the data will be stored. That pretty much pulls everything else together. wp_optionsThe table is not attached to any other tables. This table stores data about the site and WordPress installation, not posts or Users data.- Two tables are used to store data about taxonomies — more on this later in this series.
wp_usersandwp_commentsThe table is unlinked — while you can specify that you must register to post comments, WordPress doesn’t actually store data about a comment for every user who posts a comment.- A multi-site installation will have some additional tables. I didn’t include them here because they are beyond the scope of this tutorial.
Join content and database tables
After looking at the content types in WordPress and the database tables used to store them, it might be helpful to match the two. The following table shows which database table stores the corresponding type content.
| Table(s) | Content Type |
|---|---|
| wp_posts | Posts, pages,custom post typesPosts, attachments, navigation menu items, hardcoded content(if added to posts) |
| wp_post_meta | post metadata |
| wp_terms | Categories, tags, taxonomy terms |
| wp_term_taxonomy | Taxonomy terms and taxonomy |
| wp_users | users |
| wp_options | Widgets, Options, Hardcoded Content (if added to Widgets) |
| wp_links | links |
Hard-coded content and third-party content that may be saved to a related table or remain in a file if a save or add is performed:
| Content Type | Table(s) |
|---|---|
| hardcoded content | wp_posts (if added to posts) wp_options (if added to widgets) Theme and plugin files (if hardcoded) |
| third party content | wp_posts (if added to posts) wp_options (if added via widgets or plugins) Theme and plugin files (if hardcoded) |
You may have noticed that not all database tables are contained in this table. This is because some are used to store metadata, while others are used to store relationships, which are covered in more detail later in this series.
summary
Hopefully, you now have a better understanding of how and where WordPress uses database structures to store different types of data. This article series will explore all aspects in more detail.
In the next section, I’ll look at relationships between data and discuss in detail how specific tables can be linked and how some tables can be used purely to store data about relationships.