このサイトをD10.3.1に上げた

Drupal 11への移行準備もかねて、さくらのクラウド上のテスト環境で、Ubuntu22.04でDrupal 10.3.1環境でのテストを行ったところ、いくつか気になる点はあったが、大丈夫そうだということがわかったので、GCPの本番環境で10.3.1への更新を実施した。

このサイトでは記事のアクセスをCoreのStatisticsモジュールを用いてカウントしてきたがD11では外される（Deprecated and obsolete extensions）。CoreのStatisticsモジュールをアンインストールしてから、新しいStatisticsをインストールすると、当然のように過去のデータが失われてしまうが、アンインストールしないままインストールすれば、過去のデータが残り、Deprecated modules installed警告からStatisticsが消える。同じ名前なので心配したが、無用な心配だった。

それ以外で、Deprecated modules installedで残ったのは、Layout Builder Expose All Field BlocksとTourだ。Tourは単にはずせばOKで、当サイトの場合はLayout Builder Expose All Field Blocksも外しても困らない。これらは、急いで外す必要もないと考えて放ってある。テスト環境でUpgrade Statusを確認すると、まだコントリビューションモジュールはD11対応が進んでいないし、drush 13も待つ必要がある。このサイトは実運用を含めた実験環境でもあり、頻繁に触っているのでできるだけ新機能、新環境に挑戦したいと思っているが、D11化はリリース後すぐには無理だ。

Drupal10.3とDrupal11.0の新機能の「Drupal11のアップグレードはいつやる？」はとても参考になると思う。私の気持ちとしては機能拡張が大きくなりそうなD11.1が出る前にD11には上げたいと思っている。Starshotへの移行も検討したい。

ちなみにユビキタスライフスタイル研究所のWebサイトもD10.3.1に上げた（同時にUbuntu22.04に移行、nginxからApacheに移行した）。こちらは、ほとんどコントリビューションモジュールを使わないようにしている。しかし、アップデートするとフロントページでニュース記事Viewsブロックでフルページャーを使っていた部分でレイアウトが崩れるのでミニページャーに変更した。ページ数が少なければ全数チェックも可能だが、受託サイトの維持管理は易しくない。受託サイトではないが当ブログサイトのOS移行を考えると、実験的に導入したライブラリのどれをインストールしなければいけないかオーナーとしての取捨選択も求めなければいけなくなるし、それなりの手がかかる。なるべく、Coreだけを使う形にしたいと希望する歴史あるユーザー（運営者）の声はよく分かる。同じユーザーでも企画側、営業側の声は見栄えや機能拡張に傾き、とにかくやれという事になって後で運営側が地獄を見るシーンも何度も見てきた。適切なバランスを取るのは結構難しい。

画像

noteなどの外部サービスを利用してブログを書けば面倒から開放される一方で、自分の手から離れる部分が増えてしまう。何を大事にするのかは個人の価値観による。ただ、一定の能力を獲得しないと自分の自由にできる範囲は限られてしまう。そういう意味ではDrupal CMS（Starshot）に大きく期待している。自力でできる範囲が大きくなれば、プロフェッショナルサービスで収入を得る範囲は小さくなる。長い目で見れば、好ましい変化だと思うが、事業者としては環境変化への対応を不断に続けなければならない。