ブログ

しばらく前に、WordPress ME が開発終了になったのを期に、日本語版 Ver2.3.3 にアップグレードしたのですが、あまりに重過ぎるので過去にいろいろといじくったテーマだかプラグインだかが悪さしているのではないかと疑ってしまう。

JavaScript も結構いじったからもしかしたそいつのせいかもと思っているのだけれど、JavaScript はあまりよく分かっていない状態でいろいろといじったので、実際に問題があっても自分では分からないだろう。Firebug でエラーも出てないし、JavaScript を無効にして読み込んでも、見違えるほど軽くなったとは言い難いので多分たいしてネックにはなっていないと思いたい。

アップグレードしたときに、余計なプラグインは可能な限り無効にしたので、これ以上減らすのはちょっと厳しい。テーマはかなり弄っているので、見直せば無駄は省けるかもしれないけど、そこまで気力がない。

Ver2.5 を試しに使ってみているのだけれど、新しくなった管理画面も使いやすくていい（いまいち評判が良くないみたいだけど）ので、近いうちにアップグレードしたい。そしてテーマの見直しをしよう。

それまで、個人的にカスタマイズしている wp-hatena のプラグインを無効にしておこう。滅多にブックマークされないから、たまにされているのに気づいたときにうれしいので本当は外したくないのだけど、このせいで重くなっているのは間違いない。
※重くなっているのは、カスタマイズしている（これをさらにカスタマイズしてます）ためで、本来の wp-hatena はそれほど影響ないと思います。

wp-hatena の被リンク数を Ajax で表示できるようにできればだいぶストレス減るのかな？できるかどうか分からないけど。出来そうな気がする。

ME から 日本語版 Ver2.3.3 アップグレードしたときのメモ

前のことなのでほとんど覚えてないけど、WP2.3: Ultimate Tag Warrior データのインポート のページを参照したのは確か。それで、Ultimate Tag Warrior の代わりに Simple Tags のプラグインを入れた。

注意

この対処法は、古いバーションでしか通用しなくなっています。 Ver.2.7 以上を使っている場合は下記を参考した方がいいかも。
WP Basic認証をかけている場合の「予約投稿」 Ver.2.7以降？

ここから本文

以前、予約投稿で苦労したのですが、別の問題で予約投稿ができない人がいるみたいなので、ちょっと調べてみました。１ヶ月近く前の記事なので、もう解決してるかもしれませんが。。

他サイトとの違いは、Basic認証があることなので、試しにBasic認証をはずしてやってみたところ、「予約投稿」機能が動きました！

Basic認証下で、WordPressの「予約投稿」機能が動かない

Basic認証が問題になっているのはハッキリしているので、Basic認証を通るようにしてあげればいいようです。

ちなみに、修正なしでBasic認証＋未来投稿をすると HTTP/1.1 401 Authorization Required が返ってきてました。Basic認証が問題になっているのは間違いないようです。

今回検証したのは Ver2.5.1 ですが、Ver2.3.3 でも同様に修正すれば解決するのではないかと思います。

修正箇所は /wp-includes/cron.php の 101行目（function spawn_cron() 内） の fputs() のパラメータです。

fputs( $argyle,
      "GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0\r\n"
    . "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n"
);

上の部分を以下のように修正したら予約投稿できました。

fputs( $argyle,
      "GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0\r\n"
    . "Host: {$_SERVER['HTTP_HOST']}\r\n"
    . "Authorization: Basic ".base64_encode('user:password')."\r\n\r\n"
);

Basic認証用のヘッダを送ってあげればいいみたいです。４行目の user:password は、実際にBasic認証で使用しているユーザ名とパスワードを入れてください。

以下のページが参考になったので紹介しておきます。

PHPのちょっとしたTIPS

2.2系へアップグレードしたからだと思うけど、タグページが表示されなくて、404 のページが表示されていました。

対処と言うほどのことではないけど、以下のページに書かれてある通り『パーマリンク構造を更新』すれば直りました。

次の方法で解決しました。「各種設定」の「パーマリンク設定」を開き、「パーマリンク構造を更新」ボタンを押す。

WordPress 2.2.1 で UTW のタグページが表示されない

『WP 2.1から2.2のアップグレードでタグページが表示されてなかった』の続きを読む »

いまさらだけど、2.1から2.2へアップグレードした。なんだかんだでコアファイルもいじっているので、差分を取るのが面倒で、結構時間がかかってしまった。バージョン管理してないとだめですね。バージョン管理が出来るようになるという課題が増えたな。

別のところで、WP 2.2 のブログをやっているというのもあったので余り心配はしてなかったけど、修正部分やプラグインも含めて特に問題なく動いたので一安心。

