【嘘】こんなときWordPressをマルチサイト化してはいけない
嘘書いてしまいました!
間違ったことを書いてしまいましたごめんなさい。
マルチサイト化、全然OKです。
どこが間違ってたの?
このようなSQL発行すると$table_prefixが期待した値にならないから、マルチサイト化は駄目よという話だったんですが、
"select * from " . $table_prefix . "custom_table, " . $table_prefix . "_users where " . $table_prefix . "custom_table.ID = " . $table_prefix . "user.ID;"
こう書けば万事解決でしたね。
global $wpdb; "select * from " . $table_prefix . "custom_table, " . $wpdb->users ." where " . $table_prefix . "custom_table.ID = " . $wpdb->users .".ID;"
グローバルオブジェクトの$wpdbには一通りの標準テーブル名がプロパティに含まれているのでこれを活用すればOKでした。
エンジニアとして嘘の技術情報を垂れ流さないように精進していきます......。
どうもすみませんでした。以下が嘘記事です。
-
-
-
-
- -
-
-
-
どんなとき?
データベースのカスタマイズ(独自のテーブル追加等)を伴うプラグインを開発しているとき。
なぜ?
マルチサイト化したサイト(子サイト)にプラグインを適用すると、親サイトとテーブルプリフィックスが異なってしまうから。
具体例
子サイトに開発中のプラグインを適用し、テーブルを追加する。
そのテーブルとWordPress標準のテーブル(wp_usersなど)を結合したいケースがある。
select * from wp_custom_table, wp_users where wp_custom_table.ID = wp_user.ID;
みたいな。
でもこれだと当然テーブルプリフィックス変えられると動かないので、普通はこうしますね。
"select * from " . $table_prefix . "custom_table, " . $table_prefix . "_users where " . $table_prefix . "custom_table.ID = " . $table_prefix . "user.ID;"
みたいな。
ところがこの場合、custom_table は子サイトのプラグインなので子サイトのテーブルプリフィックスを持っているのに対し、users 親サイトのテーブルのままなのでテーブルプリフィックスが異なる。よって期待した結果が返ってこない、のです。がーん......
もちろん、プラグインの公開時にも「マルチサイトは非対応」と明記しなきゃいけませんね。
結論
データベースをカスタマイズする場合はWordPressのマルチサイト化は避けた方が無難です。
もちろんデータベースまで触らないのであればマルチサイトは便利な機能なので活用してOKかと思います。