ハブろぐ - havelog.ayumusato.com

LPO関連の機能

a-blog cmsのv1.3.0から本格的に実装されそうなLPO関連の機能について簡単に。検索エンジンからアクセスがあったときに、検索に使われていたキーワードを利用して、動的にランディングページのコンテンツを変える機能です。たとえば、弊社で制作中のサイトの404ページには、検索エンジンから404にきてしまったときに、検索に使われていたキーワードでサイト内検索した結果を表示するという実装(Ajax)がされています。

公開済みの例だと、株式会社マールさんが制作された、株式会社 JUNIOR【ジュニアー】さんのサイト（参考: 事例紹介）でも有名な機能です。このサイトのトップページに、検索エンジンからブランド名でランディングしたときは、そのブランドに関するコンテンツが表示されます。

検索ページじゃないと検証できない

そんな便利な一連の機能も、そもそも検索エンジンからアクセスしない限り、正常に動作しているかどうかは確認しようがありません。制作中のサイトでソレでは困ることも多いはず。

LPO機能の中核を成す、グローバル変数%{SEARCH_ENGINE_KEYWORD}には、検索エンジン（Google, Yahoo, Bing）からのアクセスがあった場合、検索に使用されていたキーワードが格納されます。この変数自体は、アクセス時のリファラを参照しているだけなので、リファラを任意の文字列に設定してしまえば、好きなように%{SEARCH_ENGINE_KEYWORD}の値を操作できるというわけです。

レッツ★改ざん

前置きが長くなりましたが、そんな事情により今回はリファラを任意に設定できるFirefoxのアドオンを紹介します。

リンク：refspoof :: Add-ons for Firefox

このrefspoofというアドオンは、任意のリファラーになりすましてサイトにアクセスできる機能を持っています。（別に悪いことしてるわけじゃないですよ！）スクリーンキャプチャの「ここでGoogleで検索したときのURLなどをセットします」という部分に、下のような検索ページのURLを貼り付けてみます。

おいしいりんご - Google 検索

おいしいりんご、というキーワードで検索したときのURLを貼り付けます。上のリンクをコピーするか、リンク先に飛んでからURLをコピーします。

a-blog cmsのサイトで実験

さて、a-blogcmsのサイトトップの下部にも検索ワードに反応する部分があります。これも、検索エンジンからアクセスがあると、使われたキーワードでサイト内検索をした結果を表示するようになっています。なので、手っ取り早くa-blog cmsのサイトで検証してみましょう！以下手順。

1. a-blog cmsのサイトにアクセス
2. 前項でGoogleの検索URLを貼り付けた欄の横のspoofをクリック
3. サイトの下部を確認してみましょう！

もちろんそんなキーワードのコンテンツはありませんでしたが、検索エンジンから飛んでるわけでもないのに、リファラーを操作してなりすますことができました。

これで、LPO関連機能の検証もバッチリですね！a-blog cmsで本格的に使うのは、v1.3.0からになりそうですが、今のうちにゼヒ導入してみてください。お役立ちツールです。

HTTPリクエストを減らそう運動モジュール

HTTPリクエストを減らすための手段として、ちょっと着目していたのがData URI（データスキーム）という方法。Data URIは、画像や音声などの色々なファイルをbase64エンコードを通して文字列(URI)に変換する技術です。技術のある人が極まると、えらいことできるらしいですが、今回は画像ファイルとHTMLを一体化させるために使います。

ACMS_GET_Plugin_DataUri(仮)

<?php
require_once ACMS_LIB_DIR.'GET.php';

class ACMS_GET_Plugin_DataUri extends ACMS_GET
{
    function get()
    {
        // 変換対象を正規表現パターンで定義
        $regex  = '@<img.*?src="(/'.DIR_OFFSET.ARCHIVES_DIR.'.*?|/'.DIR_OFFSET.THEMES_DIR.'.*?)"@';

        preg_match_all($regex, $this->tpl, $matches);

        if ( empty($matches[1]) ) return $this->tpl;

        foreach ( $matches[1] as $src ) {
            // 拡張子を取得
            $ext    = pathinfo($src, PATHINFO_EXTENSION);
            // ファイル取得後、base64エンコード
            $pair[$src]  = 'data:image/'.$ext.';base64,'.base64_encode(file_get_contents(DOCUMENT_ROOT.$src));
        }

        $pair   = array_unique($pair);
        $raw    = array_keys($pair);
        $data   = array_values($pair);

        //ズバっと置き換え
        $this->tpl  = str_replace($raw, $data, $this->tpl);

        return $this->tpl;
    }
}
?>

このソースコードを、DataUri.phpとして、/php/ACMS/GET/Plugin/内に配置します。アップデートとかには一切対応しないワンタイムモジュールですが、興味のある方はどうぞ。

