皆さんの多くがご存知の通り、先週、Syed BalkhiはWordCamp Raleigh 2012に参加しました。イベント中、彼のツイートの一つがかなりの議論を巻き起こしました。この記事では、当社の創設者であるSyed Balkhiが、WordPressカスタム投稿タイプはfunctions.phpファイルに属するのか、それともプラグインに属するのかについて議論します。この議論のきっかけとなったツイートは以下の通りです。
functions.php にカスタム投稿タイプを追加しないでください -> 必ずサイト固有のプラグインを使用してください – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 2012年11月4日
ツイートの後、WordPressコミュニティの多くの評判の良い人々が意見を述べました。 会話全体はこちらで見ることができます。Curtis McHaleはさらに一歩進んで、彼の 新しいブログ記事でこのトピックについて詳しく説明しました。
Twitter での会話から、いくつかの素晴らしい点が提起されました。
議論の要約
プラグインの議論：テーマを変更しても、ユーザーは常にデータを持っています。見た目はそれほど美しくないかもしれませんが、そこに残ります。
functions.phpの議論：デザインのないデータは無関係になります。ユーザーをさらに混乱させるだけです。
どちらの意見に賛成しますか？ 明らかにどちらの側にも問題がありますが、より少ない悪はどちらでしょうか？
カスタム投稿タイプを常に サイト固有のプラグインまたは完全に別のプラグインに配置すべきだと考える理由はここにあります。
データ万歳
カスタム投稿タイプはデータです。ほとんどの場合、あなたのデータは現在のデザインよりも長く存続します。テーマを数回変更した経験から、その声明を明確に理解しています。投稿、ページ、リンク、添付ファイル、リビジョンはすべてWordPressに組み込まれている投稿タイプの種類です。それに加えて、書籍、お客様の声、セールなどの投稿タイプがあります。もしテーマを変更してこれらすべてが消えてしまったら、どうなるか想像できますか？確かに、私たちはそうしたくありません。
チームに開発者がいるので、これはあまり問題にならないはずです。当社のすべてのテーマはチームによってカスタムデザインされていることを考えると、実際にはどのような違いがあるのでしょうか？鍵は2つの言葉にあります：時間と一元化です。必要なデータがすべて揃っていれば、将来行う必要があるのはスタイリングを変更することだけです。毎回、関数をあるファイルから別のファイルにコピー＆ペーストする心配をする必要はありません。機能を複製したい場合はどうすればよいですか？プラグインを持ってきて新しいサイトにドロップするだけです。スタイリングを変更すれば完了です。
ルールと標準
私たちのツイートのように「常に」という言葉を使うと、それは規則と基準の両方を意味する可能性があります。規則と基準はどちらも大多数のために作られています。規則が曲げられ、基準が破られる特別な状況は常にありますが、だからといって基準を完全に廃止すべきだということにはなりません。
ほとんど同じ追加メタフィールドを必要とする、一般的な投稿タイプが数多くあります。例えば、引用、書籍、レシピ、お客様の声、ポートフォリオなどです。
無料および商用の市場で入手可能な写真やポートフォリオのテーマの数を考慮すると、ユーザーがテーマを変更するたびにカスタム投稿タイプの情報をすべて再入力させるのは、ほとんど意味がありません。例を見てみましょう。
写真家 – ユーザーはブログ機能（デフォルトの「投稿」CPT）を持つWordPressをセットアップしました。彼は自分の作品のポートフォリオを追加したいと考えています（ポートフォリオCPTが必要です）。彼はクライアントの推薦文を表示したいと考えています（推薦文CPTが必要です）。これらの情報はすべて、テーマのデザインを超えて存続するはずです。1年後、ユーザーはサイトの外観を変更してリフレッシュしたいと考えます。同様の機能を持つ新しいテーマを見つけます。テーマを切り替えた瞬間、ブーム。ユーザーが入力した以前のすべてのデータが消えてしまいました。ポートフォリオというメニュー、推薦文というメニューがありますが、データは何もありません。ユーザーは「なんてこった、すべてのコンテンツを失った！」と思います。フォーラムに新しいサポート質問を作成します。WPBeginnerなどのサイトにメールを送信します。良い返信が得られない場合、すべてのデータを再入力する必要があります。これはひどいユーザーエクスペリエンスです。
では、この問題はどのように解決すればよいのでしょうか？
考えられる解決策？
新しい標準ベースを作成します。 Justin Tadlockは、ベースポートフォリオプラグインを作成することで、しばらく前にこの問題に取り組み始めました。それはすべての人にとって完璧な解決策になるでしょうか？いいえ、しかしそれは大多数の人々にとってそうなるでしょう。
Justinが彼の投稿で尋ねているように、ポートフォリオプラグイン（投稿メタを参照）にはどのような標準フィールドを含めるべきでしょうか。このような会話は、テーマで同様の機能を作成している開発者の間で起こる必要があります。同じものをテーマ間で何度もコピー＆ペーストするのではなく、プラグインで実現できるのに、なぜそうしないのでしょうか？それが標準になれば、他のテーマの作者もそれに適応し始めるでしょう。
例えば、Genesis のような WordPress テーマフレームワークでは、Gravity Forms のスタイルサポートが増加しているのを目にします。なぜでしょうか？それは、ユーザーがそれを使用していることを理解しているからです。
機能が豊富に搭載された堅牢な WordPress テーマの中には、プラグインであるべきだと私たちが考えているものがあります。求人情報テーマ、課題追跡テーマ、クラシファイド広告テーマ、不動産テーマなど。これらはすべてベースプラグインによって強化されるべきです。これはすでに WooCommerce で起こっています。WooThemes は、プラグインの組み込みスタイルサポートを備えた多数のテーマをリリースしています。他のテーマ会社も、WooCommerce ベースの e コマーステーマをリリースすると約束しています。テーマを切り替えても、すべての製品はそのまま維持できます。それは、テーマが変更されたのに、すべてがそのまま収まったようなものです。それが、私たちが目指すべきテーマ変更の体験です。
ポートフォリオ、お客様の声、その他の一般的なカスタム投稿タイプでも同じことをしないのはなぜですか？それは、eコマースよりも単純すぎるからですか？eコマースは他のものと比較してフィールドが多すぎるため、これらの一般的な投稿タイプにとってははるかに簡単になるはずです。それは単に物事をより良くするために意識的な努力をすることの問題です。
ReciPressプラグインをご覧ください。レシピフィールドを持つカスタムメタボックスを作成し、それを投稿にアタッチします。ただし、カスタム投稿タイプにアタッチすることも可能です。このプラグインを使用している人は、このような手間をかけずにテーマを変更できます。
AgentPress のようなテーマが、中央集権化されたベースプラグインによって強化されると、さらに良くなるでしょう。テーマの切り替えがより簡単になるのを見るのは素晴らしいことです。たとえば、ユーザーが写真関連のテーマから別の写真関連のテーマに切り替えた場合、混乱が生じるべきではありません。軽微なエラーは発生するかもしれませんが、少なくとも全体像としては、うまくいくでしょう。
一度きりのクライアント使用のために作成された、超カスタマイズされた投稿タイプの例を常に挙げることができますが、それは例外であり、規則ではありません。
このトピックについて皆さんはどう思いますか？カスタム投稿タイプのコードはどこに配置すべきですか？functions.phpファイル内ですか、それともプラグイン内ですか？
Yazmin
テーマを切り替えるたびにCPTを何度も失った経験から、functions.phpで同じ機能を何度も設定しなければならないことにフラストレーションを感じています。
私はプラグインルートを完全に好み、今後も私のビジネスプロジェクトでもこの方法を使用します。
ジョシュア・ジャービス
不動産テーマで全く同じ問題が発生しています。「物件」はすべてカスタムタイプでしたが、そのテーマは現在機能的に廃止されています。テーマをアップグレードしようとしたところ、カスタム投稿コンテンツがすべて失われ、すべてを転送する方法を見つけなければならなくなりました。選択肢はありますが、プラグインであればこれは必要ありませんでした。
編集スタッフ
ご不便をおかけして大変申し訳ございません。この投稿を書いたのは、それがエンドユーザーの生活を本当に困難にすることを理解しているからです。
管理者
ヒュー・H・サンズ
「毎回、関数を別のファイルにコピー＆ペーストする必要がなくなります。」
includesで簡単に分離できるのに、functions.phpにCPTのコードを書くなんて想像できません。
この議論はほとんどの場合、データ対デザインの周りで行われますが、WPにかなり慣れていない私としては、パフォーマンスはどうでしょうか？プラグインは何かオーバーロードを課しますか？
編集スタッフ
この記事は、プラグインとパフォーマンスに関するあなたの質問に答えるはずです：
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
管理者
Hugh Sands
リンクありがとうございます、とても参考になりました！
ケルビン・アルフォンソ
私は常にCPTをfunctions.phpの別のファイルを通じて含めてきましたが、プラグインのルートに切り替えることになると思います。ありがとうございます！
スダカー
私は初心者であり、プラグインまたはfunctions.phpの賛成または反対についてコメントする専門知識はありません。しかし、functions.phpのルートを選択し、子テーマの下で行いたい場合、問題は何ですか？プラグインに入れる必要がないのはなぜですか？子テーマがあれば、将来のテーマのアップグレードやテーマの変更から私を救ってくれるのではないでしょうか？
編集スタッフ
子テーマは将来のテーマアップデートからあなたを救ってくれるでしょう。しかし、テーマを変更した場合は救ってくれません。なぜなら、アクティブなテーマを変更すると、子テーマも変更するからです。
管理者
パット・ラムゼイ
カスタム投稿タイプとカスタムタクソノミーについては、プラグイン経由で行うのが良いと考えています。サイト固有のプラグインに関する著者の言及は、私がやっている方法です。カスタム投稿タイプ、カスタムタクソノミー、メタボックスはすべて、サイトの目的に合わせて調整されたこのプラグインに入れています。最終的にサイトのテーマは変更されますが、データは残り、簡単にアクセスできます。
ショーン
開発者が「データ」と「デザイン」を分離することがモジュラーアプリを作成するために必要であるという事実を無視し続け、データがどこに配置されても、そのデータ/コードの再利用は常に問題となるでしょう。
WPコミュニティの一部には、何らかの理由で、プラグインでラップされていない限りWordPressエコシステム内のデータにアクセスできないという認識があるようで、そのため「プラグイン対テーマの大論争」に寄与するこのような議論をよく目にします。
WordPressの古いプラグインシステムを進化させることに焦点を当てるのではなく、コード/データをデザインから分離するモジュラーデザインパターンに基づいたライブラリを作成することに焦点を置く必要があります。テーマとプラグインの両方で使用できるライブラリです。
このような議論は、WPのPHP4時代には無意味です!!! (再投稿)
マーク・シムチョック
Re: 「Justinが投稿で尋ねているように、ポートフォリオプラグイン（投稿メタを参照）にはどのような標準フィールドを含めるべきか。この種の会話は、テーマで同様の機能を作成している開発者の間で起こる必要があります。」
私ですか？ 拡張しやすいように設計された、ドキュメントが整備されたプラグインの方が、「クローズド」で、万能型で扱いにくいアプローチ（そのコード）よりも好ましいです。
私の言いたいことは、おそらく「私はすべての人にすべてを提供しようとしているわけではありません。これが私の基本的なプラグインです。これをカスタマイズする方法はこうです。カスタマイズできるように設計されています」と言って、それで終わりにするのが可能かもしれないということです。何をしても、あらゆるユースケース、あらゆるニーズを予測するのは困難です。では、なぜわざわざするのでしょうか？なぜ、ある種のフレームワークとしてアプローチし、必要に応じて開発者がカスタマイズできるようにしないのでしょうか？
ジャスティン・タッドロック
それがまさに計画です。私は非常に小さく、カスタマイズしやすいベースを構築しています。しかし、標準であるべきフィールドがもしあれば、知りたいです。
ケビン・メインズ
タイプミス？:
「私たちのチームはすべて、私たちのチームによってカスタムデザインされています」
編集スタッフ
修正しました。ご指摘ありがとうございます
管理者
アファン・ルスラン
プラグインにあるべきだと思います。
将来的にデータが不要になる場合でも、カスタム投稿タイプを「通常の」投稿タイプにいつでも変換できます。そのためのプラグインがあり、リポジトリで検索すれば少なくとも1つは見つかるはずです。
クリストフ・デブルエル
人々が何を言おうと、私はあまり気にしません。カスタム投稿タイプはプラグインに入れます。テーマはフロントエンドでカスタム投稿タイプに合わせて簡単に変更できます。同じカスタム投稿タイプコードを持つ異なるテーマを持つよりも、テーマをカスタム投稿タイプに合わせてスタイル設定する方が論理的だと私は思います。
インゴ
「Pods Framework」も良いプラグインソリューションになる可能性があります。CPT、CT、CF用。
http://wordpress.org/extend/plugins/pods/
編集スタッフ
はい、Podsは素晴らしいです。
管理者
エリオット・リッチモンド
私にとってはプラグインです。少なくとも技術に詳しくないクライアントにとっては、テーマが正しく機能しない場合でも問題があることが明らかになり、開発者を雇うきっかけになるでしょう。
カイラス・マハジャン
プロジェクト次第です…
一定期間後にテーマを変更する必要があるプロジェクトを扱っている場合…プラグインを使用できます。
または、1つのテーマに固執しているプロジェクトの場合は、function.phpで対応できます。
ロス W
データはテーマによってスタイル設定される必要があるという話や、そうなる例、そしてデータとテーマを分離できる例について、誰もが話しています。
テーマが特定のデータが利用可能であることを前提としているケースについて、誰も話していないのが残念です。例えば、国の地図と国固有のデータを持つテーマがあり、その地図とデータなしではテーマの主要な機能が失われるとしましょう。
はい、プラグインにデータを入れても同様のことはできますが、テーマが何らかのデータが存在すると仮定するのは妥当でしょうか？データ型を作成するプラグインがインストールされて有効になっていると仮定するのは妥当でしょうか？（率直な質問です…議論しましょう！）
技術にあまり詳しくないクライアントが、自分の「テーマ」でサイトのコピーを作成したい場合はどうなりますか？彼らは新しいWordPressのインストールでテーマを有効にしますが、多くのものが欠けていたり壊れていたりすることに気づきますか？彼らは、サイトが正しく表示されるために必要なすべてがテーマに含まれていると思っていましたか？
両方のアプローチに用途があるのがわかります。私のクライアントワークのほとんどでは、CPTとメタボックス、そしてそれらに簡単にアクセスするためのいくつかの関数を設定し、ライブラリファイルに含めています。これにより、テーマが機能するために必要なすべての「もの」が1つのパッケージにまとめられますが、必要に応じてCPTを新しいテーマに簡単に移動できます。
もちろん、CPTが複数のテーマにまたがって使用できるようなもので、単一のクライアントのデータにのみ本当に適用されるほどSO特化していない場合は、必要に応じて展開できるプラグインに変換します。
データとテーマの間には、単純で一方的な関係はないと思います。「スタイリングが必要なデータがある」という状況が常に当てはまるわけではありません。時には「私のスタイリングにデータが必要」ということもあります。
それについてどう思いますか？
アンドレス・エルモシラ
1つの「完全な」パッケージを持つことには利点があることに間違いなく同意します。多くの場合、テーマプラグインとテーマをインストールするのではなく、直接結び付けられるテーマ固有の機能（例：AuttomaticのP2）があります。
コンスタンチン・コフシェーニン
プラグイン。以上。
カーティス・マクヘイル
AgentPressへの言及は、私がCPTをプラグインで完全に支持する理由の一つです。私はそのようなテーマを扱ったことがありますが、テーマからカスタム機能を削除しない限り、適切にスキンを変更するのは非常に困難です。クライアントと私は、コードを実際に作業できる状態にするために20時間を費やしました。
Birgit
私の最高のお気に入りの推奨ソリューションは、非常に柔軟なTOOLBOXです： http://wordpress.org/extend/plugins/toolbox/
編集スタッフ
いいアイデアですね。プラグインをダウンロードせずにスクリーンショットが何を示しているのか理解できたらいいのに。
-Syed
管理者
Birgit
このプラグインは、通常 functions.php で行うコードスニペットのための「ツールボックス」です。
しかし、テーマを更新すると、テーマの functions.php にあるカスタムコードが失われる可能性があります。
そのため、私のネットワークインストールではこのプラグインを使用し、ネットワーク全体で有効化しています。すると、プラグインには「モジュール」が付属しており、例えば FTP でアクセスできます。
好きなだけモジュールを作成できます。このネットワーク内のブログごとに 1 つずつ作成しています。これらのモジュール（単なる .php ファイルで、サイト固有のプラグインのようなものです）には、通常テーマの functions.php に記述するすべてのコードを追加できます。
その後、プラグインのオプションページで、各ブログでどのモジュールを読み込みたいか、またフロントエンドのみ、バックエンドのみ、または両方で読み込むかどうかを有効にできます。
そのため、通常は各ブログの functions.php に記述する個別のコードスニペットをすべてのブログに提供するために 1 つのプラグインしか必要とせず、これらのモジュールをどこで読み込むかを決定できます。
ふぅ、私の英語は最高ではないので、これが理解できることを願っています
おそらく、これを読んでいただければうまくいくでしょう： http://tinyurl.com/bf5dflt
編集スタッフ
ブリジット、WP.org のページも翻訳しました。プラグインの意図は理解しました。しかし、スクリーンショットはドイツ語で、Google はまだ画像を翻訳するほど賢くありません。あなたが投稿したリンクでも同じ問題が発生しています
サラ
テーマが変更された場合に、フロントエンドで実質的に「壊れる」可能性のあるものや、データを失う可能性のあるものについては、常にfunctions.phpよりもプラグインを好みます。これはあなたが指摘するまさにその理由によるものであり、問題の特定のためにfunctions.phpのコードをコメントアウトしなければならない場合、phpプログラマーではない私たちにとって、競合のトラブルシューティングを試みるのは狂気の沙汰だと感じます。
マット
OK、ではどの CPT プラグインをおすすめしますか？
編集スタッフ
アイデアは、サイト固有のプラグインでCPTを登録する必要があるということです。まだ特定のプラグインはありません。しかし、これは汎用的な投稿タイプのベースプラグインを作成するというアイデアを投げかけているだけです。
管理者
ムハンマド・ワカス
ローカル関数の使用についてはより確信が持てますが、この場合はプラグインの方がより信頼できると思います。例えば、特定のフレームワークでWordPressを使い始めた場合、ほとんどの場合、そのフレームワークから設定やデータを失うことなく抜け出すのを手伝ってくれるWordPressの専門家を雇わない限り、長期間そのフレームワークの奴隷になる可能性があります。一方、プラグインはほとんどすべてのテーマで機能します。
wpを使い始めた頃は、プラグインよりもフレームワークを好んでいました。現実には、プラグイン開発者は何かを開発する際に初心者やリテラシーの低い人々を考慮しています。個人的には、wpユーザーの大部分は、サイトのコア機能のためにプラグインに依存するよりも、手動のコードハックを好むと信じています。長期的にはプラグインは信頼性がありません。私はそう感じます。