ふとWP公式見たらこんな警告が。自動アップグレードボタンを押してはいけません！

2.8への自動アップグレードを行う際の注意事項 – WP公式

先日リリースしました WordPress 2.8 への自動アップグレードの際に、サーバー上のファイルが削除される現象が報告されています。報告によると、この問題が発生した場合にはサーバー上の WordPress 以外のファイルも削除されるとのことです。

2.8 にバグがあることが確認されました。このバグが修正されるまでは自動アップグレードは行わず、手動によるアップグレードを行ってください。

これはひどい。最近は管理画面に入ると「アップデートしてください」と常に誘導が表示されるようになってますので、うっかりやってしまう人も多いのではないかと。安全のために一時取り下げればいいのに、と思いますが仕組み上難しいのでしょうか。

アップデートはバックアップしてからが基本！とはいえ、アップデートのたびにフルバックアップは現実問題としてそこまで手をかけられないことも多いですよね。ましてやWP関連ファイル以外にも影響するとは普通予想外でしょうし。

とりあえず現状としては、手動アップグレード（FTPで上書き）でユーザ側で対応して、こなれてくるのを待ちましょう。ある意味これでバグが減ることになるわけですし。

サーバ移転の舞台裏を少し。

実は、せっかくなので多言語プラグインの動作URLを、サブフォルダ（domain.com/??/）からサブドメイン（??.domain.com/）へ変更しようとしたのですが……結果、惨敗しました。何にか、といえばMod_Rewriteに、です。

ご存じない方のためにカンタンに紹介しておくと、「Mod_Rewrite」とは、URLを書き換えて、見た目のURLと実際のアクセス先を自在に操作できるようにするプラグインのことです。一般のユーザの方が意識することはまずないと思いますが、気づかぬところで様々な恩恵を受けているはずです。例えば、https://から打たずにURLをドメイン名から打ち込んでも、自動的にhttps://で始まる暗号化されたページに飛ぶようにして、利便性を向上する働きをしています。

しかしながらこの使い方が難しい。ぐぐれば、解説やサンプルは沢山あるのですが、複数ルール組み合わせたときの挙動がいまひとつ掴みきれません。

参考サイト各種
mod_rewrite モジュール – URL 書き換えエンジン
mod_rewriteリファレンス – dawgsdk.org

最終的なアクセス先URLは、「http://catswhiskers.jp/記事URL?lang=言語」というのは確定しています。

そこでまず、サブドメイン部分に言語指定を入れていた場合、例えば「http://en.catswhiskers.jp/」を「http://catswhiskers.jp/lang=en」に変換する必要があります。ここで重要なのがドメイン部分が変わるということは、たとえサブドメインのみといえど、別のサーバとして扱われる点です。つまり[P]オプションで内部プロキシ経由にしないと、リダイレクトされて見た目のURLが変わります。そのため、下記のような設定にすればOK、なはずなんですが…

RewriteCond %{HTTP_HOST} ^(en|fr|de ..中略.. |ja )
RewriteRule (.*) http://catswhiskers.jp/$1?lang=%1 [QSA,P]

この結果が何故か「404 Not Found.」　しかも通常の404とは違い、その一文のみが小さく表示されている状態です（XREAサーバでは）。ここでいきなり躓きました。ためしに[P]オプションを外して、普通にリダイレクトさせると問題なく表示されます。ということは書き換えルールは間違っていないとは思うのですが……XREAサーバはMod_Proxyが有効でないのかも？

あ、横道にそれますが、もう一つの[QSA]オプションは、その他のクエリを引き継ぐため（例えば他に?id=1がついてた場合）のものです。RewriteRuleの判定部分にクエリは含まれません。CMSなどを使っているときは、忘れるとハマりがちなので注意しましょう。ちなみにクエリ部分で何かしらマッチさせたいときは、RewriteCond %{QUERY_STRING}で判定させてください。

閑話休題。[P]オプションについてあれこれ試してみたのですが、何をやっても駄目。どう書き換わって404と言っているのか分かればと思い、ログを取ろうとRewriteLogおよびRewriteLogLevelを設定してみたのですが、XREAはどうもこのオプションは使用できないようで……　となると想像で試すしかなく、いい加減精神的限界に近づいてきたので諦めた次第であります。

さて、ではあっさり終わりかと言うとそうではなく、サブフォルダの言語指定をクエリに変換しなくてはいけません。その設定が以下です。

