ご無沙汰してます。ガッツリ制作シーズンに入った小杉です。

やー、レスポンシブサイトは Rootstrap を親テーマにして改造するとめちゃくちゃ速いということがわかりました。

それは置いといて。

 

文字列を置換できるプラグイン、Search Regex

/Everybody stand back/

Search Regex ってプラグイン。便利ですよね。

WordPress コンテンツ内の文言を検索したり、置換したりできるプラグインです。

公式サイト:WordPress › Search Regex « WordPress Plugins

ただ、更新が滞っているので若干心配ではありますが。

 

ローカル環境から本番環境に移行する際、エクスポートしたコンテンツのパスが変わるので、それを全部置換したいなと思って。

phpMyAdmin と FTP が使えない状況だったので、管理画面で何とかするしかないわけです。

ちなみに、ローカル環境からエクスポートしたデータはテキストデータなので、それを一括置換してからインポートするという方法もあります。

すっかり忘れてました。

 

まあ、そんなオッチョコチョイさんにもありがたいプラグインが、Search Regex です。

ありがたいんですが、カスタム投稿タイプに対応していないんですよね。

代替プラグインがあるかな〜?と思って探してみたんですが、見つからず。

そんなら、カスタマイズしてしまおうと。

 

ということで、ここからは自己責任です。OK?

中身なら、post_content.php を変えるだけ

plugins/search-regex/searches/ の中身が、検索対象を司っています。

その中に post_content.php があります。

10行目を以下のように変更します。

変更前

変更後

つまり、 AND post_type IN (‘post’,’page’) をカットしました。

カスタム投稿タイプに限らず、すべてを検索対象にしちゃえ!と少々乱暴ですが、意図としてはもれなく確認したいため。ひとつずつでも個別に置換できますしね。

 

同様に、タイトルの全置換は post_title.php かなって思いますよね。

ですが、ここには制限がありませんでした(笑)

タイトルは全部の記事を横断できるんじゃないかなと。

 

念のためバックアップをとっておき、ローカルで確認してから、本番の作業環境で実行しました。

特に問題なくガッと切り替わってくれました。オッチョコチョイさんでもチョチョイのチョイです。

良かったら試してみてくださいね╭( ・ㅂ・)و ̑̑

 

お好み焼きは主食派はい、ごめんください。
ちょっと質問されたけれどもすぐに解決できない割には需要があるなあと思ったのでメモしておきます。誰かプラグインにしませんか。

まず、現状は下記のとおりです。

  • お好み焼きの記事Aがある。
  • 卵焼きの記事Bがある。
  • 記事Aは「おかず」というカテゴリーと「主食」というカテゴリーに登録されている。
  • 記事Bは「おかず」というカテゴリーに登録されている。

そしてこの状態で起こりえる問題があります。

  • 「主食」というカテゴリーから、お好み焼きの記事Aを閲覧した。
  • 次の記事として、卵焼きの記事Bへのリンクが出現。
  • 確かに記事Aは主食でもありおかずでもあるが、「主食」のカテゴリーから来た以上、「おかず」のカテゴリーに属する卵焼きの記事Bへのリンクは許せない。

お好み焼きはそれだけで主食だと思うのに、卵焼きは主食か否か。や、私は主食でもいいんですけどね。

つまり、閲覧元のカテゴリーと同じカテゴリーの前後記事を表示する方法

閲覧元を調べてリンクを出すのはできましたが、そのまた次のページに行くなど、閲覧元のカテゴリーをずっと引き回すのがそのままではできなかったので、Cookie を使いました。

functions.php に下記を追加します。

下の方はフォーラムのkzさんの投稿がすごく参考になりました。

参考:WordPress › フォーラム » next_post_link:特定カテゴリーの除外について

 

そして、single.php のナビゲーション部分を下記のように変更します。位置としては while 〜 endwhile; の中ですね。

ざっくりとした概要

  • カテゴリーページに行くと、表示したカテゴリーIDをブラウザが保存(上書き)します。
  • 個別記事ページに行くと、保存されたカテゴリーIDと同じカテゴリーの前後記事を表示します。
  • ブラウザを閉じたりトップページに行くと、保存したカテゴリーIDは削除され、カテゴリーページを表示しなければ、時系列での前後記事を表示します。

