WordPressでNEWS配信システムを作る初心者向け実践講座｜第3回：カスタム投稿タイプでNEWS候補の保存先を作る

H2-1 第3回で行うこと

第2回では、TECN NEWS候補管理 V1で扱う「NEWS候補1件」に、どのような項目を持たせるかを設計しました。

元記事タイトル、元記事URL、カテゴリ、NEWS表示文、表示先NEWS、表示フラグ、承認ステータス、X投稿文案、X投稿ステータス、メモなど、NEWS候補として管理したい項目を整理しました。

第3回では、そのNEWS候補をWordPressの中に保存するための「専用の保存先」を作っていきます。

今回のテーマは、カスタム投稿タイプです。

カスタム投稿タイプという言葉を聞くと、少し難しく感じるかもしれません。

しかし、考え方はそれほど複雑ではありません。

WordPressには、もともと「投稿」や「固定ページ」という保存先があります。

通常の記事は「投稿」に保存します。

会社概要やお問い合わせページのようなページは「固定ページ」に保存します。

今回作るNEWS候補は、通常の記事でも固定ページでもありません。

公開済みの記事を、NEWSとしてどのように活用するかを管理するためのデータです。

そのため、通常の記事や固定ページとは別に、NEWS候補専用の保存先を作ります。

イメージとしては、WordPressの中に「NEWS候補専用の箱」を新しく用意するようなものです。

その箱の中に、今後、NEWS候補を1件ずつ保存していきます。

第3回では、まずこの箱を作るところまでを目標にします。

この段階では、まだNEWS一覧の表示画面は作りません。

ショートコードで表示する処理も、まだ作りません。

また、第2回で整理したすべてのカスタムフィールドを、今回一気に作り込むわけでもありません。

まずは、WordPressの管理画面に「NEWS候補」という保存先を作り、そこにNEWS候補を登録できる状態にすることを目指します。

この保存先ができると、次回以降の作業が進めやすくなります。

たとえば、次の回では、NEWS候補に元記事URLやNEWS表示文、表示先NEWS、承認ステータスなどを持たせるためのカスタムフィールドを考えることができます。

さらにその後、固定ページやショートコードを使って、NEWS候補一覧を表示する管理画面へ進めます。

つまり、第3回は、TECN NEWS候補管理 V1の土台作りです。

第1回で全体構想を整理しました。

第2回でNEWS候補1件の項目を設計しました。

そして第3回では、そのNEWS候補を保存するための箱をWordPressの中に作ります。

ここまで進むと、TECN NEWS候補管理 V1は、単なる構想から、実際にWordPress上で動く仕組みへ一歩近づきます。

H2-2 なぜNEWS候補専用の保存先が必要なのか

NEWS候補を管理する方法はいくつか考えられます。

たとえば、通常の記事にカスタムフィールドを追加して、そこにNEWS表示文や表示先NEWSを持たせる方法もあります。

あるいは、固定ページの中に手作業でNEWS一覧を書いていく方法もあります。

もっと簡単に考えれば、ExcelやGoogleスプレッドシートでNEWS候補を管理する方法もあります。

しかし、TECN NEWS候補管理 V1では、WordPressの中にNEWS候補専用の保存先を作る方針にします。

理由は、NEWS候補が「記事そのもの」ではなく、「記事をNEWSとして活用するための管理データ」だからです。

ここを分けて考えることが大切です。

通常の記事は、読者に読んでもらうためのコンテンツです。

記事本文、タイトル、カテゴリ、タグ、アイキャッチ画像などを持ちます。

一方で、NEWS候補は、読者に直接読んでもらう記事本文ではありません。

元記事をどのNEWS枠に出すか。

どんなNEWS表示文にするか。

表示するか、表示しないか。

担当者が確認したか。

X投稿文案をどうするか。

こうした運用上の情報を管理するためのデータです。

もし通常の記事に直接NEWS管理用の項目をたくさん持たせると、記事編集画面が複雑になりやすくなります。

記事を書く人にとっては、本文、見出し、画像、SEOタイトル、descriptionなど、すでに管理する項目がたくさんあります。

そこにNEWS候補用の項目まで追加すると、編集画面が分かりにくくなる可能性があります。

また、すべての記事がNEWS候補になるとは限りません。

記事として公開するけれど、NEWS枠には出さない記事もあります。

一方で、NEWS候補としては残しておきたいが、実際には非表示にしたいものもあります。

このような運用を考えると、通常の記事とNEWS候補は分けて管理した方が分かりやすくなります。

固定ページに手作業でNEWS一覧を書く方法も、最初は簡単です。

しかし、記事数が増えてくると、毎回手で追加・修正・削除する必要があります。

表示順を変えるのも手間です。

どのNEWSを承認済みにしたのか、どれを非表示にしたのかも管理しにくくなります。

Googleスプレッドシートで管理する方法もありますが、今回はWordPress内でNEWS表示まで行いたいので、WordPressの中にデータを持たせた方が後の連携がしやすくなります。

WordPress内にNEWS候補専用の保存先を作っておけば、管理画面でNEWS候補を一覧できます。

後からカスタムフィールドを追加して、NEWS表示文や表示先NEWS、承認ステータスを持たせることもできます。

さらに、ショートコードでNEWS候補を取得して、固定ページに表示することもできます。

つまり、NEWS候補専用の保存先を作ることで、保存、確認、編集、表示の流れをWordPress内で完結しやすくなります。

TECN NEWS候補管理 V1では、まずこの考え方を採用します。

通常の記事は、読者に読んでもらうコンテンツとして管理する。

NEWS候補は、その記事をNEWSとしてどう活用するかを管理するデータとして、別の保存先に分ける。

このように分けることで、あとから仕組みを拡張しやすくなります。

今回作るカスタム投稿タイプは、そのための専用保存先です。

第3回では、まずこのNEWS候補専用の保存先をWordPressの中に作るところまで進めます。

