WordPressでカスタム投稿タイプを作成する

WordPressには投稿と固定ページが標準で用意されていますが、クライアントが不動産物件リスト、スタッフ名簿、レシピアーカイブなどを必要とする場合、この2つのコンテンツタイプだけでは不十分です。そこでWordPressカスタム投稿タイプの出番です。これは、デフォルト設定を無理に改変することなく、WordPressの既存データモデルにきれいに収まる第一級のコンテンツ構造です。

カスタム投稿タイプとは?

カスタム投稿タイプ(CPT)は、WordPressに登録する名前付きコンテンツタイプです。名前とは裏腹に、これは別のデータベーステーブルではありません。組み込み投稿タイプもカスタム投稿タイプも、すべてwp_postsテーブルを共有し、post_typeカラムで区別されます。これは重要な概念モデルです。つまり、並列構造を作成するのではなく、既存の構造を拡張しているのです。

デフォルトの投稿タイプには、post、page、attachment、revision、nav_menu_itemがあります。propertyやrecipeのようなCPTを登録すると、WordPressは同じ一貫性でそれを扱います。管理画面、REST APIエンドポイント、URLルーティング、テンプレート階層はすべて同じように機能します。

カスタム投稿タイプ ≠ カスタムフィールド。 CPTはコンテンツのタイプを定義します。カスタムフィールド(ACFまたはメタデータAPIで追加)は、そのコンテンツに付加される追加データを保存します。これらは別々の概念です。

register_post_type()でカスタム投稿タイプを登録する

WordPressカスタム投稿タイプを作成する標準的な方法は、initフックで呼び出されるregister_post_type()関数です。

以下は、シンプルで動作する例です:

add_action( 'init', 'register_property_post_type' );

function register_property_post_type() {
    $labels = [
        'name'               => 'Properties',
        'singular_name'      => 'Property',
        'add_new_item'       => 'Add New Property',
        'edit_item'          => 'Edit Property',
        'not_found'          => 'No properties found.',
    ];

    $args = [
        'labels'       => $labels,
        'public'       => true,
        'has_archive'  => true,
        'supports'     => [ 'title', 'editor', 'thumbnail', 'excerpt' ],
        'rewrite'      => [ 'slug' => 'properties' ],
        'show_in_rest' => true,
    ];

    register_post_type( 'property', $args );
}

主要な引数の説明

• public — CPTを管理画面とフロントエンドで表示可能にします。内部専用タイプの場合はfalseに設定します。
• labels — 管理画面のすべてのUI文字列を制御します。編集者が混乱しないように、適切に記入する価値があります。
• supports — 編集画面に表示されるエディター機能を宣言します。一般的な値:title、editor、thumbnail、excerpt、custom-fields。
• has_archive — /properties/にアーカイブページを有効にします。WordPressは一致するarchive-property.phpテンプレートを探します(またはarchive.phpにフォールバック)。
• rewrite — URLスラッグを設定します。個別の投稿は/properties/post-name/に表示されます。
• show_in_rest — これをtrueに設定してください。 これにより、CPTがWordPress REST API経由で公開され、ブロックエディターが投稿タイプで正しく動作するために必要です。これがないと、エディターはクラシックインターフェースにフォールバックします。

プラグイン vs. テーマ:コードはどこに配置すべきか?

これはよくある混乱のポイントです。カスタム投稿タイプはテーマではなく、プラグインで登録してください。

CPT登録がfunctions.phpにあり、クライアントがテーマを変更すると、そのタイプのすべてのコンテンツがアクセス不可能になります。削除されるわけではありませんが、見えなくなります。専用プラグイン(シンプルな1ファイルプラグインでも可)を使用すれば、テーマの変更に関係なくCPTがアクティブなままになります。

リクエストごとにリライトルールをフラッシュしないでください。 flush_rewrite_rules()は一度だけ呼び出してください。register_activation_hook()を介したプラグイン有効化時のみです。initごとにフラッシュすることはパフォーマンス上の問題です。

カスタム投稿タイプのテンプレート階層

WordPressは、単一のCPTエントリに対して次の順序でテンプレートを探します:

1. single-{post-type}.php(例:single-property.php)
2. single.php
3. singular.php
4. index.php

アーカイブの場合は、次の順序になります:archive-{post-type}.php → archive.php → index.php。

まとめ

register_post_type()をinitに正しくフックし、show_in_restを有効にし、登録をプラグイン内に配置することで、堅牢でポータブルな基盤が得られます。ここから、カスタムタクソノミー、ACFまたはメタデータAPI経由のメタフィールド、カスタム管理カラムを追加できます。WordPressやテーマの更新時に壊れるようなものに触れる必要はありません。

よくある質問

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.