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:

  1. WordPress itself
  2. wp-contentContents of the directory, including themes, plugins and uploads (Themes, plugins and Uploads)
  3. 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:

  1. introduce
  2. Relationships between data
  3. Content type
  4. User data
  5. metadata
  6. [custom] taxonomy (Taxonomies), categories [contents], labels and category items (terms)
  7. The taxonomy (Taxonomies) and post metadata
  8. The options table
  9. 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 articlespostsThe 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 feedbackfeedsAnd 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:

  1. The only thing that matters is that there’s one morewp_termmetaTable that stores metadata for WP_TERM.
  2. wp_postsandwp_commentsPass between tablescomment_post_IDField association, which for some reason is not shown in the official website diagram.
  3. 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).
  4. 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 haswp_Prefix. You can change this setting when configuring your site, but it doesn’t have much value.
  • The core iswp_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.


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.