hiromasa.another :o)

ぼくの密かなたのしみは、MMRT daily life の上部に配置されたランダムポストをクリックして次々と出てくる記事をうししと読むことだった。

いつかぼくもランダムポストを、そう思って早3年。 なにやら twitter を覗くと、 kougabu を利用したランダムポストがにいさんによってつくられている!?、こ、これは…!!

…ということで、にいさんこと、をかもとさんが現在作成中の豪華エフェクト付きランダムポスト・スライドショープラグインに向けて、wp-kougabu をバージョンアップしました。 kougabu の API がいまいちだったのでプラグインに向けて拡張しています。

WordPress Plugins-JSeries » wp-kougabu （画像付きアーカイブ）

wp-kougabu-1.12.zip

kougabu_get_images 関数に新規のオプション array_ext を追加しました。画像属性が分割された形式で配列を取得できプログラムから扱いやすくなりました。

それ以外に変更はありませんので、ダウンロードいまお使いの kougabu に上書きしていただいて、にいさんのリリースを楽しみにしていただければ。 新規の方も使い方かわりません。

うちのサイドバー下でうごいているのが、そうです。

うーん、たのしすですね。 ウィジェット、ショートコード、関数から kougabu サムネイルを利用したランダムポスト・スライドショーを呼び出すことができます。

近くリリースされると思いますので、にいさんのブログを要チェックや! 

—

(23:40 追記)

JSeries にリリースされました!

WordPress Plugins-JSeries » Kougaburari ( ランダムポスト・スライドショー )

画像付きアーカイブ表示プラグイン「wp-kougabu」のランダムポスト機能を使用して、スライドショーを表示するプラグインです。

にいさん、ありがとうございます!

Kougaburari  dogmap.jp

てなわけで、前から気になっていた jQuery プラグイン JQuery Cycle Plugin を使用して、wp-kougabu が吐き出したランダムポストイメージをスライドショー表示するプラグインを作りました。

むっふっふ。

いろいろありました 2009年もあっというまに、日本は大晦日です

師走の中、WordPress 2.9.1 の準備も着々と進み、WordPress 2.9.1 RC1 が 30日にでております。 2.9.1 で修正される不具合で、いくつかプラグインの動作が直るものがありますので、紹介したいと思います。

まずはブログでもアナウンスがありました、wp-cron が動かない問題です。

WordPress | 日本語 » WordPress 2.9.1-1

残念なことに、先日の 2.9 リリースと一部のバージョンの PHP 組み合わせで cURL 拡張に関するバグが起こることが判明しました。該当するバージョンの cURL では、予約投稿およびピンバックが正しく処理されません。

wp-cron は WordPress のスケジュールイベント系を司るモジュールのことですが、これのタイムアウト待ち時間の設定が一部のサーバで速くなりすぎるため、スケジュール実行が発動しないという問題です。

予約投稿やピンバック、またスケジュールを使っているプラグインも影響を受けますが、WordPress Related Post for WordPress もそのひとつで、該当サーバでは関連が取得できなくなっていると思います。（このプラグインは辞書作成で投稿時間や過去記事の閲覧が遅くならないように wp-cron によるバックグラウンド処理を行っています）

とりあえず辞書作成について、2.9.1 までは http://www.example.com/wp-cron.php に手動でブラウザからアクセスすることで対処できます。（www.example.com はお使いのサーバスペースにあわせてください）

次はタイムゾーン問題。

以前書きましたとおり、2.9 より PHP のタイムゾーンの設定を WordPress が UTC に変更する動作が加わりました。

