2010年6月。 一応これも自分用メモ。
WordPress を動かすには通常 DB として MySQL が別途必要だが、
プラグインの導入により、MySQL の代わりに SQLite でも動作させられるらしい。
(ただし一部制限ありか?)
MySQL はライセンスがそこはかとなく不明瞭だったり
(ほとんどのケースは GPL で問題ないとは思うものの、
製造配布元の説明がいまいちモニャッとしてて、
「まァとりあえずライセンス買っとこうやアンサン」的結論に誘導されがちなバイアスがかかってる風味だったり)、
それなりにリソース食いな daemon を走らせにゃならん故、
超非力 (主にメモリ不足) なウチの自宅サーバ等では運用が厳しかったりするので、
SQLite でも使えるなら試してみる価値はあるかも、という動機。
…もっともウチの超非力なサーバには DB の有無関係なく WordPress を走らせるだけで十分重荷だが。
うろ覚え・ウソを書いてる可能性がないとは言えないので、 間違いがあったらご容赦。
OS は debian lenny。
メール送信できるよう MTA (exim4) 設定済。
PHP で SQLite PDO が使えるよう設定済。
使用したブラウザは Firefox 3.6.3。
あとなんかあったかな…。
通常の WordPress インストールは、
だが、PDO for WordPress プラグインと SQLite を使う場合は、
という手順。
WordPress アーカイブを Web 用ディレクトリに展開。
WordPress 全ファイル・ディレクトリのパーミッションを httpd (PHP) から読み書き可能にしておく
(chmod -R o+w *
みたいな具合に)。
できれば全体の所有者を httpd (PHP) と同じにしておく
(chown -R www-data:www-data *
みたいな具合に)。
こっちの方が確実か。
なお safe モードとか suexec とかはウチの環境とは関係ないのでよく知らない。
wp-content ディレクトリ内に、PDO for WordPress プラグインアーカイブ中の db.php と pdo ディレクトリまるごとを展開。 以下のような配置になるように。
languages/ pdo/ ←展開したディレクトリ plugins/ themes/ upgrade/ db.php ←展開したファイル index.php
同じ wp-content ディレクトリ内に、SQLite の DB 保存用の database/ というディレクトリも後に自動作成される。 この時ディレクトリの所有者やパーミッションが不適切だと、 ディレクトリや DB が自動作成されない可能性があるかも (試してないけど)。 心配な場合は予め mkdir して PHP から書き込み可のパーミッション (や所有者) にしておいてもいいかも。
wp-config.php を修正。 (wp-config-sample.php を wp-config.php にリネームして) UTF-8 の BOM なし (UTF-8N) で編集・保存する。
define('DB_COLLATE', '');
のすぐ下に、
define('DB_TYPE', 'sqlite');
を追加。
なお、上の方の行の define('DB_なんちゃら', 'かんちゃら');
は全てほっといて可 (SQLite では関係ないので)。
ついでにそのすぐ下の行にある認証用ユニークキーも、秘密鍵自動生成サービスを利用するなどして変えておく。
ブラウザから WordPress にアクセスし、セットアップ。 PHP の生コードみたいなのがびょろびょろ表示され (何故だ!?)、じきにセットアップ完了。 ページの一番下の方に、 インストール完了の旨と自動生成されたパスワードとログインページへのリンクボタンが表示されるので、 クリックしてログインページへ進み、先ほど表示されたパスワードでログイン。
なお lighttpd では .htaccess は無効なので、
wp-content/database ディレクトリ内に生成された .htaccess の内容 (「DENY FROM ALL
」) を
lighttpd.conf に反映させておく。
例えば wordpress の URL が http://ほにゃらら/wordpress/ だったとして、
$HTTP["url"] =~ "^/wordpress/wp-content/database" {
url-access-deny = ( "" )
}
などのように。
あとは普通に使うよろし。
ただし MySQL がからむプラグインなんかは問題が生じたり使えなかったりすると思うので注意。
個別に対処するしか。
例えば参照先サイトによると Google SitemapGenerator プラグインを使うには修正が必要らしい。
Cygwin 上にも (SQLite ベースの) WordPress をインストールしてみた。
実際には特段の違いはなし。
ただし、WordPress でのセットアップ時、
上記の 4. の段階で、
PHP コードがびろびろ表示された後、
仮パスワードとログイン (ページへのリンク) ボタンが表示されなかった。
パスワードがわからないと初回ログインができず、結果的に設定画面に入れない。
WordPress のセットアップが成功すると、
セットアップ画面冒頭で入力したメールアドレス宛にも仮パスワードが送信されてくるし、
通常のログイン画面にも「パスワードをお忘れですか?」というリンクがあって、
パスワードの初期化と仮パスワードの再設定の通知がメールで送信される仕掛けになっている。
が、 Cygwin 環境からメール送信できるようになっていないと、これも届かない。
(ブラウザ画面にはメール送信が失敗した旨表示される)
という訳で、Cygwin 上で SQLite ベースの WordPress のセットアップのために、
メールサーバを導入した
(メール送信ができるようになっているといろいろ好都合でもあるし)。
これでセットアップ完了後、 メールで送信されてくる仮パスワードを使って管理画面へログインができるようになった。
プラグインのインストールやアップデートを WP の管理画面から半自動で行なおうとしたら、 接続情報が必要とかなんとか言われて先に進めん時。 これは WP ファイルのうち必要な範囲 (メンドくさい時は全体) の所有者を http サーバと同じにしておけば防げるんだが、 それも面倒なことがある。
そういう場合は、
少なくとも wp-content/upgrade と wp-content/themes ディレクトリ (メンドくさい時は WP 全ファイル) を誰でも書き込み可にしておき、
wp-config.php に「define('FS_METHOD','direct');
」と追記しておいてやると、
自動アップデートなどがとりあえずすんなり進むようになる。
らしい。
セキュリティ的にどうか、などは不明。 全ファイル誰でも書き込み可、なんてのは全般にちょっとマズそうな、 というかマズくなる機会が増えそうな気もするが、 日常的に、悪意を持った (とは限らない) 他人がログインして ファイルを (故意ににせようっかりにせよ) 書き換える可能性がまずない環境であれば、 まあたぶんダイジョブだろう。