Lycolog

adiaryをnginxの上で動作させつつ開発する方法をメモしておく。

前提条件

動作URLとしてはhttps://hoge.example.com/adiaryのようなサブドメイン付きのサブディレクトリとする。

adiaryはネイティブでfcgiをサポートしているらしいが、そこは無視して一般的な環境で起動するのがゴール。

SSLで動かす設定を書いているため、nginxでローカル開発環境向けのhttps環境を作るも参考にすること。

特別な設定は不要で、サブドメインモードにしなくとも動く。

確認環境

手順

nginxはインストールされており、既に稼働している状態として話を進める

# adiaryを格納するディレクトリを作成する
sudo mkdir -p /usr/share/nginx/html/sites
# 既にどっかに展開済みのadiaryをディレクトリに突っ込む
sudo cp -R adiary /usr/share/nginx/html/sites
cd /usr/share/nginx/html/sites
# 所有権とパーミッションの調整
sudo chwon -R $USER:$USER adiary/
cd adiary/
sudo chmod -R 777 __cache/
sudo chmod -R 777 data/
sudo chmod -R 777 pub/
# Image::Magickを入れる
sudo apt install -y libimage-magick-perl
# nginxでCGIを動かすために、fcgiwrapをインストールする
sudo apt install fcgiwrap
# /etc/nginx/conf.dに設定ファイルを作成
cat <<'EOF' | sudo tee -a /etc/nginx/conf.d/hoge.example.com.conf
server {
    listen       443 ssl;
    server_name  hoge.example.com;

    ssl_certificate     ssl/hoge.example.com.pem;
    ssl_certificate_key ssl/hoge.example.com-key.pem;

    access_log   /var/log/nginx/hoge.example.com.access.log;
    error_log    /var/log/nginx/hoge.example.com.error.log;

    # マルチテナント用にこう書いている
    root /usr/share/nginx/html/sites;
    # /usr/share/nginx/html/sites/adiaryにadiary一式が入っている想定

    location / {
        index index.html;
    }

    location /adiary {
        index adiary.cgi;
    }

    # fastcgi用
    location ~ \.cgi$ {
        gzip off;
        fastcgi_pass  unix:/var/run/fcgiwrap.socket;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    }
}
EOF
# nginxの設定を再読み込みする
sudo service nginx restart

トラブルシューティング

403エラーで起動せず、エラーログにパスがないと出る

以下のコマンドを叩き、パスが整合するまで設定を調整する

sudo strace -f -e trace=file -p $(pidof fcgiwrap)

Google Search Consoleで状況を確認してみることにする。（Google Analyticsやレンサバのログ解析も似たような結果になっている）

アクセス数は以前よりかなり落ちている。これはタイミングの問題かもしれない。もし、CMS変更が原因であれば、URL変更やHTMLの構造変更が影響しているのだろう。少なくともコンテンツは丸ごと移してるし、URLのリダイレクトもほとんどは機能しているはずだ。いや実際に機能しているかまで確認はしてないが…。

まぁアクセスが多くても負荷が高まってサーバーが落ちたりするので、このくらいが程よいのかもしれない。

またインデックスについては未登録URLがグッと増えた。グラフを見る感じWordPressのURLがまるっと未登録になり、adiaryの分が増えた感じだろう。adiaryの方が記事URLに対してサイトマップの登録率が高いが、これはadiaryとWordPressでサイトマップのファイル構成が異なることに起因している可能性がある。例えばadiaryはサイトマップが1ファイルなのに対し、WordPressは複数ファイルであるため、Google側の解釈に差が出ているとか、そもそもXMLの内容も違うはずなので、色々影響しているのかもしれない。

インデックス状況についてはWordPressの頃は手動登録しないとインデックスされないことが少なくなかったが、adiaryでは何もせずともインデックスされるので、ここについては大きく満足している。やはりこれはWordPressよりadiaryの方が早いことに起因しているだろう。

以前WordPressで構築していたサイトが頻繁に落ちていることについて記事にしたが、adiaryに変えてからどうなったかというと、恐らく落ちなくなったと思う。

何故そう思ったかだが、今までGoogleにインデックスさせるときは毎回Search Consoleから手動登録していたが、そんなことをしなくても勝手にインデックスしてくれるようになったからだ。BingにもIndexNowを使わずとも勝手にインデックスされている。いや、BingのクローラーについてはIndexNowの有無による差を検証したことがないので有意に改善しているかは正直不明だが…ｗ

少なくともこれでインデックスされやすくなり、以前よりアクセスしやすくなることだろう。読み込み時間が0.3秒変わるだけでブラウザバックが減るとかいう話も昔どっかで読んだ気がするし、0.3秒どころか6秒くらい改善してそうなので、効果はかなり期待できると考えている。

Markdownのレンダリングについても作者に要望を出しまくったので大分改善した。とはいえ、まだ問題点は残るので、そこはMarkdown parserを自作する事で上手いことやっていきたいと思う。結果としてadiaryへの乗り換えは大成功だったといえる。

adiaryは非常に素晴らしいCMSだと思うので、WordPressを使っていて重さに悩む人や、CDNなどの費用を節減したい人は検討されてもいいのではないだろうか？WordPressのように素晴らしいテーマや有益なプラグインは存在しないが、なければ作ればいいので、そういう気概のある人には非常にお勧めできると思う。

また本体やプラグイン、テーマが勝手にアップデートされることがないので「何もしてないのに壊れた」が起きないのもいいところだ。当然、その分の保守能力はサイト管理者に求められるが、本来ホームページ運営というのはそういうものである。一定のリテラシーがないとできないのは当然のことだ。少なくとも昔のインターネットでは常識だった筈だ。