その後、もう少しプログラムを追っていくと、(wp_)options の gmt_offset という値を取得しようとするとフックにより、UTC に設定したタイムゾーンを、timezone_string 値(Asia/Tokyo とか）で再設定する動作があることが分かりました。

影響をうけたのが、 current_time() という WordPress コアの関数で、timezone_string が存在するとタイムゾーンの再設定により、日本であれば +9 +9 の時間 (2回ずらしてしまう）を返してしまうようです。 wp-kyodeki プラグインが正しく日またがりで値がクリアされないケースがこの件です。

パラ見ですが、xmlrpc 経由の投稿日付、ファイルアップロード時に作成される年月ディレクトリ、テンプレートタグのカレンダーのめくりの処理などの時間が +9 ずれる可能性がありそうです。

で、最初現象が分からなかったのがなる人とならない人がいることで、どうも昔から WordPress を使っている人で、最近、管理画面の general setting の更新をしてない方は timezone_string 値が入っていなくて、gmt_offset だけが入っている状態。 この場合は current_time() はうまく動作します。 ぼくとかおでさんとか（笑）

General Setting で都市名で値を設定すると、timezone_string に値が入るため current_time() がうまく動作しなくなります。

幸いなことに、WordPress 2.9.1 より UTC 形式での細かい値を設定できるようになりました。 この設定を使った場合、timezone_string に値が入らなくなり、うまいこと current_time() が正しい値を返してきますので、不具合で困ったことになっている方は、2.9.1 がでてアップグレードした後、日本のタイムゾーンの方は

こうしてください。（ドロップダウンの下の方に追加されています） これで修正されると思います。

current_time() の件については、Nao さんにご協力（ぼくは英語が書けません。。）をいただきましてチケットをきってあります。 Nao さん、お忙しいところありがとうございました!

3.0 にまわされていますが、おそらく修正されると思います。 それまでは、UTC な Timezone 設定でしのぐ方向で。

#11672 (current_time() does not correctly retrun localized time) – WordPress Trac

When you set you set timezone using a city name, current_time() function in functions.php does not return correct local time.

てなわけで、 +9 の日本は粛々と除夜の鐘が鳴る時間に進んでおります。

みなさま、良いお年を・・・!!

というわけで、まさに日本時間で昨日になりますが WordPress 2.9 がリリースされました。 めでたい。 いろいろ新機能もあるようで使うのが楽しみです

さてさて、昔はつくっていたプラグインがバージョンアップでよく動かなくなっていたりしていたのでベータでチェックとかしていたのですが、最近わりと動くのでさぼってたら、ふと wp-kyodeki がおかしくなっているよう、、その動作を見てコアにとある変化があったのに気がつくぼく・・・。（←遅い

というわけでとりあえず wp-kyodeki。

このプラグインはアクセスカウンタみたいなもんですが、日付をまたぐとカウントがクリアされる仕様になっております。（もともとアクセスデータを蓄積しないようにつくったプラグインでした）

夜行性のぼくは 2.9 にアップデートされた我がサイトのサイドバーをみて、日付をまたいだのにカウントがクリアされていないことに気がついたのです。。

というわけで不具合がありましたので、 JSeries にリリースしました。お使いの方は更新ください。

WordPress Plugins-JSeries » wp-kyodeki (本日人気の記事表示ウィジェット）

タイムゾーンでの日付変更クリアとならない不具合が修正されます。

さて、なんでだろうという話ですが、コアの wp-settings.php に以下のコードが追加されていました。

if ( function_exists('date_default_timezone_set') )

    date_default_timezone_set('UTC');

PHP の date 関数の戻り値などに影響する、timezone の設定でこれが標準時間になるようになっています。 というわけで、これがなかった今までは日本時間が戻ってきていたのですが、UTC になったので標準時間がもどってくるようになった、ということでした。

wp-kyodeki の不具合です。 冷静に考えたら海外サーバだと WordPress のタイムゾーンを日本に設定していてもあちらの時間で更新されていましたね。すいません（笑）

で、そういやコアがどうなっているのかあんまり考えたことなかったなぁとちらほらソースをみていると、結構 date を生でつかっているところがあるようです。

まぁ、いまも日本タイムゾーン設定で海外サーバ使われている方も多くて問題になっていないようなのでコアは大丈夫かと思いますが、プラグインは考慮漏れているものがあるかもしれない（あんまりないと思いますが）ので、万が一 2.9 の日付系で問題があったら疑ってみてください。

WordPress プラグインをつくるときにぼくが結構大変に思うのは、実は管理画面をつくること･･･。

なにげに自分のプラグインのソースを眺めると実ロジックより大きいこともあったりして笑ってしまいます。 というわけで、既存の管理画面のないプラグインにポンとつける用途を念頭に試しに（本当に試しに）フレームワーク的なものをかいてみました

といっても、PHP 的に厳しい部分もあったりしてごにゃごにゃしなきゃいけない部分もありであまり実用的ではなく、まぁまぁこんな作り方もできるよねって話でみてもらえたらと思います。 PHP 5 系専用です。

まずはサンプル。 なにかしら管理画面の持たない既存のプラグインがあることにします。（以下、ソラでかいているので間違っているかもなのでイメージで）

なんでもいいですがおなじみ the_content フィルターで何か追加する感じのやつにしてみましょう。

   1: function addContent($content) {

   2:     $header = "ほげ";  

   3:     $content = "<p>$header</p>" . $content;

   4:     return $content;

   5: }

   6: add_filter('the_content', 'addContent');

記事の頭に「ほげ」ってつけるプラグインです。。 まぁサンプルってことでごかんべんを。（笑 プラグインヘッダなどは省略です。

ここでは固定値「ほげ」を管理画面から設定できるようにしたいと思います。

とりあえず、こいつを「クラス」にします。 っていってもほぼ機械的な置き換えです。

可変にしたい部分をフィールド（メンバ）においているところと「コンストラクタ」で初期化しているところに注目してください。

   1: class example {

   2:     

   3:     var $header;

   4:     

   5:     function __construct() {

   6:         $this->header = "ほげ";

   7:     }

   8:     

   9:     function addContent($content) {

  10:         $content = "<p>{$this->header}</p>" . $content;

  11:         return $content;

  12:     }

  13:     

  14: }

  15: $example = new example();

  16: add_filter('the_content', array($example, 'addContent'));

$header 変数が外にいきフィールド（メンバ）になりました。

__construct は new ってやったとき(15行目)に勝手に動く特別なメソッドだと思ってください。（ちなみに PHP はコンストラクタもメソッド扱いらしい）

変数を初期化して、あとは WordPress からの the_content の呼び出しを待っているイメージのプログラムです。

さてここからが本題。

今回つくってみたフレームワークというのは DolphinPanel という名前のプログラムで、こいつをつかうとこの手のプラグインに管理画面をつけられます。 “Dolphin” にはなんら意味はないです。 たまたまエコーザドルフィンを思い出しただけです。。（古）

まずプラグインのあたまで、このプログラムを require してあげます(1行目)。 で、プラグインのクラスに dolphin のインターフェースを “implements” します。

まぁかくだけです。

   1: require_once('dolphin-panel.php');

   2:  

   3: class example implements Dolphinable {

   4:     

   5:     var $header;

   6:     

   7:     function __construct() {

   8:         $this->header = "ほげ";

   9:     }

  10:     

  11:     function addContent($content) {

  12:         $content = "<p>{$this->header}</p>" . $content;

  13:         return $content;

  14:     }

  15:     

  16: }

  17: $example = new example();

  18: add_dolphin($example, 'example');

  19: add_filter('the_content', array($example, 'addContent'));

implements Dolphinable したクラス(3行目)は Dolphin 管轄の WordPress 管理画面を持つことができます。 権利をもったクラスを add_dolphin します。（18行目）

さて Dolphinable であるためには 3つの管理画面に関する決められたメソッド（onActive、onBind、onDispose）が必要になります。 これを実装していきます。

といっても単純にテキストボックスをひとつつけて、値を保存したいだけなら onActive だけ実装すればいいです。 onBind には return true; 、onDispose は空実装してください。

   1: require_once('dolphin-panel.php');

   2:  

   3: class example implements Dolphinable {

   4:     

   5:     var $header;

   6:     

   7:     function __construct() {

   8:         $this->header = "ほげ";

   9:     }

  10:     

  11:     function addContent($content) {

  12:         $content = "<p>{$this->header}</p>" . $content;

  13:         return $content;

  14:     }

  15:     

  16:     function onActive(DolphinForm $form) {

  17:         $form->add(new DolphinTextBox('$header', 'ヘッダ'));

  18:     }

  19:     

  20:     function onBind(DolphinForm $form) {

  21:         return true;

  22:     }

  23:     

  24:     function onDispose() { }

  25:     

  26: }

  27: $example = new example();

  28: add_dolphin($example, 'example');

  29: add_filter('the_content', array($example, 'addContent'));

17行目が Dolphin のキモで、この書き方で変数（フィールド）と管理画面のテキストボックスを結びつけます。 HTML フォームとの値変換、変数へのバインドをこの記述だけでやってくれます。（配列渡すと複数テキストボックスがでてきたりします）

おしまい!。

なんだかここだけみると不思議かもしれませんが、このコードだけでめでたく管理画面がつきます。 簡単あるね。 もちろんプラグインはこの設定値で動きます。

一応、もうちょっといじるとユーザ対話などもできるようになっています。 追加処理を書くとこんな感じになります。

ここではサンプルだったので極力短くしていますが、onBind は値検査が必要な場合に実装するメソッドで、onDispose はプラグインが非活性になった場合に実装するメソッドです。 入力値に必須が入っていなかった場合のメッセージ出力や、プラグイン非活性時のデータベースからの削除などができます。

もうちょっと詳しいコメント付きサンプルと Dolphin のソースを JSeries の CVS にコミットしてあります。 気になる方は（いるのか?!）みてみてください。

http://sourceforge.jp/cvs/view/wppluginsj/dolphin-panel/

実は管理画面でつかえる HTML コンポーネントがまだテキストボックスとチェックボックスだけだったり実用にはほど遠いのですが、まぁプラグインのサービスクラスに管理画面の意識がなくなるのは楽かなと思います。 また、ここではサービスクラスにつけていますが、単純な VO のクラスに implements  して、上に親のサービスクラスをつくってプラグインを実装するのもいいかもです。

さて、お気づきの方もいらっしゃると思いますが、requre している関係でフレームワークとかいいつつクラス名称がかぶったりして、そのままだと Dolphinable な管理画面をもつプラグインがひとつしか作れなかったり、、、 namespace 使おうと思っても PHP 5.3 からだったりけっこう八方ふさがりなところがあったりします。

一応コントローラ自体は、ひとつで複数の Dolphinable を扱えるようにしているので、myhack.php とかにいれればいいんですが、もうないし（笑） __autoload とかで気合いで最新を読むような制御も考えましたが、hackish すぎるのでやめました。。 運用対処ということで（笑）

あとあと、PHP 5.3 じゃないと private プロパティがこじあけられないので、プラグインのフィールドは public にしてください。。 まぁスコープつけなきゃよいです。（お察しの通りリフレクションを使って変数をバインドしています）

というわけで、いろいろあって途中何度か企画倒れにしようかと思ったのですが、まぁせっかくつくったので話のネタに。 たぶんバグってると思うので、実用よりプログラム的な動きだけ楽しんでもらえればと思います。

このエントリ名に覚えがある方は hiromasa.* 通！（嘘）

あなたの深層心理を、なんとなく普段書いているブログからさぐりだす「あなたのブログは何ブログ？」。 前回はなんと 2006年。 3年ぶりにやってみることにしましょう（笑）

前回の記事はこちら。

hiromasa.zone ) » あなたのブログは何ブログ？

Masayan さんのところで、

自分でダメ出し < MMRT daily life

このブログを第三者的見方で見ると・・・何のブログ？

という興味深い記事が・・・。

うちもなんだろーと思い調べてみることに。 WordPress やってたり、夜ネタがあったり、ごはんうつしているときもあるし。。 いったいなんなんだろうか！

hiromasa.zone らしく”第三者”はコンピュータ。 自分の全エントリを形態素解析して、その品詞分類と頻出単語から探ってみることにしました。

説明すると、ブログの content のデータを形態素解析して、頻出する単語が何かを調べてみるという企画でした。

前回の結果は「:-)」が一番頻出という、、驚きの笑いっぱなしのブログであることがわかった hiromasa.zone でしたが、果たして今回はどうなるのか。（笑）

というわけで、前は chasen を使って形態素解析していましたが、今回は wp-jrelated に Yahoo! が解析してくれた結果があるのでこちらを使っています。

まぁ辞書が違うので前回との比較はあれなんですが、それはおいておきましょう。

とりあえずやり方ですが、以下のファイルを展開して WordPress の wp-config.php と同じディレクトリにアップロードします。（wp-jrelated プラグインが導入されていて、十分に辞書ができていることが前提となります）

summary-morpheme.zip

でブラウザから

http://another.maple4ever.net/summary-morpheme.php

とかって URL アクセスすれば結果がでてくると思います。 結果をみおわったら必ずこのファイルは消してしまってください。

もし画面が真っ白になったら残念。 メモリ不足です。 うちくらいのエントリ数なら大丈夫のようですが、だめな場合はローカルにデータインポートしてコマンドライン php からやるといいと思います。

てなわけで、結果発表です!

   1位	( 356出現)	WordPress
   2位	( 340出現)	ファイル
   3位	( 244出現)	Windows
   4位	( 238出現)	ぼく
   5位	( 236出現)	サーバ
   6位	( 194出現)	機能
   7位	( 179出現)	方
   8位	( 176出現)	設定
   9位	( 175出現)	イン
  10位	( 173出現)	画面
  11位	( 171出現)	画像
  12位	( 169出現)	プラグ
  13位	( 168出現)	Linux
  14位	( 153出現)	場合
  15位	( 152出現)	PC
  16位	( 150出現)	表示
  17位	( 142出現)	サイト
  18位	( 140出現)	php
  19位	( 133出現)	Web
  20位	( 131出現)	アプリ
  21位	( 130出現)	Ubuntu
  22位	( 129出現)	ソフト
  23位	( 128出現)	USB
  23位	( 128出現)	ここ
  25位	( 126出現)	ソース
  26位	( 125出現)	人
  27位	( 124出現)	自分
  28位	( 120出現)	インストール
  29位	( 119出現)	環境
  30位	( 117出現)	another
  31位	( 114出現)	hiromasa
  31位	( 114出現)	動作
  33位	( 113出現)	tegaki
  34位	( 112出現)	投稿
  35位	( 107出現)	起動
  35位	( 107出現)	記事
  37位	( 102出現)	それ
  37位	( 102出現)	対応
  39位	( 101出現)	感じ
  40位	( 100出現)	テーマ
  41位	(  99出現)	動画
  41位	(  99出現)	データ
  43位	(  98出現)	Eclipse
  43位	(  98出現)	タグ
  45位	(  96出現)	コード
  46位	(  95出現)	ブログ
  47位	(  94出現)	WP
  47位	(  94出現)	管理
  49位	(  92出現)	便利
  50位	(  91出現)	アプリケーション
  50位	(  91出現)	バージョン

以上から hiromasa.another はめでたく、

ということになりました。 うむ、そうだったのか（笑）

Ubuntu < Windows だったことに衝撃!!（ずがーん）をうけつつ 2009年度版「あなたのブログは何ブログ」でした。

意外な深層心理を発見(!?)できるかもしれませんので、jrelaetd を導入している方はおためしあれぇ。 プログラムをいじると名詞しばりを解除できたりしますので Yahoo! のくせをみるのもおもしろいでしょう。

ちなみに、この結果はストップワード作成とかにも役立つかもしれません。

WordPress + twitter なモブログをする方も増えてきて、ますます重要になる WordPress のファイルバックアップ。

コアとかプラグイン、テーマはサーバを直接修正していない限りローカル PC のどこかに残っていそうですが、wp-content/uploads とかの画像ファイルはオリジナルがなくなってしまうことも多そうです。

WordPress のブログデータの構成要素は、MySQL のデータと画像などのサイトにアップロードファイルとなりますが、ここは後者のファイルのバックアップお話。 MySQL のバックアップについては以前かいた以下の記事が参考になるかもしれません。

hiromasa.another ) » Blog Archive » WordPress の MySQL バックアップ