H2-3 通常の記事・固定ページ・NEWS候補の違い

WordPressには、最初から「投稿」と「固定ページ」という保存先があります。

WordPressをブログとして使っている場合、多くの記事は「投稿」として作成します。

たとえば、商品紹介記事、使い方の解説記事、ニュース記事、比較記事、体験レビューなどは、通常「投稿」として管理します。

投稿には、カテゴリやタグを設定できます。

公開日もあり、新しい記事から順番に一覧表示することもできます。

そのため、ブログ記事やコラム記事を管理するには、投稿が向いています。

一方で、固定ページは、時系列で増えていく記事というより、サイト内で固定的に使うページに向いています。

たとえば、会社概要、お問い合わせ、プライバシーポリシー、サービス紹介、資料請求ページなどです。

固定ページは、カテゴリで分類するというより、サイトの中で常に置いておきたいページとして使います。

今回のTECN NEWS候補管理 V1でも、固定ページは使います。

ただし、固定ページをNEWS候補の保存先にするわけではありません。

固定ページは、担当者がNEWS候補一覧を確認するための画面として使う予定です。

たとえば、WordPressの固定ページにショートコードを貼り、そこにNEWS候補一覧を表示するような形です。

つまり、固定ページは「表示画面」として使います。

では、NEWS候補は何でしょうか。

NEWS候補は、通常の記事そのものではありません。

固定ページでもありません。

NEWS候補は、公開済みの記事をNEWSとして活用するための管理データです。

たとえば、ある在庫管理の記事を公開したとします。

その記事自体は、通常の投稿として存在しています。

しかし、その記事を在庫管理 / DX NEWSに表示するかどうか、どんなNEWS表示文にするか、X投稿文案をどうするか、担当者が確認済みかどうかは、記事本文とは別に管理したい情報です。

このような情報をまとめたものが、NEWS候補です。

通常の記事は、読者に読んでもらうためのコンテンツです。

固定ページは、サイト内で固定的に表示するページや、管理用の表示画面として使えます。

NEWS候補は、記事公開後の活用を管理するための専用データです。

この3つを分けて考えると、今回の仕組みが分かりやすくなります。

投稿は、元記事を保存する場所。

固定ページは、担当者がNEWS候補を確認する画面。

NEWS候補は、元記事をNEWSとしてどう扱うかを管理するデータ。

このように役割を分けます。

もしNEWS候補を通常の記事の中に全部入れてしまうと、記事編集画面が複雑になります。

もし固定ページに直接NEWS候補を書いてしまうと、手作業での更新が増えてしまいます。

そこで、NEWS候補は専用の保存先を作って管理します。

そのために使うのが、次のH2で説明するカスタム投稿タイプです。

WordPressには、投稿や固定ページ以外にも、独自の保存先を作る方法があります。

TECN NEWS候補管理 V1では、この仕組みを使って、通常の記事や固定ページとは別に「NEWS候補」という専用の保存先を用意します。

H2-4 カスタム投稿タイプとは何か

カスタム投稿タイプとは、WordPressの中に独自の投稿データを作るための仕組みです。

少し難しく聞こえるかもしれませんが、考え方はとてもシンプルです。

WordPressには、最初からいくつかのデータの種類があります。

代表的なものが、通常の記事である「投稿」と、固定的なページである「固定ページ」です。

WordPressの内部では、通常の記事は post として管理されています。

固定ページは page として管理されています。

つまり、WordPressは最初から「post」という箱と、「page」という箱を持っているイメージです。

カスタム投稿タイプは、この箱を自分で追加する仕組みです。

たとえば、制作実績を管理したい場合は「制作実績」という専用の投稿タイプを作れます。

お客様の声を管理したい場合は「お客様の声」という専用の投稿タイプを作れます。

商品情報を管理したい場合は「商品」という専用の投稿タイプを作れます。

そして今回のTECN NEWS候補管理 V1では、「NEWS候補」という専用の投稿タイプを作ります。

通常の記事とは別に、NEWS候補だけを保存する専用の箱を作るイメージです。

この箱の中に、NEWS候補を1件ずつ保存していきます。

カスタム投稿タイプを使うと、WordPressの管理画面にも専用メニューを表示できます。

たとえば、管理画面の左メニューに「NEWS候補」という項目を出すことができます。

そこからNEWS候補を追加したり、一覧で確認したりできます。

通常の記事一覧とは別に管理できるので、記事本文とNEWS候補が混ざりません。

これは実務上、とても分かりやすいです。

また、カスタム投稿タイプには、後からカスタムフィールドを追加できます。

第2回で設計した、元記事タイトル、元記事URL、カテゴリ、NEWS表示文、表示先NEWS、表示フラグ、承認ステータス、X投稿文案、X投稿ステータス、メモなどを、NEWS候補に持たせることができます。

つまり、カスタム投稿タイプは「保存先の箱」です。

カスタムフィールドは、その箱の中に入れる「項目」です。

このように考えると、初心者の方にも分かりやすいと思います。

第3回では、まずNEWS候補用のカスタム投稿タイプを作ります。

ここでは、まだすべてのカスタムフィールドを作り込む必要はありません。

最初に作るべきなのは、NEWS候補を保存するための箱です。

その箱ができたら、次の段階で、必要な項目を追加していきます。

カスタム投稿タイプを使うことで、WordPressを単なるブログツールではなく、小さな業務管理システムとして使いやすくなります。

通常の記事は記事として管理する。

固定ページは表示画面として使う。

NEWS候補はカスタム投稿タイプで専用管理する。

この役割分担ができると、TECN NEWS候補管理 V1の全体像がかなり分かりやすくなります。

今回作るNEWS候補用のカスタム投稿タイプは、今後の固定ページ表示、ショートコード表示、承認管理、NEWS枠への出し分けにつながる重要な土台になります。

H2-5 NEWS候補をカスタム投稿タイプにする理由

TECN NEWS候補管理 V1では、NEWS候補をカスタム投稿タイプとして管理する方針にします。

