Lycolog

adiaryをローカルで開発するための動かす環境構築のログ。

前提条件

• サーバー構成は前段にnginx、後段にapache2を配置し、adiaryはapache2側で動作させる
• 動作URLはhttp://adiary.example.test/のようなサブドメイン付きURLとする
  • adiary.cgiなしでアクセス可能にする
• 開発を楽にするため、ホームディレクトリからシンボリックリンクを飛ばし、VSCodeで編集できるようにする
• nginxやapache2、perlは既にインストールされているものとする
  • apache2はポート8080でListenしているものとする

確認環境

手順

この手順では手描きした内容をteeに書き直しており、正しくファイルが生やせるか見てないので注意。

1. /etc/nginx/nginx.confのhttpセクションのincludeの手前にapacheのupstream情報を追記する

   upstream apache {
     server [::1]:8080;
   }
   

2. nginx→apache2のリバプロ設定の作成

   cat <<'EOF' | sudo tee /etc/nginx/conf.d/adiary.conf
   server {
     listen        [::]:80;
     client_max_body_size 100M;
     server_name  adiary.example.local;
   
     access_log   /var/log/nginx/adiary.example.access.log;
     error_log    /var/log/nginx/adiary.example.error.log;
   
     location / {
       proxy_pass http://apache/;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-Proto $scheme;
     }
   }
   EOF
   
   sudo service nginx restart
   

3. Apache2でadiaryをホスティングするバーチャルホスト設定の作成

   cat <<'EOF' | sudo tee /etc/apache2/sites-enabled/001-adiary.conf
   <VirtualHost *:8080>
         # internal use only domain
         ServerName adiary.example.local
   
         ServerAdmin webmaster@localhost
         DocumentRoot /var/www/html/sites/adiary
   
         # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
         # error, crit, alert, emerg.
         # It is also possible to configure the loglevel for particular
         # modules, e.g.
         #LogLevel info ssl:warn
   
         ErrorLog ${APACHE_LOG_DIR}/adiary-error.log
         CustomLog ${APACHE_LOG_DIR}/adiary-access.log combined
   
         # For most configuration files from conf-available/, which are
         # enabled or disabled at a global level, it is possible to
         # include a line for only one particular virtual host. For example the
         # following line enables the CGI configuration for this host only
         # after it has been globally disabled with "a2disconf".
         #Include conf-available/serve-cgi-bin.conf
   </VirtualHost>
   EOF
   

4. /etc/apache2/apache2.confを開き<Directory /var/www/>のセクションを次のように書き換える

   Options Indexes FollowSymLinks
   AllowOverride All
   Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
   AddHandler cgi-script .cgi
   Require all granted
   

   • Options +ExecCGI -MultiViews +SymLinksIfOwnerMatchの行は標準のserve-cgi-bin.confからパクってきたのでOptions +ExecCGIだけでも動く可能性がある
   • AllowOverride Allはindex.htmlを残したまま表示させないために.htaccessを書くのに使う

5. mod_rewriteとmod_cgiを有効化し、apache2を再起動

   sudo a2enmod rewrite
   sudo a2enmod cgi
   
   sudo service apache2 restart
   

6. /var/www/html/sites/adiaryを作成し、adiaryの動作環境一式を配置

7. 開発し易いように権限を緩和

   chmod 777 -R /var/www/html/sites/adiary
   sudo chown -R <your-user-name>:<your-user-name> /var/www/html/sites/adiary/
   

8. /var/www/html/sites/adiary/.htaccessにadiary用の.htaccessを書く

   DirectoryIndex
   
   RewriteEngine   On
   
   # favicon
   RewriteRule     ^favicon\.ico           /path/to/icon.png [L]
   
   # 正規URLは通す
   RewriteCond     %{REQUEST_FILENAME}     !-f
   RewriteRule     ^(.*)                  adiary.cgi/$1   [L]
   

Apache2でadiaryを動かす理由

結論から書くとnginx + fcgiwrapだとtry_filesの仕様的にadiaryが行うパス解析が上手く行かずに正常に動作しないためだ。

