今回使ったテーマは「Envince」。管理画面、外観/テーマの検索で普通に見つかるものだ。Proバージョンは$69だが、こちらはフリーで使用可能。

選んだ理由として、前のテーマ「twentyseventeen」は、レスポンシブとは言えBootstrapではなく手を入れ辛かったので、今回はBootstrap対応のものを。次にこのTopページを見ればお分かりだと思うが、少し変わったレイアウト編集機能を持つものにした。この手の機能は有料テーマでは一般化しているものの、購入する前に（自作するコストより明らかに安い）少し試して見たかった…と言うのが本音だ。

これがTopページのレイアウト編集画面。固定ページを一枚作り、そこへご覧にWidgetを配置していく感じとなる。投稿一覧だけだと単に日付順に数枚並ぶだけだが、これならカテゴリやタグ、そしてBLOGには無いものさえも意図的に配置できる。少しMagazine風にしてみたが如何だろうか！？

テーマを変更するにあたって最大の問題は、functions.phpに直書きしたshare用のショートコード。metaタグを触る関係でheader.phpにも入っているのでたちが悪い（笑）小テーマのルールに基づき少し変更し無事移植完了。これでテーマの更新があっても上書きされる事もなく、他のテーマにも簡単に引越しできる。

このテーマ、結構気に入っているのだがBUGが一点。ソーシャルメニューをヘッダーもしくはフッターに配置すると、一定の幅以下になった時、右に余白が入る。cssが悪いようだが、直すのは面倒なので使わないことで回避（笑）

仕様として惜しいのは、Widget名の色。テーマ標準とカテゴリ毎でしか設定することができない。タグや別件などはそのままだと標準の色になってしまうのだ。これに関してはcssでダイレクトに色指定することで対応した。

手を入れ易くなったので、このテーマが何日持つかは不明…。そう言えば、複数WordPress一本化サイトも、4つの合体に加えデザインも少し触ったので興味があれば是非！

ポイントはper_pageパラメータnの時に、何ページ分の記事があるかを知る方法と（＝ajaxを実行する回数）、非同期でajaxを使う場合、Callbackの中でしか値を参照できず、ページ分ループし得た値をマージするにはちょっとしたコツが必要となる（同期でajaxを使う場合は普通のループで問題無い）。

主要部分のコードは以下の通り。キーは、レスポンスヘッダにあるX-WP-TotalPagesと、ファンクションの再帰呼出し（recursive call）。

var posts_per_page = 10;
var url_base = 'http://blog.iwh12.jp/wp-json/wp/v2';
var url_posts = url_base + '/posts?per_page=' + posts_per_page;

// get Posts
function getPosts() {
    var posts_all = [];
    var max = 0;

    getPages(0);

    // get n page until max
    function getPages(n) {
        $.ajax({
            type: 'get',
            url: url_posts + '&page=' + (n + 1),
            dataType: 'json'
        })
        .done(function(data, textStatus, jqXHR) {
            Array.prototype.push.apply(posts_all, data);
            if (max == 0)
                max = parseInt(jqXHR.getResponseHeader('X-WP-TotalPages'));
            if (n + 1 == max)
                setDataTables(posts_all);
            else
                getPages(n + 1);
        });
    }
}

コードから分かるように、全てのデータをマージするため、Callback内でgetPages()をページ数だけ再帰呼出ししている。また初めの一回目にレスポンスヘッダから最大ページ数を保存、その値と、カレントのページ数を比較して、同じになるまで配列のマージを繰り返し、同じになったらDataTablesに値をセットして戻る…といった感じだ。これで記事数が100件超えてもいくらでも読み込める（最大何件まで行けるかは不明）。

ただ以前のコードは、そもそもWPがJSONを組み立てるのが遅く（ショートコードやfunctions.phpも展開するため）、それを解決するのにcrontabへcurlを仕込み、ファイルでのやり取りをしていたが、この手が使えなくなってしまった。最初に全件ロードするのでそれなりに時間がかかるものの、一旦ロードすれば、後はオンメモリなので、動作は非常に速く快適に操作可能だ。

