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年。

てなかんじで。

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

いきなり番外編から始まる、We Love WordPress。

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

あれからはや３年。 たとえば、Masayan さんのところ。

WE LOVE WORDPRESS No.1

[左] 会社の入り口にかけられていました。本日休業と違うのねん。

[右] 裏に回るといろんな廃棄物が・・・。おお、こんな風に汚れるとは芸術的。

すばらしい。 なんとその数、No.17 まで続けておられます!

WE LOVE WORDPRESS

我が hiromasa.* 系では、団扇 + 浴衣で毎年撮影。 今年もその方向性、ひとつもかわらず（笑）

舞台裏を明かすと、撮影は毎年「すすきの祭り」と呼ばれる繁華街すすきので行われるお祭りで行われています。 といっても基本的に飲んでいるだけなんですが（笑）

すすきの祭りは、いわゆるすすきの区画の道路を封鎖し、歩行者天国を構成した上でそこにステージや屋台をだして行われます。

という感じで、外の屋台でのんだりたべたりできる寸法です。 ステージもいろいろイベントやっていてにぎやかであります。

hiromasa.another presents We Love WordPress 番外編。

なんで番外かというと携帯電話で撮影した写真だからです。。 デジカメ高画質版はややあとにて。

浴衣はよいものですなぁ。

少し検索すると、往年のみんなの We Love WordPress 写真がでてくるとおもいます。 超かわいーのもありますゾ。

そんな感じで、We Love WordPress、思い立った方、撮影してはいかがでしょうか。 トラックバックとかもらえるとうれしいなぁぁぁ。

なんだかリリースお知らせばっかりですが（笑）、wp-kotodama と wp-kyodeki を JSeries のほうにリリースしましたのでお知らせします。 いわゆる Recent Comments と、Todays Popular を表示する WordPress 用ウィジェットプラグイン２種類です

kotodama は旧 widget、kyodeki は新 widget の仕組みをつかっていますので、ソースが気になる方はみてみてください。 せっかくなのでここで新ウイジェットの仕組みとかも書いてみます。

WordPress Plugins/JSeries » wp-kotodama (投稿コメント表示ウイジェット)

サイドバーなどに、最近投稿されたコメント者名とその親記事へのリンクを出力するウィジェットです。

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

サイドバーなどに、本日人気の記事表示の一覧とそのアクセス回数を表示するウィジェットです。

wp-kyodeki で既に .another リリース版をおつかいの方は、上書きしていただければと思います。 パスワード付き投稿も集計対象にしていたのを修正しています。

wp-kotodama のほうは修正ありませんのでそのままでOKです。

なお両方ともウイジェットといいつつテンプレートタグでも動作できます。

kotodama_get_comments($limit = 7, $gravatar = false, $size = 18)

the_kyodeki($count)

それぞれ関数定義はこんなかんじなので、<?php kotodama_get_comment(); ?> とか <?php the_kyodeki(); ?> とかをテーマ内にかいてあげれば、ウィジェットないテーマでも使えます。 引数はのりでかいてください。

さて、WordPress の Widget システムですがご存じのように 2.8 からつくりかたが変わっています。 ホントは古いつくりかたの kotodama のほうを新しくかきなおそうかとおもったのですが、コアの新旧変換ロジックもおもしろいのでそのままにしました。

新と旧ウィジェットシステムの大きな違いは、マルチウィジェットのかきやすさです。

kotodama はどこかひとつ配置したらもう配置できません。 kyodeki ではいくつでも配置できるのが分かると思います。 また同一ウィジェットで、配置によって異なる各設定も別に保持できます。

旧ウィジェットシステムではマルチしたい場合は、自分のプログラムでマルチになることを意識してかかなければならずで結構大変だったのですが(kotodama はしていません)、新ウィジェットシステムでかくと何もせずともマルチの制御をシステムでやってくれるようになっています。