理由は、NEWS候補を通常の記事や固定ページとは分けて管理した方が、あとから運用しやすくなるからです。

NEWS候補は、読者にそのまま読んでもらう記事本文ではありません。

あくまで、公開済みの記事をNEWSとしてどのように活用するかを管理するためのデータです。

たとえば、ある記事を公開したあとに、

TECN NEWSに出すのか。

ダイソーNEWSに出すのか。

どこの国NEWSに出すのか。

LDAC / Bluetooth NEWSに出すのか。

在庫管理 / DX NEWSに出すのか。

それとも今回はNEWSには出さないのか。

こうした判断を行うためのデータがNEWS候補です。

もし、このNEWS候補情報を通常の記事の中に直接持たせると、記事編集画面が複雑になってしまいます。

記事を書くときには、本文、見出し、画像、カテゴリ、タグ、SEOタイトル、descriptionなど、すでに考えることがたくさんあります。

そこに、NEWS表示文、表示先NEWS、承認ステータス、X投稿文案、X投稿ステータス、メモなどを追加すると、記事を書く人にとって少し負担が大きくなります。

また、すべての記事がNEWS候補になるとは限りません。

記事として公開するが、NEWSには出さないものもあります。

NEWS候補として保存するが、今回は非表示にするものもあります。

このような運用を考えると、通常の記事とNEWS候補は分けて管理した方が自然です。

カスタム投稿タイプを使えば、管理画面の中に「NEWS候補」という専用メニューを作ることができます。

通常の記事一覧とは別に、NEWS候補だけを一覧で確認できます。

これにより、担当者は「記事を探す」のではなく、「NEWS候補を確認する」という目的で作業できます。

これは実務ではかなり大きな違いです。

さらに、カスタム投稿タイプにしておくと、後から項目を追加しやすくなります。

第2回で設計したように、NEWS候補にはいくつかの項目を持たせます。

元記事タイトル。

元記事URL。

カテゴリ。

NEWS表示文。

表示先NEWS。

表示フラグ。

承認ステータス。

X投稿文案。

X投稿ステータス。

メモ。

これらの項目は、カスタムフィールドとして追加できます。

カスタム投稿タイプでNEWS候補という箱を作り、その中にカスタムフィールドで必要な項目を入れていく。

この構成にすると、後から仕組みを拡張しやすくなります。

たとえば、最初は承認ステータスだけを管理して、後から確認日や確認者を追加することもできます。

最初は表示フラグだけを使い、後から表示開始日や表示終了日を追加することもできます。

最初はX投稿文案だけを持たせ、後からX投稿予定日や投稿済み日を追加することもできます。

このように、少しずつ育てられることが、カスタム投稿タイプを使う大きなメリットです。

TECN NEWS候補管理 V1は、最初から大きなシステムとして作るのではなく、まずは小さく作り、実際に使いながら改善していく方針です。

そのためには、通常の記事や固定ページに無理やり機能を詰め込むより、NEWS候補専用の保存先を作った方が分かりやすくなります。

また、将来的にショートコードでNEWS候補を取得して、固定ページに一覧表示する場合にも、カスタム投稿タイプにしておくと扱いやすくなります。

「NEWS候補」という投稿タイプだけを取り出して、承認済みのものだけを表示する。

表示先NEWSが「在庫管理 / DX NEWS」のものだけを表示する。

表示フラグがオンになっているものだけを表示する。

このような処理がしやすくなります。

つまり、NEWS候補をカスタム投稿タイプにする理由は、次の3つです。

1つ目は、通常の記事とNEWS候補を分けて管理できること。

2つ目は、カスタムフィールドを追加して、NEWS候補に必要な項目を持たせやすいこと。

3つ目は、将来的にショートコードや固定ページ表示と連携しやすいこと。

この3つの理由から、TECN NEWS候補管理 V1では、NEWS候補をカスタム投稿タイプとして作る方針にします。

ここまで決めると、次に考えるべきことは、カスタム投稿タイプの名前です。

WordPressの内部で使う名前と、管理画面に表示する名前を決めていきます。

H2-6 カスタム投稿タイプ名を決める

次に、NEWS候補用のカスタム投稿タイプ名を決めます。

カスタム投稿タイプを作るときには、2種類の名前を考える必要があります。

1つ目は、WordPressの内部で使う名前です。

2つ目は、管理画面に表示する名前です。

ここでは、まず内部で使う名前を決めます。

内部名は、PHPのコードやWordPressの処理の中で使う名前です。

画面上に大きく表示される名前ではありません。

しかし、実装上はとても重要です。

今回のTECN NEWS候補管理 V1では、カスタム投稿タイプ名を次のようにします。

apice_news_candidate

この名前には、いくつかの意味があります。

まず、apice はアピス系の仕組みであることを示します。

今後、アピスminiの応用系として、WordPressを使った小さな業務改善システムをいくつも作っていく場合、先頭に apice を付けておくと、自社の仕組みだと分かりやすくなります。

次に、news はNEWSに関するデータであることを示します。

今回作る仕組みは、NEWS配信やNEWS候補管理に関するものなので、news という言葉を入れておくと分かりやすくなります。

最後に、candidate は候補という意味です。

今回保存するのは、いきなり読者向けに表示するNEWSそのものではありません。

あくまで、担当者が確認して、表示するかどうかを判断するためのNEWS候補です。

そのため、candidate という言葉を入れておくと、目的が分かりやすくなります。

つまり、apice_news_candidate は、

アピス系のNEWS候補データ

という意味になります。

カスタム投稿タイプ名を決めるときには、できるだけ後から見ても意味が分かる名前にしておくことが大切です。

たとえば、単に news という名前にしてしまうと、NEWSそのものなのか、NEWS候補なのか、NEWS表示枠なのかが少し分かりにくくなります。

また、candidate だけでは、何の候補なのか分かりません。