こうしてpostに関しては無制限になったが、category（子category未対応）とtagは最大100件のまま。これに引っかかることはあまり無いと思われるので省略した（同じ方法で対応は可能）。

改良版の記事閲覧プログラムはこちら。

これまでNode.jsはメッセージング系で少し触ったことがあるものの、Webサーバー、つまりApacheの替わりとしては使ったことがなかったので、WordPress 4.7のREST APIがある程度分かったついでに実験したくなった（笑）。

但し、管理画面も実装するならともかく、Viewだけだとクライアント側のみで出来るので、わざわざサーバー側でやることもなく、あくまでも遊びだ。

全体の概要

Node.jsの開発環境はググるといろいろ出てくるので省略。当初はWindowsのBashを使用したものの、WindowsからBashへのファイルのやり取りが面倒（逆はOK）だったので^{*追記あり}、後半はmacOSへ移行した。どちらもnodebrewを使えば簡単に環境を構築できる。

npmでインストールしたモジュールは以下の通り。

• express
• ejs
• http
• compression
• memory-cache
• lru-cache

最後の3つは軽くパフォーマンスアップするもので無くても作動する。またサイトがhttpsの場合は、http（http.get）モジュールではなくhttpsモジュール（https.get）を使用する。

ここにコードを載せても載りきらないので要点はこんな感じだ。