今回は、%{ARCHIVES_DIR}{path}のような、archivesディレクトリからの参照が確実である画像ファイルパスを対象にして、いい加減に正規表現マッチングをしています。

画像のHTTPリクエストが減る

ウェブページを表示する中で、HTTP通信の時間的コストはかなり高いです。Data URIとして、画像がHTMLの中に文字列として混ざることで、HTTP通信のコストが減少します。細かいファイルをチマチマと個別で読み込むのは想像以上に読み込み時間を食い散らかしています。

a-blog cmsの場合はHTMLと一緒に、キャッシュもバッチリされてしまいますが、そこまで大きな問題にはならないはず。サイトのページ数によってはDBのcacheテーブルの内容積がモリモリ増えてしまいそうですけど。DBの容量に自信がなかったり、サイトのページ数に自信がある場合は要注意です。

肝心の使い方は

以下、plainやvicuna等、index.htmlのテンプレート1枚で完結しているようなテーマを対象にした説明です。

当ハブろぐの場合は、既存のindex.htmlをindex_raw.htmlにリネームし、新しいindex.htmlとして下記のようなテンプレートを作成しました。

<!-- BEGIN_MODULE Plugin_DataUri -->
<!--#include file="index_raw.html" -->
<!-- END_MODULE Plugin_DataUri -->

元のindex_raw.htmlの出力結果を、最後の最後でDataUriモジュールのフィルターにかけているという感じです。対象にできるimgパスがあれば、片っ端からData URIの文字列に置き換えていきます。

変換された画像は下のようなコードに変換されます。下のコードは、サブカラムの鳥さんの写真の場合です。…連続の英数字なのでハミ出ますが気にしない。

<img src="data:image/jpg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD//gA8Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcgSlBFRyB2NjIpLCBxdWFsaXR5ID0gMTAwCv/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAH4AfgMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAA（以下略！）" width="126" height="126" alt="北端のとり" id="profileImg" />

IEには元のindex_raw.htmlを使います

IEは8以降でないとData URIを表示できません。よって、ルールを使ってUser AgentからInternet Explorerには、すべて元のテンプレートである、index_raw.htmlを直接表示するように設定します。8は対応してますけど、現状のルールにはそんな器用な項目はないので全部ナシです。

そうそう滅多なことは起こらないと思いますが、なんかあったら教えてもらえると助かります。判定をもうちょっと賢くかけばもっと遊べそうですね。ちゃんと速くなるかなー？

フォームIDのログ表示が損してた

a-blog cmsのフォームは、投稿されたデータをDBに保存しているので、後からCSV形式としてダウンロードして集計等に再利用できます。そんな投稿データですが、管理ページ上からもログとして確認することができます。

表示できるものは必要十分に備えているのですが、ちょっと大振りな感じすぎて肝心の投稿データの中身は読みづらい感じです。見栄えで損している感じですね。見せるものはあるのに、もったいないです。

じゃあ変えてみよう

/themes/system/admin/form/log.htmlを編集します。40〜57行目のtable.adminTableを下のコードに貼り替えてみます。アップデート時に上書きされないようにする場合は、件のlog.htmlを、使用中のテーマ/admin/form/log.htmlとしてコピーして編集します。

<table class="adminTable">
    <thead>
        <tr>
            <th>日時</th>
            <th>宛先</th>
            <th>件名 / 本文</th>
        </tr>
    </thead>
    <tbody><!-- BEGIN log:loop -->
        <tr>
            <td nowrap="nowrap">{datetime}[datetime(Y/m/d H:i)]</td>
            <td><p>宛先: <a href="mailto:{mail_to}[raw]">{mail_to}</a></p></td>
            <td>
                <p>件名: {mail_subject} ( <a href="#" class="{datetime}[datetime(YmdHis)]-fade-head">本文を表示</a> )</p>
                <p class="{datetime}[datetime(YmdHis)]-fade-body" style="border-top:1px solid silver;">本文:<br />{mail_body}[nl2br]</p>
            </td>
        </tr>
    </tbody><!-- END log:loop -->
</table>

なんということでしょう

劇的ビフォーアフターとまではいきませんが、ちょっとはソレっぽい感じになったのではないでしょうか。宛先にメールアドレスのmailtoリンクも貼ってみました。

送信時のテンプレートに、To[]でお問い合わせ主のメアドを仕込んで自動応答メール風にしている場合は、このフォームのログ画面からメーラーを起動して、お問い合わせ主に返信を書くこともできます。

「一般メール」をフォームからの送信者への自動応答メールに、「管理者宛メール」をクライアント（orサイト管理者）への送信内容の通知、というように設定しておけば、クライアントに対しては「ここでお問い合わせを確認して、送信者に返信できます」とか言うこともできるかも。

モノは言いようというヤツですね。もっとキレイに飾ってあげれば、もっとモノを言えるかもしれません。