ディスク容量不足！？

何時ものようにgitでコードを更新した後、docker-compose buildを実行すると途中でerror。原因は容量不足で書き込めない。dfで調べると確かにもう99%使っている。

考えてみればテストも兼ね何度もDockerをup/downしているので、不要なコンテナとイメージが蓄積され、ほぼ容量を使い切っている状態だった。

とりあえず綺麗さっぱり忘れるために以下のコマンドを実行。大幅に容量が増えたのを確認。

# コンテナの削除
$ docker ps -aq | xargs docker rm
# イメージの削除
$ docker images -aq | xargs docker rmi

HTTP/2対応へ

アップデートが終わり、v1.3.3を起動しTootを眺めていると、HTTP/2の文字が。「そう言えばまだやっていなかったな…。」と対応することに。

ただCentOS 7で普通にyumすると、OpenSSLはv1.0.1系が入るものの、HTTP/2にするにはv1.0.2系が必要。更にnginxがそれを参照しなければならない。と言うことで面倒だがmake決定。

CentOS 7はminimalを使った関係上、開発環境が入っていない。以下必要なコマンドなどをインストール。

yum -y groupinstall 'Development Tools'
yum -y install wget openssl-devel libxml2-devel libxslt-devel gd-devel perl-ExtUtils-Embed GeoIP-devel rpmdevtools

次に/usr/local/srcでOpenSSLコードを展開。makeして、バイナリを入れ替える。

# cd /usr/local/src
# wget https://www.openssl.org/source/openssl-1.0.2k.tar.gz
# tar zxvf openssl-1.0.2k.tar.gz
# cd openssl-1.0.2k
# ./config shared -fPIC
# make
# make test
# make install

# cd /usr/bin/
# cp /usr/bin/openssl /usr/bin/openssl~
# rm -f /usr/bin/openssl
# ln -s /usr/local/ssl/bin/openssl

# openssl version
OpenSSL 1.0.2k  26 Jan 2017

今度はnginx。事前に./configureに指定するパラメータを現バージョンでメモしておく（configure arguments:）。

# nginx -V
nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) 
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
.
.
--with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'

以降は普通のmake。先にメモした./configureのオプション最後に、

--with-openssl=/usr/local/src/openssl-1.0.2k \
--with-openssl-opt='-fPIC'

この2つを加えて./configureする。

# cd /usr/local/src
# wget https://nginx.org/download/nginx-1.13.0.tar.gz
# tar zxvf nginx-1.13.0.tar.gz
# cd nginx-1.13.0

# ./configure \
--prefix=/etc/nginx \
--sbin-path=/usr/sbin/nginx \
--modules-path=/usr/lib64/nginx/modules \
--conf-path=/etc/nginx/nginx.conf \
--error-log-path=/var/log/nginx/error.log \
.
.
--with-openssl=/usr/local/src/openssl-1.0.2k \
--with-openssl-opt='-fPIC'

# make
# make install

# nginx -V
nginx version: nginx/1.13.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) 
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled

既に.confには

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

http2の記述があるのでnginxをリスタートするだけでいい。

確認はChromeの検証でNetwork / Protocolがh2になっているか（冒頭の画面キャプチャ）、nginxのaccess.logでHTTP/2.0の文字が見えればOKだ。

追記：.confのサンプルではHSTSの設定がこうなっているが、

add_header Strict-Transport-Security “max-age=31536000”;

サブドメインでインスタンスを運用する時には、includeSubdomainsを追加しないと効いてない感じだ。

add_header Strict-Transport-Security “max-age=31536000; includeSubdomains”;

Qualys SSL LABSのスコアがA-！？

いろいろ変わったので再度チェックしたところ、v1.2系でインスタンスを上げた時はA+だったのに何故かA-に落ちてしまった。違いは…と考えてみるとnginxの.confが一部異なっている。

# これだとA-になる
ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA!RC4;

# これでA+
ssl_ciphers EECDH+AESGCM:EECDH+AES;
ssl_ecdh_curve prime256v1;

ここのサンプルをそのまま使うとA-になるので、当初の内容へ戻すとA+に。これで一件落着！

余談になるが今回、安定版の1.3-stableと先行版にBranchした。新機能の購読言語指定などはこの1.3-stableには入っていない。

しかし比較的天候に恵まれたGWに何をやってるのか（笑）

タイムラインに手を加えるには

ログイン後の3カラムの画面、あれは全て自らのAPIで値を取得し、JavaScriptで書いている。例えば、

連合タイムライン
インスタンスURL/api/v1/timelines/public
ローカルタイムライン
インスタンスURL/api/v1/timelines/public?local=true

をブラウザへ入力すると、文字の羅列が表示されると思う。JSONと呼ばれるフォーマットだ。画面描画はこれを元にしている（iOSやAndroidのアプリも同様）。ホームはTokenが必要なので少し細工が必要になるものの、出てくるフォーマット自体は同じだ。

となると、このJSONの中にCardの情報が入っていない場合、タイムラインには表示できない。が、残念ながら添付画像情報のmedia_attachmentsはあるものの、必要とするpreview_cardは無い(どちらもDBのTable名)。

従って改造その1はJSONにpreview_cardを加える作業となる。当然JSONの中身が変わるので、アプリなどの互換性が気になると思うが、（例外もあるかも知れないが）一般的に知らない項目が増えても無視するだけで作動には問題無い。