できてしまえば単純でした。

We love WP!はい、ごめんください。
雪国新潟のウェブ解析士マスター、小杉です。

WordPress Advent Calendar 2013 の16日目の記事となります。

去年も個人ブログの方で参加しましたが、1年後に独立しているとは夢にも思っていませんでした。

今では WordPress を利用したサイト制作とウェブコンサルティングをやっています。アクセス解析ツールを見たりいじったりもしていますが、最近はウェブカウンセラーなんじゃないかと思い始めました。そんな私ですが、WordPress は今でも大好きです。

WordPress を個人で使っている方も多いと思うので、今日は Facebook と連携するときに知っておくとイイコトを記事にしました。

ちなみに、WP 成分は薄いです。

商品に「○○使用」と書いてあって5%くらいだったり、メロン味と書いてあってメロンを使ってなかったりするくらいの薄さです。スミマセン。

きっかけは、何気なく Facebook を眺めていた時。

FB友達の 笹川さん がブログをアップしたのを Facebook で見て、「ん?」と思ったのです。

Facebookの記事に作成者名?

なんぞこれ?

Facebookの記事に作成者名?

どうやらFacebook のウォールが新しくなった頃からのようです。本人のタイムラインなどには出てきませんが、メインのニュースフィードや埋め込み投稿にも表示されます。

↓このように、埋め込み投稿にも作成者名が表示されます。

 

↓ただ、はてなブックマークなどアプリ連携で投稿したものには表示されていません。代わりにアプリ名が表示されています。リンクを直接シェアしないと表示されないということがわかりました。

 

そこでフィードに流れてくる「リンクをシェアした記事」を見ていましたが、大抵ドメイン名が表示されているだけなんですよね。

笹川さんはライブドアブログとは思えない変態カスタマイズ(褒め言葉)をしているので、そのためかなと本人にお聞きしてみましたがお手上げ状態でした。

ソースを眺めたらすぐにわかった・・・けれど

HTML ソースを調べたところ、meta タグの name=”author” が該当しました。

Facebook との連携について調べてみましたが、解釈できるブラウザもないし、あまり意味がないからいらないよーという記事がたくさん見つかりました。

そんな記事に埋もれているのか、今回の件についての日本語の記事が見当たりませんでしたが、そのものズバリの英語の記事を発見しました。

参考:Optimizing Your Site for the Open Graph (UPDATED)

そのものズバリだ!

さっそく meta タグの name=”author” を入れてみた。

メールアドレスを入れることもあるようですが、今回は Facebook の投稿に作成者名を表示させることが目的なので、表示させたい文字そのものを入れることにしました。

ということで、<meta name=”author” content=”小杉 聖(@mekemoke)” /> などとヘッダに入れれば良いわけですね。日本語もOKです。

WordPress のプラグインで対応しているものはなさそう

Facebook との連携と言っても、OGP 設定とは違うので、プラグインで対応しているものはないように思います(ちゃんと調べていないので、もしあったらそちらで適用されているかと)。
私は WordPress SEO by Yoast を愛用しているのですが、特に設定項目はありませんでした。

そこで、手動でテーマを編集します。

管理画面の、[外観]>[テーマ編集]>header.php をいじるだけで行けます。プログラムも不要で、下記を <head> 〜 </head> に追記するだけなので1分もせずに終わります。

はい、終わりました。

追加したー!・・・けど、表示されない?

実際に表示されるかどうかは、「自分のみ公開」の設定にして Facebook でリンクをシェアしてみるとわかります。わかるんですが・・・どうにもこうにも表示されません。

しかも Facebook のデバッガで確認すると、エラーになっていました。

Facebookのデバッガでエラーが〜

The meta tag on the page was specified with name ‘author’, which matches a configured property of this object type. It will be ignored unless specified with the meta property attribute instead of the meta name attribute.

「meta タグで name 要素に “author” を指定してるみたいだね。でも、property 要素として扱わないと、無視すんよ?」と言われました。

はいスミマセン。OGP として設定しろってことですね。わかります。わかりますけどでもでもだって。

結論:適切な OGP 設定 + HTML レベルの著者情報で OK

