ディスク容量30GBで５つのMySQL DBを作成可能、５つのドメインをホスティング可能というスペックは必要十分。PHPもMySQLもバージョン５が入っている上、PHPアクセラレータも用意されているのでかなり快適です。

WordPressに関してはワンクリックインストールが用意されていたので試したところ、ブログの名前とメールアドレスを記入するだけでDB作成からインストールまで本当にワンクリックであっさり出来たのにはちょっと感動。インストール時に用意されていたのはWP2.7jaでしたが、コアアップグレードもプラグインアップグレードもデフォルトでワンクリック対応していました。

ワンクリックインストールの唯一の欠点はデータベースも同時に新規作成され接頭辞が「wp_」に固定される事なのですが、手元でバックアップしておいたSQLファイルの接頭辞を置換してインポートすると文字化けする事もなく記事「だけ」は表示されるようになりました。

今回のサーバ移転に合わせてコアのアップグレード(2.6.3ja > 2.7.1ja)を行い、パーマリンク形式を記事idのみから、年／月／日／記事id、という形に変更したり、Lightboxを使っていた画像拡大をThickboxで行うようにしたり、ImageManagerプラグインで年月ごとのフォルダで管理していた画像ファイルをメディアライブラリに移行したり、という作業を行いました。

おかげでずいぶん時間を食いましたが、ともあれ２度目の再起動です。

« 記事を折畳む

VISシステムとやらを構築するために資金が要るから告知無しで引き落としたそうだけどこれはひどい。月々の使用料集めたうちから手当しておくのがスジってもんだと思うよ。もっとひどいのはレンタルサーバ等を使用せずにただ会員になっていた人の口座からも１万円キッチリ引き落とされてたらしいこと。

http://blogs.itmedia.co.jp/yasusasaki/2009/01/dm-1c1d.html

このブログで使っているのはLHXなので最初から件のVISシステムとやらに対応してるそうなのですが、もしこれで次のカード引落しにこの１万円が課金されていたら徹底的に叩きますよ。サーバスペック自体はいいし、パフォーマンスも近頃向上してきたようなので出来れば使い続けたいんですけどね。

このサイトのドメイン「alter-ego.jp」もこの会社で取得してるんですが倒産したらどうなるのか、とかも考えないといけないかな？DNSの仕向地も変更できないのでコンテンツを他事業者のサーバに逃がす事も出来ないしホント困ったものです。

« 記事を折畳む

元記事はBinsan’s Cafe>>wordpress2.6.1に(問題発生)です。先方はこれまで使っていたCoreServerだったのですが、PHP5セーフモードという点では似たようなものだということでL.H.Xに合わせて真似してみました。

プラグインの自動アップデートは .zip をダウンロードしてきて展開して配置するような仕組みらしく.zip の配置先が /tmp っていうcoreserverのディレクトリを標準でつかおうとするらしく/tmp はセーフモードだと書き換えられなくてエラーになるということです。

なるほど、/tmpというディレクトリを作ればいいわけですね。しかし、L.H.Xではここで例示されているディレクトリ構成は作成できません。CoreServerはpublic_htmlと同列のディレクトリを自分で作成できるのですが、L.H.Xではhttpdocsという公開用ディレクトリの同列には新規ディレクトリが作成できないようです。

それならばとwp-config.phpと同列に/tmpディレクトリを作成して指示通りパーミッションを707に設定。続いてwp-config.phpを修正します。ちなみにCoreServerでの指定は以下の通り。

define (‘WPLANG’, ‘ja’);←このすぐ下に
define (‘WP_TEMP_DIR’, ‘/virtual/[コアサバアカウント名]/tmp/’);

先程作成した/tmpディレクトリまでのパスを指定する行を追加しているようなのでL.H.Xのフルパスで書き換えてみます。

define (‘WPLANG’, ‘ja’);
define (‘WP_TEMP_DIR’, ‘/var/www/vhosts/(ドメイン名)/httpdocs/tmp/’);

これでバッチリ！プラグインアップデートが無事自動で行えるようになりました。貴重な情報を公開してくださったBinsan’s CafeのYutakaさんに感謝します。

« 記事を折畳む

手順としては、

1. 旧サーバのphpMyAdminからDBをエクスポート。
2. 旧サーバのWordPressファイル、プラグイン、テーマ、画像などをディレクトリごとFTPでバックアップ。
3. 新サーバにバックアップしたWordPressファイルなどをFTPでアップロード。
4. パーミッション変更を適宜行い、wp-config.phpを新サーバに合わせて書き換える。
5. 新サーバのphpMyAdminで旧サーバからエクスポートしたSQLファイルをインポート。
6. リンク切れや画像欠落などを確認。

こんな感じで簡単にサーバ移転は完了したのですがそこからが長かったです。DNSの浸透に約24時間かかって、新サーバに切り替わったのを確認してからWordPressを表示するようにしたのですが文字化けしてました。原因を確認するためにまずはDB管理ツールのphpMyAdminを開きます。

MySQLの文字セットがcp1252 West European(latin1)で照合順序がlatin1_swedish_ciとなっています。これが原因で文字化けしてるのかと思ったのですが、WordPressのデータを格納しているDBの文字コードは正しくutf8_unicode_ciになっていました。

念のためphpMyAdminで格納されてる投稿データを読んでもきちんと日本語になっています。MySQL, php, WordPressのどこかに原因があるはずなのですが全く見当もつきません。途方に暮れてもう一度WordPressをクリーンインストールしてやろうかと思いながらwp-config.phpを眺めていたらひらめきました。

「DBの文字コード変えるときになんとかCOLLATEってSQLコマンド打ったよね？｣「ここのDB_COLLATEって参考書でも空欄になってるけど文字コード入れたらなんか起きるんじゃない？｣

// ** MySQL settings ** //
define(‘DB_NAME’, ‘your_DB’); // データベース名
define(‘DB_USER’, ‘your_name’); // ユーザー名
define(‘DB_PASSWORD’, ‘password’); // パスワード
define(‘DB_HOST’, ‘localhost’); // データベースサーバ (ほとんどの場合変更する必要はありません)
define(‘DB_CHARSET’, ‘utf8′);
define(‘DB_COLLATE’, ‘utf8‘);

結果として大成功。4日間に渡って悩み続けた問題がたった4文字で解決しました。でも後でWP Codex見てたら親切丁寧にDB_COLLATEの設定と意味が書いてありました。やっぱり悩んだときはWp Codexきちんと読み返してみるべきですね。

あとはImageManagerプラグインの設定で画像を格納するuploadsフォルダの絶対パスを指定する必要があるのですが、Pleskで設定された絶対パスは/var/www/vhosts/(ドメイン名)/httpdocs/(wp設置ディレクトリ)/wp-content/uploadsとなります。まだ動作に少し不安はありますが、ひとまず移転完了したので色々試してみます。

« 記事を折畳む