RewriteCond %{REQUEST_URI} ^/(en|fr|de..中略..|ja)
RewriteRule ^[-a-zA-Z]+/(.*) /index.php/$1?lang=%1 [QSA,L]

また、このサイト特有のURLとして、/blog/の下に、カテゴリ名/年月日/記事名.htmlという構造になっています。そして実はカテゴリ名はあってもなくてもきちんと表示されるようにしています。これは将来的にカテゴリ名を変更したときでも、以前のURLで記事にアクセスできるようにするためです。これを実現するために、実体はカテゴリ名なし（画像を見るとよく分かると思います）、プラグインでリンクにカテゴリ名を挿入する、という処理を内部的に行っています。そのためのリライトルールが……

RewriteCond %{REQUEST_URI} ^/(en|fr|de..中略..|ja)/blog/[^/]+/([0-9_]+/.*)$
RewriteRule (.*) /index.php/blog/%2?lang=%1 [QSA,L]

これ（上）とこれ（下）です。

RewriteCond %{REQUEST_URI} ^/blog/[^/]+/([0-9_]+/.*)$
RewriteRule (.*) /inde.php/blog/%1 [QSA,L]

さらにその後に続けて、Word Press標準のルール（下）が入ります。

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [QSA,L]

だいぶ混乱してきましたよね。ええ、私も混乱してます（笑）。おそらく私の理解が不足してるせいなのですが、書き換えたURLを次のルールにうまく渡せないのです。本来は、「言語指定部分の書き換え」->「カテゴリ名の書き換え」と順番に渡せれば、もっとすっきり書けるのですが……　結局、

1. 言語指定あり、かつ、カテゴリ名の入るURL
2. 言語指定あり、かつ、カテゴリ名の入らないURL
3. 言語指定なし、かつ、カテゴリ名の入るURL
4. 言語指定なし、かつ、カテゴリ名の入らないURL

という4通りのルールを別個に書く羽目になっています。原因追求には、RewriteLogの取れるテストサーバを立てて実験してみるしかないかもしれません。URLと書き換えルールを入力すると、結果が出てくるようなWebツールを切望しております。。

ちなみに、WordPress標準のルールのRewriteRuleの「(.*)」ではなく「.」で済んでいるところが、個人的にはすごく不思議なのです。これだと「/test.html」へのアクセスが最初の一文字だけ変換されて「/index.phpest.html」（RewriteRuleでは最初の/は判定に含まれない）となる気がするのですが……　実際に記事を見てみるとこれで見れているので、間違ってはいないのでしょうけど。

これで一応完成なのですが、どうもディレクトリなのに最後を/で終えないURLでアクセスするとエラーがでるので、アクセス先がファイルではない場合（拡張子がついていない場合）、最後に/を補うようにもしてたりします。……リライトだけでそれなりの負荷になりそう。

ついでにXREA特有のお話ですが、PHPがセーフモードで動いていて色々と動かないものがあったりすることが多く、CGIモードと呼ばれる形態でPHPを動かすことが定番になっています。それには.htaccessに「AddHandler application/x-httpd-phpcgi .php」を記述しておきます。

が、WordPressを動かすときは要注意です。Mod_Rewriteと組み合わせて使った場合、CGIモードのPHPはPathInfoの情報がうまく取れなくなるらしく、記事URLの形式によっては個別記事が見れなくなります（ました）。結局、セーフモードに戻して運用しています。記事の閲覧には問題ないですが、自動アップグレードができなかったりします。その他の制限についてはPHP: セーフモード – Manualを参考にしてください。

あ、そうそう。コメント投稿後にエラーが出るのもついでに直しました（ようやく…そしてたぶん）。記事URLの形式のせいか、投稿後にhttp://～//～とスラッシュを2つ連続して含むアドレスに飛ばされてしまうようなので、それを書き換えるだけのプラグインを作っていれてます（わざわざ…苦笑）。もっと根本的な直し方をご存知の方は教えてくださいm(_ _)m

どうもGoogleアドセンスもAmazonアフィリエイトもiframeタグを使っているせいか、ブラウザによってブログに貼ったときの挙動がおかしい気がします。