tecn_news という名前も考えられますが、今後アピスminiの応用系として他のサイトや仕組みにも展開することを考えると、apice_news_candidate の方が汎用性があります。

ただし、管理画面上の表示名は、必ずしも内部名と同じにする必要はありません。

内部名は apice_news_candidate としておき、管理画面では「NEWS候補」や「TECN NEWS候補」と表示すれば十分です。

ここで注意したいのは、内部名はあとから頻繁に変更しない方がよいということです。

カスタム投稿タイプ名を変更すると、すでに登録したデータや、ショートコード、カスタムフィールド、一覧表示の処理にも影響が出る可能性があります。

そのため、最初にある程度しっかり考えて決めておくことが大切です。

今回のように、アピスminiの応用系として今後も似た仕組みを増やしていくなら、内部名には一定のルールを持たせた方がよいです。

たとえば、

apice_news_candidate

apice_event_candidate

apice_download_item

apice_workflow_task

のように、先頭に apice を付けて、その後に用途を表す名前を続ける形です。

このようなルールにしておくと、あとからコードを見たときに、どの仕組みのデータなのか分かりやすくなります。

TECN NEWS候補管理 V1では、まずカスタム投稿タイプ名として、

apice_news_candidate

を採用します。

この名前をもとに、次の工程でWordPressにカスタム投稿タイプを登録していきます。

第3回では、単にコードを貼るだけではなく、なぜこの名前にするのか、どのような意味があるのかも説明しておくことで、読者にも実務で使いやすい命名の考え方が伝わります。

H2-7 管理画面に表示する名前を決める

カスタム投稿タイプでは、WordPressの内部で使う名前とは別に、管理画面に表示する名前も決めます。

前のH2では、内部で使うカスタム投稿タイプ名を、

apice_news_candidate

にする方針にしました。

これは、PHPのコードやWordPress内部で使う名前です。

一方で、実際に担当者がWordPress管理画面で見る名前は、もっと分かりやすくする必要があります。

管理画面に表示する名前としては、次のような候補があります。

・NEWS候補
・TECN NEWS候補
・NEWS候補管理
・TECN NEWS候補管理

この中で、V1ではまず、

NEWS候補

または、

TECN NEWS候補

が分かりやすいと思います。

初心者向けの記事として説明する場合は、「NEWS候補」という表示名が一番シンプルです。

WordPress管理画面の左メニューに「NEWS候補」と表示されれば、担当者はすぐに「ここでNEWS候補を管理するのだな」と分かります。

一方で、TECNサイト専用の仕組みとして見せたい場合は、「TECN NEWS候補」としてもよいです。

TECN NEWS候補と表示すれば、TECNサイトで使うNEWS候補管理であることが明確になります。

ただし、今後アピスminiの応用系として、他のサイトや別の仕組みにも展開する可能性を考えると、管理画面上はあまり限定しすぎない方がよい場合もあります。

そのため、今回の基本方針としては、内部名は apice_news_candidate、管理画面の表示名は「NEWS候補」としておくのが扱いやすいです。

内部名は少し技術的で、用途や管理上の意味を含めた名前にします。

管理画面の表示名は、担当者が見てすぐ分かる日本語にします。

このように、内部名と表示名を分けて考えることが大切です。

たとえば、内部名が apice_news_candidate だからといって、管理画面にもそのまま「apice_news_candidate」と表示する必要はありません。

むしろ、担当者が日常的に使う画面では、日本語で分かりやすく表示した方が親切です。

管理画面では、

NEWS候補

新規NEWS候補を追加

NEWS候補一覧

NEWS候補を編集

のように表示されると、操作する人が迷いにくくなります。

また、メニュー名も重要です。

WordPress管理画面の左側メニューに表示される名前が分かりにくいと、担当者がどこを開けばよいか迷ってしまいます。

たとえば、「候補」だけでは何の候補か分かりません。

「NEWS」だけでは、NEWS記事なのか、NEWS候補なのか、NEWS表示枠なのかが少し曖昧です。

そのため、管理画面の表示名は「NEWS候補」とするのが自然です。

さらに、実際の運用では、担当者がこの画面を毎日見る可能性があります。

新しい記事を公開したあと、NEWS候補を確認する。

NEWS表示文を直す。

表示先NEWSを選ぶ。

承認済みにする。

X投稿文案を確認する。

このような作業を行う画面なので、表示名はできるだけ直感的な方がよいです。

第3回では、まず管理画面に「NEWS候補」というメニューを出すことを目指します。

このメニューが表示されれば、WordPressの中にNEWS候補専用の保存先ができたことを確認できます。

最初は、タイトルを入力して保存できるだけでも十分です。

そのあと、次回以降でカスタムフィールドを追加し、元記事URL、NEWS表示文、表示先NEWS、承認ステータスなどを持たせていきます。

つまり、H2-7で決めることは、実務上とても小さなことに見えるかもしれません。

しかし、管理画面にどう表示するかは、担当者の使いやすさに直結します。

内部では apice_news_candidate。

管理画面では NEWS候補。

このように役割を分けて名前を決めることで、作る側にも使う側にも分かりやすい仕組みにできます。

H2-8 Code Snippetsで登録する方針

次に、カスタム投稿タイプをどこに登録するかを決めます。

WordPressでカスタム投稿タイプを追加する方法はいくつかあります。

代表的な方法としては、テーマの functions.php にコードを書く方法があります。

functions.php は、WordPressテーマに用意されているPHPファイルで、テーマの機能を追加したり、WordPressの動作をカスタマイズしたりするときによく使われます。

ただし、初心者がいきなり functions.php を直接編集するのは、少し注意が必要です。

functions.php に書いたコードにエラーがあると、サイト全体が表示できなくなることがあります。

また、テーマを変更したときに、functions.php に書いたカスタマイズが引き継がれない場合もあります。

さらに、どのコードが何のための処理なのかが分かりにくくなることもあります。

