建築
両方のフレームワークは、コア+テーマ+アドオンという類似のアーキテクチャで構築されています。 コア（エンジン）は基本的な機能を提供します。 Drupalのアドオンは、WPではプラグインと呼ばれるモジュールです。 そして、それらを作成するためのモジュールとプラグインは最小限の労力（特定の構造を持つファイルのペア）を必要とし、本質的に違いはありません。これは、関連する可能性のあるスタイルと、システムに個別に配布およびインストールできるJSスクリプトを備えた名前付きのphpコードです。 テーマは、ルックアンドフィールサイトを提供するように設計されており、ページテンプレートとサポートコードで構成され、個別に配布およびインストールされます。 詳細は後で検討します。
カーネルと標準コンポーネントのコア機能のカスタマイズと再定義は、これらのシステムでも同様の目的を持つフックシステムを使用して行われます。 したがって、全体的なアーキテクチャは非常に似ているようです。
運用上の特徴
WordPressは、ブログエンジンとしての本来の目的から長い間成長してきました。 現時点では、その使用は事実上無制限であると宣言されています。 Drupalは、CMF（コンテンツ管理フレームワーク）として定義されることもありますが、もともとはすべてのタイプのサイトに適したユニバーサルとして考えられていました。 両方のシステムのインストールは短時間（5〜10分）で、特別なコンピューター電源を必要とせず、無料です。 どちらの場合も、インストール後、サイトを構成してデフォルトのテーマで使用する準備が整います。
WPはデータベースとしてMySQLのみを使用し、Drupalは一般的なデータベース（MS-SQL、Oracle、SQLite、PostgreSQL）のバリアントのセットを提供します。 基本的なインストール後、WPはDrupalの11個のデータベーステーブルを作成します-100以上（一見すると、2番目も怖いです）。
どちらのシステムにも管理メニューがあります。 Drupalは明確に独自のテーマを定義しています。管理パネルのWPでは、正式にはテーマは常に同じですが、プラグインを使用して構成されます。 一般に、WP管理パネルは、プロの管理者またはプログラマー向けに設計されているように見えるDrupal管理パネルよりも、エンドユーザーが使用しやすく理解しやすいように見えます（ただし、これは管理パネルのトピックにすぎません）。
WPプラグインは、管理パネルで簡単に検索してインストールできます。通常、わかりやすい説明とユーザー向けのあらゆる種類のヒントがあります（「こんにちは、インストールしました、ここをクリックしてください」など）。 Drupalにはモジュールの組み込み検索エンジンがありません。モジュールはdrupal.orgで手動で検索され、モジュールディレクトリに直接コピーするか（WPでも可能）、またはダッシュコンソールアプリケーションを使用してURLによってインストールされます（WPにはWPコンソールアプリケーションもあります） CLIですが、あまり人気がありません）。
両方のシステムの更新は非常に似ており、更新チェックは自動化されており、更新自体はボタンをクリックするだけでダウンロードおよびインストールされます。 主な違いはメジャーバージョンシステムです。WPでは、完全な下位互換性（およびサイトの最新バージョンへの更新）を備えた単一行ポリシーを順守していますが、たとえば、Drupal 7とDrupal 8は完全に異なり、互換性のない製品ラインです。 Drupal 7からDrupal 8にサイトを移行するには、プログラマーの多大な努力が必要になる場合があります。
両方のシステムの更新が体系的に行われるという事実により、「カーネルをクラックする」ことも推奨されません。 カーネルファイルを変更します。 ほとんどの場合、これを行う必要はなく、これが唯一の方法であると思われる場合は、CMSがタスクに適切に選択されていない（あまり一般的ではない）か、または（ほとんどの場合）すべてのシステム構成オプションがまだ検討されていない可能性があります。
モジュールとプラグインの詳細
Drupalモジュールは、module_name.moduleおよびmodule_name.infoファイルを定義することによって作成されます。前者は完全に空にすることができ、後者には特定の構造の最小限の情報のみを含める必要があります。 これらのファイルがモジュールフォルダー（通常は別のフォルダーにありますが、必須ではありません）に表示されると、Drupalはモジュールを認識し、管理メニューパネルに表示します。 作業を開始するには、モジュールをアクティブ化する必要があります。 カスタム（つまり、このプロジェクトのプログラマーによって作成された）モジュールは、相手（標準、Drupalデータベースにある）モジュールと違いはありません。実際には、後者は特定のプロジェクトのニーズに合わせて改良される場合があります。
モジュールには、論理的に分離された機能の一部、つまり 機能のより複雑な部分を個別のモジュールに分類することは歓迎されます（「個別の/分離可能なものを見る-モジュールを書く」）。 特にDrupal Commerce （相互接続された多くのモジュールで構成される）などの大規模なサブシステムを使用するプロのDrupalサイトには、数百の貢献者モジュールとカスタムモジュールが含まれる場合があります。
WPプラグインを決定するには、最小限の労力、つまりヘッダーにコメントを含む1つのPHPファイルだけが必要です（プラグインの名前が1行だけ必要です）。 モジュールと同様に、管理パネルでプラグインを有効にして開始する必要があります。 実際には、コードを記述する場所がないため（functions.phpテーマファイルにはすべての機能を含めることは意図されておらず、ビジネスロジックコードをテンプレートに入力することは一般的ではありません）、アプリケーションはプラグインへのブレークダウンを使用して編成されます。
WordPressは多くのプラグインが存在することでしばしば批判されますが、特定のプラグインを接続してもサイトがセキュリティホールを形成しないことを誰も保証しません。 Drupalでは、一般の人がモジュールの状態を監視することはより注意深いように見えますが、これがセキュリティシステムの問題を本当に防ぐことができるのか、すでに起こった災害に迅速に対応するだけなのかは明確ではありません。 一般に、WPプラグイン市場はより「無料」で汎用性が高い（そして安全でない）印象を与え、Drupalモジュールのセットはより専門的にテストされている印象を与えます。 ただの印象かもしれませんが。
フック
テーマ、モジュール、およびプラグインの作業の基礎は、フックを使用する能力（および必要性）です。 フック（フック）は、コードのデフォルトの動作を変更できる場合に、カーネルまたは別のモジュール/プラグイン内の場所です。 両方のシステムに多くのフックがあります（Drupalの基本的なフックは約350、WPでは約250）。
Drupalは、フックに興味深い独特の命名システムを使用します。これは、別個の明示的な接続を必要としません。 たとえば、my_moduleモジュールのmy_module_menu関数は、ルートを定義するためのフックとして自動的に機能します（テンプレート名は「hook_menu」です）。 WPでは、フック（正確には、フック/アクションまたはフィルターアクション、本質的に同じもの）を決定するには、add_actionまたはadd_filter関数を明示的に呼び出す必要があります。 これに関する考慮事項は異なる場合があります。 一方では、関数を定義してからadd_action（）を呼び出すことは、やや冗長な構文のように思えるかもしれません。 一方、次のニュアンスがあります。
- add_action（）は、コード内の「魔法」の量をいくらか減らしますが、コードの可読性には寄与しません。
- add_action（）は、1つのプラグインが必要な数のハンドラーを追加できるようにしますが、関数my_module_menu（）はこのモジュールに1つしか追加できません。
- 別のモジュールのフックをキャンセルできるremove_action（）関数がありますが、Drupalにはそのようなメカニズムはありません。
テーマを作成
Drupalテーマは、sites / all / themesフォルダーにthemename.infoファイルを作成した後に表示されます。 Infoファイルは、トピックに関する一般的な情報を定義する単純なテキストファイルです。タイトル、作成者、ページ上の領域、JSおよびCSSインクルードファイルなど。 作成またはインストールした後（テーマのインストールはモジュールのインストールに似ています）、管理パネルでテーマをアクティブにし、メインテーマを選択する必要があります。
WPテーマは2つのファイルで定義されます。メインのファイルはstyle.cssで、テーマの名前（そしてもちろん、通常はスタイル）を設定し、追加のファイルは基本的なindex.phpテンプレートです。 WPテーマ定義構造は、WPが単純なブログエンジンであり、唯一のテンプレートがindex.phpであり、style.css自体にスタイルが含まれていた時代にまで遡ります。 それ以来、より多くのテンプレートがありましたが、トピックの定義は同じままです。 style.cssを必須にし、メインテーマファイルをエレガントにすることはできませんが、下位互換性はあります。
どちらのシステムも子会社の作成をサポートしているため、非常に複雑な既製のテーマを自分でカスタマイズして作業する際の作業が簡素化されます。 子テーマの場合、* .infoおよびstyle.cssファイルのみが必須のままです。
Drupalのテーマにはtemplate.phpファイルが付属しており、テーマの設定が行われ、テーマ全体に固有の機能が決定されます。 WPにも同様のfunctions.phpファイルがあります。 独自のWPテーマを作成する場合、functions.phpは通常、テーマの典型的な機能（add_theme_supportおよびremove_theme_support関数）を接続および切断するためのコードを配置し、JSスクリプト、スタイル、およびサイドバーが登録されます。 Drupalでは、そのようなことは通常、管理パネルのマウスで行われ、テンプレートの動作をオーバーライドするtemplate_process / template_preprocessのような関数はtemplate.phpに配置されます。
用意されているテーマとその設定
既製のテーマとその設定に関しては、WPはDrupalを大きく上回っています。 無料（および非無料）アクセスでは、すべての好みに合った非常に幅広いトピックがあり、クラシックでモダンなデザイン、普通、レスポンシブ、そして一般的に何でもあります。 さらに、WPはテーマ設定を定義するための個別のAPI（カスタマイザー）を提供し、テーマ作成者はそれらを可能な限りカスタマイズ可能にしようとします。 WPテーマは、定期的な更新とプレミアム機能を備えた個別の製品である場合があります。 WPテーマを設定する際の別の機能は、プレビュー機能です。
Drupalはテーマをそのようにカスタマイズすることに焦点を合わせていません。 管理パネルの通常のテーマの場合、名前、アイコンなど、サイトの配色とメインパラメータのみを変更できます。 典型的な方法では、自分のWebサイトを作成するプログラマーは、標準的なミニマリストテーマ（たとえばStark ）を受け取り、それに基づいてレイアウトを構築します。 もう1つのアプローチは、レスポンシブデザインを使用するZenテーマ、Sass、Gulpなど、より高度な製品を使用することです。
HTTPリクエスト処理
Webアプリケーションでは、すべてクエリ文字列で始まります。 クエリ文字列を使用して、両方のシステムが処理方法を決定します。 Drupalは、標準パス（「node / 1234」、「user / 123」、「taxonomy / term / 123」など）とカスタムパス（hook_menuを使用して定義）の両方を含むパスルーターを作成します。 クエリ文字列を分析した後、目的のパスがルーターで検出され、ページレンダリング関数であるdelivery_callbackがパスに付加された追加情報から取得されます。 デフォルトのdrupal_deliver_html_pageとajax ajax_deliverの2つの標準配信コールバックがあります。さらに、パスを定義するときに独自のコールバックを設定できます。
WPでは、クエリ文字列はクエリ文字列に基づいて解析され、WP_Queryクラスのグローバル$ wp_queryオブジェクトが作成されます。 次に、条件タグが設定され（ 条件タグ -is_page、is_single、is_category、is_archiveなど）、リクエストが何であり、実際に何がリクエストされているか（特定の種類の投稿、アーカイブまたはカテゴリからの投稿など）を記述します。 グローバル$ wp_queryオブジェクトと条件タグは、テンプレートとユーザーコードでさらに使用されます。 条件付きタグに基づいて、レンダリング用のテンプレートファイルをさらに選択することもできます。
一般に、Drupalのアプローチはより体系的で堅牢です（ルーターはパスとハンドラーの単一のリポジトリです）、WPのアプローチはより単純で、明らかに進化しています（たとえば、新しい条件タグを追加することによって）が、それでもかなり柔軟でカスタマイズ可能です。 WP_Queryクラスは 、追加のクエリを使用した単純な作業に非常に便利なメカニズムであると思われ 、pre_get_postsフックを使用してメインクエリを変更できます。
パターン
Drupalテンプレートの階層構造は次のとおりです。 最下位レベルのテンプレートはhtml.tpl.phpで、これにはdoctypeタグを持つページのメインマークアップが含まれています。 CSS / JSを追加するための高レベルのメカニズムがあるため、比較的まれなケースで構成されます（Googleアナリティクスコードも別のモジュールで実装されます ）。 次に、page.tpl.phpがあります。これは、変数$ページとしてhtml.tpl.phpに挿入され、ページの全体的な構造を定義します。 page.tpl.phpでは、トピック情報ファイルで指定された地域が定義されています。 Drupalにはヘッダーとフッターの明示的な概念はありません。論理的には、これらはHTMLとページテンプレートの間で「広がり」ます。
サブジェクトのリージョンのシステムは非常に便利で柔軟です。リージョンについては、独自のテンプレート（region.tpl.phpテンプレート）を定義できます。好きなだけリージョンを追加でき、デフォルトでは適切な基本セットが提供されます。 ページテンプレートには可変の$コンテンツがあり、これを介して実際のコンテンツがテンプレートに入ります。 タイプノード（ノード）のエンティティによってDrupalで表されるコンテンツを出力するには、テンプレートnode.tpl.phpがあります。
これらすべての基本的なテンプレートには、デフォルトバージョンがあります。 テーマは、独自のフォルダにテンプレートがなくても完全に存続できます。この場合、カーネルとカーネルモジュール（システムモジュールなど）からの同じ名前のテンプレートが選択されます。 オーバーライドするには、テンプレートを見つけてテーマフォルダーにコピーします。 モジュールは、たとえばViewsモジュールで行われるように、標準のテンプレートに加えて、独自のテンプレートを定義できます。 各テンプレートには、多くの定義済み変数（テンプレートのコメントで詳細に説明）が提供されます。これらの変数は、process_page / preprocess_pageなどの関数で変更および補足できます。
一般に、Drupalテーマテンプレートの階層には「ネスト」の文字があり、フィールドはノードに埋め込まれ、ノードはページに埋め込まれ、ページはhtmlに埋め込まれます。 また、特殊化中にテンプレート間で置換が行われます（たとえば、node.tpl.phpの代わりにnode-15.tpl.phpが使用される場合）。
WPテンプレート階層は異なります。 ここでのすべての基本的なテンプレートは「フルサイズ」、つまり doctypeが含まれます。 どのテンプレートが適用されるかは、現在の要求と条件タグによって異なります。 タグは、使用するテンプレートを決定します。 たとえば、ページがリクエストされた場合（is_page（）== true）、システムはpage.phpを使用します。リクエストにカテゴリ（is_category）が含まれる場合、category.php、別のブログエントリがある場合、single.phpが使用されます。 。 中心となるのはindex.phpテンプレートで、これは特定のテンプレートが見つからなかったリクエストを処理するために使用されます。 むかしむかし、このテンプレートはWPでユニークであり、この中心的な場所はその背後にありました。
WPにはデフォルトのテンプレートはありませんが、index.php（「雑食」テンプレートとして）は、ほとんどの場合、WP ループの典型的な外観を持っています 。 WordPressは通常、header.phpおよびfooter.phpテンプレートを明示的に定義します。 これらはhtmlの「生の」部分です（header.phpでタグを開き、footer.phpでタグを閉じます）。 関数get_header（）およびget_footer（）は、挿入のために提供されています（したがって、ファイルはそのように呼び出す必要があります）。 原始的なように見えますが、シンプルで理解しやすいです。 サイドバーはWPのDrupal領域に対応し、独自のsidebar-name.phpテンプレートとdynamic_sidebar（）関数（サイドバーとウィジェットについては少し後で）があります。
WPの標準テンプレートに加えて、名前付きのカスタムテンプレートを作成して、個々のページに適用できます（ページを作成するときに、少なくとも1つ存在する場合はテンプレートを使用するオプションが表示されます）。
メインページを表示するには、静的ページ、標準のブログビュー、またはカスタムテンプレートなど、いくつかの表示オプションに基づいた明確なロジックはありません（私には思えた）。 詳細は、トピック開発セクションのWPコードに記載されています。
ご覧のとおり、Drupalのパターンはより体系的で習得が容易ですが、WPではおそらくより柔軟で実用的です。 効率的に適用するには、両方のテンプレート階層を調査する必要があります。 希望する結果を達成するための選択肢と必要な柔軟性があります。
リージョンとサイドバー
したがって、トピックのDrupal情報ファイルでは領域が決定され、page.tpl.phpファイルではページ上の領域の位置が決定され、領域ではname.tpl.phpテンプレートで特定の領域のマークアップが決定されます。 これにより、明確な構造と、テーマの構築における大きな柔軟性が得られます。 地域を決定すると、管理パネルでブロックを配置できます（ブロック）。 ブロックは視覚的に分離されたページへの出力であり、リージョン間で簡単に移動できます（たとえば、管理パネルのマウスを使用して）。 基本的に、ブロックとメインコンテンツに対応するためにリージョンが作成されます。 ブロックは標準（たとえば、「Drupal製」）にすることも、フック（hook_block_info）を使用して任意のモジュールで定義することも、管理パネルで任意のhtmlコードとして作成することもできます。 ブロックには、name.tpl.phpというブロックテンプレートがあります。
WPのウィジェットは、Drupalのブロックとまったく同じです。 WordPressウィジェットは標準（たとえば、「WPで実行されるサイト」）であり、プラグインとテーマによって作成でき（WP_Widgetクラスとregister_widget関数の継承を使用）、htmlコードを使用して管理パネルで直接定義できます（より正確には、標準ウィジェットがあります。任意のHTMLコードを配置できます）。 WPでの地域の役割は、サイドバーが果たします。 register_sidebar関数を使用して、functions.phpファイルのテーマにサイドバーを登録する必要があります。 登録後、サイドバーは[ウィジェット]セクションの管理パネルで使用可能になり、さまざまなタイプのウィジェットを配置できます。 デフォルトでは、サイドバー用のsidebar.phpテンプレートがありますが、追加の「名前付き」サイドバーについては、sidebar-name.phpテンプレートを定義できます。
一般に、Drupalのリージョンとブロックは多少使いやすいですが、重要ではありませんが、サイドバーとウィジェットの機能は完全に類似しています。
CSS / JS接続
WPでJSを接続するには、wp_enqueue_script関数とwp_enqueue_scriptsフックを使用します。 実際には唯一の方法。 接続を制御する場合、WPのフックにはadd_action（）の明示的な呼び出しが必要なので、ロジックが使用されます。 DrupalでJSを接続するには、いくつかの方法があります。
- トピック情報ファイルの接続
- drupal_add_js関数による接続（wp_enqueue_scriptと同様）
- ライブラリAPIを介した接続
- フォームのattachパラメーターを介した接続
- html.tpl.phpテンプレートへの直接接続（非推奨）;
最初の方法は最も便利で論理的で、2番目の方法では接続時にロジックを追加できます。 Libraries APIは、いくつかのバージョンを使用してライブラリ全体（JS / CSS / PHP）を接続し、ロードするバージョンを追跡できる非常に便利なものです。 ライブラリはいくつかのトピックに使用できます。
CSSを接続する場合、接続メカニズムは似ています（スクリプトをスタイルに置き換え、jsをcssに置き換えます）。
内容
歴史的な理由により、WPのコンテンツは投稿と呼ばれ、Drupalのコンテンツはノードと呼ばれます。 一般に、ニュアンスを除いて、特別な違いはありません。 たとえば、WPの2つの標準タイプのコンテンツは、実際の投稿とページです。 ページは投稿のサブタイプではありませんが、独自のプロパティを備えたコンテンツの一種です。 たとえば、ページの分類法を定義することはできません。 ページは多くの場合、静的コンテンツに使用されますが、カスタムテンプレートに従って定義できます。 本質的に何でも含む。
Drupalのノードは、ページを含むすべての種類のコンテンツです。 すべてのコンテンツは、「/ node / 12345」などの「node / node_id」タイプのリンクを介して最初にアクセスできるため、すべてのコンテンツが統合されます。
コンテンツタイプとフィールド
コンテンツタイプは、それぞれノードと投稿のサブタイプです。 WPの場合、投稿のタイプは特定のマーカー名によって単純に決定され、他には何も定義しません。 この「タイプ」で投稿を作成できます。データベースからタイプごとにプルできます。 Drupalの場合、ノード（バンドル）のタイプは名前だけでなく、たとえば、デフォルトでこのバンドルに添付されるカスタムフィールドでもあります。 WPでは、フィールドの代わりに、基本機能にメタ情報があります。これは、投稿（タイプ全体ではなく特定の投稿）に添付できるあらゆる種類のキーと値のペアです。
一般的な解決策は、Drupalのアプローチと同様に、フィールドセットを定義してコンテンツタイプに添付できるAdvanced Custom Fields （ACF）モジュールを使用することです。 Drupalでは、フィールドとフィールドインスタンスの概念が分離されているため、これはより柔軟に行われます-抽象的に定義されたフィールドと、ある種のバンドルに添付されたフィールド。 しかし、全体的には、実際的な可能性は最終的に似ています。
WPメタ情報は、投稿だけでなく、ユーザー、分類用語、コメント（add_post_meta、add_user_meta、add_term_meta、add_comment_meta関数）にも添付できます。 Drupalにはエンティティ（エンティティおよびエンティティAPI）の一般的な概念があり、フィールド化可能なプロパティを持つエンティティにフィールドが関連付けられます。
分類学
分類法は、用語の階層を使用したコンテンツの分類です。 どちらのシステムにも、アイデア自体はそれほど複雑ではないため、任意の複雑な分類法を決定するためのフル機能が備わっています。 どちらのシステムも、辞書と分類用語を使用した操作用の高度なAPIを提供します。 WPでのカスタム投稿タイプと階層的分類法の出現は、根本的な変化として発表されました。これにより、WPは単なるブログエンジンではなく、本格的なCMSになりました。 おそらくこれに同意できるかもしれませんが、以前の「ブログ指向」のWPにはかなりの初歩があります（たとえば、bloginfo関数、WP_Post、サイドバー、ループ自体など）。
カスタムコンテンツ出力
Drupalの最も重要な貢献者の1つであるViewsは 、利用可能なタイプのコンテンツをほぼすべての形式で表示するページを作成できます。 これはすべて管理パネルから設定するのに便利ですが、必要に応じてコードからも設定できます。 実際、Drupalで特定のサイトページを作成する場合、静的ページ、ノード全体（node.tpl.phpテンプレート経由）、またはビュー（つまり、Viewsモジュールによって形成されたブロックまたはページ）の形式でコンテンツを表示するタスクは解決されます。 ビュー自体が出力コンテンツの形成方法を決定し、対応するビューモジュールテンプレートが特定の出力マークアップを決定します。 そのようなテンプレートをオーバーライドするには、モジュールからテーマにコピーする必要もあります。
WPのビューの類似物は、おそらくコンテンツを表示するための主要なメカニズム、つまりループと見なすことができます。 ループは、グローバル変数$ wp_queryを使用してクエリ結果を取得します。 ほとんどの標準テンプレートは、ループとテンプレートタグ（ Template Tags ）を使用して、コンテンツの特定の部分（タイトル、日付、投稿の実際のコンテンツ、投稿へのリンクなど）を表示します。 本質的に、Drupalビューオブジェクトは、この種のループのラッパーであり、構造化配列を使用して構成されます（Drupalは非常に気に入っています）。
どのメカニズムがより便利で柔軟であるかを言うのは困難です。 プログラミングすることなくビューを作成でき、すぐに実際のコンテンツにすべてが表示される方法のプレビューを取得できます。 一方、ビューの微調整（コードからビューオブジェクトとviews_embed_viewなどの関数）は、WPループの出力を設定するよりも明らかに複雑です。 ただし、すでに構成されているビューオブジェクトはコードのどこでも再利用でき、ループコードを繰り返す必要はありません。
一連のテンプレートを使用したコンテンツの出力について言えば、1つの重要な違いに注意することが重要です-最後の瞬間（render（）またはdrupal_render（）関数を呼び出す）まで、Drupalでコンテンツを出力する形式は、いわゆるレンダリング可能な配列 -変更しやすい構造化された配列の形式のままです完成したHTML文字列よりも。 構造化配列は興味深い便利なメカニズムですが、これらの配列は時間の経過とともに信じられないほどのサイズ（時には数十万の要素）に成長し、再帰的になり、同じコンテンツを組み込み、再組み込みします。
API
DrupalとWPはどちらも常に進化し、プログラマー向けの新機能を追加しています。 両方のシステムで、これらの機能は個別のAPIとして構成されています。 それらのいくつかを考えてみましょう。
AJAX API
DrupalはAjaxを操作するための非常に興味深いインターフェースを提供します。 主なアイデアは、JavaScriptコードを記述せずに、可能な限りAjax機能を整理することです。 これは、「use-ajax」（ボタンまたはリンクにクラスを割り当てる）などのCSSクラスと、ajaxリクエストの標準処理メカニズム（すべてのajaxリクエストには1つの典型的なシステム/ ajaxパスがあります）を導入することで達成されます。 サーバー側では、ajax_command_ *シリーズの関数（たとえば、ajax_command_invoke）を使用して、特定のjQuery関数の呼び出しまで、ブラウザーで何が起こるかを完全に決定できます。 このメカニズムをマスターするには時間がかかりますが、後で必要なDOMの部分をPHPから直接効率的に再描画できます。
別の考慮事項は、 Drupalの動作メカニズムです。 設計上、このメカニズムは、ページの初期読み込み中だけでなく、たとえば、ajaxリクエストでDOMの一部を再描画した後など、適切なタイミングで含まれる動作としてJSコードを扱うことを目的としています。 動作はコンテキスト（実際には変更が発生したDOMのルート要素）を取得し、それに応じて応答できます。 ビヘイビアメカニズムは、マスターされ、正しく適用されている場合に役立ちます。
WPのAjaxメカニズムは、PHPの基本的な基本的なajaxとははるかに単純でわずかに異なります。 基本的に、WPはJSからのリクエストが送信される標準パス（JSのグローバルajaxurl変数）と、フックを介してハンドラーを決定するメカニズムを定義します。 Ajax応答は、WP_Ajax_Responseクラスを使用して生成され、必要なXMLコードを作成するだけです。 wp_send_json関数を使用することもできます。
Forms API
Drupalは、構造化配列を使用してフォームを操作するためのかなり強力なAPIを提供します。 実際、Drupalのすべてのフォームは、構造化配列の要素として、そのすべてのコンポーネントの説明によって決定され、drupal_renderを使用してテンプレートにすでに表示されている必要があります。 配列の要素を定義するとき、たとえば上記のAjax APIを使用したり、JS / CSSフォームに特に必要なものを含めたり、複数ページのフォームを作成したりなど、多くの興味深いものを指定できます。 Forms API（FAPI）は、入力検証、複数の送信ハンドラー、およびフックを使用してフォームをオーバーライドする機能をサポートしています。
WPには、フォームを操作するためのそのようなメカニズムはありません;サイトのフィードバックフォームを描画し、それらをページに埋め込む管理パネルで役立つ多くのプラグインがあります。 Drupal FAPIに似たものを作成する試みがあります。 一般的に、そのような基本的な機能のために、Form :: open（）のような単純なヘルパーすら存在しないのは少し残念です。
方法の詳細
既に述べたように、Drupalのルートはhook_menuフックを使用して定義されます。 したがって、任意の可能なパス（通常、管理パネル、Ajax、APIなど）を設定できます-メソッドは便利で統一されています。 WPにはそのような統一された方法はありませんが、2つの興味深いAPIがあります。パスを美しいリンクに変換するためのルールを個別に決定できるRewriteと、 WP REST APIです。 後者は、データベースからデータを受信できるようにする既製の実際のRESTインターフェイスを提供し、カスタムパスを決定することもできます。 Drupalには、このAPIに類似するものはありません。
エンティティAPI
少し前まで、 Entity APIがDrupalに登場しました。これは、ノードの新しいレベルの抽象化であり、コンテンツに直接関連しないエンティティを定義できます。 ノード、ユーザー、コメント、および分類用語は、エンティティの特殊なケースになりました。 エンティティAPIプラグインを接続する場合（何らかの理由でデフォルトセットに含まれていない）、エンティティを効果的に処理できます。
主な質問は、いつ、なぜそれを行うかです。 コンテンツのように見え、ノードタイプのように見えるものすべて、および画面上でより抽象的で「見えない」ものをエンティティとして推奨します。 これは、Drupalでより複雑なアプリケーションを編成するためのツールであると言えます。 たとえば、エンティティは注文の個々の特性を処理するためにDrupal Commerceで積極的に使用されます。
WPにはそのような抽象化はありません。そのため、もっと手の込んだものを作成する必要がある場合は、カスタムの投稿タイプを使用するか、PHPで楽しんで作成する必要があります。
データモデルとデータベース
CMSのデータモデルは、コンテンツタイプに基づいて構築されています。 コンテンツタイプを使用してアプリケーションのビジネスロジックを簡単に記述することができる場合は、CMSを使用するとよいでしょう。 コンテンツタイプは、固定の属性セットを持つ独立したエンティティです（その中にはタイトルや説明のようなものがあります）。 異なる種類のコンテンツは相互接続されていないことが望ましい。
WP_Queryオブジェクトとget_posts（）およびquery_posts（）関数を使用してWP投稿タイプを操作するのが最も便利です。 WP_Query機能が十分でない場合、SQLクエリを実行するように設計されたdbDelta（）関数と、wpdbクラスがあり、その機能はグローバルな$ wpdbオブジェクトを通じて使用されます。 wpdbクラスを使用すると、データベースの操作が多少簡単になりますが、多くの場合生のSQLを記述する必要があり、クエリビルダー機能は提供されません。
Drupalには、データベースを操作するためのAPIがいくつかあります。
1.データベース構造（スキーム）を操作するためのhook_schemaおよびdb_create_table / db_add_fieldなどの関数があります。
2.データベースに書き込む簡単な方法としてのdrupal_write_record関数。
3.メインAPIは、一連の関数db_select / db_insert / db_update / db_delete / db_queryと、クエリの動的な構築（ 例 ）です。
4.エンティティとフィールドの操作をより便利にするために、 EntityFieldQueryクラスがあります。これにより、動的クエリを作成することもできます。
Doctrineのようなより深刻なツールをCMSに追加する試みもあります。 WordPressとDrupalの両方に対応するモジュール/プラグインがありますが、明らかに、活発に開発されていません。 この場合も、わずかに異なるデータモデルを考慮すると、このようなツールに対する深刻な必要性はないようです。
結論と結論
, Drupal , ( ). , Drupal- . Drupal, « », .
WordPress — , . WordPress , , . CMS, , .