てなわけで、大抵のサーバは ssh の接続がサポートされていますので MySQL のバックアップ関連はこちらで操作するといいかもしれません。 まずは手動のシェル起動によるバックアップ、これがうまくいったら cron にこのシェルを登録してみます。

というわけで、お手軽にファイルもバックアップしたいよね、ということで UNIX の rsync + SSH をつかったバックアップを紹介してみます。 Windows でも cygwin とか使うとできるかもしれません。

rsync というのは、送り元先のファイルリストを確認して差分でシンクロしてくれる便利なアプリケーションです。

rsync – Wikipedia

rsync は、UNIXシステムにおいて、差分符号化を使ってデータ転送量を最小化し、遠隔地間のファイルやディレクトリの同期を行うアプリケーションソフトウェアである。類似のプログラムやプロトコルにはない rsync 独自の特徴として、ミラーサイトとの転送が双方向に高々1回で済む点がある。rsync はディレクトリ内容を表示し、ディレクトリやファイルをコピーできる。オプションでデータ圧縮や再帰も指定可能。

WordPress をレンタルサーバにインストールしているとして、、rsync が使える条件は、SSH が接続できることとサーバ側に rsync が入っていることです。 ぼくが使っているコアサーバではOKでした。（後述の siroica さんの記事によると XREA も大丈夫そうです）