そこで、このシリーズでは、Code Snippetsを使う方針にします。

Code Snippetsは、WordPress管理画面からPHPコードを登録・管理できるプラグインです。

テーマファイルを直接編集せずに、必要なPHPコードをスニペットとして管理できます。

スニペットとは、小さなコードのまとまりのことです。

今回でいえば、NEWS候補用のカスタム投稿タイプを登録するコードを、1つのスニペットとして登録します。

Code Snippetsを使うメリットは、いくつかあります。

1つ目は、テーマファイルを直接編集しなくてよいことです。

functions.php を直接編集するより、初心者にとって安全に管理しやすくなります。

2つ目は、コードを機能ごとに分けて管理できることです。

たとえば、今回のカスタム投稿タイプ登録コードには、

TECN NEWS候補管理 V1：カスタム投稿タイプ登録

のような名前を付けて保存できます。

そうしておけば、あとから見たときに、このコードが何のためのものか分かりやすくなります。

3つ目は、必要に応じてスニペットを有効化・無効化できることです。

もし動作確認中に問題が出た場合でも、該当するスニペットを無効化すれば、処理を止めることができます。

もちろん、PHPコードのエラーには注意が必要ですが、テーマファイルを直接編集するよりは管理しやすいです。

4つ目は、今後のアピスmini応用系にも向いていることです。

このシリーズでは、WordPressを使って、小さな業務改善システムを作る考え方を紹介しています。

今後も、NEWS候補管理だけでなく、無料ダウンロード管理、記事候補管理、内部リンク候補管理、簡易タスク管理など、WordPress上で使えるミニシステムを作っていく可能性があります。

そのとき、Code Snippetsで機能ごとにコードを整理しておくと、管理しやすくなります。

たとえば、

アピスmini：NEWS候補管理 カスタム投稿タイプ

アピスmini：NEWS候補管理 カスタムフィールド

アピスmini：NEWS候補一覧ショートコード

アピスmini：NEWS表示ショートコード

のように、役割ごとに分けて管理できます。

このようにしておくと、あとから修正するときにも、どこを直せばよいか分かりやすくなります。

第3回では、Code Snippetsを使って、NEWS候補用のカスタム投稿タイプを登録する方針にします。

この段階では、まだ高度なコードを書く必要はありません。

まずは、WordPress管理画面の左メニューに「NEWS候補」という項目を表示し、NEWS候補を追加・保存できる状態を作ります。

Code Snippetsを使うことで、テーマファイルを直接触らずに、この仕組みを追加できます。

初心者向けに進めるうえでも、この方法は分かりやすく、安全性の面でも扱いやすいと思います。

もちろん、本格的な商用プラグインとして配布する場合は、最終的には独自プラグイン化する選択肢もあります。

しかし、V1の段階では、まず動く仕組みを小さく作ることが大切です。

そのため、今回はCode Snippetsで始めます。

小さく作る。

分かりやすく管理する。

動かしながら改善する。

この方針が、TECN NEWS候補管理 V1にも、アピスminiの考え方にも合っています。

H2-9 カスタム投稿タイプ登録コードの考え方

ここまでで、NEWS候補をカスタム投稿タイプとして管理する理由と、内部名・表示名の考え方を整理しました。

第3回では、いよいよCode Snippetsを使って、WordPressにNEWS候補用のカスタム投稿タイプを登録します。

ただし、いきなりコードを貼り付ける前に、そのコードで何をしているのかを簡単に確認しておきましょう。

カスタム投稿タイプ登録コードでは、主に次のような内容を指定します。

・投稿タイプ名
・管理画面に表示する名前
・管理メニューに表示するかどうか
・どの機能を使うか
・一覧画面に表示するかどうか
・URLを持たせるかどうか
・管理画面での見え方

まず重要なのが、投稿タイプ名です。

今回のカスタム投稿タイプ名は、

apice_news_candidate

とします。

これは、WordPress内部でNEWS候補を識別するための名前です。

管理画面に表示される名前ではなく、PHPのコードやWordPressの内部処理で使う名前です。

次に、管理画面に表示する名前を指定します。

今回は、管理画面では「NEWS候補」と表示します。

担当者がWordPress管理画面を開いたときに、左側メニューに「NEWS候補」と表示されれば、どこでNEWS候補を管理すればよいか分かりやすくなります。

次に、管理メニューに表示するかどうかを指定します。

今回は、担当者がWordPress管理画面からNEWS候補を追加・編集できるようにしたいので、管理メニューに表示します。

もし管理メニューに出さない設定にすると、データとしては存在していても、担当者が通常の管理画面から操作しにくくなります。

V1では、まず管理画面から確認できることを優先します。

次に、どの機能を使うかを指定します。

WordPressの投稿タイプでは、タイトル、本文、アイキャッチ画像、抜粋、コメントなど、さまざまな機能を有効にできます。

今回のNEWS候補では、まずタイトルを使います。

本文については、V1では必須ではありませんが、メモ的に使う可能性もあるため、最初は本文も使えるようにしておいてもよいです。

ただし、NEWS表示文や表示先NEWS、承認ステータスなどは、本文に直接書くのではなく、次回以降でカスタムフィールドとして持たせる方針です。

そのため、第3回ではまず「NEWS候補という箱を作る」ことを重視します。

次に、一覧画面に表示するかどうかです。

WordPress管理画面でNEWS候補一覧を見られるようにするため、管理画面上の一覧には表示します。

担当者が登録済みのNEWS候補を確認し、必要に応じて編集できるようにするためです。

次に、URLを持たせるかどうかです。

通常の投稿や固定ページは、公開すると読者向けのURLを持ちます。

しかし、NEWS候補は読者に直接見せるためのページではありません。

あくまで管理用データです。

そのため、V1ではNEWS候補そのものを公開ページとして表示する必要はありません。

読者向けに表示するのは、最終的にはショートコードで作るNEWS一覧やNEWS枠です。