• Expressでのルーティング
  app.get(‘/’ …
  app.get(‘/page/:pages’ …
  app.get(‘/tag/:tags/page/:pages’ …
  app.get(‘/category/:categories/page/:pages’ …
  app.get(‘/post/:postId’ …
  ※例えば/pageといった、1ページだけのルーティングは省略
   
• 各ルーティングで必要なデータをREST APIで得る
   
• 一覧表示の各内容は、content.renderedにimgなどタグも含めそのまま入っているので、<!−−more−−>までで切り出す
   
• paginateで必要な最大件数/最大ページ数はJSONにはなく、レスポンスヘッダのX-WP-TotalとX-WP-TotalPagesに入っているので、例えばhttp.get(url, (d)とすると、d.rawHeaders[]のn番目に先の文字列があり、n+1が欲しい値となる
   
• REST APIで得たデータを加工してテンプレートejsへ渡す
  index.ejs（他の一覧も兼ねる）
  post.ejs

テンプレートはこの2本だけだが、実際はヘッダー、サイドバー、フッターなどを別ejsにしてincludeするよくあるパターン。htmlのフレームワークはお馴染みBootstrapだ。

API仕様の気になる点

プログラム自体は簡単だが、実際に動かして思ったのは、純粋に一覧だけ（title、date、categories、tags、featured_media程度のみ）得るAPIが無いため、何をするにしてもpostsでデータを得る必要がり、JSONのデータ量と、それを作るときのサーバー側の負荷（ショートコードやfunctions.phpの内容も展開する）が結構かかる。

加えてサムネイル画像を一覧に出そうとすると_embedオプションを付けなければならず、更にデータ量が増す。ここのように遅いサーバーだとその差は体感ではっきりわかるほどだ。

本家はたまたまアイキャッチ画像（featured_media）を使わず、記事の頭に大き目の画像を入れてあるので、これには引っかからなかったが、一般的には重い処理となるだろう。

本家にあって、こちらに無いのは「前後記事へのリンク」と「Archivesの年月一覧」。今のAPI仕様ではどうみても全件データを引っ張って解析しない限りこの2つには対応できないように思う。

一部クライアント側でレンダリング

一点手抜き（？）したのは、サイドバーの各一覧。これはサーバー側ではなく、クライアント側で書いている。もともとウィジェットを置く場所なのでこれもありかなと…。

ちょっとアクロバティックなのはPopular Posts。これはWordPress Popular Postsがウィジェットとして表示しているもので、実体はadmin-ajax.php?action=wpp_get_popularを呼ぶとリストのhtmlが戻ってくる形になっている。ただそのまま呼ぶとクロスドメイン制約で値を得られない。

そこで同じサーバー内にあるのを利用して、curlを使い一定間隔でそのhtmlをファイルへ保存、参照する形にしている。

これで無事表示は出来るのだがリンク先は本家。実験サイトではないため、このままだとあまり意味がない。また本家のURLはタイトルベース、実験サイトはIDベースなので、ドメインの部分だけ置換しても作動しない。

「うーん」と思っていたところ、表示するサムネイル画像のファイル名にIDが入っていることが分かり、それを使って実験サイトへのURLになるよう書き換えた（笑）

雑感

仕上げはサーバーへの設置だ。Proxyを設定するのが面倒なので、iptablesでポート3000を開けそのまま外に出している。この時、スクリプトをデーモン化する必要があり、forever -w start app.jsで起動。無事、外からアクセスできるようになった。

一式やってみた感想は、当初Node.jsの話を聞いたとき、既にいろいろあるのに何故今更JSと思ったが、サーバー側もクライアント側も全てJSで書け分かり易い上にデバックもし易く、これはありだ。

またテンプレートエンジンのEJSは、htmlそのまま<% %>の中だけJSの世界となりとっつき易い。つまり普段、LAMPを使っていれば、ベースの部分は何も学ぶ必要がなく、各モジュールの仕様だけ理解すれば（しかもJS）即扱える。これはなかなか楽しいかも知れない。

Node.js+Express+EJSで再構築したBLOGのViewはこちら。

追記

「WindowsからBashへのファイルのやり取りが面倒」と書いたが、/mnt/c/Users/にWindowsのファイルシステムがマウントされているので、ここならどちらからでも普通にアクセスできる。

更にVisual Studio Codeの総合ターミナルをBashに変更すればかなりGoodな環境となる。

Visual Studio Codeの総合ターミナルでBashが作動中

方法はメニューのファイル/設定/基本設定/ユーザー設定で、

{
"terminal.integrated.shell.windows": "C:\\Windows\\sysnative\\bash.exe",
"termnial.integrated.shell.unixlike": "bash.exe"
}

これを追加すればOK。もちろんviやnode app.jsもこの中でそのまま作動！

Instagramを張り付けた時、ImageObjectを付加しないよう、エラーを根本的に修正するにはAMPプラグインの内部を触らないとできないため＝無理（笑）。この記事だけAMPを除外する必要がある。いろいろググったところ発見！

記事編集画面で個別にAMPをON/OFFできるので非常に便利。コードをそのままfunctions.phpにコピペして、問題無く作動している。感謝♪

一覧は画面キャプチャから分かるように、Id|Date|Title|Category|Tagsが並び、選ぶと下にcssのcolumnsを使った三段組のViewが表示される。こうしたのは出来るだけスクロールして読みたくなかったから。妙な部分で切れるケースもあるが、実験的な意味合いなので気にしないことにする。

検索は、一覧の項目内容に加え、実際のContentの内容も対象になっている。これはDataTablesにデータを渡しているが、 { data: “content”, visible: false }と、非表示にしているので一覧では見えないだけだ。

ContentをDataTablesへセットする時の肝は、JSONで得られるContentはhtmlがそのまま入っているので、imgがあった場合（srcset=も含む）、テーブルロード時に、imgデータも一緒にGETしに行き、余計にロード時間がかかってしまう上、非表示なので何の役にもたたない。

escape／unescapeを自作するのは面倒なので、Underscore.jsを使った。これでテーブルロード時、記事中にあるimgをGETしなくなる。もちろんViewに書くときはunescapeしなければならない。

30件未満の記事をロードしてこの待ち時間。基本テキストデータと言うこともあり、1000件程度はオンメモリでも大丈夫だと思うが、待ち時間が長くなる。実用的にする場合はpaginateの実装が必要だろう。ただそうすると検索が一覧にある範囲しか効かなくなるので痛し痒し…。

とは言え、APIの仕様上、最大100件／回なので、いずれにしても件数が増えればpaginateするか、JSONを分割してそれをマージする必要がある。

しかしこれ、サーバー側で対策しておかないと、複数のWPサイトからJSONをGETしてマージすれば、簡単にキュレーション（と言うよりパクリ）サイトができてしまう。流石に企業は無いと思うが、個人レベルなら技術的にも簡単なので実在するかも！？

デモサイトはこちら。ついでに上のメニューにも追加（笑）

追記1：どうやらJSONのやり取り以前に、WordpressがJSONへ値を作り込む方が時間がかかっているので、crontabにcurlをセット、一定間隔でJSONファイルを作成、それを読み込むように変更した。

多少本家のBLOGとタイムラグが発生するものの、毎日何本も書かないので問題無い。大幅に速くなった♪（キャッシュ更新のタイミングでcurl動かす手もあるか…。）

追記2：Bootstrapを使って書き換え、幅によって、Contentを3段2段1段表示へ

REST APIの仕様はここにあるので、ざっと眺めたところ、結構遊べそうな内容が書かれている。例えば記事の情報を得たければ、

https://blog.iwh12.jp/wp-json/wp/v2/posts/428

428は記事のid。「Asynchronous Javascriptプラグインを有効にするとsrc=undefinedを追加するBUG修正」に相当する。またidが無ければ全ての記事が対象となる（デフォルト10件）。

これをJQueryの$.ajaxでやり取りすれば、本来のデザインとは違う別のページを簡単に表示することが可能だ。テストで軽く作ってみたのがこちら。コードは以下の通り。

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Wordpress REST API TEST</title>
</head>
<body>
<div style="width: 600px;">
    <div id="title" style="font-weight: 800;"></div>
    <div id="date" style="text-align: right;"></div>
    <div id="content"></div>
</div>
<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function() {
    $.ajax({
        type: 'GET',
        url: 'http://blog.iwh12.jp/wp-json/wp/v2/posts/428',
        dataType: 'json'
    })
    .done(function(data, textStatus, jqXHR) {
        console.log(data);
        $('#title').html(data.title.rendered);
        $('#date').html(data.date);
        $('#content').html(data.content.rendered);
    })
    .fail(function(jqXHR, textStatus, errorThrown) {
        console.log('fail');
    });
});
</script>
</body>
</html>

もう少し本格的なのを作ってみるかな…。

プラグインの設定で「visitors」があったので、これをキーワードにコードを検索すると該当箇所を発見。

// wordpress-popular-posts/wordpress-popular-posts.php 
if (
(0 == $this->user_settings['tools']['log']['level'] && !is_user_logged_in()) || 
(1 == $this->user_settings['tools']['log']['level']) ||
(2 == $this->user_settings['tools']['log']['level'] && is_user_logged_in())
) {
  add_action( 'wp_head', array(&$this, 'print_ajax') );
  // Register views from everyone and/or connected users
  if ( 0 != $this->user_settings['tools']['log']['level'] )
    add_action( 'wp_ajax_update_views_ajax', array($this, 'update_views_ajax') );
  // Register views from everyone and/or visitors only
  if ( 2 != $this->user_settings['tools']['log']['level'] )
    add_action( 'wp_ajax_nopriv_update_views_ajax', array($this, 'update_views_ajax') );
}

ここを

if ($_SERVER['REMOTE_ADDR'] != 'xxx.xxx.xxx.xxx') { // 任意のIPアドレス
}

で囲めばいい。仕事場のルーターからログインせずアクセスしてもカウントされず、4Gでスマホからアクセスするとカウントされ、作動を確認。但しプラグインの更新で戻ってしまうので要注意！

まずmod_pagespeedをOFFにしなければならないが、OFFにすると全てのページに影響するので、/ampのあるurlだけOFFにする。以下を.htaccessへ追加。

ModPagespeedDisallow “*/amp/*”

次に、BJ Lazy Loadプラグインも無効にすると全ての画像に影響するので、function.phpへ以下のコードを追加。AMPプラグインが生成したページのみ無効とする。

function bjll_compat_amp() {
  if (function_exists('is_amp_endpoint') && is_amp_endpoint()) {
    add_filter('bjll/enabled','__return_false');
  }
}
add_action('bjll/compat','bjll_compat_amp');

これで取りあえず投稿ページのみがAMP対応となる（urlの後ろへ/ampを付ける）。

構造化データでもlogoとショートコードshareを使った時のimageでエラーがあったのでコードを追加。

add_filter('amp_post_template_metadata','amp_modify_metadata',10,2);
function amp_modify_metadata($metadata,$post) {
  global $share_image_url;

  $metadata['publisher']['logo'] = array(
    '@type' => 'ImageObject',
    'url' => 'http://blog.iwh12.jp/wp/wp-content/uploads/2017/02/amp_logo.jpg',
      'height' => 60,
      'width' => 600
  );

 if(empty($metadata['image'])) {
    $image_info = getimagesize($share_image_url);
    $metadata['image'] = array(
      '@type' => 'ImageObject',
      'url' => $share_image_url,
      'height' => $image_info[1],
      'width' => $image_info[0]
    );
  }

  return $metadata;
}

logoは元々無いので作ってアップロード（幅600px以下、高さ60px以下）。ショートコードでshareした時の画像urlはglobal $share_image_urlに入っているので、そこから値をセット。これでエラーは無くなった。余談になるが、このコード、あっちこっちで同じものを見かけるが、arrayの最後は,不要。

この他、Google AnalyticsとGoogle AdSense、フォントの設定なども別途必要となるものの、これはググれば山のように出てくるので省略。

AMP化したこのページはこちら。しかし、古のiモード時代ならともかく、4G回線とパフォーマンスやメモリ、パネル解像度などが一般的なPCに追いつけ・追い越せ状態のスマホで、少し速いだけの（画像を数枚貼れば誤差の範囲）こんな味も素っ気もないページを見る（もしくは作る）必要あるのだろうか？

Nginx/fastcgi_cacheなど大したこと（？）をする前にこのスコアが出てしまったのでもういいか！？と言うところ。Googleには好かれたらしい（笑）設定は以下の通り。

Server Side
・PHP 7.1.1（FastCGI/mod_fcgid）
・mod_pagespeed（apache module）

WordPress Plugin
・WP Fastest Cache
・BJ Lazy Load
・Asynchronous Javascript
※速度に関係しそうなPluginのみ記載

たったこれだけ。

基本的に画像やjs/cssのオプティマイズはmod_pagespeedに任せて、Pluginはキャッシュと、遅延/非同期の読み込みを担当。PHPは7系になっているが、管理画面以外の表示はほぼキャッシュなので、ほとんど関係無いと思われる。

この結果を見る限り、サーバーの反応速度より（正直このサーバーは速くない）、html/js/css/imgの最適化、見えないエリアで画像を表示しない、JavaScriptの非同期…など、スマホ重視で今どきのチェック項目を優先しているようだ。

自分のサイトはどうなのか？気になる方はMobile Website Speed Testing Toolでチェック！

日頃Facebookには結構な量を書き込んでいるので（友人限定）、その中から公開しても問題無さそうなネタだけ、こちらでもピックアップしつつ、補足コメントなどを入れたいと思ってる。また三日坊主になるかも知れないが、取りあえずメモ替わり。

下のブロックはAmazonJSプラグインのテスト。うまく作動してるようだ。