OGP の詳しい説明は省きますが、ソーシャルメディアで連携する時にウレシイ設定です。

参考:これだけは知っておきたいOGP (Open Graph Protocol) | NEX.FM
参考:Facebookインサイト設定の落とし穴、app_id, page_id, admins の違いとは – Six Apart ブログ
参考:OGPに何書いたらいいか – MEMOGRAPHIX

結論から言うと、下記の設定を行なっておくことで作成者名は表示されます。

fb:admins もしくは fb:app_id は設定しておく

個人の場合は admins、複数人で更新している場合は app_id が良いようです。
これは片方でも両方でもOK。IDは調べて設定しましょう。

article:author もしくは article:publisher も設定できる

個人の場合は author に自分のFBページ、複数人の場合は publisher に FBページの URL を入れます。ちなみに、日本語版ではこの機能は反映されていないようです…(詳細は上記参考リンク)。
これはどちらか片方にしておきましょう。

私の場合、author と publisher の両方を設定していたことでうまく行かなかったようです。

このブログは個人用なので、fb:admins と article:author を設定しました。
自分の個人事業用のサイトは Facebook ページと連携させたかったので、fb:app_id と article:publisher を設定しました。

app_id の取得を別途しておけば、WordPress SEO by YOAST で fb:app_id と article:publisher をプラグインの設定画面から設定できます。

そして <meta name=”author” content=”作成者名” /> を追加する

追加する場所は <head> 〜 </head> ならどこでも良いようです。さくっといけますね。