また、バックアップ先のクライアントの PC でも rsync と SSH が使える必要があります。 Linux とか BSD とか、たぶん Mac OS X もできるのだと思います。 Windows でも cygwin とかつかうことでできそうです。

とりあえず、コアサバに SSH できる Ubuntu がお手元にあるとすると以下の感じでいけます。

先にファイルを転送する先の current というディレクトリをつくっています。（この名前はなんでもかまいません）

hiromasa@hiromasa-cube:~$ mkdir current

hiromasa@hiromasa-cube:~$ rsync -avz --delete [ユーザ名]@[サーバ名]:[バックアップディレクトリパス]/ ./current/

[実際のコマンド(参考)]

hiromasa@hiromasa-cube:~$ rsync -avz --delete another@s8.coreserver.jp:/virtual/another/public_html/ ./current/

rsync [オプション] [送り元] [送り先] が基本的な使い方です。 コアサバ –> ローカル PC です。

逆を指定すると悲惨なことになりますので十分注意してください。

特に –-delete という「消したファイルを消す」というオプションをつけている場合に、空ディレクトリを送り元にしてしまうと、送り先が空っぽになって真っ青になります。。

地雷だらけのrsyncを理解する。 – こせきの技術日記

–deleteは、DESTのディレクトリ指定を間違えると悲惨なことになる。SRCのスラッシュの有無も重要。

