Drupal9 環境構築（Docker）

## Drupal の時代が来る？

https://www.itmedia.co.jp/news/articles/2108/27/news108.html

> 落札したANNAIはCMS（コンテンツ管理システム）「Drupal」（ドルーパル）を使ったWebシステム開発を手掛ける。内閣府や東京大学、京都市などのWeb開発に携わった実績を持つという。

入札説明会の段階で、ヘッドレスCMSという点が、比較的論点になっていたと思います。

[「政府統一Webサイト構築に向けたサービス基盤及びデザインシステム等の実証に関する調査業務」に係る入札説明会での質疑応答について](https://cio.go.jp/sites/default/files/uploads/documents/210812_BidBriefingMeeting_QA.pdf)

正直、WordPressで良いんじゃない、と思っていたのですが、そうなんですね。
そうとなったら、勉強しておきますか。
そんな感じです。

## 構成を考える

こちらの構成は、非常に魅力的に感じられました。

https://qiita.com/7tsuno/items/048862dd0c64ae6f1dc5

個人的には、動的であることはCMSの一つの魅力ではないかと思っていたのですが、世界はどうもそうではない、という気もしてきていて、例えば政府サイトなどは、結構CMSから静的サイトを出力するタイプが多いのではないか、という気がしています。（気がしているだけで、エビデンスはなし）

そう考えた時に、コンテンツをDrupalで作って、何かを介して静的サイトを構築する必要があるのではないか、上記構成はこれに応えるものではないか、そう思ったわけです。

## 素のDrupal

とはいえ、まずは、素のDrupal サイトを構築します。
DBも必要だし、Docker 構成にします。

基本的には、こちらの通りです。

https://pu10g.com/node/38

ただし、ディレクトリ権限の設定が必要です。

https://www.y-hakopro.com/entry/2021/01/11/200130

```sh
chmod +x docker-entrypoint.sh
```

しかし、これだけだと、この後のインストール画面で、

```
デフォルトの設定ファイル
デフォルト設定ファイルが存在しません。
Drupal のインストールでは、./sites/default/default.settings.php ファイルをダウンロードしたそのままの状態で、削除も変更も行ってはいけません。
設定ファイル
設定ファイル は存在しません。
Drupal インストーラーはインストールプロセスの中で ./sites/default/settings.php を作成できることを必要としています。 ./sites/default/default.settings.php を ./sites/default/settings.php にコピーしてください。 Drupal のインストールについてのより詳しい情報は INSTALL.txt でご確認いただけます。
```

というエラーになりますので、事前にもう少し権限をつけておく必要があります。
ちなみに、各フォルダも作っておく必要があります。

```sh
chmod a+w default
chmod a+w default/files
```

また、上記サイトで、

> 最後に Drupal の configuration management を有効にするために、固定のUUIDをセットしています。
> このUUIDはプロジェクトごとに変更すると良いと思います

とありました。uuid生成は、こちらで生成してみました。

https://uuid.doratool.com/

準備ができたら、docker compose up して、しばらく待ちます。
ちょっとわかりにくいですが、この表示になったら、スタンバイOKです。

```
drupal_1  | [Sun Aug 29 08:24:13.240857 2021] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
```

ここで、http://localhost:3080/ を開くと、Drupal 9.2.4 のインストール画面が開きました。

そういえば、ポートは

```yml:docker-compose.yml
    ports:
      - "3080:80"
```

にしてます。

プロフィールというところで、初期構成を選択しますが、せっかくなので、プロフィールとして Umamiフードマガジン を選択してみました。

先に述べた、default.settings.php はこのタイミングで発生しました。
ここで改めて対応する場合は、権限を付けて（これはコンテナ内でやらなくて良いです）、イメージを削除（docker rmi）してから改めて　up　する必要があります。

あとは、メンテナンスアカウントなどを設定すると、動きました！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/77307/16ce56b2-85ed-3091-0c5c-63da00ece891.png)

検索、ホーム、記事、レシピのフォントが気になるけど、全体的には良い感じかな。

とりあえず、テーマをBootstrapに変更してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/77307/0a9216b7-23ba-dd1e-34c2-c6a1cb8298b0.png)

ふむふむ。

## ヘッドレス対応

では、ヘッドレスが重視されているようなので、対応してみます。

日本語サイトとしては、真っ先にこちらがヒットすると思います。

https://www.studio-umi.jp/blog/12/357

RESTful Web Services と REST UI の2つのモジュールをインストールすると書かれています。

モジュールのインストールは、日本語だと、「拡張機能」からおこないます。
ところが、行ってみると、ここに用意されているのは、RESTful Web Services と、Serialization。

こちらに、その構成で書かれているので、それに従って、設定していきます。

https://drupalize.me/tutorial/add-rest-endpoint-views?p=3377

手順3で、対象データを選択しますが、今回は、コンテンツ(/admin/content)を指定してみました。

ここで問題。管理画面が思いっきり崩れている。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/77307/9fde4118-d6be-96ca-c8e0-5a6be2463266.png)

管理用テーマはSevenに戻します・・・

その後は手順に従って、無事jsonのプレビューができました。

## このあとどうするか

当初の構成だと、ここから静的サイトの出力に行こうと思いました。

こんなモジュールも提供されており、それはそれでできるようです。

https://annai.co.jp/article/drupal8-tome-ssg

ただ、例えば、検索機能は死んでしまう。
その他、色々制限があることが書かれています。

確かに、自分のブログも、Hugo で静的生成していますが、検索は外部に頼るわけですね。

https://jqinglong.github.io/programmers-office/

ここで、完全に静的にする必要はないかと考え直します。

静的コンテンツは静的にしておきますが、コンテンツ部分はAPI経由で取得する。
JAMスタック構成ですね。

結局そうなるんだなぁ。
まあ、ちょっと今作っているものを、Drupal対応してみようか（続く・・・）。

## Drupal に対する現時点での感想

ここ最近作っているものは、APIを Django REST Framework で作って、フロントをNuxtで作って、Netlify とか、Azure Static Web Apps のJAMスタック環境で動かしています。

https://qiita.com/JQinglong/items/e35294f7a260c5a26ae8

Djang でも、データメンテ画面はそれなりに生成してくれるので、これで良いんじゃないかと思っていました。

ただ、もう少し複雑なデータになってくると、確かに、CMS的な画面が必要になってくるかという気はします。
そもそも、Modelを作って、serializer作って・・・というのは、確かに敷居は高い。
というのが、Django REST Framework に対する、ヘッドレスCMSの優位性かと理解しました。

さらに、WordPressだと、やはり本来ブログツールかな、というのは否定できず、要するにデータ構成がそうなっている。
もちろん、色々拡張して、商品販売とかもできるわけですが、それは標準データからは外れてしまうので、ヘッドレス化した時に、どこまで対応しているか不安（これはやってみていないので、意外とできるものもあるかもしれませんが、それはプラグインが頑張ってくれているのであって、やはりそのプラグインの構成には縛られるはず）。

これに対して、Drupal は、そもそもデータ構成の定義（コンテンツタイプ）が本来の機能となっているため、それをAPIとして提供することが当然想定されている。要するに、ビジュアルに、ノーコードでデータ定義をして、データ作成ができる。これは強いかなと思います。（ちょっと気になっているのは、データの親子関係とか、その辺はこれから勉強）
ここが、Drupal の、WordPress に対する優位性ですね。（合っているかな・・・）

ちょっとポエムっぽくなりました。すみません ><