修正したところは、WordPress 投稿エディタに LightBox のコードを挿入 と ATOM がValidation にならなかったところの２点。

『LightBox のコードを挿入』のほうは、2.1 とはまた違う構成になっているので、記事をそのまま丸写しってわけには行かないけど、やってたから参考にはなるってぐらいでした。でも、なんとなく正常に動いてない気がするので、気が向いたら確認しよう。ATOM の方は、昔そんなことをした気がするくらいであんまりよく覚えてません。

今回、アップグレード中に『メンテナンス中』ってメッセージを出したくて、ステータスコードはどうすればいいかとか分からなかったので調べてたら、下記のページにやりたいことがずばり書いてたので勉強になりました。

ErrorDocument 503 /error/maintenance.html
RedirectMatch 503 "^/(?!error/)"

サーバメンテナンス中にエラー画面を返す方法

自分の場合は、ブログの部分だけ 503 を返せばよかったので、

ってやっとけばOKでした。404 Not Found でリダイレクトの勘違い で書いてたリダイレクト検証ツールで確認してみたらしっかり 503 が返ってました。

引用記事のコメント欄に mod_asis や mod_rewrite を使えばよりよい対処法だというようなことを書いていましたが、まぁ、そんなに頻繁に使うものでもないし、個人的なブログなんで、まぁそこまでこだわらなくてもいいかなってことで、本当に必要になったときにまた参考にさせてもらうことにしよう。

まえまえから不便だから何とかしたかったんだけど、いじるのが面倒で放置していたページのナビゲーションですが、Some styles for your pagination の記事を見て、自分好みの分かり易いページャーだったので、ここからCSSを頂いてくれば、手間が減るなと思い設置することにしました。

自分で作る気だったんですが、プラグインがあるんではないかと思って探してみたら WP-PageNavi 2.20 というプラグインを見つけました。これで、上記で配布している CSS をプラグイン用にちょこっと直せば、自分好みのナビゲーションになるなと思い、プラグインを入れて CSS をいじろうとしたら、上記の記事からダウンロードした CSS のヘッダに、Plugin Name: WP-Digg Style Paginator と書かれているではありませんか。これ、WPのプラグ引用のCSSなんすか？ってことで、Plugin URI: に書かれてあるページに行くとありました。WP Digg Style Pagination Plugin V 1.0 というプラグインが。

早速入れてみたんですが、これWPのバージョンが、2.2 からじゃないとエラーが出ますね。このブログ（zontheworld）はまだ、2.1 なんですよ。とりあえず、関数が宣言されていないってエラーだったので、宣言されていない関数user_trailingslashit() と untrailingslashit() を 2.2 のソースからプラグインのファイルにコピペしてみたら動いてるみたいなんで、一件落着って事でそれ以上詳しくは追ってないです。

さっさと2.2にしないといかんですね。

WordPress のデフォルトで使える、 🙂 や 😉 などのアイコンがどうも好みではないので独自にアイコンを追加する方法を調べて、投稿フォームに独自の絵文字アイコンを追加する という記事を参考に自作プラグインを作ってみたので、自分が追加したアイコンをデフォルトに配布してみようかと思っていたのですが、よくよく調べてみると、More Smilies というプラグインがあって、使ったことはないけど説明を見た感じでは、自分が作ったものと考え方がほとんど同じどころか、画像の追加部分だけを切り分けて、管理画面で追加できるようにしていうところに関しては、多くの人が設定を共有できるので、こっちの方が便利だよってことで、この記事書いている途中でプラグイン配布は没にしました

自分にとっては、必要な機能のみを実装していたり、onclick を HTML のソースに書きたくない等の理由で、自分が自作したプラグインの方が好みなので、More Smilies は使いませんが、一般的に考えて More Smilies の方がいいです。使っていないのに薦めるのもどうかと思いますが。

※日本語版はこちらで配布されています。→ More Smilies 日本語版

なので、プラグインを配布する代わりに、現在自分が追加しているアイコンの More Smilies 追加用パッケージを配布しようかと思います。

ただ、アイコンは自分が作ったわけではありません。 A Trial Product’s 素材置き場の絵文字風から拝借したものです。

利用規約や FAQ を読む限りでは問題ないと思うのですが、個人的にアイコン制作者様に承諾なく配布するのも気が引けるので、連絡してみて許可をいただければ、パッケージとして配布しようかと思います。

コア部分を変更するのであまり参考にしない方がいいと思います。

変更後のイメージは以下のようになります。

■バージョン：2.1.3
■変更ファイル：/wp-admin/upload-js.php

修正点その１

【変更前】116行目：