ただデータ転送量が若干増えるので、微妙に反応が鈍くなる可能性はある。

JSONへpreview_cardを追加する

タイムラインAPIのcontrollerは、

app/controllers/api/v1/timelines_controller.rb

これだ。Status.as_public_timeline()など、modelsのstatus.rbにあるclassを呼んでいる。しかしAPIに関しては、status.rbの中を見てもDBのstatuses Table（Tootの中身）しか実質扱っていない。

別Tableになっているmedia_attachmentsをどこで引っ張ているのか…と、しばし悩んだところ該当箇所を発見。

app/views/api/v1/statuses/_show.rabl

ここで出す直前にmedia_attachmentsをJSONへマージしている。つまりここへpreview_cardを追加すればいい。

# app/views/api/v1/statuses/_show.rablへ追加
child :preview_card, object_root: false do
  extends 'api/v1/statuses/_card'
end

実体は新規で_card.rablを作り中は以下のようになる。

# app/views/api/v1/statuses/_card.rablを新規作成
attributes :url, :title, :description, :type,
           :author_name, :author_url, :provider_name,
           :provider_url, :html, :width, :height

node(:image) { |card| card.image? ? full_asset_url(card.image.url(:original)) : nil }

これで一旦build/assets:precompileをし直し、先のAPIをブラウザで入力すると、

"preview_card":{"url":"https://www.youtube.com/watch?v=2tvooAF67z0","title":"BABYMETAL Kami Band Intro Awadama Fever Columbia SC 2017","description":"BABYMETAL Kami Band Intro Awadama Fever Opening for RHCP Columbia SC 2017","type":"link","author_name":"","author_url":"","provider_name":"","provider_url":"","html":"","width":0,"height":0,"image":"http://192.168.11.205:3000/system/preview_cards/images/000/000/016/original/maxresdefault.jpg?1492667166"},

preview_cardが追加されているはずだ(Cardが無い時は”preview_card:null”のみ)。これで準備は完了。改造その2は、画面側の追加プログラムとなる。

タイムラインへCardを表示する

詳しい話を書くと長くなるので単刀直入に（笑）。詳細表示のCardはここで書いている。

app/assets/javascripts/components/features/status/containers/card_container.jsx
app/assets/javascripts/components/features/status/components/card.jsx

二番目が実際に表示している部分。調べたところタイムラインにも共通で使えそうだ。従ってタイムラインからcard.jsxを呼ぶcard_container_tl.jsxを新規で作成する。

# app/assets/javascripts/components/features/status/containers/card_container_tl.jsxを新規作成
import { connect } from 'react-redux';
import Card from '../components/card';

const mapStateToProps = (state,{status}) => ({
  card: status.getIn(['preview_card'], null)
});

export default connect(mapStateToProps)(Card);

次に実際タイムラインを描画している部分

app/assets/javascripts/components/components/status.jsx

へ、以下を追加する。一番目はコードの初めにimportの山があるので、そこへ挿入。二番目は、コードの最後の方に{media}だけ書かれた行があるので、その横に追記する。

import CardContainer from '../features/status/containers/card_container_tl';

<CardContainer status={status} />

これで準備が出来たので、再度build/assets:precompileすればOK。タイムラインにCardが表示されたら正解だ。

現状の問題点は2つ。

1. ローカルインスタンス内でしかCardが表示されない（但し、これは非改造のv1.3.2でも外部インスタンスは詳細に出ないので同じ症状）
2. リンク先の情報を取得するタイミングが詳細を表示した時なので、誰かが詳細を見ない限り、タイムラインにCardが表示されない

1)はもともと外インスタンスのCardは詳細でも出ないので、システム側の問題だと思われる。2)は投稿した時に自分で確認しつつ詳細を見るのが一番手っ取り早い（笑）。一度詳細を表示すれば情報がDBへ入る。

Card用のデータをFetchするコードは

app/services/fetch_link_card_service.rb

ここにある。以降はまだコードを追ってないので不明。sidekiqのWorkerにもlink_crawl_worker.rbが入っている。

いずれにしてもこれで少しはタイムラインが賑やかになる。ただこれらの改造はブラウザからのアクセスのみ有効で、残念ながら勝手改造を関知しないアプリは無関係だ。

またこの改造によって何か不都合が発生しても責任は持てないので自己責任でお願いしたい。本家に同等の機能が付けば嬉しいのだが…。

追記1：1)の件はBUGのようだ。”cards only get created for local posts”
追記2：v1.4系では後半の表示系PATHが変わった（内容は同じ）。
app/javascript/mastodon/features/status/containers/card_container_tl.js
app/javascript/mastodon/components/status.js

controllers/tags_controller.rbの

# frozen_string_literal: true

class TagsController < ApplicationController
  layout 'public'

  def show
    @tag      = Tag.find_by!(name: params[:id].downcase)
    @statuses = @tag.statuses.order('id desc').paginate_by_max_id(20, params[:max_id]) #####
    @statuses = cache_collection(@statuses, Status)
  end
end

この#####の行を

@statuses = @tag.statuses.order('id desc').where(visibility: [:public]).paginate_by_max_id(20, params[:max_id])

これに変更する。つまり対象をvisibility: [:public]として、一覧に表示するTootを絞っている。

コード修正後のインスタンスの起動は先に書いたここの後半を参考にして欲しい。既にMyインスタンスは修正済みで作動している。

Unlistedとタグ付きDMのネットからの一覧表示問題も片付いたので、これで少しは安心できるかな！？

