私はGroupモジュールに魅力を感じてる。CMSの地平を変えるものだとすら思う。ただ、まだ端緒にあって今後モデルそのものが変遷していって恐らく最終的にはCoreに入ることになるだろうと思っている。
Webページの管理にCMSを利用するのはかなり常識化した。そして、複数ユーザーのBlogサイト等の構築では、執筆者とコンテンツを結びつけて考えなければいけないので、ユーザー管理が行われるようになった。さらに、内容の適切性をチェックする必要があるケースに対応して「草稿執筆→編集者承認による公開」といったワークフローも利用されるようになっている。さらに、チーム内だけに限定公開したいというニーズも生まれ、一人の執筆者が複数のチームに属するとか、ニーズはどんどん拡大する。
Drupalは編集ワークフローに関しては、CoreにContent Moderationモジュールを組み込み、標準ワークフローを提供している。状態管理という観点では優れた機能を提供しており、私も複数の案件で実用している。すごく捨象すれば、このモジュールを上手に使えば、非公開と公開のワークフロー管理は可能になる。
DrupalのGroupモジュールが正式リリースになり、同時にDrupal 9対応を完了した。しかも、リリースノートにANNAIがクレジットされている。
とても、幸せな気分だ。
今日の早朝（昨晩深夜）に初オンライン開催のDrupalCon GlobalのDries noteを聴講した。
このブログを6月12日にGCPに移して実運用を始めて1ヶ月弱。先月の請求額は0円だった。
Static IPは設定時に、サーバーを消去する前に削除を忘れたのが原因。Storage PD Snapshot in USは、スナップショットを取得する際にローカルでなくUS全域で利用可能な選択をしてしまったミス。実際に発生したのは、Network Internet Egress from Americas to Chinaの0.3円、中国からのアクセスに対する課金である。本当に無償で運営できることは良くわかった。
実運用で感じるのは、やはりマシンパワーの非力さだ。メモリーが小さいのとCPU能力が低いのでComposerの処理に非常に長い時間がかかる。定常的なコンテンツ制作や参照については、特に問題は感じないので、アップデート対応の方法を考え直せば、実運用上の問題は消えると思う。ローカルPCに環境を作るのか、別の環境を準備するのか少し悩むところだ。
故あって、Drupalサイトへのチャットツールの組み込みを調査した。結論から言えば、組み込みは簡単にできる。しかも、条件が整えば無償だし、商用で有償サービスを利用しても、恐らく元は取れるだろう。ただし、技術的に容易に組み込みが可能ということと、ビジネスでチャットツールをどう使い、どう位置づけるかは別の問題であることもわかった。この記事では、最初に「別問題」と思った背景に触れて、その後に技術的な話をする。
私が、初めてWebサイトでチャットを使ったのは何だったか思い出せないが、多分英語でサポートを得る必要があるときだったのではないかと思う。コールセンターにつながるまでに長く待つのも嫌だし、つながった後に英語の（相互）聞き取りに苦しむと悲しくなるし、用が足せないこともあるから、チャットの方がマシだと思ったからだ。今は、言語に関わらず、どちらかと言えば、コールセンターにつなぐ方を好むが、チャットツールはチャットツールの良さがある。URLリンクを正確に伝えたり、選択質問などは、口頭でやり取りするより遥かに優れている。
このBlogを開設した時に、設定資料は匿名アクセスからガードしようと思って、Content Accessモジュールを導入し、特定のContent Typeに対して、匿名ユーザーのアクセスを不可にして、認証済みユーザーからのアクセスを可能にするように設定していた。Google Loginを許可するようにした段階で、誰でも認証済みユーザーになれるようになっていたので、ザルになっていたのもある。対象コンテンツが2つしかなくて既に古くなっているので気にしていなかった。
残念がら、Content Accessの現在のリリースは8.x-1.0-alpha1 released 7 November 2017のままだ。ユーザーも多く、devは動いているので9への対応も問題はないと思うのだが、Groupモジュールの方がユーザー数は下がるが拡張性が高く魅力的で動きも活発なのでGroupモジュールに移行した。とりあえず、Content Accessでやっていたのと同様の設定を「確認済みユーザー」という権限に対して実施した。
2つ問題点を発見。
一夜経過して、早速Google Adsenseのコンソールで警告されてしまった。
実際にads.txtをWebで表示させてみると、Forbiddenになっていて読めなくなっている。既存の環境と比較して違うのはapacheからnginxに変えたことだけど、まずは.htaccessを疑った。とは言え、まずは、「ads.txt forbiden」でググってみた。1件目は日本語の.htaccessに関する記事だったので、とりあえず目を通すのだがしっくりしない。もう一度一覧を見ると4件目に「How To Enable Google Adsense ads.txt file for Drupal on Nginx」という記事が出てきたのである。これはビンゴかも知れんという事で、中身を見ると
ある意味で仕上げの回。今回は、当Blogを本当に移行してしまうことにして実行した。
実際にやったのは、/etc/nginxの下で、virtualホストをDefaultファイルをコピー・修正してhagihara.tokyo, takayuki.hagihara.tokyo, www.hagihara.tokyoを作成し、/etc/letsencrypt/renewalの対応部分でapacheになっている部分をnginxに書き換えて、DNSを切り替えた。念のため、証明書も早期更新したので、今日からの証明書に変わっている。
非力なので、composerが遅いのが痛いが、通常にWebとして立ち上げている分には、使えないわけではない。当面はこの状態で、走らせてみることにする。
中国からのトラフィクが多少課金されているが、1ヶ月の課金予想額が1円。ほぼ無料で運用できそうである。使っていれば、ノウハウが溜まってくるし、いろいろトラブルにも巻き込まれるだろう。ひょっとしたら、続報があるかも知れないが、一旦終了。
今回の一連の作業で、nginxとletsencryptの動きが大分理解できたのとDebian 10に少し慣れたので、やがて何かの役に立つだろう。
今回は、Let's Encryptを利用して、https用の電子証明書の設定を行う。途中、数点ひっかかった。
まず、
sudo apt install certbot python-certbot-nginx
でcertbotを導入する。このやり方は、https://certbot.eff.org/lets-encrypt/debianbuster-nginxで調べられる。
前回に引き続いて、セットアップを継続。まず最初は、PHPの初期値2項目の設定を行う。
php.iniの初期値では、
post_max_size = 8M
upload_max_filesize = 2M
だが、ファイルのアップロードが2Mだと小さすぎるので、この値を大きくしておく必要がある。個別の制限はともかく、phpのレベルではねられると面倒なので、一応どちらの値も128Mにしておくこととする。ただ、この値を大きくしてしまうと、アップロード権限がある人が大きなファイルを上げてしまって、ディスクを食ってしまう危険があるので、もっと小さくしておく方が良いかも知れない。
