日本語
English
Français / French
Deutsch / German
Español / Spanish
Português / Portuguese
Italiano / Italian
Nederlands / Dutch
dansk / Danish
norsk / Norwegian
suomi / Finnish
svenska / Swedish
język polski / Polish
Ελληνικά / Greek
Български език / Bulgarian
Hrvatski / Croatian
čeština / Czech
limba română / Romanian
русский язык / Russian
اللغة العربية / Arabic
हिन्दी / Hindi
中文(簡体) / Chinese(Simplified)
中文(繁体) / Chinese(Traditional)
한국어 / Korean

WordPress 2.8に注意!

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

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

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

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

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

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

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


2009年6月15日(月) 12:23 コメント(0)   トラックバック(0)

お引越し余談

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

実は、せっかくなので多言語プラグインの動作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


2009年3月31日(火) 12:56 コメント(0)   トラックバック(0)

Google AdsenseとAmazon Affiliateの微妙な関係

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

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

FirefoxとInternetExplorerの見え方の違い

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

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

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

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

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

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


2009年2月2日(月) 23:22 コメント(0)   トラックバック(0)

パーマリンクの憂鬱

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

具体的にどういうリンクにしたかというと、「/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のシミュレータってどこかにありませんかね?(渇望

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


2008年8月11日(月) 23:33 コメント(0)   トラックバック(0)

MovableTypeからWordPressへ

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

2008年7月27日(日) 17:44 コメント(0)   トラックバック(0)

In progress.

現状はこんなかんじです。
設定画面イメージ 結果イメージ
公開できるようになるまでは、まだ少しかかります。

2008年7月6日(日) 19:20 コメント(0)   トラックバック(0)

All your post are translate by us.

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

2008年6月16日(月) 23:13 コメント(0)   トラックバック(0)