何よりこのCMSは日本製だ、日本人なら日本製に拘ってみるというのもありだろう。

改善の余地は山ほどあると思うので、最近開発から遠ざかっていた人にも大変お勧めできる。adiaryはOSSなので、コントリビュートするのもよし、フォークするのもよしだ。逆にシンプルで複雑さがないので、これで必要十分というケースもあるだろう。

この機会に昔懐かしいPerlに触ってみるというのも一つの経験になるだろう。かつてCGIを書いていた人も、使っていただけの人も、どっちでもない人も、Perlという言語の魅力に触れてみたり、新しく発見してみる一つの機会になると思う。Perlの言語仕様はもしかしたら余り良くはないかもしれないが、夢中になって書いていれば、そんな言語でも新しい発見があったりして、きっと楽しいと思う。

いろんな意味で自分のホームページを作るという意味では非常に良いCMSだと思うので、私はそこが好きだ。

余談だが記事ID「0268」以降がadiaryの記事で、それ以前がWordPressの記事となる。厳密にいうとWordPressの記事の中には、はてなダイアリーやQiitaで書いた記事も入っているのだが、区別する術がないのでWordPressの記事ということで一緒くたにしている。特にない限りCMSの乗り換えはもうしないと思うので、この法則がずれることは恐らくないだろう。

因みに私がフォークしているバージョンでは暫定的にクリップボードの画像を直接アップロードできるように改造している。実験的な機能であるため動作保証などは一切しないが、もし画像が貼り付けられずに不便を感じる人がいたら使ってみてほしい。

skel

1. 書き替えたいコードの所在をgrepする
2. skel/の中に該当する行を見つける
3. skel.local/に該当ファイルをコピーする
4. 該当行を編集
5. ブログの管理＞ブログを再構築する

plugin

skel書き換えでうまくいかない場合

1. 書き替えたいコードの所在をgrepする
2. plugin/配下のmodule.htmlに該当する行を見つける
3. 該当行を編集
4. プラグイン設定＞リセット＞再インストール

参考

• adiary開発マニュアル
  • 大まかな全体の考えを知るのに役立つが細かい情報はなく、リファレンスとしては微妙

前々からGoogle Search Consoleがエラーでクロールできないと言っていたのだが、最近サイトがダウンしている瞬間に出くわすことが増え、やっと意味が分かった。負荷によってMySQLに繋がらない状態になっているのだ（ブーストすると解除されたので、恐らく何かしら制限かかけられているのだろう）

かつてMovaleTypeからBlognに移った時はテキストDBだったので軽くなり、BlognPlusに移った時にDBがMySQLになったのでサイトが重くなったのは記憶に深いし、WordPressにしてさらに重くなったのも記憶にある。うちはさくらのレンタルサーバーで共用なのでDBが重いのだと思う。

私が遭遇するのは深夜帯が多いが、このサイトはIT企業の業務時間中にアクセスが増える傾向があるので、そういったケースでも落ちている可能性がある（ログを見ていなないので推測だが）

更に昨日WordPressのテーマをアップデートしてからYet Another Related Posts Plugin (YARPP)のカスタムテーマが意味不明なエラーを吐き、動かなくなった。

エラーの内容は以下の通りだが、意味不明である。同じ行で同じ名前の関数が再定義されているとか言われている。

Fatal error: Cannot redeclare get_post_data() (previously declared in /wp-content/themes/sango-theme-child/yarpp-template-thumbnail.php:3) in /wp-content/themes/sango-theme-child/yarpp-template-thumbnail.php on line 3

というわけで、WordPressに見切りをつけるかどうか迷っていた矢先だったので、もうWordPressを捨てようと思った。早々にMarkdown parserを書いてadiaryに乗り換えるか、或いは表示が崩れている今でも乗り換えたほうがいい気がしてきたくらいだ。

週末を目途にadiaryへの移行作業を行おうと思う。幸いなことにWordPressからadiaryにリダイレクトするための.htaccessは2024/01/23の記事分までは作ってあるので、ちょっと足せば使える。

markedをadiaryのMarkdown parserに噛まして何とかするのも試したのだが、さつき構文がHTML化されてadiaryのパーサーが上手く食べてくれず、頑張って再パースする必要がありそうなので諦めた。そもそもMarkedのパーサーも地味にバグっていたり、注釈の出力が結構不便だったり不満はあるので、自分でパーサーを書くのは全然ありだと思った。或いはEditor.mdをadiaryにねじ込んで、どうにかしてさつき構文のパーサーを組み込めれば、それも一つだと思う。（が、こいつはクライアントサイドでHTMLを捏ねるのでadiaryの仕組みと相性が悪い）

何よりパーサーを書こうとしただけでブログ記事はポコポコ湧くし、Perlは面白いしで、いろいろ発見があり、退屈な日常が無駄に忙しくなったので、これは是非ともやっていきたいし、やろうという感じで、一旦WordPressを捨てadiaryに移ろうと思う。しばらく色んな記事で表示が崩れるだろうが、現状でもサイト自体にアクセスできないことがあると考えれば大差のない話だと思うし、どうでもよくなった。

むしろ能動的にサイトをいじれるほうがいいし、ある日突然謎のアップデートでサイトが壊れるとか、そういうのは要らないので、平穏なadiaryに移れれば精神的にも安定できるかもしれない。正直WordPress 5でGutenbergが実装されたときとか、軽く絶望したわけで…。Classic Editorがなかったらやっていけないレベル。

というわけで、十数年ぶりの真っ当なサイト制作、再開していきますか～