this documentationについて質問があります。
Docが示すようにinit関数にカスタム投稿タイプを登録するのはなぜですか?プラグインを使用していない場合に限りますか。
私が理解しているように、 initはWordPressが実行されるたびに/ is-loadedされます ユーザーによって実行されます。これは、サイトが毎回の訪問で不必要に新しい投稿タイプを再登録しているという意味ではありませんか?プラグインがアクティブになったときに(プラグインを作成する場合)投稿タイプをrequire_once plugin_dir_path( __FILE__ )
に登録しないのはなぜですか?
それはまたサイトをスピードアップさせませんか?それともinit()
の解釈が間違っていますか?確かにカスタム投稿タイプはどこかのデータベースに残っているので、すべてのinit()
で呼び出す必要はありませんか?
これはinit()
を使った、ドキュメントからのカスタム投稿タイプの例です:
function create_post_type() {
register_post_type( 'acme_product',
array(
'labels' => array(
'name' => __( 'Products' ),
'singular_name' => __( 'Product' )
),
'public' => true,
'has_archive' => true,
)
);
}
add_action( 'init', 'create_post_type' );
WP要求が行われるたびにregister_post_type
関数を実行する必要があります。デフォルトの投稿タイプにはこの要件はありません。 MUプラグインでは、コードをそのまま使用できます。このコードで.PHP
ファイルを作成し、それをmu-plugins
のwp-content
サブフォルダーに置くだけです。標準のプラグインヘッダを提供する必要はありません。
確かにカスタム投稿タイプはどこかのデータベースに残っているので、すべてのinit()で呼び出す必要はありませんか?
いいえ、ちがいます。それはなぜ必要なのでしょうか。カスタム投稿タイプは、その投稿タイプでデータベースに保存されたデータのUIを設定するためにWordPressが使用するいくつかの変数です。
データが頻繁に変更され、変更が永続的である必要がある場合は、データベースに格納する必要がありますが、投稿タイプは開発後に変更されません。
それを考慮すると、投稿タイプの設定をデータベースに保存することはhurtperformance)に過ぎず、WordPressはすべてのページ読み込みで登録済み投稿タイプの設定を取得するだけでよく、実行より遅くなります。毎回の登録コード(これはほんの一握りの変数です)。
投稿タイプを登録する際の最も高価な部分は、書き換え規則を生成することです。そのため、これらのareはデータベースに格納され、書き換え規則はアクティブ化および非アクティブ化フックでフラッシュされます)。