WordPressのTransients APIで有効期限付きのデータを保存する。

前回の記事で紹介しているプラグインでは、FacebookのURLリンターというページにfile_get_contents()でアクセスしてキャッシュを更新しているのですが、エラー処理についてtwitterでアドバイスを頂きました。

@miya0001 wp_remote_get() を使えば、URL送信の成否確認も楽々やで。 http://dogmap.jp/2011/04/26/wp_remote_get/
@wokamoto あっ、でもsave_postの時のエラー処理ってどうやるのがベターなんですかね。警告とかって出せるのですか?処理を止めるほどのエラーではないので警告程度に留めたいのですけど。
@miya0001 この辺使えば、管理画面に警告メッセージ出せるんでは無いかな? http://www.wprecipes.com/how-to-show-an-urgent-message-in-the-wordpress-admin-area

twitter APIの不具合でリンクが切れちゃいますが、admin_noticesというフックで管理画面に警告を出せるそうです。

How to show an urgent message in the WordPress admin area

でもこれが意外と一筋縄ではいきませんでした。

WordPressではsave_postフック後にリダイレクトしてしまうので、admin_noticesフックに放りこんでも意味が無い…

一時的なデータにフラグを保存して、リダイレクト後にadmin_noticesフックをコールする必要があります。

@miya0001 そっか、リダイレクトされちゃうもんね。そしたら、set_transient(), get_transient() と組み合わせれば良いかもだよ。制限時間を付与して、update_option(), get_option() してくれる関数。

おー、Transients APIなどというものが!

これを使うと有効期限付きの一時データを保存することができるそうです。

Transients API – WordPress Codex 日本語版

この関数のソースはwp-includes/functions.phpにあって、ざっと眺めてみると有効期限のデータとset_transient()で指定されたデータの二つをadd_option()して、get_transientの時に有効期限外なら削除という処理をしているようです。

キャッシュ系のプラグインでスピードアップされるので、twitterやGoogleなどのAPIから取得したデータを保存するとか、重いSQLの結果を保存するとか、そういう時に威力を発揮しそうです。

$autoloadがnoになってるので、キャッシュ系のプラグインを使用するとスピードアップするけど、使ってないときにはクエリーが一回増えるということかな?

へー、上手く考えてありますね。

まとめ

  • wp_remote_get()を使うと外部へのリソースにアクセスするのが楽になる。
  • admin_noticesフックを使うと管理画面でエラーメッセージを出せる。
  • Transients APIを使うと有効期限付きのデータをオプションに保存できる。

保存の際にfacebookのクローラーを再度お招きするWordPressプラグイン

Facebookではlikeボタンをクリックした時などにクローラーが攻めこんできてコンテンツをキャッシュします。

そのため、タイトルなどを後から修正しても、修正結果が反映されません。

しかし、Facebook謹製のURLリンターというツールでURLを送信するとクローラーがもう一度来てくれて、キャッシュを再生成してくれます。

そこで、WordPressのsave_postでフックして、URLリンターにURLを送信するプラグインを作りました。

  • 単なる手抜きですが、URL送信の成否に関する評価は一切しておりませんので、あしからず。
  • facebookのドキュメントではURLの末尾にformat=jsonとありますが実際のレスポンスはhtmlです。

Enhancing CSS 1.2 & Enhancing JS 1.0

以下の二つのプラグインをアップデートしました。

http://firegoby.theta.ne.jp/wp/enhancingcss

http://firegoby.theta.ne.jp/wp/enhancingjs

修正内容

WPMLなどの一部のプラグインでは、home_url()へのフィルターフックでURL末尾にクエリー文字列を追加することがあります。

これらのプラグインと併用した際に、今回アップデートしたプラグインが出力するCSSやJavaScriptへのリンクが切れてしまう不具合を修正しました。

具体的には、home_url() としていた部分を get_option(‘home’) に変更することで、フィルターフックを回避しています。

この対処方法は、ちょっと気持が悪いのですが…もっといい方法があったらアドバイスください。

WordPressのadd_action()の使い方について教えてもらった。

今、新しいプラグインを作ってるのですが、以下のような疑問が湧きました。

そこでadd_action()の使い方について、WordPressのおじさんたちに質問をしてみました。

事前に女子高生じゃないと親切にしてもらえないという情報を得ていたので、女子高生と名乗って質問しました。

@odyssey @wokamoto @jim0912 女子高生の初心者ですが質問です。これはどっちがいいんでしょうか?(質問の内容は真面目です。) http://t.co/S2aYjQZ

作戦が成功して3人とも快く答えてくれました。