したがって、カスタム投稿タイプとしては管理画面で扱えるようにしつつ、単独ページとして公開表示する必要はない、という考え方にします。

この方針にしておくと、NEWS候補データが読者向けに直接表示されることを避けられます。

最後に、管理画面での見え方です。

WordPress管理画面の左メニューに「NEWS候補」と表示し、そこから新規追加や一覧確認ができるようにします。

この時点では、まだ完成形ではありません。

第3回で作るのは、あくまでNEWS候補を保存するための箱です。

次回以降で、その箱の中に元記事URL、NEWS表示文、表示先NEWS、承認ステータスなどの項目を追加していきます。

つまり、第3回のコードで行うことは、とてもシンプルです。

WordPressの中に、

「NEWS候補」という専用の保存先を作る。

管理画面に、

「NEWS候補」というメニューを表示する。

NEWS候補を、

1件ずつ追加・保存できるようにする。

ここまでできれば、第3回の達成目標は十分です。

最初からすべてを作ろうとせず、まずは保存先を作る。

この小さな一歩が、TECN NEWS候補管理 V1を実際に動く仕組みにしていくための土台になります。

H2-10 NEWS候補用カスタム投稿タイプの登録コード

それでは、NEWS候補用のカスタム投稿タイプを登録するコードを用意します。

今回は、Code Snippetsに貼り付けて使う前提で書きます。

このコードを有効化すると、WordPress管理画面の左メニューに「NEWS候補」が表示され、NEWS候補を追加・編集できるようになります。

<?php
/**
 * TECN NEWS候補管理 V1
 * カスタム投稿タイプ登録
 *
 * このコードは、WordPress管理画面に「NEWS候補」という
 * 専用の保存先を追加するためのものです。
 */

function apice_register_news_candidate_post_type() {

    $labels = array(
        'name'                  => 'NEWS候補',
        'singular_name'         => 'NEWS候補',
        'menu_name'             => 'NEWS候補',
        'name_admin_bar'        => 'NEWS候補',
        'add_new'               => '新規追加',
        'add_new_item'          => '新規NEWS候補を追加',
        'new_item'              => '新規NEWS候補',
        'edit_item'             => 'NEWS候補を編集',
        'view_item'             => 'NEWS候補を表示',
        'all_items'             => 'NEWS候補一覧',
        'search_items'          => 'NEWS候補を検索',
        'not_found'             => 'NEWS候補が見つかりませんでした',
        'not_found_in_trash'    => 'ゴミ箱にNEWS候補はありません',
    );

    $args = array(
        'labels'                => $labels,
        'public'                => false,
        'show_ui'               => true,
        'show_in_menu'          => true,
        'menu_position'         => 25,
        'menu_icon'             => 'dashicons-megaphone',
        'capability_type'       => 'post',
        'hierarchical'          => false,
        'supports'              => array( 'title', 'editor' ),
        'has_archive'           => false,
        'rewrite'               => false,
        'query_var'             => false,
        'show_in_rest'          => true,
    );

    register_post_type( 'apice_news_candidate', $args );
}

add_action( 'init', 'apice_register_news_candidate_post_type' );

このコードのポイントを、簡単に確認しておきます。

まず、register_post_type() というWordPressの関数を使っています。

この関数は、WordPressに新しい投稿タイプを登録するためのものです。

今回の場合は、

apice_news_candidate

という名前で、NEWS候補用のカスタム投稿タイプを登録しています。

次に、$labels では、管理画面に表示する名前を指定しています。

たとえば、

NEWS候補

新規NEWS候補を追加

NEWS候補を編集

NEWS候補一覧

といった表示名です。

これにより、WordPress管理画面上で担当者が見たときに、何を操作しているのか分かりやすくなります。

次に、public を false にしています。

これは、NEWS候補を読者向けの公開ページとして扱わないためです。

NEWS候補は、あくまで管理用データです。

読者に見せるのは、後で作るNEWS表示欄です。

そのため、NEWS候補1件ごとの個別ページを公開する必要はありません。

ただし、show_ui は true にしています。

これは、WordPress管理画面上でNEWS候補を操作できるようにするためです。

show_in_menu も true にしています。

これにより、管理画面の左メニューに「NEWS候補」が表示されます。

menu_icon には、dashicons-megaphone を指定しています。

これは、WordPress管理画面のメニューに表示されるアイコンです。

メガホンのようなアイコンなので、NEWSやお知らせの管理には比較的合っています。

supports では、title と editor を指定しています。

これにより、NEWS候補にタイトルと本文を持たせることができます。

V1では、タイトルをNEWS候補の見出しとして使い、本文は一時的なメモや説明用として使うこともできます。

ただし、NEWS表示文や表示先NEWS、承認ステータスなどは、次回以降でカスタムフィールドとして追加していく方針です。

has_archive は false にしています。

これは、NEWS候補専用のアーカイブページを作らないという意味です。

NEWS候補は読者向けに一覧表示する投稿タイプではないため、通常のアーカイブページは不要です。

rewrite も false にしています。

これにより、NEWS候補1件ごとのURLを持たせる処理を行いません。

show_in_rest は true にしています。

これは、ブロックエディターやREST APIとの連携を考えて有効にしています。

今後、管理画面やブロックエディターとの相性を考えると、true にしておく方が扱いやすいです。

このコードをCode Snippetsに登録して有効化すると、WordPress管理画面の左側メニューに「NEWS候補」が表示されます。

そこで新規追加を行えば、NEWS候補を1件登録できるようになります。

この段階では、まだNEWS候補管理システムとしては完成していません。

しかし、WordPressの中にNEWS候補専用の保存先ができたことになります。

ここまでできれば、第3回の大きな目的は達成です。

次の段階では、このNEWS候補に第2回で設計した項目を追加していきます。

元記事URL、カテゴリ、NEWS表示文、表示先NEWS、表示フラグ、承認ステータス、X投稿文案、X投稿ステータス、メモなどを、カスタムフィールドとして持たせる流れに進みます。

