リンクをブログカード形式で表示する「Pz-LinkCard」をお試し稼働中。
まずは恒例の宣伝から。
外部リンクを「はてなブログカード」に置き換えて表示させるWordPressプラグイン「Pz-HatenaBlogCard」を公式プラグインディレクトリにて公開しています。
内部リンクも外見をカスタマイズしてブログカード形式で表示できます。
直接コードを埋め込むタイプだと、「乗り換え」したいときに置き換えるかどうしようか…となってしまいます。
Pz-HatenaBlogCard はショートコード方式なので、プラグインの設定画面で外見を変更すれば、全ページ一斉に変わります。
そして、ショートコードの最大の利点！
「Pz-HatenaBlogCard に飽きたら、別のプラグインに乗り換えやすい！Σ(ﾟロﾟ)oﾞ」
これってけっこう大事なことだと思います。
ショートコードそのものは、「Search Regex」とかで置き換えられちゃいますし。
さてと、なんやかんやで自分でも便利に使っている Pz-HatenaBlogCard。
名前のとおり「外部リンクのときはタイトル・抜粋文などの取得は全部はてブカードにおまかせ」なのです。
なるべくなら自前で取得したい
外部リンクでも内部リンクでもレイアウトを自由にしたいものです。
カードの周りの枠とかまでは手が出せるのですが、はてブの中身、配置だとか色だとかは手が出せません。
（そもそも人のもの借りておいて、手を入れるも何も無いですけど(^-^;）
とはいえ、Pz -HatenaBlogCard は、外部リンクを「はてブカード」で表示させるのが目的なので、やりたかったことはだいたいできた感じです。まんぞく、まんぞく。
そして、外部リンクだって自前取得しちゃう Pz -LinkCard というのも水面下で作成中だったりしたのですが…。
取得→保存
まずはリンク先のHTMLを取得します。
OGPとかで設定されている、タイトル・抜粋文を取得します。
上の記事では、 file_get_contents とか cURL とかを使っています。
file_get_contents … 読むだけ！手軽！Σ(ﾟロﾟ)oﾞ
cURL … 普通にブラウザ機能。便利！Σ(ﾟロﾟ)oﾞ
という感じでしたが、file_get_contens は、サーバーの設定によってはサイト取得には使えないことがあるようです。
結局、WordPress関数の wp_remote_get を使うようにしました。
取得した文字をそのままDBへ格納してみたところ、「NTT-Xストア」のブログカードが化け化けでした。
NTT-Xストアは「Shift_JIS」なので、そのままだと
取得→格納→はい、モジバケーΣ(ﾟロﾟ)oﾞ
とりあえず、何でもかんても UTF-8 にしちゃえばいいのかな？
自分が UTF-8 使っているので、WordPress って全部 UTF-8 なのかなぁ、と思っているのですが、もしかしたら環境によってむしろ全部化けちゃうかも？
上記リンク先にも書いていますが、WordPress 3.5.0 以降は UTF-8 ということで良いみたいです。
関係無い話ですが、職場で見る UTF-8(BOM付) ファイルを見てると、いつもドキドキします(^-^;
DBに保管？どうやってキャッシュする？
「カスタム投稿タイプ」とやらを使って、保存しておく方法も思いつきました。
「たくそのみー」だか「かみだのみー」だかが、未だに何のことだか分かりません。
WordPress 4.3.0 で不具合があったので、テストサイト含めて3～4サイトの taxonomy.php を触りましたけど、（関係無いかも）
正確には「カスタム分類」＝「カスタムタクソノミー（Custom Taxonomies）」みたいですね。
ことばは何だかちょっとおもしろいです。まあ、必要があったら覚えたいと思います(^-^;
さて、このカスタム投稿ですが、「WordPress Download Manager」とかで使っているのがカスタム投稿あんだとすると、サムネイル画像とかも添付させておけそうです。
普通の記事や固定ページみたいな一覧・編集画面とかを流用できるならば、何かめっちゃ楽に色々できそうなのですが…。
つまりは、「みんなに見えないカテゴリーを1個つくる」くらいに考えていたのですが、さすがにそこまで甘くは無いようです(^-^;
記事とほとんど同じ扱いなら、内部リンクのカードと処理を共通化させちゃって、ソースがもっとスッキリしそうなんですけど。
現在、めっちゃスパゲティ。
下手に「最初から Class で作るようにクセつけた方がいいに違いない！Σ(ﾟロﾟ)oﾞ」とか思ったもんだから、サブルーチン分けとかがキレイに出来なくて困ったものです。
お話し戻って、タクノミカスタマミーの話。（何か違う）
カスタム投稿タイプを使えたとしても、どうやらデータは wp_posts とか wp_postmeta とかに格納するようなので、記事データやらとごっちゃになってしまいそうです。
無駄に増える記事ID、そして、テスト時に不要なデータだけを消そうとして、「ギャー！Σ(ﾟロﾟ)oﾞ」とか恐いですね(^-^;
アンインストール時とかに綺麗にしていくのも気を使いそうです。
DBをキャッシュに使うという選択肢
そんなこんなで専用のDBテーブルを作成することにしました(^-^)o
ちょっとしたプラグインであんまりいくつもテーブルを作るのはよろしく無いと思い、1つにしておきました。
ドメイン名とファビコンを管理する小さいテーブルがあると便利そうではあったのですが、面倒が増えるだけな気がしました。
DBテーブルは、wp_pz_linkcard というテーブル名。（先頭の「wp_」はプレフィックスです。環境によって変わります。）
プラグインと合わせてあります。
「何かキャッシュが変になった！Σ(ﾟロﾟ)oﾞ」と思ったら、プラグインを無効化、「pz_linkcard」を削除、プラグインを有効化すれば大丈夫です。
（近くの違うDBテーブルを削除しませんように。）
プラグインのアクティベーション時にDBテーブルを作成。
dbDeltaを使用しているので、バージョンアップ時に足りない項目は追加されます。（多分）
そして、アンインストール時に削除（DROP）します。
（最初はテストのためにちょいちょいテーブルをクリアしたかったので、非アクティブ時にDROPしていましたが、アンインストール時に削除するようにしました。）
WordPressには $wpdb という DBアクセスのクラスが用意されていて、比較的安全にDB操作ができます。（多分）
select、insert、update、delete は、良い感じのアクセス方法があるのですが、CREATE TABLE と DROP TABLE はちゃんとSQLを書かないといけないので面倒です(^-^;
DBを意識しない関数群があると嬉しいのですけど(^-^;
なお、設定内容は get_option 、update_option、delete_option というWordPress関数を使用しています。
実体は、WordPress標準のDBテーブル wp_options です。
ここにキーが作成されて保存されます。
一応、アンインストール時に削除しています。
ブログカードを表示する際に、外部サイトだった場合にはDBへアクセスして、保存されている内容があれば、そこから表示します。
これで、相手サイトへの負担も最低限（カード作成の初回だけアクセスします）で済みそうです。
キャッシュの有効期間とかどうしよう？
保存した日時を保存しておいて、ある程度の日数（秒数）が経過したら、読み直すのが良さそうですが、同じ記事にあるカードは同じタイミングで作り直されてしまいます。
つまり、その記事を見たある人のタイミングで全カードが更新がかかって、時間がかかるということ。
「そもそも更新なんてしない」というのが自分の中では有力なのですが、定期的に更新した方がいいのならば「基本の更新タイミングに数十分～数時間のランダムなズレを設定しておく」のが良さそうです。
実は「更新しない」利点がありまして、例えば数年前に書いた記事があって、「タイトル」と「抜粋文」が書かれています。
そのリンク先のサイトはもう閉鎖もしくは移転されていて、要は「リンク切れ」になっているとします。
リンク切れしていても、「このリンク先の記事、ぜひ見てみたいなぁ！Σ(ﾟロﾟ)oﾞ」と思えば、表示されているタイトルと抜粋文を元にして検索することがあるかも知れません。
移転だったらタイトルとかで検索すればすぐ見つかるかも知れませんね。
これが、定期的に読み直しをして更新をするようになると、カードには「404 Not found」と書かれているだけになります。
URLから移転先URLを類推するのは難しいかも知れないですね(^-^;
「取得しなおした結果が 404 だったら更新しない」なんて仕組みなら、誤字修正とかが反映されるので、悪くは無いかも知れませんけど。
あー、そういえば、自動更新のデメリットを思い出しました。
リンク先のサイトが移転・閉鎖
↓
そのドメインをアダルトサイトなどが取得
↓
その内容を自動取得
↓
「リンクカードのタイトルも抜粋文も完全アダルティー！Σ(ﾟロﾟ)oﾞ」
↓
下手したら、Googleさんとかからペナルティー。
アダルティーからのペナルティーですね。（←別に上手く無い）
まあ、このパターンは、タイトルや抜粋文を取り直していなくても、ペナ受ける可能性はあるのですが、やっぱりそういう文字を自サイト内に堂々と掲載しているタイミングがあるのは避けたいところです。
そんなこんなで、再取得は手動のみが良いのかな、と思っています。
サムネイル画像とファビコンはWebAPIを利用
本当はサムネイル画像とファビコンも自前取得したいのですが、保存するディレクトリを作成しておいて、取得した画像を保存しておく必要があります。
| URLをURLエンコードして、保存するファイル名を作成しておく（.png とかに統一しちゃうのが良さげ） ↓ リンク先のHTMLを取得 ↓ OGPとかで設定された画像URLを取得 ↓ 100×100に整形もしくはトリミング ↓ pngファイルとして保存 ↓ そのファイルを読み込み ↓ headerと一緒にファイルを返却 |
こんな感じのCGIをphpで作って試してみました。
「いやあ、思ったよりもうまくつくれた！Σ(ﾟロﾟ)oﾞ」
プラグインに組み込んじゃわないで、CGIにしちゃうことで、別のサーバにのっけて処理分散も出来そうです。
でも、
「これ、変なURLとか飲まされたら、絶対変なことなる！Σ(ﾟロﾟ)oﾞ」
「相対パスとか飲まされたら、pngと称してphpソースとかそんまんま渡しちゃうバグとか絶対潜んでそう…！Σ(ﾟロﾟ)oﾞ」
なんか、付け焼きで作ると大やけどしそうなので、優秀なWebAPIを素直に使用することにしました。
ソーシャルカウントも諦めムード
「JavaScriptを組み合わせて、非同期取得する」というのが一番現実そうです。
でも、これ、けっこう面倒そう。
「自記事のソーシャルカウントを非同期取得する」みたいなのは結構見つかるのですが、「人んちの記事のソーシャルカウントを非同期取得する」みたいなのは一応ありましたが、かなり少ないです(^-^;
同一ページ内でカードを作成するときに、連番を振っておいてクラス名に入れておいて、感じでしょうか。
それに対応した JavaScript が、対応したクラス名のところに順次数字を入れてってくれる感じでしょうか。
…いや、これ、すごく面倒そう(^-^;
というか、正直に言います。
「JavaScript苦手っ！Σ(ﾟロﾟ)oﾞ」
なんでか分からないけど、かなり苦手意識があります(^-^;
できることなら手を付けずに終わらせたいΣ(ﾟロﾟ)oﾞ
となると、DBテーブルにソーシャルカウントの値も入れておくのが良さそうです。
自サイト内のソーシャルカウントは「SNS Count Cache」が優秀なので、function_exists で確認しつつも取得。
インストールされていない場合と外部サイトのソーシャルカウントはDBから取得する感じでしょうか。
「DBキャッシュは更新しないぞ！Σ(ﾟロﾟ)oﾞ」
って決めたあとだったので、けっこうソースをいじらないとダメな気がします。
具体的に言うと、
| キャッシュがあったら取得 ↓ 無かったらサイトから取得 ↓ あれこれリンクカード作る準備(1) ↓ DBへキャッシュ保存 ↓ ソーシャルカウント取得 ↓ あれこれリンクカード作る準備(2) ↓ リンクカード表示 |
DBへ保存したあとに、ソーシャルカウントを取得するタイミングしています。
順番を入れ替えれば良いのですが、記事そのものは更新しない予定なので、このままだと最初に取得したソーシャルカウントが微動だにしませんΣ(ﾟロﾟ)oﾞ
…そこそこ面倒そう(^-^;
「SNS Count Cache」の外部サイトに対応した版みたいなのがあれば、呼び出す感じで使うのですが…さすがに無さそうですね(^-^;
Pz-LinkCardに使うように作っちゃえば、他のプラグインとかからも呼び出しできて使えるのかも知れませんが…ぷしゅううううう。
パンクしますΣ(ﾟロﾟ)oﾞ
当面、普通にAPIを呼び出す感じで。
本当はレイアウトに手を入れたい…
実はCSS、よく分かってません！Σ(ﾟロﾟ)oﾞ
いえ、全然分かってません！Σ(ﾟロﾟ)oﾞ
当プラグインのCSS見てるとイライラしちゃう方もいるのでは無いかとドキドキしております。
本当は !important つかいたくないのですが、多くの WordPress テーマで !important 使っているので、インポータント合戦状態ですΣ(ﾟロﾟ)oﾞ
セレクタがもっと上手に使えるようになると、!important なんて使わなくても、テーマのCSSに勝てるようになるのかも知れませんが…！Σ(ﾟロﾟ)oﾞ
サムネイルまわりとか、もうちょっと柔軟にしたいのですが、手が付けられていません。
サイト情報を上にしたり下にしたりするのも、position 使えば出来るのだと思うのですが、HTMLソースを生成する段階で対応していたりします(^-^;
（基本は記述順だと思うので、まあ自分の中では正解だとも思っていますが…）
保守画面追加…？
キャッシュを管理する画面を追加したいのですが、なかなか苦戦中。
「削除」ボタンとかありますけど、押してもまだ何も起こりません。
「JavaScriptいやーん！Σ(ﾟロﾟ)oﾞ」
「削除」ボタンじゃなくて、最初は「チェック」にしたんですけど、一番上をチェックにしても、全チェック／全解除の JavaScript が全然動いてくれませんΣ(ﾟロﾟ)oﾞ
「JavaScriptいやーん！Σ(ﾟロﾟ)oﾞ」
いっそ、Aタグでリンクで「削除」とか「再取得」とか付けちゃった方がラクそうです…(^-^;
そして、phpMyAdminを使わないでもキャッシュの内容が見られるようになったので、ざっと見てみました。
「製品サポート」とかなってるのがありましたが、記事を開いてみたところ、カードにはちゃんと「製品サポート」と表示されていました。
リンク先のHTMLソースを見ると、元々 <title>～</title> の間に16進表記で書かれているので、元々こうだったみたいです。
とりあえず、当サイトでお試し使用
とりあえず、当サイトの「Pz-HatenaBlogCard」を「Pz-LinkCard ver0.0.0」に差し替えてみました。
ちなみに標準設定の外観がこんな感じな予定で、上側が「外部サイト」、下側が「自サイト内」のカードです。
Pz-HatenaBlogCard のときは、まんま使わせていただいている「はてブカード」を尊重しつつ、内部リンクも違和感が無いように標準設定では「はてブカード」を意識した外見になっていました。
内部リンクも外部リンクも自前で取得しているので、ぱっと見、「はてブカードじゃないのが貼ってある」と分かるのを標準にしたいと思っています。
でも、標準設定で色付いていると、「うちのサイトの色と違うんだよなぁΣ(ﾟロﾟ)oﾞ」とか敬遠されそうでドキドキです。（小心者）
「色とかカスタマイズできますのでー！Σ(ﾟロﾟ)oﾞ」
「見た目変えられますのでー！Σ(ﾟロﾟ)oﾞ」
「はてブカード風とかもできますのでー！Σ(ﾟロﾟ)oﾞ」
ところで、OGPでサイト名が設定されている場合、外部サイトでもサイト名が表示されています。
キャッシュされていないカードがあるときの表示速度がとても遅いので、記事内のカードを順次スケジュールして取得すると良いのでしょうが…さすがにそこまでは遠いなぁ…(^-^;
その内、人柱バージョンを公開するかも…？Σ(ﾟロﾟ)oﾞ
コメント