久しぶりにwordpressをいじる必要があったためデータベース関連をバックアップしようと思ったら
管理画面のdbmanagerがなぜか英語表記に戻っていたことに気付きました。
プラグインの自動アップデートでいつの間にか日本語moファイルが対応できなくなっていたのかもしれません。
たしか以前導入したときはwp-dbmanager2.1か2.2の時だったはずです。
MMRT daily lifeさんの関連記事を参考に日本語化したはずです。
http://wp.mmrt-jp.net/
で、2010年1月現在の最新版である2.6ですが、前のver.である2.5の日本語化ファイルを作ってくださった
Technologさんのものがそのまま流用できるようです。
http://technolog.jp
感謝感謝。
たしかにメニュー名などは英語でもなんとなくはわかりますが、
解説などはやはり日本語でないとすぐには理解しにくいものです。
裏でwp.Vicuna Ext. Custom 1.5.9をwp Vicuna 2.0.2に変更しようとしたり、
デザインを変更したりしょうとしていたのですがどうにもカレンダーが上手く動かない。
カレンダーそのものは表示できるのですがEC 1.5.9みたいに投稿記事の日付にリンクが紐付かないのです。
こうゆう仕様なんでしょうか。
phpソースをちょっと見ただけでは理解できなかったので地力でなんとかするのは諦め
wp.Vicuna Ext. Custom 1.5.9に戻してしまいました。
※phpに関しては素人です。
うーむ。
他のサイトはみんな普通にカレンダーが動いているので何が間違っているのか理解できない。
大分昔からmixiアカウントを持っているものの、mixiを使う前からロリポブログを
使っていたので特にmixiに書き込むものがありませんでした。
今現在、ロリポブログを止めてWPとMTをいじくっていますが、
やはりmixiに何も書き込まないのはもったいないかな、という気持ちもありました。
実際mixiを使っていない期間も外部ブログでは相当数の書き込みをしていました。
で、少し調べてみたところWPとMTにはmixiにクロスポストできるプラグインが
あるようなので試してみることにしました。
wp-mixipublisher
以下自分の失敗。
すぐに導入したいという方は最下部まで読み飛ばしてください。
＃
まずはYUJILOGさんのこちらからプラグインをダウンロード。
ただしこれはすでに3年近く前のものということで大分昔のもの。
現在の2.8.4では残念ながら正常に動作しませんでした。
さらに検索すると、有志の方々がコードの一部を書き換えたりしたものが
いくつかあるようなので試してみました。
などを参考に試してみました。
しかし、ＷＰの設定項目でwp-mixipublisherの設定をしたところ
「Mixiへログインできないか、Mixiの日記が外部のブログに設定されています。」と
表示され使用不能。
IDとパスワードを何度も確認するも徒労に終わりました。
どうやらこれらの手法では現在の2.8～以降ではwp-mixipublisherは使えないようです。
＃
一旦調べなおしてたどり着いたのはmy96softさんのこの記事。
上記の方々の修正を施したものをアップしてくださっています。
これを適用したところ上手く動作し、mixiへの投稿が可能になりました。
ということは自分の修正作業のどこかが間違っていたということなのでしょうか＾＾；
しかし、今になってwp-mixipublisherを使おうとした私の場合、
どれが最新の情報かは投稿日時だけではいまいちわからず、my96softさんのように
きちんとまとめられていた方がいたのは幸いでした。
ありがとうございます。
とりあえずはwordpress2.8.4での動作を報告します。
終わり
ロリポップの時に失敗したデータベースのバックアップの問題をまず解決することにしました。
ロリポップの時はサーバー上のmysqlパスとmysqlダンプパスがわからず使えなかったWP-DBManager。
しかしさくらではパスの位置がわかりました。
ちょっとググったら出てきました。
mysqldumpパス：
/usr/local/bin/mysqldump
mysqlパス：
/usr/local/bin/mysql
これはさくらに限っての話です。
その他のレンタルサーバーは違うのでご注意を。
自分用覚え書き的な資料ですね。
参考にしたのは病的溺愛シンドロームさん。
この設定でうまくバックアップできました。
復旧もテストしてうまくインポートできました。
よかったよかった。
ロリポではこれがどう頑張ってもできなかった。
週一の定期バックアップをメールで送信する設定もうまくいき、
ちゃんとメールに圧縮ファイルが添付されてきます。
ロリポの時はなんであんなに苦労したんだ？と思えるほどあっさりと上手くいきました。
WP-DBManagerの具体的な設置は小粋空間さんで詳しく説明していますので、是非ご一読を。
あわせて.htaccessの設定もしておくといいでしょう。
詳細は違いますが似たような状況の方もいらっしゃったようなのでご紹介。
こちらのsuzukikenichi.comさんの記事も参考になるかもしれません。
これで一通りロリポからさくらへのWPの引っ越しは終了。
以前よりかなり快適に記事を投稿できるようになりました。
同じものを使っていてもレンタルサーバーが違うだけでここまで違うとは
少々驚愕しております。
これからWPを使おうかな、と思っている方がいらっしゃったら参考になれば幸いです。
終わり
ロリポップ間のMySQLサーバーの引っ越しの効果がなかったので
次はいよいよレンタルサーバーの引っ越しを考えざるを得ない状況となりました。
そうなると今度は次のレンタルサーバー選びをするわけですが、
当然MySQLサーバーを使える前提条件でサーバーを探すわけです。
ロリポップより値段（263円/月）の安いサーバーは皆無のようで、
そうなるとロリポップよりもMySQLが快適でなおかつできるだけ値段が安いところ、
という方向性でサーバー選びを考えました。
かなり長い時間ネットで調べていましたが、候補は以下のものものから選んでいくことにしました。
割とメジャーなレンタルサーバーですが、あまり知名度の低いサーバーだと
評判がよくわからないので今回はスルーしました。
いずれも個人ユーザー向けの低価格サーバーです。
具体的にはHeartlogicさんのこちらの記事の比較表を大いに参考にさせていただきました。
ありがとうございます。
当初考えいていたのはヘテムル。
今まで使っていたロリポップの上位的位置づけと考えていたからです。
それをいうならチカッパもですが、カタログスペックでは値段の上昇分の性能差が
あまりないような気がしていたので、最初から除外しました。
欲しいのは容量ではなくWPを使ったときの速度と軽さ。
ハッスルサーバーはさくらやロリポの後続サーバーらしいですが、ロリポと比べてそこまで差が
ないような気がしたのこれもまた除外しました。
ロリポより安くてロリポより性能がいいとはあまり考えられないので。
それならもっと人気が出てるでしょうし。
X-serverはMTやWPを使うにはかなり評判のいいサーバーらしいですが、
ネックになるのはそのコスト。（X10の月1050円）
それでもヘテムルに比べれば安いですが。
同様にヘテムルもその値段の高さがネックになり、即決はできない状態でした。（月1500円）
最終候補に残ったのがロリポを使っていたという理由だけで同系列のヘテムルとさくらのスタンダード。
これは実際にお試し期間でその性能を実感してみることにしました。
Heartlogicさんほどはないですが、MTを使い一般的に重いとされる時間帯の21時と23時で
150件ほどの記事の再構築時間を計ってみました。
ヘテムルが
さくらスタンダードが
という結果に。
ちなみにロリポの時は100件ほどの記事の再構築に8分とか10分とかかかっていた（ような気がする）。
さすがにヘテムルは高いだけあってさくらよりは速いという結果に。
しかしさくらはヘテムルにくらべて1/3の値段です。（月500円）
個人的にはさくらのこの結果は必要十分と感じ、さくらのスタンダードに決定しました。
もしかしたら1000件、2000件の記事を再構築するとなると
大きく時間は変わってくるのかもしれませんが、現段階の小規模なサイトの運営上は
まったく問題ないとの結論に達しました。
値段的な問題も考慮しました。
アファリエイトをするわけでもなく、趣味でサイトを作るのに
月1500と月500では1年後、3年後ではかなり違いますからね…。
というわけで、さくらのスタンダードのお試し期間中にWPを新規でインストール。
データベースの引っ越しは失敗していますが、記事データ自体は問題なくエクスポートできていたので
記事そのものは無事移植成功。
お金を払って正式契約しました。
次は同じ失敗は繰り返さないぞ！っていう意気込みでデータベースのバックアップの設定を最初に
やってしまおうというお話。
続く
これは過去の苦労話になるのですが、以前使っていたレンタルサーバーのロリポップのお話。
低料金でいいのですが、データベース（MySQL）が非常に重くMTやWPは正直言って使えたものではありませんでした。
特にMTの重さは尋常ではなく、管理画面でメニューをワンクリックするだけで1秒以上のウエイトは当たり前。
ソースを少し編集してプレビューするだけで10秒以上かかっていました。
ほんの少し、短い記事を書いて再構築するだけで5分以上かかり、頻繁にエラーを吐き出す。
私は思いました。これは無理だと。
そういった流れで（少なくともMTより軽かった)WPを使うに至ったのですが、それでも重いという印象は変わりませんでした。
契約更新の時期が迫るにつれてサーバーの引っ越しを考えるようになったのですが、
やはり面倒な話なのでなんとかならないだろうかと思い、少し検索するとUnbridled blogさんに
ロリポのMySQLサーバー移動の記事がありました。
昔のMySQLサーバーは共有している人が多めなので
新しい空いているMySQLサーバーに引っ越せば軽くなるというものです。
細かい操作は端折るとして、ようはMySQLをphpMyadminでバックアップ（エクスポート）し、
復旧（インポート）するという話なのですけれど。
ひとまずlucky bugさんの記事を参考にしてバックアップ作業を開始してました。
ここで問題だったのがロリポップのMySQLではインポートの容量にに上限があるということ。
上限はどこのMySQLにもあるのでしょうけどロリポップは2MBだったような。
ちなみにさくらは8MBです。
うろ覚えですけどかなり少ない容量だった気がします。
それに対してエクスポートした私のsqlデータは28MB。
サイトの規模に不釣合いなデータサイズです。
原因はWPのアクセス解析プラグインで、MySQL上にかなり大きなサイズのテーブルが作られていました。
というわけで、私のような小規模のサイトでもアクセス解析を導入していると
上限まで簡単に到達してしまいます。
やはりMySQLをそのままインポートすることはできそうにありません。
（アクセス解析関連以外をエクスポートしてみましたが、それでも14MBもあり、やはり断念）
ロリポップの助け合い掲示板ではSQL分を適切なところで分割する、とのアドバイスがありましたが、
SQLの知識がない私ではどこから切ればいいのか皆目検討がつきません。
これはレンタルサーバー上で上限があるのではなく、操作インターフェイスであるphpMyadminで
上限を設けているのかな、 とも思い他の操作方法を模索してみました。
しかし私にはコマンドラインで操作するなどという方法はできるはずもありません。
ネット上をしばらく検索していると、IDEA*IDEAさんで紹介されていたSQL Buddyに注目。
ブラウザ上から操作してみました。
使い方はbojovs logさんの記事を参照。
エクスポートは成功。
容量は46ＭＢ?
phpMyadminでエクスポートしたデータより一回り大きい。
なぜ？WPのテーブル以外に何かあっただろうか？わかりません。
仮にこれをphpMyadmin上にて読み込むために2MBで分割していったら
単純計算で23箇所も切らなくてはならない。
それはありえない。まともに読み込めるとは思えない。
28MBだろうが46MBだろうがインポートできないことには変わりはないのでスルー。
そのままSQL Buddyでインポートできるか実験。
これは失敗。
ホワイトアウトしてしまう。
やはり容量が大きすぎるからでしょうか。
数回試してみても一切読み込まず。
インポートはできないとの結論に。
phpMyadmin上もSQL Buddyでも容量的にインポートするのは無理なようだったので、
WPのプラグインでそういった類のものはないかと調べてみることに。
まず一番最初に使ったのがWP-DBManager。
ですが…。
WP-DBManagerを使うに当たってサーバー上のmysqlパスとmysqlダンプパスが必要なんですが、
ロリポップではそれがどこかわからずこれまた断念。
エクスポートすらできない結末。
（データベース関連はサポート外のため問い合わせるのもためらった）
次にWordPress Database Backupを使ってみました。
これはエクスポートは上手くいったのですが、インポートにこれまた5MB（うろ覚え）の上限があり断念。
（補足：sqlデータは通常サーバー上の任意のフォルダに作成されるのでFTPにローカルに保存することも可能でした）
ロリポップのMySQL間の引っ越しにあたり、データベースのバックアップは諦めました。
WPの記事データだけをバックアップして引っ越しを決断。
ロリポップのユーザー管理画面でデータベースを削除。
新たにデータベースを作成。
ここで引っ越し先のデータベースのサーバーの番号を選びます。
私の時はmysql39となぜか40が二つありました。
mysql40を選びデータベースを作成。
ダメもとでsqlデータをインポートしようとるすもやはりエラー。
潔く諦めWPをインストール。
WPをアップロード中一度もエラーが出なかったのでちょっとはマシなのか？と一瞬思いました。
続けて記事データをインポート。
一連の作業を終え、MySQLサーバーの引っ越しを完了。
これによって少しは軽くなるのかな、と思っていたら。
変わらない。
重い。
マシになったか？と思ったのは勘違いだったようです。
そもそもアップロード時にそんなにエラーでるのもおかしな話。
他に何もしていないのに。
この後もう一度データベースを削除してmysql39で同じ作業をするも結果は変わらず。
これはMysqlサーバーの引っ越しではなく、レンタルサーバーそのものを引っ越ししなければ
状況は改善されないとの結論に至りました。
次回：レンタルサーバー選びに続く