WordPress のカスタム データベース テーブル: パート 1
公開: 2022-06-27この一連の記事では、プラグインの有無にかかわらず、WordPress でカスタム データベース テーブルを作成する方法を見ていきます。
カスタム データベース テーブルを使用する必要がある場合とその理由は?
ほとんどの場合、WordPress のインストール時に作成されるデフォルトの WordPress データベース テーブルだけで十分です。 これらのテーブルには、投稿の種類や関連するメタデータなど、あらゆる種類の情報が含まれています。 では、なぜカスタム データベース テーブルが必要なのでしょうか。
これらは、WordPress で使用される通常の情報とは異なるデータを扱う場合に真価を発揮します。 そのため、データベースに情報を保存する必要があるプラグインを作成するときに、カスタム テーブルにデータを配置することが必要になる場合があります。 WooCommerce などのプラグインに独自のカスタム テーブルがあることがわかるのはこのためです。
別のテーブルを使用すると、情報をより適切に格納できるだけでなく、使用するクエリで不要なデータの行を検索する必要がないため、パフォーマンスが向上します。 代わりに、必要な情報をより迅速かつ効率的に見つけることができる「正しい」テーブルに誘導することができます。 これは、データベース テーブルが大きくなり始めると非常に重要になります。
WordPress カスタム データベース テーブルの作成
学生のリストを整理するのに役立つ簡単なプラグインを作成したいとしましょう。 実際には、このような単純なタスクは、カスタム テーブルをまったく使用する必要がないことを意味します。 カスタム投稿タイプは完璧に機能します。
ただし、この例では、この種のデータはカスタム テーブルの背後にある理論を示すのに最適なので、それを使用して実行します。 注: 基本的な PHP と MySQL の知識があることを前提としています。
入門
まず、名前、年齢、電子メール、一意の ID の列を持つ「学生」データベース テーブルを作成します。 これを行うには、ジョブを完了するためのカスタム プラグインを作成します。
注: カスタム プラグインの作成方法にまだ慣れていない場合は、このチュートリアルを再開する前に、独自のカスタム WordPress プラグインの作成に関するガイドを確認してください。
プラグイン ファイルを作成する
plugins フォルダー内に「my-custom-db-tables」というフォルダーを作成し、その中に「my-custom-db-tables.php」という名前のファイルを作成します。このファイルには、次のコードが含まれています。
<?php /* Plugin Name: My Custom DB Tables Description: A plugin for registering my students Author: Tassos Antoniou */ function create_the_custom_table() { // THE CODE } register_activation_hook(__FILE__, 'create_the_custom_table');
WordPressがプラグインを認識できるように、プラグイン情報を導入しました。 明らかに、テーブル スキーマをデータベースに追加する関数も必要になります。これはcreate_the_custom_table()
関数です。
ほとんどの場合、この関数を実行する必要があるのは 1 回だけです。理想的には、プラグインがアクティブ化されている場合です。 したがって、WordPress が提供する register_activation_hook() を使用して、プラグインの有効化時に関数が確実に実行されるようにしました。
テーブルの構造を定義する
もちろん、関数がまだ空であるため、プラグインを有効にしても何も起こりません。 実際にテーブルを作成するために、次のコードを入力してみましょう。
<?php /* Plugin Name: My Custom DB Tables Description: A plugin for registering my students Author: Tassos Antoniou */ function create_the_custom_table() { global $wpdb; $charset_collate = $wpdb->get_charset_collate(); $table_name = $wpdb->prefix . 'students'; $sql = "CREATE TABLE " . $table_name . " ( id int(11) NOT NULL AUTO_INCREMENT, name tinytext NOT NULL, email VARCHAR(100) NOT NULL, age int(11) NULL, PRIMARY KEY (id) ) $charset_collate;"; require_once(ABSPATH . 'wp-admin/includes/upgrade.php'); dbDelta($sql); } register_activation_hook(__FILE__, 'create_the_custom_table');
ここで少し立ち止まって、このコードで何を行ったかを調べてみましょう。
まず、データベースと通信するグローバルな$wpdb
WordPress クラスを使用して、テーブル プレフィックスを取得します。 これは、 wp-config.php
ファイルで定義されているものと同じプレフィックスであり、カスタム テーブルでも使用することをお勧めします。 また、現在の照合順序を$charset_collate
変数に保存して継承し、後でクエリで設定します。
次のステップは、必要なスキーマを正しく取得するために、SQL クエリでテーブルの構造を定義することです。 前述したように、id、email、name、age の各列に適切なタイプのデータが含まれています。
$sql = "CREATE TABLE " . $table_name . " ( id int(11) NOT NULL AUTO_INCREMENT, name tinytext NOT NULL, email VARCHAR(100) NOT NULL, age int(11) NULL, PRIMARY KEY (id) ) $charset_collate;";
次に、 upgrade.php
ファイルをrequire_once
します。 これは、直後にあるdbDelta
関数を使用するために必須です。 WordPress では、データベース テーブルを作成する (または既存のテーブルを新しい構造に更新する) ために、dbDelta 関数を使用する必要があります。
注: SQL クエリを直接実行する代わりに、この関数を使用して、指定された SQL ステートメントに基づいてテーブルを作成または更新することにより、データベースを変更します。 $queries
パラメータを使用して、カスタム テーブルのスキームを渡すことができます。
プラグインを有効にしてデータベースを確認すると、テーブルが作成されていることがわかります。
ここで、 wp-admin/includes/upgrade.php
ファイルの内部を読むと、SQL ステートメントから情報を取得するためにdbDelta()
がpreg_match()
関数を使用していることに気付くでしょう。 そのため、編集する際には注意が必要です。 公式ドキュメントにはこれに関する詳細情報が記載されていますが、以下の重要なポイントを強調しています。
- SQL ステートメントでは、各フィールドを個別の行に配置する必要があります。
- PRIMARY KEY という単語と主キーの定義の間には2 つのスペースが必要です。
- 同義語の INDEX ではなくキーワードKEYを使用し、少なくとも 1 つのKEY を含める必要があります。
- KEY の後には、単一のスペース、キー名、スペース、フィールド名を含む開き括弧、閉じ括弧が続く必要があります。
- プライマリ以外の KEY には名前を付ける必要があります。 例えば:
... PRIMARY KEY (id), KEY age (age) ...
- フィールド名の前後にアポストロフィやバッククォートを使用しないでください。
- フィールド タイプはすべて小文字にする必要があります。
- CREATE TABLE や UPDATE などの SQL キーワードは大文字にする必要があります。
- たとえば、id 列の int(11) のように、長さパラメーターを受け入れるすべてのフィールドの長さを指定する必要があります。
また、テーブルがデータベースに既に存在するかどうかを確認していないことにも気づいたかもしれません。 これは、 dbDelta
が代わりにそれを行うためです。 更新クエリについて心配する必要はありません。 テーブルを作成するだけでなく、同じ名前のテーブルが既に存在するかどうかをチェックし、存在する場合はテーブルを作成しません。 必要な場合にのみ、既存のテーブル構造を更新します。
これについては、シリーズの今後の記事で詳しく説明します。
機能性とスケーラビリティ
では、プラグインを非アクティブ化またはアンインストールするとどうなるでしょうか? 理想的には、プラグインが非アクティブ化または削除された場合に、このテーブルをデータベースから削除するかどうかを選択する管理者オプションが必要です。
さらに、遅かれ早かれ、プラグインを変更する必要があることがほぼ確実にわかります (プラグインを改善したり、バグを解決したりするため)。 おそらく、データの格納方法を変更したり、テーブルに列を追加したり、そのデザインを変更したりする必要があります。 つまり、可能な限りスケーラブルで、加えられた変更に適応できる方法でプラグインを構築する必要があります。
このシリーズの次の記事では、これらのトピックを掘り下げ、これを達成する方法を示します。 すぐにもう一度チェックしてください!