具体的に何がおかしいかというと、記事を一覧で表示したとき（つまりトップページ）の昨日の記事なんですが、最初のAmazonアフィリエイト用iframeに、Firefoxでは何故かGoogleの広告が表示されています。一方、Google Chromeでは一昨日のアフィリエイト用iframeの商品（AirStation）が表示されてしまっています。変なキャッシュが残っていた？　現在は正常。IEは正常です。

しかしタイトルをクリックして、個別記事で表示させてやるとどちらも正しく表示されます。ということは原理的には問題ないわけで。うーん、どこに原因があるのやら。

まあ、そもそもiframeタグはValidなXMLとしては不適合なワケで、下の記事を参考にしてobjectタグにしてみようかと考え中。

広告スクリプトを object タグで読み込む方法 – 亜細亜ノ蛾

ついでにこの辺も参考に、というか上の記事もここから辿って見つけてたり。

Google Adsenseをできるだけ最適化してみる – TICKLER’S BUMNUM DAYS

ちなみに「アフィリエイトで本気で儲けるぞ！」とは今更過ぎて思ってないので、なるべく邪魔にならないように置いているつもりです。世間で騒がれているモノがどんなものか試し半分、それで多少なりともコストが賄えればが半分です。ちょっとだけご容赦を。

記事リンクを変えました。考えていた通りのリンクで動作するまでだいぶ苦労しましたよ。また各検索サイトのキャッシュ待ちになってしまいますが仕方ないですね。

具体的にどういうリンクにしたかというと、「/blog/category/y_m_d/postname.html」という設定にしました。まずはブログがあることを表す「blog」で区切り、次に「category」、そして年月日をアンダーバーでつないで「y_m_d」で区分けして、最後に記事名のファイルを置く、という設定です。これで先頭から自然に分類される形になります。ちなみにWord PressはMovable Typeと違い実体のファイルを作りませんので、上記のはあくまでも表示上の（かつ検索エンジンが理解する）扱いとなります。

一見問題なさそうですが、じゃあ何故タイトルに「憂鬱」なんてついているかと言うと、サーバ内部で認識されるリンク名は「/blog/y_m_d/postname.html」にしてあるのです。そう「category」がありません。なぜならカテゴリは後から変わる可能性があるからです。そしてカテゴリが変わってもパーマリンクは維持したい、そう考えるとカテゴリはない方がいいのです。じゃあ最初からカテゴリなしで良いじゃないと言われるかもしれませんが、検索エンジンにはカテゴリ分けを認識して欲しいのです。

そのジレンマを解消するために、ModRewriteを利用して「/blog/category/y_m_d/postname.html」を「/blog/y_m_d/postname.html」に置き換えたのですが、この設定がまさに憂鬱極まりないもので……　前述の通りWord Pressは実体のファイルを作りません。その代わりModRewriteを使い、PHPの”PATH_INFO”という仕組みで記事を指定して表示させています。”PATH_INFO”とは、たまにURLで見かける「~xyz.php/path/info/」というやつですね。この設定がすでに.htaccessファイルに書いてありますから、これを邪魔しないように付け加えてやらないといけません。さらにこのブログはご存知の通り多言語化されていまして、それもModRewriteを利用しています。これら3つの設定が全てうまくいくように.htaccessファイルに設定を書かねばならず、その記述で頭を抱えることになった、という顛末でした……

なにせURLを書き換えると言う仕組み上、うまく動いているかどうか見た目では分からないですから、どの設定までがあっていて、どの設定が間違っているのか推測するしかないのです。この徒労感たるや！　今動いているこれもかなり強引に設定してありますので、どこか不具合が出るのではないかと戦々恐々の状態だったりします。正規表現のシミュレータはいくつかありますが（たとえばこれ）、ModRewriteのシミュレータってどこかにありませんかね？（渇望

さて記事個別にファイル名を付ける作業に戻らないと　λ..ﾄﾎﾞﾄﾎﾞ

移行することにしました。 別にMTが悪いというわけではなく、やっぱり一長一短なわけですがプラグインをWordPress用で作ってしまったので。 まだあちらこちら不具合があると思いますが、おいおい解決していきたいと思います。

現状はこんなかんじです。 公開できるようになるまでは、まだ少しかかります。