同期という技術の特性上、危険なパターンもあるので、よく理解した上で行ってください。

ここではコアサバの public_html 配下をローカルの ./current とういうディレクトリにもってきています。 wp-content/uploads などバックアップしたいところをピンポイントを指定するのも良い方法でしょう。

実行するとパスワードをきいてきますので、SSH のログインパスワードを入力します。

で、こんな感じでドヴァーとゴールドな感じでファイルが転送されてきます。（ファイル数が多いときは転送量に注意してください）

ファイル数が多いと時間がかかり、またコアサバの場合途中で切断されてしまう場合があるようですが、そのときは再試行してください。 差分でとってきますので、そのうち全部終わります。

sent 20 bytes  received 1158377 bytes  210617.64 bytes/sec

total size is 549995346  speedup is 474.79

こんなのがでたら転送完了です。

current ディレクトリ下をみてみるとファイルがきているのが分かると思います。 尚、この下のファイルは直接修正などしないほうが良いでしょう。（編集したいときは別な場所にコピーして使いましょう）

で、ある時期がたったらまた同じディレクトリ(current)があるところで rsync コマンドをうてば何も考えずに更新差分のみ取得できます。 この辺が FTP ではできない有利なところです。 backup.sh などのシェルスクリプトに rsync コマンドを記述しておけば間違えも少なくてよさそうです。

backup.sh

#!/bin/sh

rsync -avz --delete another@s8.coreserver.jp:/virtual/another/public_html/ ./current/

取得した current ディレクトリは圧縮して別途保存しておくと履歴バックアップになりますね。

なんてことをやっていると、cron で全部自動でやりたいなぁという欲求がふつふつと。 ということで、siroica さんが rsync + mysqldump + pdumpfs + cron でファイルとMySQL ダンプの自動履歴バックアップをする記事を書かれています!

XREAのサーバーに設置したWordPressを自動バックアップする環境を整える – SharpLab.

みんな大好きWordPress。だからこそ、データが飛んでしまうのはなんとしても避けたいもの。そのためには、常日頃からデータのバックアップを取っておくのが重要なのですが、いちいち手動でバックアップするのは手間なので、なるべく自動化しておきたいものです。バックアップしたいのは次の二つ：アップロードしたファイルとMySQLのダンプ。

玄箱などいえにローカルにサーバがある方は自動化にチャレンジしてみると良いかもしれません。

ぼくが WordPress で好きな機能の一つに「メディアライブラリ」があります。

ブログの投稿と、その投稿内にある画像や音声などのメディアのひも付けを行ってくれるまっことに便利なもので、wp-kougabu もこの機能を使って画像の抽出、またそのリンクから本文にとばすようになっています。