@miya0001 @wokamoto @jim0912 後者で、add_action は最後にしてます。心配性なんでなんとなく。
@miya0001 @odyssey @jim0912 あぁ、そういうことであれば、両方でやります。心配性なんで。
@miya0001 @wokamoto @odyssey んー、でもフック書くところって大体、プラグインがロードされる時で、そのときはis_adminくらいしか使えないから、結局後者かもw 一応、管理画面のフックは全部is_adminで括りますけんども。

なるほど前者の方法だと心配ということは共通しているようです。

@miya0001 @odyssey @jim0912 WordPress の初心者が WordPress を使い始めたばかりと言う意味なら、女子高生の初心者は女子高生と付き合い始めたばかりという解釈になるべぇ。

なるほどw

WordPressのWP-OGPが怪しい気がしてしょうがない。

この数日facebookについて勉強してるんですが、OGPについていろいろ調べてるうちにWordPressのWP-OGPプラグインが不十分というか怪しい気がするので、OGPについて私なりに調べてみたことを書きます。

ていうか、誰か詳しい人は教えてください。お願いします。

OGPについては詳しく解説しませんので、Google先生などに聞いてください。

og:type について

og:typeの値はWP-OGPプラグインでは、全てのページがarticeで固定になっているようですが、違うような気がします。

まず、投稿の場合、これはarticleでいいと思われます。一時的な情報はarticleとすべしとのことなので。

しかし、サイトのトップページでは、以下のような感じになるような気がするんですけどどうでしょう?

  • 個人的なブログの場合はblog、場合によってはwebsite。
  • 企業のCMSとしてWordPressを使用している場合には、barとかcompanyとかcafeとかhotelとか、このページのObject Typesの一覧にあるものの中から適切なものを選ぶ。

あと、固定ページの場合。

これもarticle固定ではおかしい気がします。

たとえば、このサイトではWordPressのプラグインを配布しているのですが、それらのプラグインのページでは、productとなるべきではないのかな?

プロフィールのページがもしあるならprofileとすべきじゃないかと。

なんでarticleではマズイの?

facebookのAPIでは、”イイネ”ボタンをクリックしてくれたユーザーに対して、そのページの更新をお知らせすることができるようです。(試せてません…)

しかし、ブログの記事はファンの対象にはならない一時的なものであるため、articleを指定するべきであり、articleにはこの機能が働かないそうです。

http://d.hatena.ne.jp/amachang/20110117/1295233078

なので、例えば企業サイトの製品紹介のページを更新した場合に、せっかくそれをお知らせするための素敵な仕組みがあるのに、それを使えないのは悲しくないですか?

(だからといって、なんでもかんでもarticle以外にして呼び戻し機能を使うのは、スパムって言われちゃう可能性があります。)

fb:app_id と fb:admins について

根本的にWP-OGPではfb:appidと出力されていますが、fb:app_idの間違いのようです。

あと、fb:admins と fb:ap_id はどちらか片方だけを使用するべきのような気がします。 両方でもいいみたいです。

Open Graph protocol

fb:admins or fb:app_id – A comma-separated list of either Facebook user IDs or a Facebook Platform application ID that administers this page. It is valid to include both fb:admins and fb:app_id on your page.

og:title と og:type は変更できない可能性がありますよ。

facebookの説明によると、50個以上”いいね”をゲットすると”og:title”が固定され、10,000以上”いいね”をゲットすると、og:typeは固定されるようです。
(キャッシュされて、修正しても反映されないようです。)

Open Graph protocol

You can update the attributes of your page by updating your page’s <meta> tags. Note that og:title andog:type are only editable initially – after your page receives 50 likes the title becomes fixed, and after your page receives 10,000 likes the type becomes fixed. These properties are fixed to avoid surprising users who have liked the page already. Changing the title or type tags after these limits are reached does nothing, your page retains the original title and type.

まとめ

以上、私なりに調べた結果を書いたのですが、OGPに関連するAPIとかの挙動については、わからない事だらけです。

詳しい方は、ぜひ教えてください。お願いします!

facebook向けiframeアプリの横幅や高さの設定方法

現在、WordPressをfacebookのアプリとして動作させるためのプラグインを作ってるのですが、コンテンツ部分の横幅や高さに関するメモ。

アプリのキャンバスの横幅

facebook アプリは、アプリとして登録するとiframeで外部サーバーのコンテンツを表示しています。

iframeなので、好き勝手に横幅を設定しちゃとスクロールバーが出てカッコ悪いので、CSSなどで横幅を予め合わせておく必要があります。

わかりにくいのですが、アプリは単独で開かれる場合とタブで開かれる場合があって、それぞれ最大の横幅が違います。

  • タブ経由で開かれる場合の横幅 – 520px
  • アプリ単独で開かれる場合の横幅 – 760px

アプリ側のbody要素のmarginとpaddingの調整もお忘れなく。

