ハードコードされたページ/投稿IDを `get_post`に渡す
私は、これを使って自分のホームページにページのコンテンツを取り込んだり、アーカイブから特定のカテゴリを削除したりしているようです。
$post = get_post( 5 );
誰かがこれが悪い習慣であることを提案しました。なぜそれが悪いのですか？
初心者のために、本当に5とは何かについて調べてみましょう。投稿のIDです。しかし、IDとは何ですか？特定の投稿レコードを識別するMySQLテーブル行の値です。
IDの使用に関する問題
それで最初にそれに関するいくつかの概念的な問題があります。内容ではありません。ユーザーが作成、操作、または（ほとんどの場合）認識していることではありません。 WPは（設計上）ユーザーにIDを公開することについてはかなり卑劣であり、それをすることはほとんどありません。そのためだけにかなりの数のプラグインが生成されます。
それが満足していない（または価値がある意味がある）という結果として、それは自己文書化されていません。 5という投稿がスニペットからのものである可能性があると推測する方法はまったくありません。
そして最後に、IDは特定のデータベース内の投稿を一意に識別しますが、コンテンツがデータベース間や異なるシステム間で移動し始めるとすぐにそれを行うことは確実ではありません。
それでより良い選択肢は何ですか？
私は、スタンドアロンの投稿を取得して利用する2つの典型的な理由を観察しました。
サイト内の特定のコンテンツを操作する
永続的なコンテンツは通常かなり静的で、ほとんどの場合タイトルで識別できます。例えば5のようなあなたのスニペットの低IDはしばしば "About"ページのようなものを参照します。
そのようなコンテンツの検索には get_page_by_title() が適しています。名前にもかかわらず、それは3番目の引数として$post_typeを受け入れて、ページだけでなく働きます。
そのため、より優れた識別情報を使用して（そしてその間に自己文書化コードを作成して）、スニペットは次のようになります。
$about_page = get_page_by_title( 'About' );
サイト内の特定の場所で作業する
別のケースは、投稿が特定のコンテンツではなく、サイト内の場所として使用されている場合です。たとえば、サイトのFAQを取得したいのですが、正確な名前やその他のコンテンツの詳細がわからない（または気にしない）。
しかし、それがサイトの構造のどこにあるかわかっていれば、 get_page_by_path() 関数を使うことができます。
$faq_page = get_page_by_path( 'about/faq' );
その他の場合
より複雑な場合には、必ずしも適切な関数があるとは限りません。 1つの投稿に対してだけであっても、豊富なクエリオプションを使用して get_posts() を使用することになることがあります。
この質問では、意見に基づいた答えを得ることができますが、試してみます。
誰かがあなたに言ったかもしれない理由がいくつかあります、それは文脈も知っているのは素晴らしいでしょう。
- バージョン3.4または3.5までは、この関数はパラメータがvarのときにしか機能しなかったため、誰かがそう言った理由の1つかもしれません。
- 私自身、これを悪い習慣とは考えていませんが、そのようなIDのハードコーディングを避ける方が良いと思います。そのような値を変更する方が簡単なので、私は常にOptions APIを使用しようとします。場合によっては、テーマカスタマイズAPIを使用することもできます。
- 誰がサイトを管理するつもりですか？サイトを管理しているのであれば、値を変更しても問題ないかもしれません。しかし、あなたがあなたのクライアントがコードを変更しなければならないものであると予想するならば、適切な「オプションパネル」を作成することはより良いかもしれません。
私は数週間前にそれに似たものを作りました、私はそれのためのプラグインを書きました。そしてテーマで私はちょうどプラグインの機能を呼びました。 IDを変更するオプションは各投稿のメタボックスにあり、ユーザーは自分がメインサイトに表示したい投稿のIDを選択するためにチェックボックスをチェックするだけでした。
お分かりのように、理由の大部分は誰が値を変更しなければならないのかに関連しています。また、間違った場合に備えて適切なデータ検証を設定できるため、適切な「オプションパネル」を作成することも便利です。
あなたが私にもっと文脈を与えれば私は私の答えを広げることができるかもしれない、私はあなたがそれが有用であると思うことを望む。