メディアライブラリは、、2.0 くらいから本格的に入ってきた機能でしたでしたか（失念）。 以前の WordPress はこの機能がありませんでしたので、実は導入前のコアからの投稿や、またプラグインの機能でのアップロードを行っていると画像がメディアライブラリに入っていないという問題がでてきます。

世紀の荒技でkougabuを動かす – MMRT daily life

・・・ことでした。そうです、IImage-Browser愛好家だったので、登録できていないのです。

そう、、Masayan さんは今回すべての画像を後からメディアライブラリに登録したのです。 勇者であります!!

WordPress 2.9 くらいからまたメディア機能の拡充が図られそうな雰囲気なので、おさらいもかねてまずは現状の動きをみてみることにしました。

まず記事を書きます。

で、アップロード/挿入の一番左のアイコンを押下。 で、アップロードするファイル選択。 フラッシュアップローダをつかうとファイルを複数選択できます。

ここでは 5 ファイルアップロード。

画面を閉じずにメディアライブラリを別画面でみてデータベースの状態がどうなっているかみてみました。

一番右のカラム「リンク先」に記事名が入っていれば”くくりつき”が成功している証拠です。

「メディアライブラリの試験」とちゃんと入っています。

実はどうもぼく間違っていたみたいで、上の子画面の「挿入」ボタン押下のタイミングでくくりつけやっていると思っていたのですが、アップロード直後に行われているみたいです。。 ごめんなさい。。（たしか以前動かしたときそう見えたのですが、変わったか勘違いだったのかも。。）

さて、ここで話は派生。

ファイルのアップロードですが、おそらく多くの皆さんは管理画面の設定で「アップロードしたファイルを月日ベースのフォルダに格納」をしていると思います。

これは今日(2009/9) に行ったアップロードは 2009/09/ フォルダにはいることになりますが、たとえば過去記事の修正を行った場合にもアップロード当日フォルダにはいってしまうことになります。 これだと何かで手管理する場合に混乱する可能性がありますね。

（訂正）現在これはやらなくてもちゃんと過去フォルダに入るみたいです。

そんなときはワンショットプラグイン。 ということで、アップロードフォルダを強引に疑似ってしまうプラグインをつくりました。 簡単なものですが、つかう方がいたらどうぞ。

wp-back2future-1.0.zip

パッチを有効にするにチェックを入れて日付をいれておくと、いつアップロードしても指定日付フォルダに格納されます。 適当プラグインなので、使い終わったら削除しておいてください。。

てなかんじで、記事とくくりついた５つの画像。

まぁ普通ならこの後記事内にアップロードしたファイルの URL を記事の任意の位置に挿入するわけですが、メディアライブラリ機能をみるために gallery ショートコードを使ってみます。 上のタブにギャラリーってあるので選択します。

で、「ギャラリーを挿入」ボタンを押下。 こんな感じになります。 記事中に画像の URL の記述がが一切ないことに注目してください。

投稿してみます。

アップロードした画像がでてきました。

（ちょっとこの例は CSS いじってないのでだっさいですが）このように gallery ショートコードは投稿からくくりつく画像を勝手にとって URL を展開してくれます。

実際のところ gallery ショートコードさんは、サムネイルが img タグ伸張だったり、正方形固定だったりちょっと個人的には使いにくいのですが、まぁまぁメディアライブラリの機能のデモとしてはわかりやすいですね。

投稿と画像のつながりが分かっていないと実装できない機能のひとつです。 大量の画像をドヴァーと入れたいときにはお手軽で便利でしょう。

さてさて、WordPress の管理画面にはメディア –> 新規追加という画面があって、投稿とは別の世界でファイルをアップロードすることができます。 やってみましょう。

してみました。 これをメディア –> ライブラリからみてみると・・・。

当然「リンク先」がついていません。 記事とくくりつかない浮いた画像となっています。

これをさきほどの投稿につけてみます。 投稿を開きアップロード画面へ。

いつもは「コンピュータから」を選んでいるところを「メディアライブラリ」タブにうつります。 アップロードした画像が見えますね。

表示するを押します。

一番下の「投稿に挿入」を押下します。（今度は挿入をおさないとダメ）

投稿下部に自動で URL がはいりました。 でも実は URL は、便利なように入っただけでメディアライブラリ的くくりつきとは無関係。 「投稿に挿入」を押したところでメディアとの関連はとれています。

じゃーってことで、記事内の画像 URL をけずって publish!

gallery ショートコードにちゃんと認識されました。（記事と関連付いたということですね）

そうそう今回の例は管理画面からやっていますが xmlrpc 経由の投稿でも同様の動作をします。 でもなんか実は 2.8.0 くらいからバグってくくりつけがうまくいってないみたいなので、該当だったら以下を見てください。

hiromasa.another ) » Blog Archive » WordPress 2.8 の xmlrpc 経由の投稿で記事とメディアの関連がつかない場合

そんなこんなで、twitter をのぞいていたら 2.8 以降の投稿で wp-kougabu の画像がでてこないという話がちらほら。なんかやらかしたかと思ってみてみたら、どうも kougabu じゃない模様。 コアの不具合なのか、xmlrpc 経由の投稿だと記事とメディアがくくりつかない現象がでているようです。