ちらっと仕組みを書くと、新ウィジェットシステムは、クラスの継承を行う形で処理をかくのがキモです。 extends WP_Wiget ってやつです。

クラスの継承というのがよくわからない方は、コアにある WP_Wiget の中身（結構長いぜ）を全部コピペして自分のソースにはりつけたと思ってください。 コピペはあんまりなので extends ってかくだけでOKなようになってると思ってもらえれば、とりあえずは正解です（笑）

WP_Wiget にはウイジェット状態維持（配置場所やオプション）、その他管理画面の入出力が便利なようにする処理がはいっていて、自分がしたい処理の部分だけ書き換（オーバーライド）すると簡単に WordPress のウィジェットとして成立するようになっています。

で、ここからはクラスの妙。 クラスは定義するだけでは動作はせず、インスタンスというものをつくる必要があります。 これは言葉がめんどくさいだけで、実質的には構文で「new クラス名」ってかくだけなのですが、これをやってくれているのは今回から WordPress のコアです。

インスタンスはひとつのクラスの定義から複数作成することができます。 振る舞い（メソッド）は同じだけど、値が違う・・・。 まさにマルチウィジェットです。 必要時に必要な数だけ WordPress が該当ウィジェットを new してくれるので、こっちは考えなくてもマルチになってくれるという寸法です。

うーん、オブジェクト指向でよくある「車クラスを継承してカローラクラス」をつくります。 なんて説明よりなんて実践的（笑） 実際のところオブジェクト指向のとっかかりとしては、継承の感覚（さっきコピペっていったところ）より、ひとつのクラスから複数のインスタンスがつくれる感覚の方が、実例がないとつかみづらいですよね。 カローラは大量生産できるのです。

というわけで、オブジェクト指向まで勉強できちゃうすてきな WordPress の巻でした。

画像付きアーカイブを作成する WordPress プラグイン wp-kougabu 1.10 を JSeries のほうにリリースしましたのでお知らせします。

変更点は、画像のアスペクト比率維持モードの搭載と、処理の高速化です。 1.00 をお使いの場合は上書きしていただければと思います。 images 内のフレーム画像も増えていますので、忘れずにアップロードしてください。

1.01 プレビューをお使いの方も、いただいたレポートを元に、途中 CVS でいくつか変更していますので念のため上書きしていただけると助かります。

ダウンロードは JSeries よりです。

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

WordPress の投稿やページにアップロードされた画像ファイルを抽出し、サムネイルでページに一覧表示するショートコードを提供します。過去に投稿した画像をサイトに一覧表示しそこから本文にリンクされる、画像付きアーカイブのようなプラグインです。

アスペクト比率維持モード搭載により、画像サムネイルが若干かわっています。 1.00 の方は現在あるキャッシュが優先になります。 wp-content/cache/wp-kougabu 内部のファイルを一度削除すると新画像になります。

いままでの表現でかまわない方はキャッシュ削除は不要です。 次回の生成からアスペクト維持モードで生成されます。 混在を嫌う方は、wp-kougabu-resize.php の先頭行を以下のように変更してください。

//define('KOUGABU_FRAME_NAME', 'nashi');

//define('KEEP_ASPECT', true);

//for version 1.00 compatible

define('KOUGABU_FRAME_NAME', 'maru');

define('KEEP_ASPECT', false); 

これで表現はいままで通りの引き延ばしになります。 1.10 の高速化（といっても体感ほとんど分からなそうですが）だけ対応されるです。

さてさて、次期 WordPress 2.9 はメディア機能がパワーアップするようですね!

WordPress | 日本語 » 2.9 メディア機能のアンケートに投票を！

先週の水曜日、コア開発チームと多くの貢献開発者が IRC の #wordpress-dev チャンネルに集まりました。このチャットの目的は、現在開発フェーズに入りつつあるバージョン2.9に含める機能について話し合うことでした。2.9ではメディア関連の機能（訳注: 画像・動画・音声他のファイルアップロードや管理など）に集中することを計画してきており、予想通りメディア関連の機能についての話題が大半を占めました（*注）。

