[WordPress] 外掛分享: Custom Post Type Tables

首頁外掛目錄 › Custom Post Type Tables
⚠ 此外掛已下架 — 不再更新維護,建議勿安裝。
60+
安裝啟用
★★★★★
5/5 分(3 則評價)
1048 天前
最後更新
0%
問題解決
WordPress 5.9+ PHP 7.1+ v1.2.6 上架:2023-03-29

內容簡介

WordPress的自訂文章類型通常會儲存在默認的文章表格中,但當網站有大量自訂文章類型時,查詢會變得非常昂貴,特別是涉及到生成元數據的外掛。因此,將數據拆分到單獨的表格中,可以加快查詢速度,改善組織和管理內容,和提高網站安全性。此外,外掛會自動重寫查詢來使用自定義表格,可與Multisite安裝、WooCommerce和Advanced Custom Fields一起使用。使用此外掛還可以增強WordPress的處理速度,並改進網站性能和安全性。

問題與答案:
- WordPress的自訂文章類型通常儲存在哪個表格中?
答:默認的文章表格(通常為wp_posts)中。
- 當網站有大量自訂文章類型時,查詢會變得昂貴的情況通常涉及哪些外掛?
答:生成元數據的外掛,例如Advanced Custom Fields。
- 把數據拆分到單獨的表格中,可以有哪些好處?
答:可以加快查詢速度、改善組織和管理內容,提高網站安全性。
- 使用此外掛需要注意哪些事項?
答:選擇自訂文章類型後,會在數據庫中創建一個新表格並轉移數據;請事先備份數據庫以避免意外情況發生;在編寫自己的查詢時,尽量指定所需的自訂文章類型來減少不必要的查詢。

外掛標籤

開發者團隊

⬇ 下載最新版 (v1.2.6) 或搜尋安裝

① 下載 ZIP → 後台「外掛 › 安裝外掛 › 上傳外掛」
② 後台搜尋「Custom Post Type Tables」→ 直接安裝(推薦)
📦 歷史版本下載

原文外掛簡介

WordPress stores custom post types in the default posts table (typically wp_posts), which is fine for most setups. In the majority of use cases, WordPress sites are not used to store in excess of thousands of posts, and so this sort of setup doesn’t place much additional load on servers.
In cases where the site generates a significant amount of posts across multiple post types though, queries can become very expensive – especially where meta generating plugins such as Advanced Custom Fields are involved. Where a WordPress site is expected to generate thousands of posts (and subsequently, many thousands of rows of post meta) queries can be sped up significantly by splitting out data into separate tables. This plugin splits out data by post type, creating additional tables for each custom post type used. A ‘product’ custom post type for example will have its posts stored in product and its meta in product_meta.
If you are using WordPress a little bit longer, you already know that it is an incredibly versatile platform. With its numerous features and extensions, however, it can sometimes be difficult to keep track of and find the right method for managing your content. This is where the use of WordPress custom post types in separate tables comes in!
By outsourcing your custom post types to separate tables, you can better organize and manage your content. It also allows you to have better control over your database and process queries more quickly and efficiently, which can positively impact the performance of your website.
Moreover, outsourcing custom post types to separate tables can also help improve the security of your website. By separating your content into separate tables, you can prevent malware or hackers from accessing your entire database.
Overall, outsourcing WordPress custom post types to separate tables offers a range of benefits for your website. It can improve the organization and management of your content, optimize the performance of your website, and increase your security. If you want to take your website to the next level, you should consider outsourcing your custom post types to separate tables!
Works with

Multisite Installations
Woocommerce
YOAST etc.
Advanced Custom Fields
… and all other registered active custom post types

Settings
As soon as you select a Custom Post Type, a new table is created in the database. This table will be used for all entries of this custom post type.
When you migrate the existing entries, the data from the old table is copied to the new table. This process is not reversible.
Backup your database before migrating in case something doesn’t work as you expect.
Implementation
Each new post and meta table is created to the same structure as the WordPress default post and meta tables. This streamlines the storage process and means that WordPress is capable of interpreting the data wherever it would normally use a wp_posts row, e.g. on the admin edit post pages, admin post listing pages, and in the wp-posts functions (e.g. get_post()).
When new posts are created, a row is inserted into the wp_posts table (as normal) and an automatic MySQL trigger is used to copy this data into the new custom table. Queries to the wp_posts and wp_postmeta table are then rewritten to use the custom table, so that all future lookups and updates made by WordPress and its plugins are made to the new tables. The original wp_posts row is retained for lookup purposes, so that we can determine the post type (and therefore custom table) when there is only a post ID available to work with. Since these lookups are (usually) only necessary in the WordPress admin and exclusively use the primary key, they do not significantly increase the load of the request. Additionally, each ID lookup is made a maximum of once per request and the result is cached on a per-request basis.
To minimise unecessary lookups when writing your own queries, specify the post type you are looking for whenever possible. This will allow the plugin to simply parse the table from the query without having to lookup the post type in the wp_posts table.
Filter Hooks
cpt_tables:settings_capability:
Customise what capability the settings page should be limited to. Default is ‘manage_options’.
Contribute
Developed with ♥ by Sebastian.
This plugin was initially created for own usage to get a big database cleaner.
Check out the GitHub repository and submit pull requests or open issues
1.2.6

Find orphaned meta values and copy to new custom table
Trigger optimization

1.2.5.2

Hotfix: Altered correct auto_increment field for meta table

1.2.5

Removed autoincrement from copied table as it is controles by the posts_table (Revert CPT Tables and migrate them again to get the changes working)

1.2.4

Bugfix in cleanup-cronjob

1.2.3

Revert tables on plugin deactivation

1.2.2

German translation
Add missing migrated post_types, when the custom table exists
Fixed bug on deactivate the plugin

1.2.1

Load plugin the right time when all post types are registered
Refactoring and bugfixing
Added language pot template

1.1.0

Clear orphaned post_types from activated entries
You can activate a cronjob for table optimization in the settings

1.0.9

Automatically remove orphaned entries in the main post table under certain conditions

1.0.8

Re-create triggers if they don’t exist

1.0.7

tested with WordPress 6.2

1.0.6

Fixed debugger warnings
Clean up code
Escape vars
Sanitize vars
Refactoring

1.0.1

Added _ to accepted chars of post type

延伸相關外掛

文章
Filter
Apply Filters
Mastodon