こんな感じでメディアライブラリ機能はなかなかおもしろいです。 画像の他にも .mp3 ついていたら RSS に enclosure タグがついてポットキャストになっていたり、いろいろいじっていると意外に知られていない機能を発掘できるかもしれません。

ためしてメディアライブラリ

･･･がってん、がってん、がってん、がってん。。

WordPress Related Post for Japanese の 1.52 をリリースしました。

1.50 における Yahoo! API の URL 変更に伴うエントリポイントの変更で旧バージョンからアップデートしたさいに正しく URL が更新されない不具合の修正です。 条件にあたってしまった方は、現在関連がとれなくなってしまっていると思いますので、バージョンをあげていただければと思います（すいません）。

WordPress Plugins/JSeries » WordPress Related Post for Japanese (関連投稿表示プラグイン)

2009/09/15 にバージョン 1.52 にアップデートされました。

バージョン 1.50 において Yahoo! API のエントリポイント URL 変更を行っていますが、アップデートプロセスの不正によって旧バージョンからのアップデートの場合 URL が正しく変更されませんでした。 条件にあたる方は関連の取得ができなくなっていますので 1.52 にアップデートお願いいたします。

また、記事中に実体参照が含まれる場合に解析エラーが発生し、関連がうまく取得できない場合がある不具合も修正されています。

をかもとさんから先日いただいておりました、実体参照文字列がある場合のレスポンスで XML パースエラーがでる場合があった不具合の修正もマージさせていただいています。 ありがとうございました。

もし最近とれない記事があった場合はプラグインをアップデートした後に、管理画面から「閲覧時」にチェックをいれて、何度か該当記事のシングルページにアクセスしてみてください。 そのうち再取得されると思います。

尚、過去ログの関連がすべて取り終えている方は、ここのチェックをハズしておいた方がいいです。 処理的に 1 クエリー得します。

—-

以下余談。

先日から .another でも関連がとれなくなっていて、おかしいなぁとおもいつつ、他の方もとれていたりとれていなかったりで、原因がぱっと思いつかず困っていたのですが、今日重い腰を上げてみてみたところ、思いっきりバグってました。。 すいません。。

ぼくの管理画面付きのプラグインは、業務ロジックのオブジェクトをシリアライズしてそのまんま (wp_)options に保存して実装されているのが多いのですが（要はメンバがオプション値）、前回 URL のメンバ変数の初期設定を変えたときに、オブジェクト・アップデートロジックに URL の変更を忘れていたのが不具合の原因です。 とほほ。 （なので新規インストール時は大丈夫でした）

さて、このプラグインって投稿時のレスポンスを落とさないようにバックグラウンド非同期(wp-cron)で Yahoo! に問い合わせにいくようにしているのですが、解析に「重い腰」というのはここでした。

いつもならデバッガでブレイクして、鼻歌交じりに「あぁここ」と思って修正完了なのですが、非同期の場合は別セッションで動くためデバッガが使えないのです。 じゃーログファイルデバッグ、という手もあるのですがどうも wp-cron 中にあまりに長い処理を動かすと、PHP に途中でぶったぎられてしまうこともあるようでうまくありませんでした。

ということで、動機側に処理をまずもってくる。。 管理画面に post_id 指定でとれるよう項目を新設。

で、デバッグブレイク。

こんな感じで１行ずつ処理を追っていきます。 たまに変数を確認。

こんな感じでみれるでありますね。

PHP のデバッグについては、以前かきましたので興味のある方はどうぞ。

hiromasa.docs ) – Eclipse PDT + XAMPP で WordPress の開発環境をつくる (3)

Eclipse PDT と XAMPP に入っている xdebug モジュールを利用すると、実行中のプログラムを任意の位置で停止させ、ソースコードとあわせて１行ずつ動作させるステップ実行や、変数の値の監視や書き換えが行えるウォッチなどのいわゆるデバッグ機能を使うことができるようになります。

せっかくなのでPHP デバッグ (XDebug) のちょっとしたコツを。

WordPress の管理画面など cookie 認証を伴う場合に、デバッグセッションがうまくつながらなくてブレイクできない場合があります。 そんなときは以下のようにするととまってくれます。

まず、デバッガの設定でログイン前の画面にデバッグエントリポイントを指定します。 WP だとトップの index.php あたりに。

「File」の部分がワークスペース上のパスで、「URL」がブラウザでアクセスしたときのパスです。 ここの対応キモ。 あっていないとブレイクしないので、よく確認します。

で、デバッグスタートさせると WP のトップが表示されますが、このときブラウザに表示された URL の引数をどっかにコピペしておきます。

http://127.0.0.1/wp/wordpress-28y/?XDEBUG_SESSION_START=ECLIPSE_DBGP&KEY=12530144423293

この ? 以降をとっておいた上で、WP の管理画面にログインして、ブレイクの張ってある画面にたどりつきます。 ブレイクしましたか？

もしもしなかったら、その画面の URL のおしりに上でとっておいた ? 以降の引数をつけてあげましょう。 これでとまるとおもいます。

動きしか見てないですが、たぶん WP の認証によりデバッグセッションの cookie がきえてしまうのがとまらない原因です。 なので GET でつけてあげて再設定すればこの後は何もしなくてもとまるようになります。