まずは箱を作る。

次に、その箱に項目を追加する。

この順番で進めることで、初心者の方にも分かりやすく、実務でも使いやすい仕組みにしていきます。

H2-11 登録後にWordPress管理画面で確認すること

Code Snippetsにカスタム投稿タイプ登録コードを貼り付けて有効化したら、次にWordPress管理画面で正しく動いているかを確認します。

コードを書いたあとは、必ず確認作業を行うことが大切です。

エラーが出ていないか。

管理画面にメニューが表示されているか。

新規追加画面が開けるか。

実際にNEWS候補を保存できるか。

こうした点を順番に確認していきます。

まず最初に確認するのは、WordPress管理画面の左側メニューです。

コードが正しく有効化されていれば、左側メニューに「NEWS候補」という項目が表示されます。

このメニューが表示されていれば、WordPressの中にNEWS候補用のカスタム投稿タイプが登録されたことになります。

もし「NEWS候補」が表示されない場合は、Code Snippetsのスニペットが有効になっているかを確認します。

スニペットが無効のままになっていると、コードは実行されません。

また、コードの中に入力ミスがある場合も、正しく表示されないことがあります。

次に、「NEWS候補」をクリックして、一覧画面を開きます。

最初はまだ何も登録していないので、NEWS候補一覧は空の状態でも問題ありません。

ここで確認したいのは、一覧画面が開けるかどうかです。

エラーが出ずに一覧画面が表示されれば、基本的な登録はできています。

次に、「新規追加」をクリックします。

NEWS候補の新規追加画面が開けば、次の確認に進みます。

この段階では、まだ第2回で設計した元記事URL、NEWS表示文、表示先NEWS、承認ステータスなどのカスタムフィールドは表示されていません。

第3回では、まずNEWS候補を保存する箱を作ることが目的です。

そのため、新規追加画面にタイトルと本文欄が表示されていれば、まずは十分です。

試しに、タイトル欄に次のようなテスト用の名前を入れてみます。

テスト用NEWS候補

本文欄には、簡単なメモとして次のように入力してもよいです。

これはNEWS候補管理V1の動作確認用データです。

入力できたら、保存または公開ボタンを押します。

保存後に、NEWS候補一覧へ戻り、先ほど登録した「テスト用NEWS候補」が一覧に表示されているか確認します。

一覧に表示されていれば、NEWS候補を1件登録できたことになります。

ここまで確認できれば、第3回の実装としては大きく前進です。

WordPressの中に、通常の記事や固定ページとは別に、NEWS候補専用の保存先ができたことになります。

確認ポイントを整理すると、次のようになります。

・WordPress管理画面の左メニューに「NEWS候補」が表示されるか
・NEWS候補一覧画面が開けるか
・新規追加画面が開けるか
・タイトルを入力して保存できるか
・保存したNEWS候補が一覧に表示されるか

この5つが確認できれば、カスタム投稿タイプの登録は成功と考えてよいです。

ただし、この段階ではまだ完成ではありません。

今できているのは、NEWS候補を保存するための基本の箱を作ったところまでです。

まだ、元記事URLやNEWS表示文を入力する専用項目はありません。

表示先NEWSを選ぶ項目もありません。

承認ステータスを選ぶ項目もありません。

X投稿文案を管理する項目もありません。

これらは、次回以降でカスタムフィールドとして追加していきます。

第3回では、まず「NEWS候補」という保存先がWordPress管理画面に表示され、1件登録できるところまで確認できればOKです。

システム作りでは、このように小さな単位で確認しながら進めることが大切です。

いきなり全部の機能を作ってから確認すると、どこで問題が起きているのか分かりにくくなります。

まず箱を作る。

箱が表示されるか確認する。

1件登録できるか確認する。

そのうえで、次の項目追加に進む。

このように順番に進めることで、初心者の方でも安心してWordPressの仕組みを拡張できます。

H2-12 V1ではまだカスタムフィールドは作り込まない

第2回では、NEWS候補1件に持たせる項目を設計しました。

元記事タイトル、元記事URL、カテゴリ、NEWS表示文、表示先NEWS、表示フラグ、承認ステータス、X投稿文案、X投稿ステータス、メモなど、V1で使う項目を整理しました。

そのため、第3回でカスタム投稿タイプを作ったあと、すぐにすべての項目を入力できるようにしたくなるかもしれません。

しかし、第3回では、まだカスタムフィールドの作り込みまでは行いません。

今回の目的は、あくまでNEWS候補専用の保存先を作ることです。

つまり、WordPressの中に「NEWS候補」という箱を作るところまでです。

箱ができていない状態で、中に入れる項目を作り込もうとすると、話が少し複雑になります。

そのため、まず第3回ではカスタム投稿タイプを登録し、NEWS候補を1件保存できることを確認します。

カスタムフィールドは、その次の段階で追加します。

この進め方には理由があります。

まず、初心者の方にとって、カスタム投稿タイプとカスタムフィールドを同時に理解するのは少し大変です。

カスタム投稿タイプは、保存先の箱です。

カスタムフィールドは、その箱の中に入れる項目です。

この2つを同時に作ると、どこまでが箱の話で、どこからが項目の話なのか分かりにくくなります。

そこで、第3回ではカスタム投稿タイプだけに集中します。

まず、NEWS候補という箱を作る。

その箱がWordPress管理画面に表示される。

テスト用のNEWS候補を保存できる。

ここまで確認します。

そして次回以降で、その箱に元記事URL、NEWS表示文、表示先NEWS、承認ステータスなどの項目を追加していきます。

このように分けることで、ひとつひとつの作業が理解しやすくなります。

また、実務上もこの進め方は有効です。

システムを作るときは、最初からすべての項目を完璧に作ろうとすると、途中で止まりやすくなります。

「この項目も必要ではないか」

「入力欄の形はテキストでよいのか、選択式がよいのか」