追記1：参考までにログイン後のHome画面（3つTLが並ぶ画面）では、先のUnlistedも含め問題は発生しない。理由は使っているロジックが違うから。自らAPIを呼んで描画している。

インスタンスURL/api/v1/timelines/public/
インスタンスURL/api/v1/timelines/tag/mastodon

この様に呼ぶとJSONが得られる。同じ方法でネット側（非ログイン系）の画面も作れると思うのだが、何故この様な仕様になっているかは不明だ。

追記2：このBUGはcommit済みとのこと。次のリリースまで待てない時に参考にして欲しい。

@rokuzouhonda これは https://t.co/F6uZPConTA で報告されて、2日前のコミットで修正されたようなので、次のリリースでは直っているかと思います

— masayoshi takahashi (@takahashim) April 23, 2017

追記3：v1.3系で修正済み

Mastodon本体はRuby on Railsで書かれており、昔やったな…と思いながらコードを探すと、controllersのaccounts_controller.rbに

def show
    respond_to do |format|
      format.html do
        @statuses = @account.statuses.permitted_for(@account, current_account).order('id desc').paginate_by_max_id(20, params[:max_id], params[:since_id])
        @statuses = cache_collection(@statuses, Status)
      end
.
.
.

を発見。どうやらmodelsのpermitted_for()でデータを取得しているようだ。該当箇所は、status.rbのここ。

def permitted_for(target_account, account)
    return where.not(visibility: [:private, :direct]) if account.nil?

account.nil?つまり非ログイン時、privateとdirectだけ除外している。ここへunlistedを加え、

def permitted_for(target_account, account)
    return where.not(visibility: [:unlisted, :private, :direct]) if account.nil?

こうすればいい（外に何も出したくない時は:publicも加えればいい）。

ただDockerからシステムを剥がして運用している場合は修正するだけでいいのだが、docker-compose up -dで起動している場合は、一旦downして再度buildしないとこの修正が反映されない。

docker-compose downするのはちょっと嫌なので（笑）、直接コンテナの中を触ることにする。

$ docker-compose ps
        Name                      Command               State 
--------------------------------------------------------------
mastodon_db_1          docker-entrypoint.sh postgres    Up    
mastodon_redis_1       docker-entrypoint.sh redis ...   Up    
mastodon_sidekiq_1     bundle exec sidekiq -q def ...   Up    
mastodon_streaming_1   npm run start                    Up    
mastodon_web_1         bundle exec rails s -p 300 ...   Up

ログインする名前を探す（ここではmastodon_web_1）。

$ docker exec -it mastodon_web_1 ash

でログインできるので、該当コードを修正（viが使える）。

$ docker-compose stop
$ docker-compose start

これでコードが反映される。既にMyインスタンスは修正済だ。

余談になるが、Privateで写真を添付した場合でも、写真のURLが分かればネットから抜けてしまう（大昔のmixiもそうだった）。

真面目に対応するのは結構面倒で且つDBに負荷がかかるので（画像を表示する度に相手との関係を調べる必要があるのと、URLではアクセスできないPATHへ画像を置き、表示する時はリダイレクトしなければならない）、Mastodonが対応するのは望み薄だろう。

追記：この件、どうやら意図的らしいので、pullリクしても駄目な雰囲気。各インスタンスで個別対応だろうか！？

使用OS

CentOS 7(Minimal ISO)、メモリ1GB、2 Core
※実際運用してみると、メモリは2GBあった方が良さそう

インストール手順

1)/etc/sysconfig/network-scripts/ifcfg-eth0
※ネットワーク周りに合わせて設定

2)DNSへインスタンスのIN Aなどを記述

3)yum update、gitなど必要なコマンドをインストール

# yum update
# yum -y install git
# yum install bind-utils
# yum install net-tools

4)firewallの設定

# firewall-cmd --add-port=80/tcp --zone=public --permanent
# firewall-cmd --add-port=443/tcp --zone=public --permanent
# firewall-cmd --reload

5)SELinuxをdisabled

# vi /etc/sysconfig/selinux
SELINUX=disabled
# reboot

6)SSL証明書の取得

$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
$ ./letsencrypt-auto certonly --standalone -d xxxx.xxxx.jp
※xxxx.xxxx.jpは使用するドメイン名（事前に有効なのを確認）
※nginx側は特に設定する必要無し

と、先にオーソドックスなネットワーク関連の設定を済ます。この辺りは他のサーバーでも同じ。

7)Mastodonをclone

$ git clone --depth=1 -b v1.3.2 https://github.com/tootsuite/mastodon.git

8)nginxをインストール

$ sudo vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1

$ sudo yum -y --enablerepo=nginx install nginx

9)docker-ceをインストール

$ sudo yum -y install yum-utils
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
$ sudo yum install docker-ce

$ sudo groupadd docker
$ sudo usermod -aG docker $USER
$ sudo service docker start
$ sudo chkconfig docker on
$ sudo reboot
※この一連を行わないとdocker-composeが作動せず

10)docker-composeをインストール

# curl -L https://github.com/docker/compose/releases/download/1.12.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose

11)Mastodonの設定

$ cp .env.production.sample .env.production
$ vi .env.production
LOCAL_DOMAIN=xxxx.xxxx.jp
LOCAL_HTTPS=true