ただいま極秘プロジェクト中につき、ブログ更新が滞っております。 そういえばデザイン変更は、って？　いやサボってるわけじゃないんですよ？ MovableType4.2の正式版が出たら、フォルダ構成とか一緒に変えようかと。 |ω･｀) ﾁﾗ　実はWordPress変更案もちょっと復活してたりして。 あと空いてる分の過去記事がこっそり増えていても気にしないでください（笑）。 タイトルネタ元を知らない方はこちら。

うさんくさいですね～（笑）。いや夢があって良いんですけど。

頭から疑ってかかるのは良くないかもしれませんが、エネルギー保存の法則を考えれば、まず「ありえない」という言葉が出てくるのは仕方ないですよね。水分子というのは、この地球上にあまねく存在していることから分かるように、とても安定的な物質なわけです。その安定を覆すには、外からの何らかのエネルギーが必要なわけで。「水分子＋外部エネルギー→水素分子＋酸素分子」だとすれば、逆に「水素分子＋酸素分子→水分子＋外部エネルギー」も成り立ちます。つまり「水分解」→「水生成」なんてしてたらスタートに戻るだけで何の意味もないのです。

当たり前のように聞こえたかもしれませんが、これ意外に重要ですよ。水を生成して電気を取り出すというのは燃料電池と同じなわけです。ですので、燃料電池は水しか出さないから環境にやさしい、というのは後半しか見てないことに気づきます。じゃあその水素と酸素をどこから持ってきたか、まで見ないとエコかどうかは分からないのです。火力発電所の電力でがんがん電気分解してたら全然地球に厳しいです。

さて百歩譲って、常温下で水を分解する触媒があったとしても、その反応はごくごく緩やかなものでしょう。車を動かせるほどの量の酸素と水素を発生させられるとは到底……　どうせなら太陽光＋触媒で超高効率の電気分解を実現！とか言われたほうが信じられるのに。

分からないのが、これを公表して何をしようとしているのか、という点です。その場で投資資金でも集めてくれれば分かりやすかったんですが（笑）。ある程度販売して夜逃げするにも、いきなり導入するところなんてないでしょうしね。一個サンプル支給してもらって試せば一発で分かりますし。

ついでに知りましたが、水電池なるものがあるんですね。こちらは今回の話とまったく関係がなく、電極のみがセットされていて、水を入れることで+/-のイオンが溶け出して電気が発生するという原理のようです。乾電池になる一歩手前で止めたような状態で、何の利点があるかというと「保存性が高い」こと。乾電池は使わなくても少しずつ放電して、いざというときに使えないってことがありますから。古い乾電池は切れが早いと思ったことありますよね。

知り合いから教えてもらったのですが、Google AJAX Language APIなるものが公開されていたんですね。

これを使えば、誰でも多言語対応サイトを作れる！　……かもしれないAPIです。かもしれない、というのは精度的にはやはりまだまだ、というところで。とはいえ他の翻訳サイトも似たようなものですし、Javascriptで誰でも使えるというのがすごいところです！

mycomの記事に分かりやすいサンプルソースがありますので、気になる方は一度ご覧ください。APIのシンプルさを感じてもらえると思います。

Googleからの贈り物 – Google AJAX Language APIでカンタンに翻訳サイトを

上のサンプルソースを参考にして、ブログの<p>タグ内の文字を翻訳するサンプルを作ってみました。うねうね訳していくのは仕様です（笑）。あと、あまり長文は訳されません（恐らくAPIの制限）。

追々、もうちょっとこなれたのを公開します。

サンプルスクリプト：言語を選択して下さい。

現在のじょうきょう。

• トップページからうにうに変更してます
• faviconつくりまつた→
• ブログをマーケット/その他で分けようか検討中。もしかしたらアニメも？

  平日はマーケット中心、休日は日常話中心という感じ更新していこうかと。問題はMovableTypeでどう実現するか。マルチブログだと両方のカテゴリに共通させたい記事が扱えなくなるし、ひとつのブログでやる場合、ブログルートの変更とカテゴリ管理が煩雑に。

• 携帯対応はテンプレートで

  MT4iが配布中止？になっているようなので（サイトが403Forbidden）、とても困ったことに。追記：単に一律のアクセス制限に引っかかっていただけのようです。ほかの場所から普通にアクセスできました。フリーじゃないのならほかにあるようだけど……　なのでしばらくはテンプレートで携帯用ページを吐き出すようにしようかと。きちんとは表示されないけど（タグ除去や画像リサイズ、カナ変換はむりー）、とりあえず見れる状態を目標に。