アプリの高さ

高さもコンテンツが縦長になると縦スクロールが出てみっともない事になってしまいますが、これはfacebookのJavaScript SDKで親ページのiframeの高さを変更するためのAPIが提供されています。

以下はAPIを使った高さ調節の例で、body要素の終了タグ直前にコピペしてください。

jQueryを使ってます。

FB.Canvas.setAutoResize() で自動的に高さが調整されるのですが、サイトによっては FB.Canvas.setSize() も紹介されていることが多いようです。

個人的には、FB.Canvas.setSize() のほうは他のJavaSCript でコンテンツ領域の高さが変わる場合に、いちいちコールする必要があったので、使いにくいと思いました。

Gist上のソースを超簡単にWordPressに表示するプラグイン

Gist.GitHub上のソースを超簡単にWordPress上に表示するプラグインを作りました。

http://firegoby.theta.ne.jp/wp/oembed-gist

このプラグインを使うとGistのURLをエディター上にコピペするだけで、以下のようにソースが表示されます。

facebookのlikeボタンとGoogle Analyticsとieのいけない関係

先日、このサイトを軽くリニューアルしました。

そのリニューアル作業の中で、ソーシャルボタンを設置しなおしたのですが、それ以来Google Analyticsが挙動不審になりました。

具体的には以下のような現象です。

  • fb_xd_fragment というクエリー文字列付きのリクエストがやたら多い。
  • 訪問別ページ数が不自然に高い。
  • 一部のページだけが飛び抜けてページビュー数が高い。

など。

正しい対処方法

これらはどうやらfacebookのいいねボタンとGoogle Analytics とIEの組み合わせで起こるバグのようです。

http://seoblog.seosearch.biz/?eid=45

微妙な対処方法

なお、この件に関しては複数のブログで記事にされているようですが、対処方法に微妙に間違いがあるものがちらほらありました。

たとえば、以下のような感じ。

http://www.myu-zin.com/webridge/archives/687.html

このページに記載されている方法ではクエリー文字列を無視するだけなので、やたらページビュー数が高いページが出てきてしまいました。

twitterの最新のツイートをfacebookに投稿する。

twitterで指定したユーザーの最新のツイートをfacebookのウォールに投稿するPHPスクリプトを作りました。

このアプリのために作りました。

ただーし、実際にこれを動かすには、

  • facebook にアプリケーション登録をする。
  • アクセストークンを取得する。

という一見簡単そうだけど、めっちゃめんどくさい手続きが必要です。

以上が完了したら、以下のスクリプトの”YOUR …”の部分を修正して Cron でぶん回してください。

twitterのユーザー名は、コマンドライン引数で渡すようになっています。

あと、require してるファイルは facebook のPHP 用の SDK です。

Cronには、以下のように渡したほうが幸せになれると思います。

*/10 * * * * export LANG=ja_JP.UTF-8; /usr/bin/php /path/to/cron.php twitter_user

WordPress + mod_ruid で自動アップデートをハッピーにする。

WordPress の自動アップデートをハッピーにする環境の構築方法をご紹介します。

http://vps.fean.info/archives/server101.html

さらにいい方法があります。

mod_ruidを使う。

mod_ruid とは、CGIでいうSuExecのような仕組みで、Apacheのバーチャルホストを指定したユーザーで実行させるという仕組みです。

たとえば、/home/wp ディレクトリを foo というユーザーで FTP アクセス(SSHでも同じ)して、WordPress を構築するとします。

その場合、そのバーチャルホストが、apache ユーザーではなく、foo という権限で動作してくれれば、パーミッションの設定や FS_METHOD の設定をすることもなく自動アップデートが可能になるわけです。

一方で冒頭に紹介したブログに記載されている方法では、以下のような問題がります。

  • ファイルのアップロード等の作業をrootで行うかapacheユーザーにftpアクセスを許可する必要がある。これはかなり危険。
  • 全てのバーチャルホストが同じ権限で動作するため、複数のユーザーによる運用を考えた場合、セキュリティリスクがある。
    たとえば違うバーチャルホストのファイルを書き換えたりデータベースのパスワードを参照できるなど。

mod_ruid を使用すれば、これらの問題も解決しつつ、パーミッション設定などに煩わされることもありません。

mod_ruid のインストール方法

一応、Apacheモジュールのインストールなのでコマンド入力が必要ですが、それほど大変ではありません。

http://firegoby.theta.ne.jp/archives/9

あと、上記の記事には記載されていませんが、このままではPHPのセッションを使用する際に書き込み権限がなくて不具合が発生します。

以下の作業も必ず行いましょう。

http://firegoby.theta.ne.jp/archives/289

というわけで、今日の記事は過去の記事の焼なおしですいません。