元々ModRewrite前提のCGIとして設計されており、個人的なユースケースがCGIとしての動作であることから、Apacheで動かすことにした。

adiaryの作者がcgiラッパーを作っているため、これを使えばnginxでも動かせそうだが、adiary専用のデーモンを起動するのもなんか嫌というのも理由の一つとしてある。

何より現在このブログが動作している環境が、さくらのレンタルサーバーであり、構成的にnginx + Apacheであるため、この構成を作ることに興味があったというのもあるし、現状のローカル環境ではnginxをフロントに立たせて後ろで様々なものを動かしている都合で、フロントはnginxで捌いた方が管理がしやすいのもある。

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

adiaryは高速に動作し、検索機能やタグツリーがすこぶるいい。そこはいいのだが、MarkdownのパーサーがMarkdown.plをベースに作られているようで、個人的に合わなかった。

また投稿画面もシンプルでいいのだが、膨大にタグがある場合設定に非常に苦労するUIになっていて、これもイマイチだ。

他にも見栄えの問題がある。PCとSPのUIをサーバーサイドで切り替えるというかなり古典的な実装になっていて、ここを潰すだけなら簡単なのだが、全体的にレスポンシブにするにはフルスクラッチで書き直す必要があり、これが非常に骨が折れそうだ。WordPressのテーマを一本書く並みの労力はかかるのでプロのデザイナーに頼めば100万以上はするだろう。

まだ他にも画像に設定されるAlt属性の値がおかしいなど、様々な問題があり今は一旦採用を見送ることにした。

これらを解決するためにはGFMベースのMarkdownパーサーを書き、タグの絞り込みUIを作り、レスポンシブテーマをフルスクラッチで書き、A11y周りの実装を直す必要があるのだが、全部やっていたら一年は掛かるだろうし、正直きついなと思ってしまった。

何より実装言語がPerlというのも厳しさを加速させている。幸いadiaryのコードは比較的奇麗なので、手の入れようはあるのだが、余りにもやることのボリュームが大きすぎる。最低でもMarkdownパーサーとUIとA11yだけは何とかしたいが、そこに注力するほど気力が持つかも怪しいので、ここは努力目標としたい。

因みに現状のサイトhttps://test.lycolia.infoで公開しているが、いったん整備が終わるまで更新はしないつもりだ。途中で飽きて消す可能性すらある。

Markdownパーサーについては、今WordPressで使っているものにもバグがあり、結構運用でカバーしている部分があるので、せめてここだけでもちゃんと作ることができればadiaryに移行してもいいかもしれない。いやでも、テーマも作りたいかも…。

正直今のWordPressサイトを90点とするとadiaryは87点くらいで、かなり惜しい感じなのだ。なお、改造はGitHubのリポジトリをフォークして行っている。

2024/01/29追記

MarkedでMarkdown部分をパースすればうまくいくかと思ったが、さつき記法との兼ね合いで、そう単純ではなかった。ToCと画像挿入、注釈周りがどうにかできればワンチャンありそうな気もするが、adiary本体の処理がかなり密結合してるので骨が折れそうだ。

MarkedにMarkdownをパースさせてやるだけのテキストDBブログならフルスクラッチで自作も考えたものの、adiaryがかなりパフォーマンスに固執した書き方をしているらしいので、どっちかといえばadiaryのMarkdownパーサーを何とか自分好みに改編して解決したい気がした。Marked互換ならとりあえず満足であるが、adiaryの注釈の仕組みはMarkedより優れている部分もあるので、この辺りを取り入れたいとかいろいろあり、前途は多難そうだ。

ただ正直後方互換をあんまり重視する気がないWordPressのアップデート体制や、プラグインやテーマの謎アップデートにも辟易しているところはあるので、乗り換えたいような気もするし、微妙な気持ちである。

2025/01/13追記

脚注に対応させたので、脚注がいったん機能するようになった。

詳細は重い腰を上げてadiaryのMarkdownパーサーを脚注記法に対応させたに書いてある。