WordPress のメディアライブラリ機能

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

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

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

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

メディアライブラリに画像が一枚もない!

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

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

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

まず記事を書きます。

media01

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

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

media02

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

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

media03 

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

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

さて、ここで話は派生。

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

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

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

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

wp-back2future-1.0.zip

media04

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

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

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

media05

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

media06

投稿してみます。

media07

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

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

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

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

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

media08

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

media09

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

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

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

media10

表示するを押します。

media11

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

media12

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

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

media13

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

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

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

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

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

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

・・・がってん、がってん、がってん、がってん。。

wp-jrelated 1.52 リリース (関連取得不具合修正)

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 パースエラーがでる場合があった不具合の修正もマージさせていただいています。 ありがとうございました。 🙂

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

jrelated01

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

—-

以下余談。

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

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

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

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

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

jrelated02

で、デバッグブレイク。

jrelated03

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

jrelated04

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

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

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

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

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

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

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

jrelated05

「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/ ディレクトリをつくっておくとログファイルもかくようにしています。 (ちゃんとバリデーションとかしてないので本番では使わないでください)

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

WordPress の memcached による高速化

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 で読まれていることを確認します。

memcached

できたら、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.

ぶはは、4クエリ(笑)

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

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

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