「ステータスの種類はこれでよいのか」

「表示先NEWSは今後増えるのではないか」

このように考え始めると、なかなか前に進めなくなります。

もちろん項目設計は大切です。

そのために第2回で項目を整理しました。

しかし、実装は段階的に進めた方が安全です。

第3回では保存先を作る。

第4回でカスタムフィールドを追加する。

第5回で固定ページやショートコードを考える。

このように分けて進めることで、仕組みを確認しながら完成に近づけることができます。

TECN NEWS候補管理 V1は、最初から巨大なシステムを作るのではありません。

WordPressの機能を組み合わせて、小さな業務改善システムを作っていく取り組みです。

そのため、今回のように作業を分けることが重要です。

第3回では、カスタム投稿タイプでNEWS候補専用の保存先を作る。

ここまでを確実に完了させます。

カスタムフィールドの追加は、次の回で丁寧に扱います。

このように進めることで、読者も「今どの部分を作っているのか」を理解しやすくなります。

H2-13 第3回のまとめ

第3回では、TECN NEWS候補管理 V1で使うNEWS候補専用の保存先を、WordPressの中に作る方法を整理しました。

第1回では、TECN NEWS候補管理 V1の目的と全体構想を確認しました。

第2回では、NEWS候補1件に持たせる項目を設計しました。

そして第3回では、そのNEWS候補を保存するための箱として、カスタム投稿タイプを作りました。

今回のポイントは、NEWS候補を通常の記事や固定ページとは分けて管理することです。

通常の記事は、読者に読んでもらうためのコンテンツです。

固定ページは、会社概要やお問い合わせページのような固定的なページや、今後作る管理用表示画面として使えます。

一方で、NEWS候補は、公開済みの記事をNEWSとしてどのように活用するかを管理するためのデータです。

そのため、NEWS候補専用の保存先を作る方が分かりやすくなります。

今回作成したカスタム投稿タイプの内部名は、

apice_news_candidate

としました。

管理画面上の表示名は、

NEWS候補

としました。

内部ではアピス系のNEWS候補データであることが分かる名前にし、管理画面では担当者が見て分かりやすい日本語名にする方針です。

また、今回はテーマファイルの functions.php を直接編集するのではなく、Code Snippetsを使って登録する方針にしました。

Code Snippetsを使うことで、テーマファイルを直接触らずに、小さなPHPコードを機能ごとに管理できます。

初心者向けにも、今後のアピスmini応用系の管理にも向いている方法です。

今回のコードを有効化すると、WordPress管理画面の左メニューに「NEWS候補」が表示されます。

そこから新規NEWS候補を追加し、保存できるようになります。

この段階では、まだ元記事URL、NEWS表示文、表示先NEWS、承認ステータスなどの専用項目はありません。

しかし、NEWS候補を保存するための基本の箱はできました。

ここまでできれば、第3回の達成目標は完了です。

今回できたことを整理すると、次の通りです。

・NEWS候補専用の保存先が必要な理由を確認した
・通常の記事、固定ページ、NEWS候補の違いを整理した
・カスタム投稿タイプの考え方を理解した
・NEWS候補をカスタム投稿タイプにする理由を確認した
・内部名を apice_news_candidate に決めた
・管理画面の表示名を NEWS候補 に決めた
・Code Snippetsで登録する方針を決めた
・カスタム投稿タイプ登録コードを用意した
・管理画面でNEWS候補を追加できることを確認する流れを整理した

これで、TECN NEWS候補管理 V1は、実際にWordPress上で動く仕組みへ一歩進みました。

次の段階では、このNEWS候補という箱の中に、第2回で設計した項目を追加していきます。

H2-14 次回はカスタムフィールドを追加する

次回は、第2回で設計した項目を、NEWS候補に持たせるためのカスタムフィールドを考えていきます。

第3回では、NEWS候補専用のカスタム投稿タイプを作りました。

これは、NEWS候補を保存するための箱です。

しかし、箱だけではまだ十分ではありません。

その箱の中に、どのような項目を入れるかを決め、実際に入力・保存できるようにする必要があります。

第2回では、V1で使う項目として次の10項目を整理しました。

・元記事タイトル
・元記事URL
・カテゴリ
・NEWS表示文
・表示先NEWS
・表示フラグ
・承認ステータス
・X投稿文案
・X投稿ステータス
・メモ

次回は、これらの項目をNEWS候補にどのように持たせるかを考えます。

WordPressでは、投稿や固定ページ、カスタム投稿タイプに追加情報を持たせる方法として、カスタムフィールドがあります。

カスタムフィールドを使うことで、NEWS候補1件ごとに、元記事URLやNEWS表示文、表示先NEWS、承認ステータスなどを保存できます。

たとえば、NEWS候補の編集画面に、次のような入力欄を追加していくイメージです。

元記事URLを入力する欄。

カテゴリを確認する欄。

NEWS表示文を入力する欄。

表示先NEWSを選ぶ欄。

表示するかどうかを選ぶ欄。

承認ステータスを選ぶ欄。

X投稿文案を入力する欄。

X投稿ステータスを選ぶ欄。

メモを入力する欄。

このような項目が追加されると、NEWS候補管理は一気に実務的な形に近づきます。

ただし、次回もいきなり複雑な画面を作り込むのではなく、まずはカスタムフィールドの考え方を分かりやすく整理します。

カスタムフィールドとは何か。

なぜNEWS候補に必要なのか。

どの項目をテキスト入力にするのか。

どの項目を選択式にするのか。

どの項目をチェック式にするのか。

このあたりを整理しながら、V1として無理のない形を考えていきます。

第3回で箱を作り、第4回で項目を入れる。

この流れで進めることで、TECN NEWS候補管理 V1は少しずつ完成に近づいていきます。

最初から全部を作ろうとせず、WBSに沿ってひとつずつ進める。

これが、初心者にも分かりやすく、実務でも使いやすいWordPressミニシステム作りの進め方です。