まだ予定は未定と言うことですが、

メディアメタデータ (Media Metadata): メディアファイルに対してカテゴリーやタグを指定できるようにします。

投稿サムネイル (Post thumbnails): 投稿・記事・抜粋と共に表示する画像を選べるようにします。

とかいいですね～。

メディア機能はぼくも好きな機能のひとつなのでどうなっていくのか楽しみです。

画像アーカイブプラグイン wp-kougabu 1.01 と、いわゆる Todays Popular な記事の一覧を表示する新しいプラグイン wp-kyodeki をつくってみたので、とりあえずここでプレビューリリースしてみます!。

まず、wp-kougabu ですが、処理で遅い部分があったのの修正と、サムネイル画像のアスペクト比率がくるっていたのをなおしています。

wp-kougabu.tar.gz (CVS HEAD)

いま kougabu をお使いで、試験してみたい方はいれてみてください。 キャッシュを削除すると新形式で画像が作成されます。

こちらが新サムネイル形式です。 左右に灰色がでているとおもいますがこれが比率がくるっていた部分です。 現行版は引き延ばしていました。

(2009/07/13 追記)

うちの専属デザイナー（勝手に専属化。。）から、それなら内枠があるのはへん(?) という指摘がありましたので、対応しました!

うむ、よい。 ついこんもかわいくなりました。

比率維持時は内枠を消すように修正して、CVS HEAD にコミットしてあります。 images の画像も増えていますのでこちらもアップロードしてください。

また、現行版の”画像いっぱいモード”も define で選択できるようにしています。

/******************************************************************************

 * WpKougabu Resize - Define

 *****************************************************************************/

//for version 1.00 compatible

//define('KOUGABU_FRAME_NAME', 'maru');

//define('ASPECT', false);

define('KOUGABU_FRAME_NAME', 'nashi');

define('KEEP_ASPECT', true);

現行版の表現の方が好みの方は、wp-kougabu-resize.php の上２行のコメントアウトをはずして、下２行をコメントアウトしてください。 で、うえの ‘ASPECT‘ ってなっているのは、KEEP_ASPECT に修正してください。。（まちがえです、リリース版では修正しておきます）

(2009/07/13 追記おわり)

また、wp-kougabu にはキャッシュを作成する非同期側と本体側とで通信をするためのデータが処理上存在するのですが、この容量が大きくなって処理を重くする可能性があったため改善しています。 こちらはいれるだけで機能します。 キャッシュの削除は不要です。

つぎ、wp-kyodeki のほうですが、現在うちのブログの右サイドバーにでている、「本日アクセス数の多い記事一覧」を出力する widget です。

いままでは bsuite プラグインで出力していたのですが、term 系のテーブルに reffer 情報などをアクセスごとに書き込む動きがあったため、アクセスごとにテーブルレコードが増える可能性がありました。

まぁまぁそれは仕様なのでよいのですが、ぼくの場合は本当に Todays Popular の出力だけを使いたかったのでちょっと余計。。

というわけで、いいかげんですがコンパクトな処理のものを自分でかいてみました。

wp-kyodeki.tar.gz (CVS HEAD)

widget “表示時に”カウントする仕組みをとっています。 また、Today だけなので翌日にはそのデータは捨てる仕様です。 なのでデータ増加はその日の範囲内だけになります。

一応、プログラムは新 widget 形式対応にしてみました。 これによりマルチ widget もいけますが、アクセス解析はひとつなのですべてに同じデータが表示されます。 別にしたらかっこいいかな、とも思いましたが使い道なさそうなのでやめました。。（笑