h += "<label for='link-file'><input type='radio' name='link' id='link-file' value='file' checked='checked'/> <?php echo attribute_escape(__('File')); ?></label><br />";

【変更後】file のチェックをはずして、その上に LightBox のラジオボタンを追加

h += "<label for='link-lightbox'><input type='radio' name='link' id='link-lightbox' value='lightbox' checked='checked' /> <?php echo attribute_escape(__('LightBox')); ?></label><br />";
h += "<label for='link-file'><input type='radio' name='link' id='link-file' value='file' checked='checked'/> <?php echo attribute_escape(__('File')); ?></label><br />";  

修正点その２

【変更前】236行目～241行目：

if ( 'none' != link )
	h += "<a href='" + ( 'file' == link ? ( this.currentImage.srcBase + this.currentImage.src ) : ( this.currentImage.page + "' rel='attachment wp-att-" + this.currentImage.ID ) ) + "' title='" + this.currentImage.title + "'>";
if ( display && 'title' != display )
	h += "<img src='" + ( 'thumb' == display ? ( this.currentImage.thumbBase + this.currentImage.thumb ) : ( this.currentImage.srcBase + this.currentImage.src ) ) + "' alt='" + this.currentImage.title + "' />";
else
	h += this.currentImage.title;

【変更後】LightBox を選択時、rel 属性に lightbox[post-id] を設定する処理を追加。ついでに、img タグに width、height、title 属性を設定する処理を追加

if ( 'none' != link ) {
	h += "<a href='"
	if ( 'file' == link )
		h += this.currentImage.srcBase + this.currentImage.src;
	else if ( 'page' == link )
		h += this.currentImage.page + "' rel='attachment wp-att-" + this.currentImage.ID;
	else if ( 'lightbox' == link )
		h += this.currentImage.srcBase + this.currentImage.src + "' rel='lightbox[" + this.postID + "]";
	h += "' title='" + this.currentImage.title + "'>";
}
if ( display && 'title' != display ) {
	h += "<img src='";
	if ( 'thumb' == display ) {
		imageThumb = new Image();
		imageThumb.src = this.currentImage.thumbBase + this.currentImage.thumb;
		h += imageThumb.src + "' width='" + imageThumb.width + "' height='" + imageThumb.height;
	} else {
		imageBase = new Image();
		imageBase.src = this.currentImage.srcBase + this.currentImage.src;
		h +=  imageBase.src + "' width='" + imageBase.width + "' height='" + imageBase.height;
	}
	h += "' alt='" + this.currentImage.title + "' title='" + this.currentImage.title + "' />";
} else {
	h += this.currentImage.title;
}

img タグの width、height、title 属性は、LightBox とは関係ないのですが、W3C XHTML1.0 valid を意識して、毎回設定しているのが面倒になったので、コア部分を変更するならと、ついでにやっておきました。

プラグインを駆使してなんとかなるものなら、コア部分を変更せずになんとかしたいものですが分からないのです。

2.0系でこのカスタマイズを行いたければ、inline-uploading.php 辺りを変更すればいいのかと思って、ソースをざっくり追ってみましたが、2.1.3 の仕組みとは大きく変わっていたので追うのが面倒になりました。2.0系をカスタマイズしたい人は、ほとんど参考にならないと思います。

結論から言ってしまうと、Smart Update Pinger の影響のようです。プラグインを無効にすれば正常にタイトルが反映されました。

私の使っているバージョンは、2.1.3 なので、サポートされているバージョンで Smart Update Pinger を使っている人は、この症状は出ないのではないかと思います。
※ざっくりソースを流し読みしただけの予想です。

ちなみに、Smart Update Pinger のサポートされているバージョンは、配布元をみると1.5系か2.0系と書かれているようです。
※自信がないので、それっぽく書かれているところを引用。

WordPress 1.5/2.0 Support

If you’re still using WordPress 1.5.x, you must use the older version of Smart Update Pinger. This version will not work properly on WordPress 2.x, so make sure you have the right version of Smart Update Pinger.

WordPress Plugins: Smart Update Pinger, Jerome’s Keywords; Enhance your blog tool

原因

Smart Update Pinger（日本語版） の 161行目の、$post_title = ""; が悪さをしているような気がします。
2.0系までは、ファイルをアップロードする際のタイトルに、imgtitle を使っていたみたいですが、2.1系からは post_title を使っているので、Smart Update Pinger で post_title を初期化することで、post_title が設定されていないと判断されているみたいです。

対処

ファイルアップロード時は、Smart Update Pinger のプラグインを読み込まないようにしました。
※正確には読み込むが、if文で処理を通さないようにしました。

smart-update-pinger.php の最初と最後に以下のコードを追加

