やあ、エンジニア諸君。WordPressの世界へようこそ。
WordPressのデータベース構造を「ただのテーブルの集まり」だと思っているなら、それは大きな間違いだ。`wp_posts`や`wp_postmeta`は、WordPressという巨大なエコシステムを支える「心臓部」。ここを直接触ることは、心臓外科手術に等しい。
今日は、プラグイン開発において最も重要で、かつ最も恐ろしい「データベース・マイグレーション」を、安全かつ確実に実行するための極意を伝授しよう。
—
1. なぜ「WordPressのマイグレーション」は特別なのか？
LaravelやRailsのようなモダンなフレームワークには、標準で堅牢なマイグレーションツールが備わっているよね。しかし、WordPressには「標準のマイグレーションシステム」が存在しない。
多くの初心者は、プラグイン有効化時（`register_activation_hook`）に`dbDelta()`関数を適当に叩いて満足してしまう。だが、それだけでは足りないんだ。
- スキーマの進化: バージョンアップでカラムを追加したとき、前のバージョンはどうなる？
- ロールバック: 失敗したとき、データは元の状態に戻せるのか？
- 非同期実行: 大規模なサイトで数百万行のデータを更新する際、タイムアウトはどう防ぐ？
これらを解決するための「戦略」を身につけよう。
—
2. 実践：バージョン管理によるマイグレーションの自動化
まずは、データベースの「現在のバージョン」を`wp_options`テーブルに保持することから始まる。
// プラグインの現在のDBバージョンを定義
define( ‘MY_PLUGIN_DB_VERSION’, ‘1.1.0’ );
/
- データベース更新チェック関数
/
function my_plugin_check_db_version() {
$current_version = get_option( ‘my_plugin_db_version’ );
// バージョンが違う、あるいはインストールされていない場合
if ( $current_version !== MY_PLUGIN_DB_VERSION ) {
my_plugin_run_migrations( $current_version );
update_option( ‘my_plugin_db_version’, MY_PLUGIN_DB_VERSION );
}
}
add_action( ‘plugins_loaded’, ‘my_plugin_check_db_version’ );
なぜ `plugins_loaded` なのか？
`admin_init` ではなく `plugins_loaded` を使うのは、管理画面にログインしていないユーザーのアクセスでも、バックグラウンド処理で確実にスキーマを同期させる必要があるからだ。
—
3. `dbDelta()` の正しい作法と落とし穴
WordPressには `dbDelta()` という強力な関数がある。これは、現在のテーブル構造と「あるべき構造」を比較し、差分だけを適用してくれる魔法の関数だ。
陥りやすいエラー：文法ミス
`dbDelta` はSQLの記述に非常に厳しい。以下のルールを守らないと、無視されるかエラーになる。
- 各フィールド定義は、新しい行で開始すること。
- `PRIMARY KEY` の定義は、必ず `PRIMARY KEY (id)` のように記述すること。
- `KEY` (インデックス) は、`KEY key_name (column_name)` と書くこと。
function my_plugin_run_migrations( $installed_version ) {
global $wpdb;
$table_name = $wpdb->prefix . ‘my_custom_data’;
// SQLは「複数行」で記述し、インデントにも気をつける
$charset_collate = $wpdb->get_charset_collate();
$sql = “CREATE TABLE $table_name (
id mediumint(9) NOT NULL AUTO_INCREMENT,
user_id bigint(20) NOT NULL,
meta_value text NOT NULL,
PRIMARY KEY (id),
KEY user_id (user_id)
) $charset_collate;”;
require_once( ABSPATH . ‘wp-admin/includes/upgrade.php’ );
dbDelta( $sql ); // ここで差分のみが適用される
}
—
4. 失敗時の「ロールバック戦略」：データは守るもの
本番環境でマイグレーションが失敗したとき、サーバーを真っ白にしてしまうのはエンジニアとして避けたいよね。
ロールバックの黄金律
1. トランザクションは期待しない: MySQLのMyISAMテーブルが混在している場合、`START TRANSACTION` は効かない。
2. 一時テーブル（Backup）の作成: 破壊的な変更（カラムの削除や型変更）を行う前に、`CREATE TABLE _backup AS SELECT FROM …` で必ず退避領域を作る。
3. 成功フラグの更新: 全てのプロセスが終了した後にのみ `update_option` でバージョンを更新する。途中で落ちれば、次回アクセス時に再試行される仕組みにするんだ。
—
5. 初学者がクリアすべき壁
「コードを書いたのに反映されない！」という相談をよく受ける。原因の9割はこれだ。
- キャッシュ: `dbDelta` はSQLの構文解析時に厳密なチェックを行うため、余計なスペースや改行が混じると、WordPressは「何も変更されていない」と判断してしまう。
- 権限: データベースユーザーに `ALTER` 権限がない。
- Prefix: `$wpdb->prefix` を使わず、決め打ちで `wp_` と書いている（マルチサイト環境で確実に壊れる原因になる）。
—
最後に：WordPressをマスターするということ
データベースのスキーマ管理ができるようになれば、君はもう単なる「プラグイン利用者」ではない。「WordPressという巨大なOSの管理者」だ。
次に挑戦するなら、`wp_postmeta` のインデックス最適化や、`wp_options` のオートロード（autoload）をオフにするテクニックを学んでみるといい。さらに深く、WordPressのパフォーマンスを極められるはずだよ。
ここをクリアした君なら、もう怖いものはない。さあ、安全で堅牢なコードを書いていこう！