私はDrupal CMSをMacBookProにインストールしています。開発というより最新技術の確認用としての利用でありしばらく触っておらずアップデートが溜まっていたのでアップデートを行います。
私のDrupal CMSはプレリリース版をインストールしています。過去の記事で触れましたが、Drupal CMSが開発途中でのリリースにより、Beta版のモジュールを使用しており、その影響で管理画面上にエラーや警告が出てしまいます。
エラーや警告の修復を行う為にモジュールの強制削除などをしており、私のDrupa CMSは少しイレギュラーな状況になっています。
Drupal Coreが11.1.5のままでしたので、現在の最新版Drupal Core 11.2.2にアップデートします。Composerでのアップデートを行いますがDrupal Core 11.1.8のアップデートで止まり11.2.0には依存関係からアップデート出来ません。
イレギュラーな設定をしたモジュールとの依存関係からアップデート制限がかかっているので、原因となるモジュールのアップデートを試み依存関係の修復を試みますがエラーで先に進みません。
色々調べますが、エラー修復や再構築を行うよりも、クリーンインストールした方が早く後々を考えても良さそうなので、現状インストールしているDrupal CMSを削除して、新たにDrupal CMSのインストールを行います。
私のMacBookProでのDrupal開発環境はOrbStackとDDEVを使用しています。今回のようにプロジェクトを追加したり削除したりが非常に簡単に出来ますので、Docker環境のメリットを再確認しました。
- 最近、仮想環境とコンテナのメリットが少し理解できて来ています。簡単に追加削除できる異なる指定環境（PHPのバージョンやDBのバージョンなど）のLAMP環境が簡単に用意出来ます。
- 異なる指定環境（PHPのバージョンやDBのバージョンなど）で開発出来ることは、複数のプラットフォームが異なるWebサイトを構築したりする際に非常に恩恵があります。
この2つのアプリケーションを使い以下の形でDrupalを動かしています。
- Macのローカル環境にOrbstackが提供するLinux仮想マシンを稼働、デフォルトでコンテナとして稼働
- Linux仮想マシン上にDDEVを使用しLAMP環境(Drupalに最適化)を構築してDrupalをインストールしています。
Introduction.
久しぶりに、Local環境を動かすので、DDEVをはじめComposerやDrushの使い方を忘れてしまっています。ローカル環境はセキュリティ上SSHの管理者権限の制約がないのでVscordでほとんどの作業が完了出来ます。コード確認やファイルの階層の確認、ターミナル一を一箇所で管理出来るのは非常に効率的です。
余談ですが、公開しているDrupalのサイトはVsCord+GitではなくDrupal管理画面とSSHで管理しています。DrupalはCMSであり基本は管理画面での編集作業が多くVsCordを使いGit管理にすると面倒なのでこの形での管理としています。
CSSの変更作業などエディタを使用する作業はターミナル上からviを使用しています。実作業はターミナルを使用しますが、ファイルの置き場所やディレクトリ構成の確認を一見で確認したい場合sftpクライアント(私はTransmitを使用)を使うとGUI上でサーバー構成を確認できます。sudoの許可はSSH以外はしていないのでsftpでの作業はできませんが、サーバー構成をGUIで確認出来るメリットはあります。
sftpクライアントを使用するメリットはいくつかありますので機会があれば記事にしたいと考えています。
今回の作業
- インストール済みのDrupal CMSのアッデート > アップデートが上手く進まないので、再インストールを行う > 既存のDrupal CMSの削除
- 新しいDrupal CMSのインストールをAppにて行ってみる > Appのインストールに問題があるので断念 > AppでインストールしたDrupal CMSを削除
- DDEVでDrupalCMSのインストール > エラーの確認と対応
1.Drupal CMSの削除
開発用モジュールの警告やエラーの対応を無理やり行った為、Drupal CMSで使用しているモジュールの依存関係に問題があります。そのため今回 Drupal Core 11.2.x系へのアップデートが上手くいきません。今後のことを考えたら削除して再インストールを行う方が結果的に良さそうなので既存のDrupal CMSを削除します。
Drupal CMSもDDEVで管理していますので、DDEVを使い削除します。
DDEVでのDrupalの削除
DDEVでのDrupalプロジェクトの削除は、DDEVが管理するWebやDBを削除します。DDEVでの削除後、ディレクトリにはDrupalの設定ファイルが残りますが、使用しないのであればディレクトリ毎削除しても大丈夫なのでディレクトリも削除します。
// DDEVのプロジェクト削除
---
% ddev delete drupal-cms --omit-snapshot --yes
---
# ddev delete : プロジェクトの削除
# drupal-cms : プロジェクトディレクトリ
# --omit-snapshot : DBのバックアップ
# --yes : 削除の確認をしない
---
// DDEVプロジェクトの確認
% ddev list
┌──────────┬────────────────────┬────────────┬───────────────────────────┬──────────┐
│ NAME │ STATUS │ LOCATION │ URL │ TYPE │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ dr-cv-tm │ stopped │ ~/dr-cv-tm │ │ drupal11 │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ dr103 │ stopped │ ~/dr103 │ │ drupal10 │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ dr11 │ stopped │ ~/dr11 │ │ drupal11 │
├──────────┼────────────────────┼────────────┼───────────────────────────┼──────────┤
│ Router │ OK │ ~/.ddev │ http://127.0.0.1:10999 │ │
└──────────┴────────────────────┴────────────┴───────────────────────────┴──────────┘
# drupal-cmsは削除されていますDDEVでプロジェクトの削除が完了しましたので、ディレクトリの削除をします。Finderでディレクトリを選択して"ゴミ箱に入れる"を選択し、その後ゴミ箱を空にすれば完全に削除できます。コマンドラインから削除する場合は以下になります。
#Drupal CMSのディレクトリを削除
% rm -rf drupal-cms
# drupal-cmsのパスを確認してください2.Drupal-CMS Desktop Appによるインストール
Drupal CMSはデスクトップアプリからもインストールできますので今回試してみました。
- Desktopアプリのダウンロード(Apple Silicon)。
- Zipファイルの解凍。
- MacのアプリケーションディレクトリにDesktopアプリを移動。
- Desktopアプリを起動しインストール。
と非常に簡単にインストールが完了します。
インストールが完了し、管理画面にログインしようとすると問題が生じます。指定のURLがlocalhost:8888となっていますがブラウザでアクセスするとエラーが表示されています。
The website encountered an unexpected error.
エラーの原因を探すのでインストール先の確認を行います。htdocsなどローカルのApacheのパスが通っているディレクトリを見ますが、インストールしたdrupal-cmsのディレクトリは見つかりません。
Finderでdrupal-cmsの検索をかけたら驚きました。インストール先が、Macの書類ディレクトリになっています。。。流石にこれでは話にならないので、今回初試みのDrupal-CMS Desktop Appのインストールは諦め、従来通り、DDEVとComposerでのインストールにします。
今回インストールしたDrupal-CMSもデスクトップアプリも必要ないので削除します。特に依存関係はないのでFinderで選択し"ゴミ箱"に入れるで大丈夫です。MySQLやApacheが動いている可能性もないわけではないので以下のコマンドで確認してから削除を行うと安全です。
% ps aux | grep drupal
s-takeda 28475 0.0 0.0 410724848 1440 s002 S+ 3:56AM 0:00.00 grep drupal
# grep drupalのプロセスのみなので、DrupalやMySQLは稼働していません。3.Drupal CMSのインストール
過去にインストールしたDrupal CMSを削除し、デスクトップアプリも削除したので、DDEVを使いDrupal CMSをインストールします。
DDEVのDrupal CMSのインストール
久しぶりにDDEVを使いMacBookにDrupalをインストールしますので、DDEVの使い方を復習します。
DDEVの基本にプロジェクトはディレクトリ単位となっています。ディレクトリ内に.ddevを置いてプロジェクトを管理します。
# プロジェクトのディレクトリを作成し移動
% mkdir dcms-01 && cd dcms-01
---
# プロジェクトの設定をします。
% ddev config --project-type=drupal11 --php-version=8.3 --docroot=web
# プロジェクトはDrupal :Drupal11を使用 : --project-type=drupal11
# PHPのバージョンは8.3系 : --php-version=8.3
# ドキュメントルートのパスをwebディレクトリとする : --docroot=web
# 本来DBの指定などを行う必要がありますが、QuickInstallはこのあたりをデフォルトで行ってくれます。
---
# DDEVの起動
% ddev start
---
# Drupal CMSのインストール
% ddev composer create-project drupal/cms
# Composerを使いインストールをします。
---
# Drupalの起動と設定
% ddev launch
# Drupal CMSが立ち上がり、サイトのタイプを選択(Blogを選択)
メールアドレスとパスワードを入力するとDrupal CMSの管理画面にログインします。
---以上でDDEVのDrupal CMSのインストールは完了します。
インストール状況の確認
ddev describeで設定状況の確認が出来ます。ローカルなのでDBのパスワードがdb/db、root/rootとなっていますが、本番環境では推測されないUser/Passを設定ください。
web,db,mailpit(ローカルフォームメールのテストで重宝します)とコンテナになっています。Dockerのメリットにプロジェクト毎にWEBのPHPのバージョンを変えたり、DBのバージョンを変えることが出来ます。
# インストール状況の確認
% ddev describe
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Project: dcms-01 ~/dcms-01 https://dcms-01.ddev.site │
│ Docker platform: orbstack │
│ Router: traefik │
├──────────────┬──────┬──────────────────────────────────────────────────────────────────────────────┬────────────────────┤
│ SERVICE │ STAT │ URL/PORT │ INFO │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ web │ OK │ https://dcms-01.ddev.site │ drupal11 PHP 8.3 │
│ │ │ InDocker -> Host: │ Server: nginx-fpm │
│ │ │ - web:80 -> 127.0.0.1:32788 │ Docroot: 'web' │
│ │ │ - web:443 -> 127.0.0.1:32789 │ Perf mode: mutagen │
│ │ │ - web:8025 -> 127.0.0.1:32790 │ Node.js: 22 │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ db │ OK │ InDocker -> Host: │ mariadb:10.11 │
│ │ │ - db:3306 -> 127.0.0.1:32791 │ User/Pass: 'db/db' │
│ │ │ │ or 'root/root' │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ Mailpit │ │ Mailpit: https://dcms-01.ddev.site:8026 │ │
│ │ │ Launch: ddev mailpit │ │
├──────────────┼──────┼──────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ Project URLs │ │ https://dcms-01.ddev.site, https://127.0.0.1:32789, │ │
│ │ │ http://dcms-01.ddev.site, http://127.0.0.1:32788 │ │
└──────────────┴──────┴──────────────────────────────────────────────────────────────────────────────┴────────────────────┘
言語設定がデフォルトの英語なので、日本語に変更します。
Drushで翻訳のインストール
言語設定 /admin/config/regional/language のデフォルトが英語になっていますので日本語を追加してデフォルトにします。ここで日本語を指定してもすぐに日本語が反映されず、管理画面が全て英語のままですので、Drushで一気に翻訳を進めて管理画面を日本語にしてしまいます。
# 翻訳の更新が必要なプロジェクトを表示
% ddev drush locale:check
---
# 翻訳ファイルをダウンロード＆インポート
% ddev drush locale:update
---
# キャッシュをクリア
% ddev drush cr
--- 以上で管理画面が英語から日本語になります。
エラーの考察
今回インストールしたDrupal CMSのDrupal Coreは最新のDrupal Core 11.2.2となっています。モジュールも最新版がインストールされていますが、一部開発用のモジュールがコアプログラムにインストールされ、エラーや警告が出ています。
この開発用モジュールが出す、エラーや警告はDrupal公式で認定されています。（エラーや警告は基本無視して大丈夫）私が前回ハマったautomatic_updates や package_manager のエラーや警告の解消の根本的な原因が実は、Drupal公式が認定していたエラーや警告で、そのエラーや警告を潰すために四苦八苦してしまったのが顛末だったと今回気がつきました。。。
Drupal CMSはDrupalの従来のイメージである、開発者が使用するCMSというイメージからWordPressのような一般ユーザーが気軽に利用出来るCMSとしての裾野を広げる為に進化しています。
インターフェースの洗練や、コマンドラインではなくGUIで全て完結出来るインターフェースや目的毎にパッケージ化されたディストリビューションなど、よりユーザーライクなCMSへと変貌を遂げています。
モジュールやテーマが、WordPressのように管理画面からワンクリックでダウンロードして自動インストールしたり、更新もcronで自動化するなど、ユーザーがシステムを意識せずサイトを構築し、運営できる機能を実装している途中なので、今回のようなエラーや警告を出してしまっています。
# エラー
Package Manager
Package Manager is available for early testing. To install the module set the value of 'testing_package_manager' to TRUE in your settings.php file.
# 警告
Experimental modules installed
実験用のジュールが見つかりました: Navigation, Package Manager。実験用のモジュールはテスト目的でのみ提供されています。自己責任で使用してください。
Drupal CMS
Project Browser のGUI上でモジュールやテーマを検索して Package Manager でGUi上からインストールやアップデートが可能になるとWordPressのテーマやプラグインと同様なインターフェースが構築されます。
そのことでサードパーティーのマーケットが形成される可能性を持っています。優れたモジュールやテーマは有料でも利用される可能性が出ますので、開発が進み利用者も増える事でDrupalの普及が進む好循環が生まれる可能性があります。
開発者にとってはこれまでとは異なるインターフェースへの対応という産みの苦しみのような開発経過への対応をしている最中であり、対応として用意された実験用モジュールでの配布にたまたま遭遇して、無理やり解決しようとした顛末が、前回苦戦したエラー対処であったと考えるとなるほどと納得できる出来事であります。
私自身がせっかちで新しいもの好きなところがあり、アップデートは即対応、不具合も即対応という運用スタイルをしています。今回のようなシステムそのものが変化するような大きなアップデートに対しては少し様子をみるという慎重さも必要であると考える出来事でした。
settings.phpのパーミッションの変更
Home > 管理 > レポート > サイトの状態
保護が無効
ファイル sites/default/settings.php は変更に対して保護されていないため、セキュリティー上の危険性があります。 ファイルのパーミッションを書き込み禁止に変更してください。
ローカルでの使用なので、基本無視しても問題ありませんが、Drupalインストールのルーティンなので対応します。本番環境では必ず対応してください。
このエラーはsetting.phpのパーミッションの問題です。Drupalのインストール時点でsetting.phpは644に設定されていますので444[読み取り専用]に権限を変更します。通常は以下のコマンドで解決します。
$ cd web
$ chmod 444 sites/default/settings.php
早速変更します。
パーミッションの変更
iTermからコマンドを入れ、パーミッションを変更します。
DDEVの構成
DDEVはコンテナで動いています。以下が構成図になります。
|-ddev-dcms-01
| |-db
| |-web
|
|-ddev-router
| |-ddev-router
|
|-ddev-ssh-agent
|-ddev-ssh-agent今回のエラーを解消するために権限を変更するsettings.phpはMacのターミナルに表示されるdcms-01/webではなくOrbstackのコンテナであるddev-dcms-o1/webにあります。このsettings.phpの権限を変更する必要がありますので変更するにはddev-dcms-01/webのコンテナにsshで接続する必要があります。コンテナへのssh接続はDDEVのsshコマンドで行います。
DDEVでコンテナにssh接続
DDEVのsshでコンテナに入りsettings.phpの権限を変更します。
# ddevのsshを使用しコンテナにログインします。
% ddev ssh
---
#ディレクトリ構成の確認
$ cd web/sites/default
$ ls -al
# settings.phpの権限は読み書きとなっています。
-rw--r--r--- 1 s-takeda dialout 36727 Dec 7 18:37 settings.php
---
# 権限の変更をします。
$ chmod 444 settings.php
# 変更の確認をします。
$ ls -al
// 読み込みのみの444に変更されています。
-r--r--r-- 1 s-takeda dialout 36727 Dec 7 18:37 settings.php
---
# キャッシュをクリアします。
$ drush cr
[success] Cache rebuild complete.
---
# sshの終了
$ exit
---
# 参照 Macのターミナルで作業する際は、パスの関係でコマンドの入力前にddevを入れる必要がありますがコンテナ内ではddevを入れる必要がありません。
# Macのターミナル
% ddev drush cr
# Orbstackのコンテナ内
$ drush crDDEVのコンテナにsshで入りweb:/var/www/html/web/sites/default/settings.phpの権限を読み書きから読み込みのみに変更し保護が無効の警告を解消しました。
Adminコンソールでエラーの確認
Home > 管理 > レポート > サイトの状態
1エラー 1警告 29確認済み
開発用モジュールの1エラー、1警告、はありますが問題なくアップデートされました。
Conclude.
Drupal-CMSが24年12月にリリースされ半年経ちました。本番環境での利用はもう少し様子を見る必要があるかなと考えています。プレリリースの状況から半年間で進化しています。インターフェースが異なった管理画面も最初は使いにくいと考えていましたが、今回各機能の配置などを時間をかけて確認してみると、非常に洗練されたインターフェースになっています。
私自身がDrupalの利用期間が1年未満と短く、まだまだ理解すべき事が山積みですが、WordPressに比べDrupalの優れた点や、私自身に合っていると感じる点は多数あります。一般的な評価とは異なりますが、構造の厳格化とルールの厳格化が私にとってDrupalを使用する一番のメリットであります。
構造の厳格化とルールの厳格化で思い出すのが、30年ほど前に、PC-UNIXと言われ、PCにUNIXを移植し実利用が可能になり、そこからLinuxやFree BSDが登場し普及します。現在の状況をみるとLinuxの普及が圧倒的でFreeBSDはLinuxに比べるとあまり普及しませんでした。
当時、周りのエンジニアもこぞってLinux(RedHat系)を使用しており、FreeBSDは少数派でした。理由は利用者が多く使用方法も確立されていて業界スタンダードの地位を固めていたRedHat系を使うのは当然でしたが、私はFreeBSDを好みました。
その理由が構造とルールの厳格化が徹底されており、どこに何を設置しているかの把握がしやすく、当時の脆弱なハード構成から無駄なものは徹底して省き軽いシステムを構築（ドライバーの削除など）するという用途において使いやすかった事があります。
Druplaのポリシーがどことなく当時のFreeBSDの思想に近いと感じることが私がDrupalを利用する一番の理由になります。
今回のDrupal-CMSのリリースが、これまでのDrupalの良い部分を活かしながら利用者の裾野を広げていくことを願っています。
仮)Dupalのセキュリティ管理
本来今回の記事でまとめようと考えていたDrupalのセキュリテイ管理についてまとめてみます。ただ、セキュリティに関連する記事となるためどこまでを記事としてまとめて良いのかが悩みどころです。