てなかんじでデバッガでウオッチしてたら、URL に古いエントリポイントがでてきたというかなり、とほほな結末でした。

wp-jrelated-debug-1.52.zip

なくしそうなので、管理画面から同期取得できるバージョンもおいておきます。 wp-jrelated/debug/ ディレクトリをつくっておくとログファイルもかくようにしています。 （ちゃんとバリデーションとかしてないので本番では使わないでください）

という感じでした。（←オチを考える元気がなかった

Nao さんが PHP カンファレンスの質疑の時に、「wordpress.com では memcached が使われている」ということを言われているのをふと思い出し、ためしにぼくも WordPress に memcached を適応してみようとやってみました。

といっても memcached が動いているレンタルサーバはないと思いますので、実際に利用できるのは専用サーバ使われている人になるとおもいます。 ぼくはちょっとローカルで試してみただけですので、その辺はご容赦ください。。（笑）

とりあえず、memcached。

memcached – Wikipedia

memcached は、汎用の分散型メモリキャッシュシステムである。

もともと Danga Interactive によって LiveJournal サービスのために開発されたが、現在は多数のサイトで利用されている。memcached は、データとオブジェクトをメモリ内にキャッシュすることでデータベースから読み出しを行う回数を減少させ、データベースを用いた Web サイトを高速化するために良く用いられる。memcached はpermissive free software licence によりライセンスされている。^[1]

高スケーラブルが要求される、Web サービスでよくつかわれているメモリキャッシュの実装です。 たしか mixi も使っているとどこかで読んだきもします。

memcached の WordPress の適応範囲は、SQL のクエリキャッシュのような感じで使われ、MySQL への負荷をさげ、同一参照に関してはメモリ内のキャッシュを返すことで動作を速くすることです。

（注意） wordpress.com で実際に行っていることは分かりません。 おそらくは似たこともやっていると思いますが、いろいろ追加チューニングしていると思います。

ここで使ったのは WordPress コアに付加できるようになっている object-cache.php の一つで、以前をかもとさんが動かされていたファイルキャッシュの memcached 版ということになります。

WordPress サイトのパフォーマンスチューニング (4) : dogmap.jp

さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、File-Based Extension to the WordPress Object Cacheなるモノを発見。

DBアクセスせずにファイルアクセスで、済ませてしまおうという仕掛けです。
要はコレ、WordPress 2.5.x 以前にあったオブジェクトキャッシュを、2.5.x 以降のバージョンでも使えるようにしてしまおうというものです。

てなわけで、とりあえずローカルの Ubuntu に memcached をインストール。 これは簡単。

sudo apt-get install memcached

でもって、PHP に memcached クライアントをインストールします。 ぼくは Ubuntu の XAMPP なので以下のようにしてモジュールをコンパイルします。(xampp-dev とか gcc とか autoconf とかは事前に入れておくのこと）

モジュールは以下にあります。

PECL :: Package :: memcache

memcache-2.2.5.tgz (35.1kB)

現時点 2.2.5 が stable だったのでこれをダウンロードしてどこかに展開。

ダウンロードしたソースフォルダに cd した後、

/opt/lampp/bin/phpize

./configure --enable-memcache --with-php-config=/opt/lampp/bin/php-config

make

sudo make install

sudo vi /opt/lampp/etc/php.ini

 extension="memcache.so" ←行追加

sudo /opt/lampp/lampp restart

これでOKです。 Apache リスタート後、phpinfo で読まれていることを確認します。

できたら、object-cache.php をダウンロードして wp-content/object-cache.php に配置します。

/memcached/trunk/ – WordPress Plugin Repository

object-cache.php

ちなみに Authoer は、

Author: Ryan Boren

Ryan さんですね。

てなかんじで、これで準備完了です。

ローカルにおいてある .another のトップページを表示してみました。 まずは、一回目。

17 queries. 1.987 seconds.

これでキャッシュしたハズなのでもう一度トップにアクセス。

4 queries. 1.020 seconds.

ぶはは、４クエリ（笑）

ちなみにこのローカルは、PHP の debuger とかプロファイラ等いろいろいれていおり MySQL 以外の部分が元々遅く、ちゃんとチューンしたサーバをつかえば相当速い速度がでそうです。 あと MySQL の負荷が高いときにはさらなる威力を発揮するでしょう。

さて、一応いくつか動作確認はして大丈夫そうでしたが、まぁまぁキャッシュ技術の特性上不具合もでやすいと思いますので、もしも本番運用する方がいましたら老婆心ながら試験は十分に･･･。

プラグインから発行される SQL なんかは object-cache 対応していないものがおおいので、そのへんのチューニングも含めてアクセスの多いサイトでは試してみるのもおもしろいかもしれません。

というわけで、番外編に続きデジカメ画像が届きましたのではるのであります!。。。

hiromasa.another ) » Blog Archive » We Love WordPress in Susukino (番外編)

日本の WordPress ユーザの間で “We Love WordPress” というロゴがはいった写真をとろうじゃないかと、ちょっとしたブームになったのが 2006年。

てなかんじで。

来年もまた撮れますように。