というわけで、下記のように作成者を表示することができましたヽ(=´▽`=)ノ

注意点。

今回の流れで気になった点を4つほど。

自由度が高いけど虚偽表示はダメ、ぜったい。

著者表示は単純なドメイン名だけでなく、自分の名前を表示させることができます。

私もふと気づいたものだし、メインのフィードにしか現れないので「著作者が表示されるから、自分の名前を出して信頼を得よう!」とか声高に言うのは早計すぎるので、あくまで小技程度の紹介です。

ただ、自由度が高いので悪用されかねないなあとも思いましたが……、そうなったら Facebook 側で表示することはしなくなるだけでしょうね。

昔の記事に適用されるまでにはタイムラグがありそう

Facebook はデータをキャッシュするので、一度 Facebook でシェアした記事のデータは変わってくれません。OGP はデバッガで更新できるようですが、この作成者名については対応していないのかな?と思いました。

ただ、記事を書いている間に適用されたのを目の当たりにしたので、タイムラグがあるようですね。Facebook では、「自分のみ」の公開範囲で投稿して、全体のニュースフィードを確認してみると良いでしょう。

エラーが消えない

最初のきっかけとなった笹川さんの記事は、デバッガでエラーが出てこないのです。OGP 設定を合わせてみましたが効果なし。

無視するよーと言いつつ表示しているあたり、仕様のよく変わる Facebook のツンデレっぷりがよくわかります。そのうちなんとかなるのかも。

アプリで連携させない

アプリを介すとその情報が入ってしまうので、手動でシェアするようにしましょう。
せっかく書いた思い入れのある記事ですから、読んで欲しいポイントや気持ちを添えてシェアすると良いですよ。

いいね!ボタンだけでなく、シェアボタンを置いておくと楽かもしれませんね。

参考:Share Button – Facebook開発者

ウラ話。

なんていうかもう、WordPress <<< Facebook 的な記事でスミマセン。

実は WP のネタを考えているときに、

WP Test の日本語化とかやろうかなー → 公式が数日前にアップデート → orz
(参考:WordPressテーマユニットテストデータ日本語版を更新したよ! ‹ nuuno

WordPress SEO by YOAST の日本語化しようかなー → 最新版がんばってる方発見 → orz
(これは自分用にまとめました:WordPress SEO by YOAST を日本人が使いたい場合のメモ – NAVER まとめ

となっていてちょっと焦っていたのですが、WordPress 3.8 が出たという情報を振りきって、ムリヤリ WP にこじつけた感が…。

・・・ま、細かいことは気にしない!

明日17日は、あのプライム・ストラテジーの藤 祐太郎さんです!(実は誕生日が一緒だった!)

wp-seo-by-yoastWordPressを使った機械的な部分のSEOについては、もうこのプラグイン使っちゃえば、あとは別にいらないんじゃないかと思っている昨今です。

むしろオススメあったら教えてください。

参考:WordPress › WordPress SEO by Yoast « WordPress Plugins

Facebook でページをシェアする時に表示される画像の話です

Facebook とかでシェアする時に、サムネイル画像が表示されるのを見たことがあるかと思います。あれは、「このURLの画像を使ってね〜」と教えてあげると、それらを参照します。(og:image として設定します)

でも Facebook は 1,500px だか 2,000px だか(どんどん大きくなってる)を推奨しているので、小さい画像だと無視されちゃって、ページ内の他の画像をサムネイルとして使ってしまいかねない場合もあります。

Facebook はちょこちょこ仕様が変わるのですが、「また変わるのー?勘弁してよー!」と思うより、「ああ、解像度のめちゃ高い画面に最適化しようとしてるのね〜。時代がそうなっていくのを見越してるのね〜」と思っていたほうが精神衛生上お勧めです。

WP SEO は OGP タグを自動的に出してくれるのですが

さて、本来ならその元画像を og:image として設定しておけば、投稿内の画像をサムネイルとして使うことができるようになります。

手作業でやるのはちょっと面倒なので、WP SEO を使うと、投稿内にある画像を og:image として自動的に設定してくれます。何も考えなくて良いので嬉しいですね!

ですが、元々の画像は大きくても、表示するために小さめの画像(中サイズとか)を設定している場合があります。これが問題。

元画像を og:image に設定できる方法はないものかな?
ってことで、プラグインの中身覗いてみました。

WP SEO でフルサイズの画像を og:image として設定する方法

本題です。

WP SEO を有効化しているという前提で、下記を functions.php にコピペして保存すればOKです。

久しぶりに PHP いじったので、変な書き方だったらご指摘ください。英語はわかればなんでもいいです。

何をやってるかというと、WP SEO では og:image を出力する時に、一旦 content を参照してイメージタグを取得しているのですね。その content で使っている画像の、元画像ではないファイル(-300×240とかついている画像)のサイズ指定部分を取っ払ってから読み込ませているわけです。

直接プラグインをいじるより、フックしたほうが安全なのでこれで実現できました。

・・・うん、まあ、動かなかったら該当ページ教えてください。改良してみます。

画像がでなかったり、シェアする時におかしかったら?

Facebook でシェアするときとかに「サムネイルがちゃんとでなーい!」「何か変!」という場合には、下記のページにURLを突っ込んで、確認すると良いですよ。ここでキャッシュさせると表示されるよーって話も見かけました。

参考:Debugger – Facebook Developers

ameblo2WPコスギスの方に書くようなネタでもないので、こっちに投下。

結論から言うと、ひじょーに使いにくいしこれで有料ツールなのかっていうと首を傾げざるを得ないのですが、コツ(癖)さえ掴めばなんとかなりそうなので、メモ。

1.リスト全取得→画像も取得→MT形式にエクスポート(画像へのリンクは切る)

画像へのリンクが残っていると、結局リンク先が変わるので切っておく。

それでも残ってしまうのはあるのだけど…。

あと、取れない画像があるようですが、今回は大丈夫そうでした。体験版で取れない場合、おとなしくFC2を使ったほうが良いと思います。

2.WPにインポートする前に、必要な物は全て置換する

まず、絵文字はサイズの小さいgifとpngなので、テーマフォルダにでも突っ込んで、パスを正規表現で置換。

過去の絵文字形式のものは、[]の部分を<>に変えておけば表示はされない。

写真等はメディアからアップしておけばいいけれど、大きい物はもうサイズ変更しちゃってからアップして、フルサイズにしたほうが楽。
なので、画像のサイズ指定は置換してすべて取っ払っておく。

フォントサイズが入り組んでいる場合は、3はカット、2以下は83%、4以上は125%とかにしてしまう。

strongとspanをくっつけちゃったけど、閉じタグの関係でfontはすべてspanに置換したほうが楽。

中身が空のタグは、対応できる記事数じゃなければ、見なかったことにしておいたほうが精神的におすすめ。入り組んでなければ正規表現で置換してしまえばOK。

<p>タグは残しておいたほうが良い。もしくは、よくわからない改行は置換してしまう。<br>に頼らない方が良かった。

正規表現使えないと、置換は非常に大変です。

3.mt.txt をインポートして確認する

MT形式のインポートには専用プラグインがあるので、それをインストールしてインポート。

インポート自体はすぐに終わりますが、問題は内部リンクがあった場合…リンク先全部変わってるので。

4.リンク先を変えるのは手作業を覚悟する

ここが一番苦労するところ。カテゴリーへのリンクなら Search Regex とかのプラグインで一括置換できるけれど、過去の記事へのリンクとかが手作業で入っていると、泣けます。

ほとんどのリンクが「こちら」とかでリンクされていて、その先が想像できないと尚更です。

そんなわけで、深夜作業で音楽でも聞きながら、目視確認ついでに編集していくのがオススメです。1記事につき、1〜3分くらいかな。

 

というわけでザックリメモでした。

FC2通すと楽ですよ〜とは聞いたんですが、上記のことどこまでやってくれるんだろう?

WordPress › Improved Page Permalinks « WordPress Plugins

はい、ごめんください。

WordPressで「ページの」パーマリンクを変更したい場合は、「.html on PAGES」を使っていたのですが、ページの構造が複雑になってくると、親ページはスラッシュ(/)で終わらせて、子ページは .html で終わらせたい、という要望が出てきます。従来のホームページのURLを変えたくない場合などには頻出するのでしょうかね。

そんな時に救世主になった(と言うより単純に私が知らなかっただけ)プラグインがありました。

WordPress › Improved Page Permalinks « WordPress Plugins

このプラグインの何が嬉しかったって、子ページがなくても親ページとみなし、スラッシュで終わらせることができる点です。つまり、スラッシュ(/)で終わらせるか「.html」をつけるかを設定することができるんですね。

特定のプラグインが重宝しているからといって、そればかりに束縛されるのは良くないと反省。

Anchorはい、ごめんください。
前に使ったことがあったのに忘れてしまって、使いたい時に使えなかったのでメモメモ。

WordPress 3.5 以降から、左側のメニューからリンクが消えました。

以前からリンクの機能を使っていて、バージョンアップされているかたは問題なく表示されていますが、新規でインストールすると消えています。

ちょっとしたバナーの管理とかしやすかったんですがね。

プラグインを使わなくても function.php に1行書けば一発 OK

リンク機能がなくなった!でもこのプラグインを入れればOK!というものはあります。それが Link Manager というプラグイン。
公式プラグインなので、検索してインストールすれば OK です。

ただ、プラグインのソースを見てみると・・・

link-manager.php in link-manager/trunk – WordPress Plugin Repository

・・・実質一行!!

というわけで、下記の一行を function.php に入れておくだけで、リンク機能を使うことができます。要するに、機能は存在しているものの、それを表示していないだけなのですね。

表示されていないということは、今後そのまま消滅する可能性があるとも言えます。その場合はカスタム投稿タイプを利用して、リンクを管理すると良いでしょう。

カスタム投稿タイプは難しそう…と敬遠している方は、これこそプラグインを使って管理すると良いでしょう。

WordPress › Custom Post Type UI « WordPress Plugins

私は他に投稿タイプを使う予定もなかったので、しばらくはリンクの機能を復活させて使います。

セミナーイメージはい、ごめんください。
普段インドアな人間にゴールデンウイークの遠出はこたえました…渋滞とか行列とかの待ち時間が。そして色々食べ過ぎて消化が追いつかないとか。その辺を散歩したり、公園でのんびりしている方がいいなあ。

さて、告知が遅くなってしまいましたが、下記の通り、新潟県は長岡市で無料セミナーを行ないます。主催はウェブ解析士協会の株式会社環様ですが、私も登壇させていただくことになりました。

【新潟開催】受注につなげる企業向けホームページ活用講座:初級編(個別相談付き) – ウェブ解析士認定講座・検定

私としては、ホームページを持っている中小企業の方に来ていただきたいような内容です。
日程が調整しにくいという意見もお聞きしているのですが、ぜひご都合をつけていただければ幸いです。(次回の反省にします…)

開催日 2013年5月20日(月)
時間 14:30~16:30 ※セミナー後、個別相談会を開催
会場 まちなかキャンパス501会議室
住所 〒940-0062 新潟県長岡市大手通2-6 フェニックス大手イースト4F
講師 江尻俊章(WACA一般社団法人ウェブ解析士協会 代表理事、株式会社環 代表取締役)
小杉聖(WACAウェブ解析士マスター)
定員 30名
参加費 無料
14:30~15:20 Webマーケティングで失敗しがちな5つのポイント(江尻・小杉)
・アクセス数は多ければいい?
・ホームページを作れば世界中から顧客が集まる?
・SEOではロングテール対策で売り上げのばす?
・リスティング広告で効率的な集客ができる?
・ソーシャルメディア活用が収益UPのカギ?
※質疑10分
15:20~15:30 休憩
15:30~16:30 企業の成果につなげるウェブ解析(小杉)
ウェブ解析士マスターの小杉さんから、参加者の皆様が日頃疑問に思っていること、
聞きたいことをベースに、一問一答形式でお答えします。
ウェブ解析士協会代表理事の江尻さんもアドバイスします。
16:30~ 個別相談会

ご相談の内容をお聞きしているので基本は事前申込制ですが、定員の余裕が十分あるので、直接お越しいただいてもよろしいかと思っています(その際は参加者確認のため名刺をご持参ください)。

普段疑問に思っていること、問題視しているほどでもないけど課題には感じていることなど、ウェブ解析に関することも、そうでないことも、ざっくばらんに聞いていただける場になっています。

お申込みは下記よりどうぞ。

【新潟開催】受注につなげる企業向けホームページ活用講座:初級編(個別相談付き) – ウェブ解析士認定講座・検定

はい、ごめんください。
備忘録のためのメモです。

Advanced Custom Fields はカスタムフィールドを柔軟に設定できるプラグインです。
ここでセレクトボックスを使っているのですが、値と表示名を変えているんですね。

apple : りんご
banana : バナナ
chocolate : チョコレート

という状態です。
設定された値で、画像を表示させることが目的でした。

<img src=”./images/apple.gif” alt=”apple” />

という具合に。

選択肢として使われている表示名も欲しいなあ・・・

上記だと、 alt で表示するものも apple や banana になってしまうので、

<img src=”./images/apple.gif” alt=”りんご” />

と、表示名の値を取得したいところです。

Advanced Custom Fields のセレクトボックスの、ここ!

ですが Advanced Custom Fields の利用方法は値と表示名が同じ場合が前提となっている記事が多いので、なかなか方法が見つかりませんでした。

なら、直接データベース覗いちゃえばいんじゃね?

何処かに格納されているはずなのでデータベースを見てみたところ、フィールド番号で格納されていました。
このフィールド番号を確認する一番簡単な方法は、Chrome などの開発者用ツールで該当する入力欄の id を確認すると良いです。

acf-field_1_label という id が設定されている場合、下記の方法で実現できます。

ポイントは get_field_object で該当フィールドのデータを取得するところですね。

素敵なWPライフを~

WordPress LOGOはい、ごめんください。

wp_is_mobile は 3.4 移行から使える、モバイルからのアクセスを判別する便利な関数です。
例えばスマホ用に見せたい物がある場合や、表示を変更したい場合に、下記のように使えます。

wp_is_mobile のモバイル判別方法

wp-includes/vars.php の 101 行目で、下記のようなコードがあります。

つまり、ユーザーエージェントに下記の文言が含まれていると、モバイルと判断されます。

Mobile, Android, Silk/, Kindle, BlackBerry, Opera Mini, Opera Mobi

WP Super Cache のモバイル判別方法

そしてキャッシュ機能として有名なプラグイン、WP Super Cache 。
これはモバイルにも対応していて、モバイルからのアクセスがあった場合にはキャッシュしないという機能があります。

下記がモバイルと判断されるユーザーエージェントのリスト。これらが含まれていると「モバイルからのアクセスだ」と判断されます。(2013.2.15 ver1.2)

2.0 MMP, 240×320, 400X240, AvantGo, BlackBerry, Blazer, Cellphone, Danger, DoCoMo, Elaine/3.0, EudoraWeb, Googlebot-Mobile, hiptop, IEMobile, KYOCERA/WX310K, LG/U990, MIDP-2., MMEF20, MOT-V, NetFront, Newt, Nintendo Wii, Nitro, Nokia, Opera Mini, Palm, PlayStation Portable, portalmmm, Proxinet, ProxiNet, SHARP-TQ-GX10, SHG-i900, Small, SonyEricsson, Symbian OS, SymbianOS, TS21i-10, UP.Browser, UP.Link, webOS, Windows CE, WinWAP, YahooSeeker/M1A1-R2D2, iPhone, iPod, Android, BlackBerry9530, LG-TU915 Obigo, LGE VX, webOS, Nokia5800

同じく下記も設定されていますが、接続ネットワークでも見てるのかな?

w3c , w3c-, acs-, alav, alca, amoi, audi, avan, benq, bird, blac, blaz, brew, cell, cldc, cmd-, dang, doco, eric, hipt, htc_, inno, ipaq, ipod, jigs, kddi, keji, leno, lg-c, lg-d, lg-g, lge-, lg/u, maui, maxo, midp, mits, mmef, mobi, mot-, moto, mwbp, nec-, newt, noki, palm, pana, pant, phil, play, port, prox, qwap, sage, sams, sany, sch-, sec-, send, seri, sgh-, shar, sie-, siem, smal, smar, sony, sph-, symb, t-mo, teli, tim-, tosh, tsm-, upg1, upsi, vk-v, voda, wap-, wapa, wapi, wapp, wapr, webc, winw, winw, xda , xda-

モバイルとパソコンの表示を変えたい時、管理画面の「詳細」タブから、「詳細」項目の Mobile device support. (External plugin or theme required. See the FAQ for further details.) という部分から設定を確認できます。

チェックが入っていれば、モバイルからのアクセス時にはキャッシュを生成しません。
これによって、「モバイルとパソコンの画面デザインを分けている」かつ「キャッシュ機能を有効にしている」場合でも、キャッシュを作るのはパソコン用画面のみとして対応しているわけです。(モバイル用のキャッシュも作れればいいんだろうけどなあ…)

iPad はパソコン?モバイル?

さて、タブレット端末の場合、私はパソコン用の画面を見せるのが一番良いと思っています(今のところ)。
そのため、iPad での表示はパソコンと同じ物を想定していました。

iPad のユーザーエージェントは下記のようになっています。(Chrome で iOS5 のエミュレートした場合)

Mozilla/5.0 (iPad; CPU OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3

wp_is_mobile では、Mobile が引っかかるので モバイルと判断されます。
WP Super Cache では、該当するものがないので パソコンと判断されます。

ただ違うのね、で終わりではありません。

wp_is_mobile でモバイルと判断されるということは、モバイル用の画面を表示する
WP Super Cache でパソコンと判断されるということは、キャッシュを生成する

モバイル用の画面がキャッシュされ、パソコンでアクセスしても有効期限までモバイル用の画面が表示されてしまう。

という状況になります。逆なら、iPad でアクセスしたらパソコン用の画面だけどキャッシュされない、ってなるのですが。

じゃあ、どうしたらいいの?

キャッシュプラグインの内容のほうが複雑なので、

(1) wp_is_mobile をカスタマイズする
(2) 使わないで別の関数を使う

という 2 つの選択肢があります。ただし、(1) はコアファイルの修正なのでお勧めしません。必然的に (2) の選択肢となります。functions.php に is_mobile という関数を作って使うのが一番。

参考:【WordPress】User-agentを判定してモバイル用コンテンツを切り分け、検証する方法

上記コードを functions.php に書いて使います(少し修正しています)。
これでも willcom や google phone に対応できてないのですが、アクセス解析のユーザーエージェントを確認して追加していくくらいでいいのかなあと。

参考:スマートフォンUSERAGENT一覧+モバイル版クローラ | カグア!Googleアナリティクス解説Blog
参考:serbanghita/Mobile-Detect · GitHub

タブレット端末での検証もお忘れなく!