この前書いた、RedMineの0.8.4へのアップグレードの失敗でしたが、Ruby-1.8.5のままでアップグレードしてみたら普通に成功しました。Ruby-1.8.7のインストールの途中でこけたのか、設定が間違っていたのか、原因は定かではないのですが。
とりあえず、FastCGIでも0.8.7は動くと。
何が原因だったんだろうなぁ〜？俺の設定ミスかな〜（絶対そうだと思う）。
RedMine:アップグレードに失敗したのちに復旧
会社の開発用サーバに入れているRedMineのバージョンアップを試みたが失敗したので、その軌跡を書いておく。
まず、RedMine 0.8.4 にしようとして、svn updateをしてRedMineのソースを最新版にした後に、rubyのバージョンが1.8.7でないといけないことに気付いた。CentOS5.3でyumを使ってrubyをインストールすると1.8.5が入ってしまい、バージョンアップが必要となった。そこで、rubyのバージョンアップを行った。
参考にしたサイト：http://d.hatena.ne.jp/amacou/20090409/1239245934
まず、yumで必要なものをインストール
yum install gcc yum install zlib-devel yum install rpm-build yum install openssl-devel yum install readline-devel yum install nkf yum install mysql-devel
次に、今まで使っていたrubyとおさらばする。
yum remove ruby
次に、ruby-1.8.7をインストールする
wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p174.tar.bz2 tar xfj ruby-1.8.7-p174.tar.bz2 cd ruby-1.8.7-p174 ./configure --prefix=/usr --with-install-readline make checkinstall --fstrans=no
バージョン違いのものが残っていたらいけないからだと思うが、rubyにまつわるものを消しとく。
rm -rf /usr/bin/ruby rm -rf /usr/lib/ruby
で、さっき作ったrubyのRPMをインストールする。
rpm -ivh /usr/src/redhat/RPMS/i386/ruby-1.8.7-p174-1.i386.rpm
次に、RubyGemsをインストール。最新版の1.3.5にした。
wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.5.tgz tar xfz rubygems-1.3.5.tgz cd rubygems-1.3.5 checkinstall -R "ruby setup.rb" rpm -ivh /usr/src/redhat/RPMS/i386/rubygems-1.3.5-1.i386.rpm
ここで、Railsのインストール。バージョンを指定しないと、最新版が入ってしまうので注意。RedMine 0.8.4は、2.2.2が指定されているので、とりあえずそれを入れてみた。
gem install rails -v=2.2.2
ここで、ようやくRedMineのアップグレードを行う。
データベースのバックアップは必須！！私は毎日自動でバックアップをするシェルスクリプトを組んでたので、今回は助かった。
svnからチェックアウトしている前提です。
参考にしたのは、RedMine.JPのアップグレード方法です。
svn update rake db:migrate RAILS_ENV=“production” rake tmp:cache:clear rake tmp:sessions:clear
アプリケーションを再起動後、権限のあたりを修正ということだったので、Apacheを再起動したら、RedMineがInternal Server Errorになった…。ここからが悲劇の始まりだった。（いろいろやって記憶が曖昧なので、情報が違う可能性がありますがご容赦ください）
まず、何が悪いのかわからない。.htaccessを見る限り、俺がRedMineをインストールしたのはFastCGIを使っている状態で、Passengerを使ってなかったので、それが原因かなぁと思った。入門RedMineに、よほどのことがない限りはPassengerのほうがいいよと書いてあったので、Passengerに変更しようとした。
Passengerをインストールした。
gem install passenger
その後、Passengerモジュールをインストール。
passenger-install-apache2-module
Passenger用にApacheのconfファイルを作成しておく。
/etc/httpd/conf.d/passenger.confを作成。conf.dにある*.confは自動的に読み込まれるようにしてあるのが前提。
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4
PassengerRuby /usr/bin/ruby
RedMineはサブディレクトリで運用していたので、/etc/httpd/conf.d/redmine.confに以下を追加した（redmine.confは私が作成しただけで、普通にあるわけではない。しかも、FastCGI用の設定を書いていた）。
# PassengerでサブディレクトリのRedMineを動かすため
RailsBaseURI /redmine
# その後、FastCGIで設定していたものなどをコメントアウト
# ただし、それらがあっていたかはわからない。
Apacheを再起動したが、駄目。RedMineのpublicディレクトリの.htaccessを修正しても、駄目。1日かけて作業をしたのだが、RedMineのアップグレードができなかったので、元に戻すことにした…。
まず、既存のRedMineディレクトリをバックアップしておく。
その後、svnで自分が使っていたRedMineのバージョンをチェックアウトする。自分が使ってたのは、RedMine-0.7.0。
バックアップしていたRedMineから設定ファイル（database.yml, email.ymlなど）をコピーする。
データベースからテーブルを削除して、バックアップデータから復元する。（phpmyadmin経由で）
ruby-1.8.7, RubyGems-1.3.5を削除する。
rpm -e rubygems rpm -e ruby-1.8.7 rm -rf /usr/lib/ruby
yumで、ruby-1.8.5を再インストールする。
yum -y install ruby ruby-devel ruby-irb ruby-rdoc ruby-ri
RubyGems-1.3.5を再インストールする。
cd rubygems-1.3.5 checkinstall -R "ruby setup.rb" rpm -ivh /usr/src/redhat/RPMS/i386/rubygems-1.3.5-1.i386.rpm
Railsのインストール。0.7.0では、Rails 2.0.2を指定する。
あと、fcgiも入れとく。
gem install rails -v=2.0.2 gem install fcgi
以前のredmine.confとpublicディレクトリ以下の.htaccessを以前のものに戻して、Apacheの再起動をしたら、見事に復旧した。とりあえず、ほっとした。ただ、1日何やってたんだろうという徒労感だけは半端なかったけど、データのバックアップって大事だなぁと痛感されられた。アップグレードできなかった原因はまた後日、余裕があるときにやろうと思う。
WordPress:admin_head-ページフック名って？
admin_headフックを使って、cssやjavascriptを読み込ませていたんだけど、プラグインによって重複したり、全ての管理ページでcssとjavascriptを読みにいってるみたいだったので、なんか回避方法はないものかとWordPressのドキュメントを読んでいたら、こんなフックがあった。
- admin_head-ページフック名
- admin_head-プラグイン管理ページ名
どういう意味なのか、さっぱりわかんない。
wordpress ページフック名 でググってみたが、よさげな情報が出てこない。うーむ。
先人の知恵を拝借するために、Eclipse内で、正規表現を使って
admin_head-[\w]+?
で検索したら、admin_head-プラグイン管理ページ名を使ってるプラグインがあったー！
add_action('admin_head-wp-postratings/postratings-manager.php', 'ratings_header_admin');
なるほど。プラグインディレクトリからのパスを書くのか。
じゃあ、admin_head-ページフック名ってどうするの？
答えは、
// 新規投稿画面でのみ、hoge_header_include関数を呼び出す
add_action('admin_head-post-new.php', 'hoge_header_include');
// 投稿編集画面でのみ、hoge_header_include関数を呼び出す
add_action('admin_head-post.php', 'hoge_header_include');
おそらく、/wp-admin/****.phpの****.phpをadmin_head-****.phpで指定すればよさそう。
はぁ〜、めっちゃはまったので、とりあえず備忘録として残します。
WordPress: プラグイン開発でログを出す方法
まあプラグイン開発じゃなくてもいいんだけど。
プラグインを開発していると、テーブルを新たに作成して、投稿したタイミングでそのテーブルにデータを保存ということもあるかと思うんですが、フックであるsave_postのタイミングのデータをvar_dumpとかで出力できないんじゃないかと思って（そういえば試してないな…）、ログファイルに出力する方法を探していた。
functions.phpに、
- debug_fopen($log_file, $mode);
- debug_fwrite($fp, $message);
- debug_fclose($fp);
という関数があったので、これを使うこととした。
ただし、これらの関数はWordPressのデバッグモードでしか動かないらしい。デバッグモードにするには、$GLOBALS[‘debug’]を1に設定しなければならないらしいのだが、どこで設定すればいいのか見つけられなかったので、wp-config.phpの最後に以下を追加した。
// wp-config.phpに追加 $GLOBALS['debug'] = 1;
その後、プラグインのクラスにデバッグログを保存するためのメソッドを追加。各プラグインディレクトリ内のlogディレクトリ内にdebug.logというファイルを作成して追記していく仕様にした。
// プラグインファイルで処理担当のクラスを実装
class hoge{
/**
* プラグインのログディレクトリにデバッグログを保存する
* @param $message ログファイルに出力するメッセージ
* @return void
**/
function debug_log($message){
$message = date('Y-m-d H:i:s') . ' ' . $message . "\n";
$log_file = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'log' . DIRECTORY_SEPARATOR . 'debug.log';
$fp = debug_fopen($log_file, 'a+');
debug_fwrite($fp, $message);
debug_fclose($fp);
}
}
ひょっとしたらもっとスマートな方法があるのかもしれないけど、ログを残す方法としては、いいのではないかと。プラグイン用の基底クラスが欲しくなるな〜、とかいって。
開発環境って大事
この前からMacBookでヒルクライムしようぜの開発を始めたんだけど、WindowsのXAMPP環境とのレスポンスに比べて全然早いから、俄然やる気になる。新規開発じゃなくて、移植かつ、デザインやアルゴリズムの見直しなどもやっているので、時間はえらいかかるが、このレスポンスの速さなら、ストレスなくコーディングできる。
デュアルディスプレイだから、ソースを確認しつつ、ブラウザでチェックもできるし、XAMPPが遅いのを差し引いてもWindows環境の頃よりも開発しやすいんじゃなかろうか？
まあ何が言いたいかといいますと、開発者には開発しやすい環境を与えると生産性が何倍も上がるので、マシンに関しては無駄にケチらないほうがコスト回収できるんではないか？ということです。まあ上の話だと、マシンが遅いんじゃなくてXAMPPが遅いって話だけど。でも開発用PCがちょくちょく止まると、思考が分断されてしまい、コーディングの速度がすごく落ちるんですわ。
別に、最強の環境を与えてくれということではないので、あしからず。ただ、開発者は一般ユーザに比べると多くのアプリを起動しているので、やっぱりマシンは速いほうがいいのです。
それにしても、自分がこんなにMacに傾くとは思わなかった。
実は会社の開発環境もMacにした。iPhoneアプリ開発用に買ったMac miniだったのだが、俺が使っているWindowsマシンのパワーが非力すぎて、Eclipseのコードアシストが動き出すと最低5秒くらい止まるということを繰り返すようになったので（アシストないほうが早い！）、普通のエディタで開発するようにしてたんだけど、Eclipseの良さはコードアシスト以外にもメソッドの参照とかもできて便利なので、Mac miniにしたほうがいいなぁということで。
ただMac miniにつながってるキーボードはWindows用なので、非常に打ちづらい。
会社のMac用にキーボード欲しいけどMac用キーボード買うと高いしな〜…。