2010年08月04日

mixiチェック
WordPress 3.0も3.0.1と2010/07/30にリビジョンが上がりました。
内容的には細かい修正のようです。

そういえば、あすまるとBeLiveのホームページのWPも最新版にしました。
今まで使っていたCPIのVPSの一つを閉じ、X-SERVERの方で管理することにしたのです。
結構、WP2.8.6に独自に作ったプラグイン(未公開もの)を入れていたので、WP3.xは大丈夫か心配していました。
しかし『案ずるは産むが易し』
修正箇所もなく、案外すんなり移行完了。
あすまるもBeLiveも、問題なく動いています。

さて、前回 WP3.0の新規インストールで再検証したのですが、今回は『マルチサイト』について試して見たいと思います。
今まで『マルチサイト』といえばWordPress MUという別系統のワードプレスだったのが、WordPress本体でできるようになりました。

『マルチサイト』の方法はCodexにあります。

ここではやり方というより、どこが変化するのか不親切検証をしてみたいと思います。
なお、サーバはX-SERVER X10、サブディレクトリ型で検証してみます。

そうそう、WPの『マルチサイト』対応は、Apacheのmod_rewriteを多用します。
対応しないサイトでは難しいでしょう。

〜 扉の呪文『WP_ALLOW_MULTISITE』 〜
いきなり、Codexの手順3まではしょります。
wp-config.phpを編集して、「マルチサイトの許可」を指示します。
define ('WP_ALLOW_MULTISITE', true);

WordPressマルチサイトインストールこうすると管理画面の「ツール」に「ネットワーク」が出現。
さて、ここで「ネットワーク」の設定です。
画面での設定箇所は2箇所
・ネットワークのタイトル
・管理者のメールアドレス
な〜んだ。簡単じゃない...と思ったあなた。これで終わりではないのですよ。
次いきましょう。



WordPressツール-ネットワーク「ツール」-「ネットワーク」に適当な入力ののち、「インストール」ボタンを押します。
すると、いろいろなことが書いてあります。





  1. 『blogs.dir』をwp-content下に作りなさい。
  2. wp-config.phpに『マルチサイト』に関する記述を加えなさい。
    • 定数「MULTISITE」でマルチサイト宣言
    • 定数「SUBDOMAIN_INSTALL」をfalseにしてインストールを止める
    • 変数「$base」でワードプレスのベースディレクトリを設定
    • 定数「DOMAIN_CURRENT_SITE」でサイトドメインを宣言
    • 定数「PATH_CURRENT_SITE」でサイトルートパスを宣言
    • 定数「SITE_ID_CURRENT_SITE」で初期サイトIDを宣言
    • 定数「BLOG_ID_CURRENT_SITE」で初期ブログIDを宣言
  3. .htaccesにリライト宣言を追加しなさい。
    • リライトベースとindex.phpの取り扱い
    • 各サイト毎のアップロードファイルのリライト
    • 各サイト毎の管理画面のリライト
    • wpフォルダの処理

1の『blogs.dir』は自動生成でもいいのではないかと思うのですが、まぁ特別なWordPressだから仕方ないか。
因みに、『blogs.dir』は追加されたサイトのアップロードファイル等が納まるところ。
サイトを追加し、画像等をアップすると、『blogs.dir』下にサイトIDのディレクトリ+「files」が追加され、その下に納まる仕組み。
3のリライト宣言と組み合わされ、ソース上は「(サイトURL)/files/...」となる。

2のwp-config.phpでは、『マルチサイト』に関する多くの宣言がある。
しかし、言語指定がありません。
実はwp-config.phpの「WPLANG」は、初期サイトにのみ適用されます。
そのため、追加されたサイトは最初 英語版です。なぜ引き継がないのでしょう。
または「WPLANG_CURRENT_SITE」宣言があってもいいのではないかと思うのですが...

WordPressのリライト宣言にはなぜか「QSAフラグ」がついていません。
「QSAフラグ」は付けるべきではないのか。

〜 特権! 〜
これで、『マルチサイト』が使えます。
管理画面に『特権管理者』メニューが追加されました。
wp-config.phpや.htaccessがいじれれば、結構簡単ですね。

『特権管理者』メニューには下記のサブメニューがあります。
  • 管理
  • サイト
  • ユーザ
  • テーマ
  • 設定
  • 更新