if (false === strstr($_SERVER["SCRIPT_NAME"], '/wp-admin/upload.php')) :
～ (中略) ～
endif;

初めから smart-update-pinger.php 自体を読み込まないような方法があるような気もするのですが、プラグインの読み込み時に振り分ける方法が分からないし、処理を追っかけるのが面倒なので上記のような安易な対処しました。

この対処で問題ないかどうかは不明ですが、今のところ正常に動いているようです。

個人的に別ウィンドウを開かせるようなリンクの張り方はほとんどしないのですが、たまにどうしても別ウィンドウで開いて貰いたい場合があります（PDFデータのダウンロードページとか、そのページからリンクが張れなくて、行き止まりになってしまう場合とか）。

でも、_blankは XHTML 1.1 では廃止されたとか、HTML4.01とXHTML1.0で非推奨だとか、そういった感じのイメージだけはなんとなくあって、今は基本的にほとんどが XHTML1.0 で書いているので良くはなくてもダメではないという感じなので、使ってもいいかとも思うのですが、将来的に XHTML 1.1 とかにしていくときに修正するのが大変なので、軽く調べて以下を参考にすることにしました。

_blankを使わないで別ウィンドウを開くにはrel=”external”を使うのが美しいと思う。

_blank 使わない別ウィンドウを開く方法

コメント欄を見るといろいろと議論されていて、この記事の内容から修正されている点もありますが、特にガチガチに XHTML に準拠した形にしたいわけでもないので、とりあえずは、a タグに class="extarnal" を指定して、JavaScriptで anchor.target = "_blank"; にすることにしました。

rel="extarnal" にしなかった理由は、WordPress のコア部分の auther 関連が既に class="extarnal" を指定していたからです。コア部分に手をつけるのはあまりしたくないし。

それなら external じゃなくて、別の名前にすればよかったのですがもう一つ理由があって、上記の記事のコメント欄を読んでいると、rel="external" は非準拠だどうだといった議論があったりして、詳しく調べるのも面倒なので、無難に class にしておくことにしました。ついでに rel属性の準拠、非準拠の話の中で、(X)HTML仕様に定められていないリンクタイプを記述するときは、プロファイルをhead要素で指定しないといけないといったことが書かれていました。

headタグの profile要素の指定について

プロファイルとか言われても、あまり意味が分からないので、とにかく参考にされている以下のリンク先などをざっと読んで rel="nofollow" を使う場合もプロファイルを指定しておく必要があるとありました。

rel="nofollow" ほかメタデータのプロファイル

WordPress のプロファイルは既に、XFNを使っていますが、このプロファイルが、どうも複数指定は出来ないようで、XFN をとるか XHTML metainformation profile 二者択一になってしまうので、XHTML metainformation profile を採用することにしました。幸い XFN は、指定するのが面倒で、全く使っていなかったし。

ソースコードは、<head profile="http://gmpg.org/xfn/11"> を <head profile="http://purl.org/net/ns/metaprof"> に変更すればOKのはず。

この件はWP 未来投稿（予約投稿）の注意点で、問題なかったのでいったんクローズしたんですが、このブログの環境では問題なかったものの、実際に問題が発生したブログの方では、やはり未来投稿（予約投稿）が出来ない症状が続いています。ここのところ忙しかったので見てみぬフリをしていたのですが、やはり不便なのでもう一度調査します。

症状が発生している方との違いを調査するのにこのブログのデータを取るための記事なので、内容のある記事ではありません。原因が特定できた場合は追記を書くと思います。

調査結果追記（2007/05/15）

未来投稿が反映されない原因はソケット接続オープン時のタイムアウトでした。
/wp-includes/cron.php の 87行目（Ver 2.1.3）の fsockopen タイムアウトが 0.01 に設定されていて、$errstr に Connection timed out を返していました。タイムアウト時間を長めにとれば大丈夫かと思います。

未来投稿が反映されなくて困っているけど、難しいことが分からないという人は、下記の部分の 0.01 の部分を 0.1 にしてみると問題が解決する場合があるかもしれません。

$argyle = @ fsockopen( $parts['host'], $_SERVER['SERVER_PORT'], $errno, $errstr, 0.01 );

一応、他にも短すぎるタイムアウトが設定されていないか fsockopen で水平展開してみましたが問題になりそうなところはありませんでした。

確か、以前もVer 2.0系でタイムアウトが原因の問題で悩んだことがありました。（詳しく覚えてないけどトラックバック関連だったような気がします。）メモしておいたんですが、サーバトラブルでバックアップデータを復旧せずそのままに状態で放置してたのですっかり忘れてました。これからはちゃんとメモをしておこう。