著者の伝統によると、いくつかの点を明確にします。
- 明確にするために、私はまた、技術的な観点から記事を検討するつもりであるが、経験豊富な開発者だけでなく、すべての開発者のプリズムを通して検討するつもりであることをすぐに言わなければなりません。
- ほとんどすべて、OOPを厳密に使用して書かれたezpublishを含む多くのCMSに対処しなければなりませんでした。 かつて彼はDrupalをしっかりと使用していました。
- 私はほとんどの場合、サードパーティのフレームワークを使用してプログラムを作成し、優れたエンジンがどうあるべきかを認識しています。
- 決して、私は自分をPHPの第一人者とは考えていません。本当の達人はおそらくWordPressテーマをバイパスすることを知っています。
WordPressよりもシンプルでエレガントな機能の実装を見たことはありません。 すべてのプロジェクトでこのCMSを使用する必要はないと思いますが、私の意見では、WordPressはそれに割り当てられたタスクにうまく対処し、OOPを使用しない限り決して対処しません。 全体的なトリックは、誰もOOPの使用を禁止していないということです。 多くのプラグインは、使用するだけで作成されています。
それでも、WordPressを使用する価値がある場合には、線を引く価値があります。
私は自分で次の点を個人的に特定しました。
-このサイトは、ORMまたはActiveRecordが必要になる可能性のある複雑なクエリを含まない、有益なものである必要があります。 つまり API、統計の場合-CMSの使用はお勧めしません。
-誰も別のコントロールパネルを必要としないため、管理パネルは受け入れられる必要があります。
-WordPressはほとんどの機能をカバーし、追加する必要のあるものは少ないと想定されています（プラグイン、テーマ）。
-プロジェクトは大きくて騒々しい。 この場合、WordPressを使用してもメリットがあるのは、広告としてのCMS開発者とプロジェクト開発者の両方です（頻繁な更新、低しきい値、既成ソリューション）。
それ以外の場合、私は完全に自分自身または他の人のフレームワークを使用するためのものです。
さらに、著者は例を挙げています。
「グローバル変数はとてもクールですね。」
はい、プロジェクトのさまざまな部分でエラーを見つけるのは困難です。 ただし、グローバル変数を使用するよりも簡単なことは何ですか？ 異なる関数に変数を渡す必要があるため、これらの変数がどこから来たのかを誤解しているように、初心者がコード内で何が起こっているのかを理解するのが難しくなります。 私たちの場合、それらは事前に決められた場所で償却され、当然のこととして提示されるため、よく知られています。
「データベース抽象化レイヤーは開発者にとって有用でしょうか？」
これにも独自のプラスがあることに注意してください。 MVCに慣れていると、意図せずに自分自身を横切ってしまい、データベースへのクエリを作成するコードをテンプレートで見ることができます。
このリクエストを作成するときに、入力パラメーターのロジックを実際に悪用する人は考慮しません（ここでは、functions.phpファイルに関数の形式ですべてを入れる方が良いことに同意します）。 しかし、私はまだこれが超自然的なものだとは思わない。 それどころか、post_typeチームを指定してチームテンプレートでリクエストを行うことができる場合に便利です。
リクエストを行うと、コンテキスト情報の出力に影響を与える可能性があることは、誰かにとっては珍しいことのように思えますが、これを回避する方法を理解すれば、問題はすぐに消えます。 get_postsまたはwp_reset_queryの使用を避けることができます。 完全に怠laな場合は、次の形式のデザインを使用できます。
$oldpost = $post; // query_posts() $post = $oldpost;
上記のコードを使用することをお勧めしません。このアプローチは基本的に間違っています。
さらに、著者は、すべてのデータが1つの共通のテーブルレイアウトに収まることをinしています。 これに最初に出会ったとき、私は少しショックを受けました。 私は、新しいエンティティごとにテーブルを作成する必要がないほど慎重にすべてを行う方法の考えに悩まされていました。 さらに、あらゆる種類のデータが変更（改訂）の履歴を保持し、同様の素材（分類）のコレクションとして相互に統合される可能性を確保します。 1つの場所ですべてのデータへのアクセスを拡大しました。
「mod_rewriteを使用したルーティング」
この点で私は同意します。 開発者は初心者向けにこの点を単純化できませんでした。正規表現の知識がなければ、リンクの事前定義を使用することは困難です。
独自に、多くの方法で書き換え関数が互いに競合することを追加します。 たとえば、分類法リンクは、カスタムコンテンツタイプまたはページへの既存のリンクと競合する場合があります。
「ファイルアーキテクチャはどうですか？」
現在の形式では、ファイルアーキテクチャがあまり柔軟ではないことに同意します。 繰り返しますが、開発者は独自のincludeとrequre_onceを使用して、すべてのDRYを別のサブフォルダーに分類することを禁じられていません。
単純なファイルアーキテクチャがどうあるべきかについてのすべての考えは、多くの場合、普通の初心者、またはレイアウトを微調整するだけのデザイナーの理解の境界を曖昧にします。 テンプレートの命名規則がすべてを構成します。
少ないの使用に関して、sass。 現在WordPressにあるように、私はそれらを非常に使用することができました。
著者は、ある程度まで、名前空間、カプセル化、継承を備えたオートローダーの使用を始めたばかりだと思われます。 同時に、WordPress開発チームをプログラミングするための機能的なアプローチを書き留めて、適切なアーキテクチャを作成しようとします。 実際のところ、PHP5のみのプログラミングにはヒットせず、名前空間を使用してクラス内にすべてをカプセル化することはできなかった、というのは控えめなことです。
OOPの要素を備えた別の超シンプルなCMSのリリース後、このアプローチが遅かれ早かれ廃止されるとは言いませんが、これまでのところ伝言によるプログラミングに精通している人でもすべてが非常に明確であり、プロが自分で書くことを含めてすべてを理解するのは簡単ですプラグイン、フック、定義済みのカスタム関数。複雑なドキュメントの作成に3日間余分に費やす必要はありません。
擬似Cronタスク
ここで私はignしている著者に同意すると簡単に答えます。
「画像スライス」
宣言された型は、意図された目的に使用されると想定されています。そうでない場合、問題が発生します-なぜ宣言する必要があります。 著者が特定の画像に特定のタイプの使用を示唆していることは明らかですが、ここで別の質問があります-この画像の使用が別のユーザーの場合に必要ないことをどのように確認できますか？
開発者に、必要に応じて画像を生成するサードパーティのプラグインの運命に任せていなかったことに敬意を表さなければなりません（擬似クラウンを持つ同じアイテム）
おわりに
パターン、アルゴリズム、アメニティのトピックについて長い間哲学を立てることができます...ちょっと待ってください。WPはプロのプログラマーのためではなく、自分のブログの作成方法に興味がある普通の人々のために作成されたものです。 この観点では、おそらくWordPressは99％の仕事をしています。