WordPressサイト管理設定直ちにサイトの追加をしたいと思ってしまうのですが、まずは『設定』を先にすることをおすすめします。
なぜなら、「初期設定言語」がここにあるからです。
私はこれに気付かず、いきなりサイトを追加したら、英語版になってしまいました。
もちろん、各サイトで言語設定は可能なのですが、自分以外のユーザに管理をゆだねるのならば、その方の利用する言語に最初に設定しておかないと、ちょっとパニクるかもしれませんね。
「メディアアップロードのボタン」も設定しておいた方がいいでしょう。
「画像がアップロードできない」といわれかねませんから。

さぁ、サイトを追加します。
追加して気付いたのですが...オプションで下記の設定があります。
なんでしょう?
  • 一般公開
  • アーカイブ化
  • スパム
  • 削除
  • 成人向け
ソースを見る限り、サイトのステータスのようですが、管理画面以外は特に対応しないみたいです。

〜 データベースは? 〜
では、データベースはどうなっているのだろう。
まず、主テーブルの違いは以下の通りでした。
  • {$table_prefix}blog_versions
  • {$table_prefix}blogs
  • {$table_prefix}registration_log
  • {$table_prefix}signups
  • {$table_prefix}site
  • {$table_prefix}sitemeta
※{$table_prefix}の部分は「wp_」などのテーブル接頭辞

さて、なぜ『site』と『blogs』が分かれているのでしょう。
【site】
  • id
  • domain
  • path

【blogs】
  • blog_id
  • site_id
  • domain
  • path
  • registered
  • last_updated
  • public
  • archived
  • mature
  • spam
  • deleted
  • lang_id
どうやら、『sitemeta』を見ると、『site』はネットワークを示すもののようです。
きちんと調べていないので、私見ですが『site』は一個だけ登録されています。
子サイトを追加すると、その追加状況は『registration_log』に追加されます。
分からないのが、『signups』と『blog_versions』
『registration_log』『signups』と『blog_versions』の3つは、『blogmeta』のようなテーブルを作れば、対応できたのではないかと思う。
『blogs』内の子サイトの状況も、『blogmeta』で扱った方が融通性が高いWPッぽいのだけどなぁ
※『blogmeta』のようなテーブルは現在ないよ。

『blogs』は、各子サイトの状態がはいっています。
各子サイトの詳細設定は下記のテーブル群に納まるようです。

では、各子サイトはどうなのかというと、以下の通り。
  • {$table_prefix}{$blog_id}_commentmeta
  • {$table_prefix}{$blog_id}_comments
  • {$table_prefix}{$blog_id}_links
  • {$table_prefix}{$blog_id}_options
  • {$table_prefix}{$blog_id}_postmeta
  • {$table_prefix}{$blog_id}_posts
  • {$table_prefix}{$blog_id}_term_relationships
  • {$table_prefix}{$blog_id}_term_taxonomy
  • {$table_prefix}{$blog_id}_terms
※{$blog_id}は、各子サイトのブログID

しかし、MUとの互換性のため、サイトとブログ、ネットワークの扱いが煩雑になっている見たいですね。
テーブル上のsite = (呼称)ネットワーク
テーブル上のblog = (呼称)サイト

さて、WP3.0から新設されたカスタム投稿タイプは、どのようになるのでしょう。
これについては、カスタム投稿タイプを扱えるようにするプラグインで試すしかありません。

プラグインがどのように対応するかですね。
ということで、プラグインについては次回。
BeLiveで作ったプラグインの検証も必要ですから。
では


(06:39)

この記事へのコメント

1. Posted by ほんわか4    2011年05月01日 12:40
どうもマルチサイト化をすると、子サイトでプロフィールの画像のアップデート先が判らなくなりますね。

マルチサイトと言えども、万能ではないのかな?
2. Posted by MOO@あすまる   2011年05月02日 14:04
ほんわかさん、コメントありがとうございます。
プロフィールの画像は、どんなプラグインを使っていますか?

マルチサイトは厳密にはユーザを共有する別々のブログの集まりみたいなものです。
画像も基本的には各子サイト持ちです。
そのため、シングルのWPで、wp-content/uploadをプロフィールの画像置場にしているプラグインは対応できないようです。
(マルチサイトのWPでは、wp-content/blogs.dir/xxx/files下が画像置場)
ユーザに関連する情報置場を独立して持っているプラグインは、マルチサイトでも対応できるのではないでしょうか?

> どうもマルチサイト化をすると、子サイトでプロフィールの画像のアップデート先が判らなくなりますね。
>
> マルチサイトと言えども、万能ではないのかな?

コメントする

名前
 
  絵文字