SMTP_SERVER=smtp.sparkpostmail.com
SMTP_PORT=587
SMTP_LOGIN=SMTP_Injection
SMTP_PASSWORD=xxxxxxxxxxxxxxxxxxxxx
SMTP_FROM_ADDRESS=xxxx@xxxx.xxxx.jp
SMTP_AUTH_METHOD=plain
SMTP_OPENSSL_VERIFY_MODE=none
SMTP_ENABLE_STARTTLS_AUTO=true
※SMTP_PASSWORDはhttps://app.sparkpost.com/dashboardで得たキー
※サイト認証用にDNSへscphxxxx._domainkey.xxxx.xxxx.jp. IN TXT "v=DKIM1;..."を追加

$ docker-compose run --rm web rake secret
※三回実行し得たキーを下記へコピペ。一回目は時間がかかる
$ vi .env.production
PAPERCLIP_SECRET=
SECRET_KEY_BASE=
OTP_SECRET=

$ vi docker-compose.yml
 db:
    restart: always
    image: postgres:alpine
### Uncomment to enable DB persistance
    volumes:
      - ./postgres:/var/lib/postgresql/data

  redis:
    restart: always
    image: redis:alpine
### Uncomment to enable REDIS persistance
    volumes:
      - ./redis:/data
※インスタンスをdownした後でもTootやアカウントを残すため、DB関連のコメントアウトを外す

smtpは、SparkPostというサービスを利用。無料の範囲では送信可能な件数が限られるものの、今回の用途程度なら問題無さそう。サイト確認用のDNSによる認証があるので要注意（これに気付かずハマった）。

12)nginxの設定

$ sudo vi /etc/nginx/conf.d/mastodon.conf
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  listen [::]:80;
  server_name xxxx.xxxx.jp;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name xxxx.xxxx.jp;

  ssl_protocols TLSv1.2;
  ssl_ciphers EECDH+AESGCM:EECDH+AES;
  ssl_ecdh_curve prime256v1;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  ssl_certificate     /etc/letsencrypt/live/xxxx.xxxx.jp/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/xxxx.xxxx.jp/privkey.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 0;

  root /home/mastodon/live/public;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://localhost:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}
※xxxx.xxxx.jpを使用するドメイン名に書き換える

mastodon.confは公式のここにあるので、example.comの部分のみ書き換えればOKだ。

最近、少し内容が変わり、 ssl_dhparamが追加された。事前に

sudo openssl dhparam 2048 -out /etc/ssl/certs/dhparam.pem

を実行すること。

13)起動

$ sudo systemctl start nginx
$ sudo systemctl enable nginx

$ docker-compose build
$ docker-compose run --rm web rails db:migrate
$ docker-compose run --rm web rails assets:precompile
$ docker-compose up -d

$ docker-compose run --rm web rails mastodon:make_admin USERNAME=xxxxx
※USERNAME=は管理アカウントのusername

仕上げは、dailyメンテナンス用のコマンドを1日1回（以上）叩くよう、以下をcrontabに仕込む。

docker-compose run --rm web rake mastodon:daily

ググりながら、インストールしながらメモしたのをそのままコピペしているので大丈夫と思うが、間違っていたら申し訳ない。

身内との遊び用なのでここではURLを掲載しないものの、連合タイムラインに載るのでばれるな（笑）

“筆者のブログは、WordPress REST APIからみでいろいろプログラミングネタを載せているが、さすがにここでそのまま扱うには場違いのような気がするので、まずNoSQLのMongoDBで遊んでみたい。“

記事の最後で同期と非同期について触れているものの、詳細は書いていないので、こちらでフォローしたい。まず「実は単に繋げるだけではうまくいかない。」この部分をテスト。

単純にMongoDBへのロードと検索を繋げると以下のようになるだろうか（以降、コピペで作動。ただしエラーチェックなどは含まず）。

var mongoClient = require('mongodb').MongoClient;
var mongodb = 'mongodb://localhost:27017/test';

console.log('json read start');
mongoClient.connect(mongodb, function(err, db) {
    var http = require('http');

    http.get('http://blog.iwh12.jp/test/tags.json', (json) => {
        var body = '';
        json.setEncoding('utf8');

        json.on('data', (chunk) => {
            body += chunk;
        });

        json.on('end', () => {
            var d = JSON.parse(body); 
            db.collection('tags').insertMany(d).then(function(err, r) {
                db.close();
                console.log('json read end');
            });
        });
    });
});

console.log('search start');
mongoClient.connect(mongodb, function(err, db) {
    db.collection('tags').find({}).toArray(function (err, tags) {
        console.log(tags);
        db.close();
        console.log('search end');
        process.exit(0);
    }); 
});

これを実行すると…。

$ node test1.js
json read start
search start
[]
search end

やはり’json read end’の文字がどこにも無く、検索結果は何も表示されない。これはMongoDBへのinsertMany()が非同期で行われるためで、「insertMany()宜しくね！」で丸投げして、結果を待たず先に進んでしまうからだ。

insertMany()が正常に終わった後、検索するには以下のようになる（見易いよう、検索側を関数にしている）。

var mongoClient = require('mongodb').MongoClient;
var mongodb = 'mongodb://localhost:27017/test';

console.log('json read start');
mongoClient.connect(mongodb, function(err, db) {
    var http = require('http');

    http.get('http://blog.iwh12.jp/test/tags.json', (json) => {
        var body = '';
        json.setEncoding('utf8');

        json.on('data', (chunk) => {
            body += chunk;
        });

        json.on('end', () => {
            var d = JSON.parse(body); 
            db.collection('tags').insertMany(d).then(function(err, r) {
                db.close();
                console.log('json read end');
                dbSearch();
            });
        });
    });
});

