WordPressのバージョンは2.7.1です。 いつも書いてる通りXREAのサーバーはあまり触りたくないのですが、依頼なので仕方ありません。 XREAでWordPressを動かす場合、モジュール版PHPではパーミッションの関連上ファイル操作に難があり、普通に設置しただけではWordPressから画像などをアップロードすることが出来ません。（PHPのセーフモードがらみの問題で、仕様ですね） そこで、管理画面は（もしくはアップロード用スクリプトのみを）CGI版PHPで動かす設定を.htaccessで施すことによってその問題を回避する方法があります。 まぁココまでは”XREA WordPress”などで検索すれば幾らでも出てくる情報なんですが、その設定をやった上で、今回新たに「メディアライブラリの一覧で、個々のファイルの左にあるチェックボックスを複数チェックして、一括して削除しようとしたときに、サーバーからの応答が無くなる」という問題が発生しました。 応答がなくても、実際によく調べてみると、ファイルの削除もデータベースの操作も完了してるっぽかったので正確には「削除できてる」んですが、削除ボタン（実際には適用ボタンですか）を押してから、ブラウザが延々といわゆる「読み込み中」のまま、という状態です。 HTTPヘッダも何も返ってこない状態。 該当部分のソースを読んでみたり色々テストしていくと、削除処理をした後のリダイレクト処理部分で”wp_redirect”という関数が呼ばれており、どうもその関数が上手く動いてない様子でした。 ちなみにモジュール版なら”wp_redirect”関数自体は普通に動作します。 一括削除処理だけモジュール版で動作するようにしようかと一瞬思いましたが、そのwp_redirect関数を含むファイルって、upload.phpなんですよね。 つまりupload.phpに表示・追加・削除の機能が一つにまとめられてるので、htaccessのfilesディレクティブで切り替える方法が使えません。 とりあえず今回はwp_redirectを呼んでる行をコメントアウトして、 <html> <header> <title>wordpress redirect</title> <meta http-equiv=”Refresh” content=”0; URL=$location”> </header> <body> しばらくお待ち下さい。 </body> </html> という内容を返すようにしました。 文字化けるかもしれないのでもっとちゃんとしたソースを返すようにした方がいいです。 他にもwp_redirect関数を呼び出してる部分があったのですが、それらはちゃんと動いてるようでした（ホントかな）のでそのままです。 一応調査の中で、 header(‘Location: http://example.com/’); などと一行だけ書いたスクリプトをCGI版で動かしてみたりしましたが普通に動きました。 まぁ、これが動かなかったら大問題になりますけど。 原因は複合的なんでしょうね。
Read the rest of this entry »
久しぶりにphpやりました。文法がcに似てるのであまり迷うことは無いですが、foreachやif ～ elseの書き方で一瞬止まります。inだったかなasだったかなとか、else ifだっけelseifだっけelsifだっけとか。基本的過ぎてググるのもちょっと難しいです。（多分、それ”だけ”を説明してるページは多くないでしょう。）まぁそういうときは、誰かが書いたソースを見ればすぐ分かるので問題ないですが。 それより、cal_days_in_monthです。暦の種類（グレゴリウス暦やユリウス暦など）と、年月を渡すと、その月の日数を得ることができる関数です。例えば、 cal_days_in_month(CAL_GREGORIAN, 2008, 9) とすれば、2008年9月の日数である30が返ってくるわけです。うるう年の場合なんかもよしなにやってくれるので便利なわけです。 この関数はphpの標準関数だと思っていたのですが、どうも明示的with-calenderオプションをつけてphpをコンパイルしてないと使えないらしいです。以前はそんなこと無かったような気がするのですが・・・yumとかaptとかrpmとかportsとかで入るものがどうかは知りません。 たまたま今回使ったxreaのサーバーでcal_days_in_monthが使えなかったのです。 何とかする方法がないかとちょっとだけ調べてみましたが、調べるよりもcal_days_in_monthを独自に実装する手間の方が少ない気がして作ってみました。 if(!function_exists(“cal_days_in_month”)){ function cal_days_in_month($calender, $month, $year){ $year = (int)$year; $month = (int)$month; $year = ($year <= 100 && $year >= 0)?(($year < 70)?($year+2000):($year+1900)):$year; $isLeap = (($year % 4 == 0) && (($year % 100 != 0) || ($year % 400 == 0))); $days_in_month = [...]
Read the rest of this entry »
最近なんか多いですねぇ。セキュリティに絡んだPHPとそのユーザいじめ。 でもさぁ、僕はPHPもRubyもPerlもPythonもやるけど、どれも似たり寄ったりだと思いますけどねぇ。 確かにPHPは標準関数のネーミングとかに行き当たりばったり的なものを感じるし、文字コード周りの妙な自動化処理は気に食わないけど、それって、関数に別名つければいいし（そうするだけの価値があるなら）、文字コード周りのこともその回避策を知ってれば済むはず。 逆に言えば、妙な挙動が文字コード周りに限定されるから回避もしやすいけど、言語仕様レベルでクラスの妙な挙動を許しているPerlとか、そっちのほうが問題かと。 なので実際には、「PHPのhtmlspecialcharsはけしからん！」と言えるだけマシだと思うんですよ。だって、他の言語で書かれたhtmlspecialcharsよりもけしからん名もないhtmlspecialchars的な処理が現実にwebサービスとして動いてるほうが怖いですよ。（もちろんPHP vs その他という構図ではなくて。） 啓蒙しづらいし、修正方法も教えにくい。 ただ、僕がPHP好きで他が嫌いかといったらむしろ微妙に逆です。上に挙げた4つの中では微妙にPythonが一番ですけど、でもPHPをVB5に例えるなら、他はVB6くらいにしか見えません。つまりどんぐりの背比べ。 どの言語でも等しく選択する機会が与えられればPHPは使いませんが、世の中の共用レンタルサーバってmod_phpは入っててもmod_perlは入ってないし、RubyとPythonは実行環境すらないのが普通なので、どうしてもPHPになってしまいます。 自分の好きな言語のユーザを増やしたかったら、ネガキャンやって足引っ張ってないで、どんな鯖管でも真っ先に入れたくなるような共有環境でも問題のない「素性のいい」mod_なんとかを作れば良いんですよ。 話は少し変わるのですが、こことかここをみて、もやもや感が晴れた感じ。 やっぱりまずは作ってナンボの世界ですよ。もちろん最初から最後までセキュリティ糞食らえじゃダメだけれとも、少なくともセキュリティのことを考えるのは設計してプロトタイプを作った後にするべきです。 セキュリティって画一的にこうしておけば良いってもんじゃなく、個々の場合に応じて考えられるべきなので、その「個々の場合」ってのがはっきりしないうちから考えるのは時間の無駄です。 僕にも昔ありました、セキュリティやオブジェクト指向のことばかり考えて悦に浸ってるけど、実際は何も生み出してない時期が。 それは今考えるとまったくの無駄って訳じゃないけども、まるで好きな人に告白する場面を何百回もイメトレしたけど、100万分の1の確立のことにまで考えを巡らせすぎて行動を起こせなくて期を逃すみたいな。 先に行動すれば、結果が良くても悪くても得るものはあるのです。結果が良ければその結果自体を、結果が悪ければ「その方法はダメだった」という事実を得ることができます。 学ぶ者としては、そのほうが学ぶスピードが格段に速いと思います。 PS. Web系に限らなければConcurrent Clenが最高だと思います。他の言語はクソですよ。本気でそう思います。 しかしそう表明することにどれほどの公的な価値があるでしょうか？
Read the rest of this entry »