WordPress にログインしている人のアクセスはのぞきます。 その他はボットなどのアクセスもそのままカウントしますし、同一 IP からの連続アクセスも複数としてカウントします。 ありありルールです。 まぁ１日の範囲なのでちょっとしたランダムポストみたいなイメージです。

また、widget 使っていない場合はテンプレートタグが使えます。

<?php the_kyodeki(6); ?>

とテーマにいれると同様のものが出力されると思います。（こちらのパターンは hiromasa.zone のほうに試験をかねて導入してみました）

kougabu & kyodeki とも CVS HEAD リリースです。 もしいれてなにか変なところあったら教えてください。 コミットしておきます。

とりあえず、今日は前から気になっていたところの修正からでした。。 もっとお休みがほしいであります。（笑）

WordPress 2.8 リリースということでみなさん続々とアップデートされていますね!

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

記事とメディアのくくりつけは管理画面のメディアライブラリでみることができます。

ちょっと小さくて見づらいですが、”リンク先” という項目があって記事名がでているのが見えていると思います。 これがでているメディアは、記事が結びついているということになります。

wp-kougabu を使われている方は気がつきやすかったのですが、どうも 2.8 で xmlrpc 経由で投稿するとうまくこのリレーションが結びつかないようです。 実際には、(wp_)post テーブルの post_parents という項目で制御されています。

なんでだろーとおもって、xmlrpx.php を追っていく。 と、

$post_id = –1;

動きとしては、まず post_parents を –1 の未確定状態として画像を (wp_)posts に登録して、その後のシーケンスで –1 になっているものを探して、記事の id で post_parents を上書きするようになっています。

だがしかし、(wp_)post をみると 0 で登録されているのです。 なぜ？

ふと、(wp_)posts テーブルの DDL をみてみると、

CREATE TABLE wordpress_28x.wp_posts

(

    (略)

    ID                          BIGINT UNSIGNED NOT NULL,

    post_parent                 BIGINT UNSIGNED NOT NULL,

    (略)

)

ありゃ、UNSIGNED になっていますねぇ。。 これでは –1 は入りません。

というわけで、超ハックコードですが直し方。

xmlrpc.php を –1 で検索して、それを 999999 とかにしてください。（コメント含めて 3カ所）

とりあえず、なおるとおもいます。。。 このコードはいんちきなので、緊急避難という扱いでお願いいたします。

しかしながら xmlrpc 的にはこのへんあんまり変わってないぽいんですよね、、、なんでいままで動いていたか追う元気はありませんでした。 原因も間違ってたらごめんなさい。

2.8 ではデータベースのフィールドをみて SQL を組み立てるようになっているのですが、そのへんとからんで潜在的な不具合が出たのかもしれません。

trac みてないけどもうあがっているかな･･･。 xmlrpc 投稿をしている方はみてみてください～。

この投稿がうちのギャラリーにでてばとりあえずは、直ったということで。（ほんとにとりあえずですが。。

あとあと、これはまったく別件ですが、xmlrpx 経由の投稿でタグが削れるという環境的な問題が起きている方は Toru さんのエントリが参考になります。 (今の xampp が該当かもしれません

さくら＋WordPressでHTMLタグが消えるバグ « Waviaei

Vistaを入れ直した際に、最近使い始めてたWLWな再インストールしたんですが、ローカルからサーバへ投稿した時になぜかHTMLタグの<や>が取り除かれると言う不具合が。再インストールが原因とも思わなかったけど、原因が分からずアンインストール。

しかしその原因と対策方法がようやく分かりました。

PHP がつかっている libxml2 ライブラリの問題ですが、以下のプラグインをいれると解決することができます。 Toru さんありがとうございました!

WordPress › LibXML2 Fix « WordPress Plugins

Work around for some versions of libxml2 2.7.x that strip out brackets when parsing XML. This plugin fixes XML-RPC requests that are mangled because of this problem. The real fix for this (making the use of this plugin unnecessary) is to use PHP 5.2.9+ with libxml2 2.7.3+.