function dbSearch() {
    console.log('search start');
    mongoClient.connect(mongodb, function(err, db) {
        db.collection('tags').find({}).toArray(function (err, tags) {
            console.log(tags);
            db.close();
            console.log('search end');
            process.exit(0);
        }); 
    });
}

実行結果は、

$ node test2.js
json read start
json read end
search start
[ { _id: 58f29ed0b0e7000078daf12d,
id: 21,
count: 3,
description: ”,
link: ‘https://blog.iwh12.jp/tag/2in1/’,
name: ‘2in1’,
slug: ‘2in1’,
taxonomy: ‘post_tag’,
meta: [],
_links:
{ self: [Object],
collection: [Object],
about: [Object],
‘wp:post_type’: [Object],
curies: [Object] } },
.
. // 結果の表示
.
search end

と、’json read end’と結果が表示される。一般的に非同期で値を参照するには、コールバック内でしか有効とならず、（今回は1つだが）必要な処理が増えるほどネストも増えコードの見通しが悪くなる。

これを解決するには、本文でも触れたasyncモジュールを使う。npm install async −−saveでモジュールをインストールした上で、コードは以下のようになる。

// npm install async --save
var async = require('async');

var mongoClient = require('mongodb').MongoClient;
var mongodb = 'mongodb://localhost:27017/test';

async.series([
    function (callback) { step1(function() { callback(); }); },
    function (callback) { step2(function() { callback(); }); }
], function (err, results) {
    process.exit(0);
});

function step1(callback) {
    console.log('json read start');
    mongoClient.connect(mongodb, function(err, db) {
        var http = require('http');

        http.get('http://blog.iwh12.jp/test/tags.json', (json) => {
            var body = '';
            json.setEncoding('utf8');

            json.on('data', (chunk) => {
                body += chunk;
            });

            json.on('end', () => {
                var d = JSON.parse(body); 
                db.collection('tags').insertMany(d).then(function(err, r) {
                    db.close();
                    console.log('json read end');
                    callback();
                });
            });
        });
    });
}

function step2(callback) {
    console.log('search start');
    mongoClient.connect(mongodb, function(err, db) {
        db.collection('tags').find({}).toArray(function (err, tags) {
            console.log(tags);
            db.close();
            console.log('search end');
            callback();
        }); 
    });
}

MongoDBへの読み込み（step1）と検索部分（step2）をどちらも関数にし、async.seriesへこのように書く。また各関数に引数callbackと、実際の処理終了部分にcallback();を追加。これにより、callback()が呼ばれるまで先に処理が進まず、見かけ上、同期作動となる。

全ての処理が終わるとfunction (err, results)の部分へ移り、（今回は）プログラムを終了。これなら非同期の数が増えてもコードの見通しが良くなるのがお分かり頂けだろうか。もちろん実行結果は二番目のコードと同じだ。

例えば、WordPress REST APIを使って記事を表示するには、該当するpost idを見つけ、その中にあるcategory idとtag idからカテゴリ名とタグ名を探し、前後の記事idを得るには、少なくともネストが4重になり、いろいろ処理を加えて行くとコードの見通しが非常に悪くなる。このような時に、asyncモジュールを使うと便利だ。

…と、言った内容を、PC Watchのあの後に追加するのは場違いのような気がしたので省略した次第。これで本当の（完）

余談になるが、macOSで構築している開発環境をBashへ移そうとしたところ、mount -t cifsやsshfsなどに対応しておらず、NASの共有フォルダがマウントできないことに気が付いた。RS2でやっとpingなどに対応したばかりなので、ある意味仕方ない部分だ。

ただ仕事場では案件ごとにフォルダ分けしてNASへ入れ、それをmacOSでmount、親フォルダをapacheのDocumentRootにしているが（Web系の内容が多いため）、Bashでは不可能。これでは開発環境を移行できない。

さらにPHPが7系。メンテナンスしている古いサイトはPHP 5.1とか普通にあり（笑）まずそのままでは動かない。このためバージョン違いのPHPをCGIで動かすなど、ちょっとした細工も必要となる。ここまでするならVMでLinuxを動かしても然程労力は変わらない感じがしないでもない。

Part1で使用したasyncモジュールは、いろいろな作動モードがあり、async.seriesで動かした。この場合、callbackが呼ばれるまでは次の処理に進まず、見かけ上、同期作動となる。

ただ考えてみれば、collectionのdrop、各APIの読み込みは非同期で作動しても問題無く、順番待ちをしている時間が無駄になる。従って流れとしては…。

1. 同期用のwp0にあるposts、categories、tagsのdropは非同期だが、全部終わるのを待つ
2. 各APIの読み込みは非同期だが、全部終わるのを待つ
3. 表示用のwpにあるposts、categories、tagsのdropは非同期だが、全部終わるのを待つ
4. 最後にwp0をwpへコピーする

以上の順番さえ守れば、DBの更新に影響なく、加えて、各パートは非同期なので、全てをasync.seriesで行うよりも処理時間が短くなる。このようなケースにはasync.parallelを使用する。

var mongoClient = require('mongodb').MongoClient;
var mongodb_org = 'mongodb://localhost:27017/wp0';
var mongodb_url = 'mongodb://localhost:27017/wp';

var assert = require('assert');
var async = require('async');

var POSTS = 'posts';
var CATEGORIES = 'categories';
var TAGS = 'tags';

var base_url = ['http://blog.iwh12.jp','http://techtalk.pcmatic.jp'];

dbReload();

function dbReload() {
    // drop all collection from wp0
    mongoClient.connect(mongodb_org, function(err, db) {
        assert.equal(null, err);
        async.parallel([
            function (callback) { db.collection(POSTS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(TAGS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(CATEGORIES).drop(function(err) { callback(); }); }
        ], function (err, results) {
            if (err) {
                throw err;
            }
            db.close();
            console.log('drop all collection from wp0.');
            step1();
        });
    });
}

上のvar群は関連するモジュールや変数の宣言で特に説明の必要は無いだろう。ポイントは、async.parallelの部分。wp0の各collectionのdropは非同期で作動し、全部終了した時に、function (err, results)を実行する。

// get all API
    function step1() {
        var api = { tags:'/wp-json/wp/v2/tags', categories:'/wp-json/wp/v2/categories', posts:'/wp-json/wp/v2/posts' };

        async.parallel([
            //site 1
            function (callback) { SetCollection(TAGS, base_url[0], api.tags, function() { callback(); }); },
            function (callback) { SetCollection(CATEGORIES, base_url[0], api.categories, function() { callback(); }); },
            function (callback) { SetCollection(POSTS, base_url[0], api.posts, function() { callback(); }); },
            //site 2
            function (callback) { SetCollection(CATEGORIES, base_url[1], api.categories, function() { callback(); }); },
            function (callback) { SetCollection(POSTS, base_url[1], api.posts, function() { callback(); }); }
        ], function (err, results) {
            if (err) {
                throw err;
            }
            console.log('get all API done.');
            step2();
        });
    }

step1()は、各APIで得たデータをmongoDBに保存する部分だ。前回は順番に行っていたが、今回は5つのAPIの読み込みが非同期作動となる。全て終了後、step2()を実行。

// drop all collection from wp
function step2() {
    mongoClient.connect(mongodb_url, function(err, db) {
        assert.equal(null, err);
        async.parallel([
            function (callback) { db.collection(POSTS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(TAGS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(CATEGORIES).drop(function(err) { callback(); }); }
        ], function (err, results) {
            if (err) {
                throw err;
            }
            db.close();
            console.log('drop all collection from wp.');
            step3();
        });
    });
}

step2()は、wp0をwpへコピーする時、コピー先にcollectionがあると失敗するので、先に3つのcollectionをdropする。dbReload()直後と全く同じで対象がwp0かwpかの違いだけだ。

// db.copyDatabase("wp0","wp")
function step3() {
    mongoClient.connect(mongodb_org, function(err, db) {
        if (err) {
            console.log(err);
        } else {
            var mongoCommand = { copydb: 1, fromhost: "localhost", fromdb: "wp0", todb: "wp" };
            var admin = db.admin();
            admin.command(mongoCommand, function(commandErr, data) {
                if (!commandErr) {
                    console.log(data);
                    console.log('DB Reloaded.');
                } else {
                    console.log(commandErr.errmsg);
                    console.log('DB Reloaded error!');
                }
                db.close();
            });
        }
    });
}

step3()はwp0からwpへDBをまるまるコピーする部分となる。これで一連の流れは完了する。

最後に、APIから得たデータをmongoDBへ保存する＝SetCollection()を掲載する。前回との違いは、フラグを使い中でcollectionをdropする部分を削除している（APIがhttpかhttpsかの判断も追加）。

と言うのも、非同期で作動する場合、記述した順に実行されるとは限らず、dropせずに追記してしまうケースが発生するからだ。今回はこれを避けるため、一番初めにwp0からdropしているのはご覧の通り。

// get data from API and set collection
function SetCollection(collection, base, url, callback) {
    var api_url = base + url + '?per_page=' + 10;
    var max = 0;
    var db;
    console.log('API url: ' + api_url);

    // connect to monogo server
    mongoClient.connect(mongodb_org, function(err, mongodb) {
        assert.equal(null, err);
        db = mongodb;
    });

    // get from API
    getFromAPI(0);

    // get JSON with paginate
    function getFromAPI(n) {
        if (api_url.slice(0,5) == 'https')
            var http = require('https');
        else
            var http = require('http');

        http.get(api_url + '&page=' + (n + 1), (json) => {
            var body = '';

            json.setEncoding('utf8');

            json.on('data', (chunk) => {
                body += chunk;
            });

            json.on('end', () => {
                if (max == 0)
                    max = json.rawHeaders[parseInt(json.rawHeaders.indexOf('X-WP-TotalPages')) + 1];
                var d = JSON.parse(body); 
                db.collection(collection).insertMany(d).then(function(err, r) {
                    console.log(collection, 'page: ' + (n + 1) + ' (' + base +')');
                    if (max == n + 1) {
                        db.close();
                        callback();
                        return;
                    }
                    getFromAPI(n + 1);
                });
            });

        });
    }
}

以前掲載した”WordPress REST APIで得たJSONをNode.jsとMongoDBを使い保存する”に関しても、今回のコードの方がよりロジカルなので、こちらを参考にして欲しい。単一サイトの場合は、step1()のsite 2が不要となる。

Part2で説明するExpress + EJSはmongoDBにwpさえあれば作動するので、今回の部分は別扱いにして、cronを使い一定間隔でDBへリロードするのがいいかも知れない。

実験サイトはこちら。

この時肝になるのが、”APIを使って複数サイトのデータをMongoDBへ保存する方法”と、”post、categories、tagsのIDが被る可能性があるので、それを回避する方法”だ。まずPart1では前者から説明したい。

サイトのソースは、自分のブログと、許可を得て、http://techtalk.pcmatic.jpのブログ、この2つを使っているが（画面キャプチャ上のタイトルがtechtalk.pcmatic.jp、下のタイトルがblog.iwh12.jp）、ロジック上はいくつでも対応可能となっている。

単一サイトからAPIを使いMongoDBにpost、categories、tagsのcollectionを保存するのはもう説明済だが、複数サイトを対象とした非同期での書き込みは、全て完全に終了したのを知るにはいろいろ面倒なことになる。

そこで今回はasync（npm install async）モジュールを使うことにした。使い方は以下の通り。

var async = require('async');
async.series([
    //site 1
    function (callback) {
        SetCollection(TAGS, base_url[0], '/wp-json/wp/v2/tags', true, function() { callback(null,null); });
    },
    function (callback) {
        SetCollection(CATEGORIES, base_url[0], '/wp-json/wp/v2/categories', true, function() { callback(null,null); });
    },
    function (callback) {
        SetCollection(POSTS, base_url[0], '/wp-json/wp/v2/posts', true, function() { callback(null,null); });
    },

    //site 2（tagsは無い）
    function (callback) {
        SetCollection(CATEGORIES, base_url[1], '/wp-json/wp/v2/categories', false, function() { callback(null,null); });
    },
    function (callback) {
        SetCollection(POSTS, base_url[1], '/wp-json/wp/v2/posts', false, function() { callback(null,null); });
    }

], function (err, results) {
    if (err) {
        throw err;
    }
    console.log('Series all done.');

    // response send
    res.send('DB Reloaded.');
});

上から順にAPIが実行され、callbackが呼ばれるまでは次の処理に進まず、見かけ上、同期で作動する。

SetCollectionの4番目の引数はcollectionをdropするかどうか。以前説明したように、DBは差分ではなく、全件保存しなおしているため、2つめ以降のサイトはdropしないようにする。

そしてAPIを処理する側は、http.getのend部分を一部書き換える。追加したのはcallback()。これで一つのAPI呼出しとDBへの保存が終わったことを先のcallbackで知らせ、次の処理へ進むことが出来る。

json.on('end', () => {
        if (max == 0)
            max = json.rawHeaders[parseInt(json.rawHeaders.indexOf('X-WP-TotalPages')) + 1];
        var d = JSON.parse(body); 
        db.collection(collection).insertMany(d).then(function(err, r) {
            if (max == n + 1) {
                db.close();
                callback(); // add
                return;
            }
            getFromAPI(n + 1);
        });
    });

以上で理論上はOKなのだが、実際はAPIを使ったデータの取得が（場合によっては）分単位になるため、DB書き換え中にサイトをアクセスすると、対象となるデータが不完全でエラーとなる。

これを回避するには、同じ構造の同期用DBと表示用DB、2つ持ち、APIでの同期が済み次第、表示用DBへ同期用DBをまるごとコピーするのが手っ取り早い。コードは以下の通り。

// db.copyDatabase("wp0","wp")
mongoClient.connect(mongodb_org, function(err, db) {
    if (err) {
        console.log(err);
    } else {
        var mongoCommand = { copydb: 1, fromhost: "localhost", fromdb: "wp0", todb: "wp" };
        var admin = db.admin();
        admin.command(mongoCommand, function(commandErr, data) {
            if (!commandErr) {
                console.log(data);
            } else {
                console.log(commandErr.errmsg);
            }
            db.close();
        });
    }
});

これはmongoコンソールで、db.copyDatabase(“wp0″,”wp”)とするのと同じ動きとなる。先のAPIでの読み込みをwp0へ行った後、console.log(‘Series all done.’);の後ろにあるこのプログラムでwpへまるまるコピーする。これなら瞬時なので、表示側に影響が出ることは（完全に無いとは言い切れないものの）無いだろう。

但し、表示側（ここではwp）のcollection 3つを先にdropしてからコピーする必要がある。

作動中のサイトはこちら。サイドバーのウィジェットは全てExpressでルーティングしたAPIを使って描画している（Part2で説明予定）。

MongoDBはNoSQLと呼ばれるDBの一種。JSONフォーマットのまま、keyとvalueを操作でき、SQLでdb、table、row、columnに該当する部分が順に、db、collection、document、fieldとなるイメージだ。

今回、WordPress REST APIで得たJSONをMongoDBで扱うのに、db=wp、collection=tags、categories、postsとした。Node.jsとMongoDBのインストールは省略。既に作動するものとして話を進めたい。macOSでもWindowsのBashでも簡単に環境を構築できる。

使用するモジュールは以下の通り。事前にnpm install xxxx −−saveで用意する。

• mongodb
• assert
• http

早速コードその1。ここはロジックに必要な変数などと、MongoDBの初期化まで（}はまだ閉じてないので要注意。その1と2をコピペすれば作動するが、タイムアウトなどのエラー処理は含まれていない）。

var mongoClient = require('mongodb').MongoClient;
var mongodb_url = 'mongodb://localhost:27017/wp';
var assert = require('assert');

var http = require('http');
var base_url = 'http://blog.iwh12.jp';
var per_page = 10;

var POSTS = 'posts';
var CATEGORIES = 'categories';
var TAGS = 'tags';

setCollection(TAGS, '/wp-json/wp/v2/tags', false);
setCollection(CATEGORIES, '/wp-json/wp/v2/categories', false);
setCollection(POSTS, '/wp-json/wp/v2/posts', true);

// get data from API and set collection
function setCollection(collection, url, exit) {
    var api_url = base_url + url + '?per_page=' + per_page;
    var max = 0;
    var total = 0;
    var count = 0;
    var db;

    // connect to mongo server
    mongoClient.connect(mongodb_url, function(err, mongodb) {
        assert.equal(null, err);
        console.log("Connected to server: wp." + collection);
        db = mongodb;
        db.collection(collection).drop(function(err) {
            console.log('Drop collection: ' + collection);
        });
    });

ここでの肝は、はじめにcollection=tags、categories、postsをdropしている点となる(有無を確認せずいきなりdropでも動く)。これを行わないとプログラムを実行するたびに（ロジックにもよるが）各collectionに同じものも含め追加されてしまうからだ。

もともとは全件読み込んだ後にこのプログラムを動かすと追加分だけマージする予定だったが、考えてみればAPIから簡単に得られるのは全件数のみ。

DBの件数と比較してもし+αになっていても、純粋に+α分追加したのか、1件削除+α+1件でその値になったのか知る由もない。また古い内容も何かのタイミングで再編集している可能性がある。

そう考えると、どのみちAPIを使うとデータが飛んできてしまうので、小細工は不要。全件リロードするため、事前にcollectionをdropしている（もちろん全件削除でもいい）。また、dbとcollectionは、無いと自動的に作られる。

コードその2は、各collectionのJSONを得て、MongoDBへ保存している部分。全て再帰呼出しなので件数に制限は無い。exitは、全件取得後、プログラムを終了するか、継続するかのフラグとなる。

// get from API
    getFromAPI(0);

    // get JSON with paginate
    function getFromAPI(n) {
        http.get(api_url + '&page=' + (n + 1), (json) => {
            var body = '';

            json.setEncoding('utf8');

            json.on('data', (chunk) => {
                body += chunk;
            });

            json.on('end', () => {
                if (max == 0) {
                    max = json.rawHeaders[parseInt(json.rawHeaders.indexOf('X-WP-TotalPages')) + 1];
                    total = json.rawHeaders[parseInt(json.rawHeaders.indexOf('X-WP-Total')) + 1];
                }
                var d = JSON.parse(body); 
                d.forEach(function(elem, index) {
                    db.collection(collection).insertOne(elem).then(function(err, r) {
                        console.log(collection, 'page: ' + (n + 1),'item: ' + (index + 1));
                        count++;
                        if (exit && total == count) {
                            db.close();
                            process.exit(0);
                        }
                    });
                })
                if (max == n + 1)
                    return;
                getFromAPI(n + 1);
            });

        });
    }
}

ここは前回の「WordPress 4.7のREST APIを使った記事閲覧プログラム、Post数無制限版」と内容がほぼ同じ。forEachでdocument毎にinsertOne()している。ただMongoDBへの書き込みも非同期でちょっと工夫したのがexitの部分だ。

と言うのも、何も考えずにコーディングすると、if (max == n + 1) return;のところへ、exit==trueならprocess.exit(0);と書きそうになる。が、このタイミングでは、まだMongoDBへの書き込みが終わっておらず実際の件数と合わなくなるケースが発生する。

確実なのはCallback内で、total（=X-WP-Total）と書き込み回数（=count）が同じになったタイミングだ。

実はnの要素を持つJSONをまとめてInsertできるinsertMany()というmethodもあり、forEach無しでper_page分、いきなり全部保存も可能。こちらの方がコードもスッキリするし、おそらくMongoDBの作動も速い。

// forEach、total、countが不要
var d = JSON.parse(body); 
db.collection(collection).insertMany(d).then(function(err, r) {
    console.log(collection, 'page: ' + (n + 1));
    if (exit && n + 1 == max) {
        db.close();
        process.exit(0);
    }
});

これで無事JSON全件が保存された。確認はこんな感じでできる。

$ mongo
> use wp
switched to db wp
> show collections
categories
posts
tags
> db.posts.count();
39
> db.posts.find({id:769}, {title:1,_id:0});
{ “title” : { “rendered” : “WordPress 4.7のREST APIを使った記事閲覧プログラム、Post数無制限版” } }
※¹ :1は表示、:0は非表示（_id=primary keyは必ず表示される）
※² 同様にcollectionのtags、categoriesも操作できる。dbの削除はdb.dropDatabase();

日頃MySQLにお世話になってる身としては、何といっても感動は、詳細を知らないJSONをinsertOne()やinsertMany()でドン！と入れれることと、JSONのまま検索などができること。この手のシステムに向いているDBと言える。

後は、冒頭に書いたようにExpressで簡単なAPIのルーティングを書き、クライアントとやり取りするか、Express＋EJSでViewを書くなどいろいろパターンが考えられる。ただ、連日遊び過ぎでちょっと燃え尽きたので続きが何時になるかは未定（笑）

ポイントは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でスマホからアクセスするとカウントされ、作動を確認。但しプラグインの更新で戻ってしまうので要注意！