====== Drupal 10 sous Virtualmin-Apache-Debian 12 ======
===== Cas d'utilisation =====
Je souhaite installer un site web motorisé par Drupal 10 sur un système Debian 12. Le serveur est administré par Virtualmin et utilise Apache pour serveur web. Le site est implanté dans un //serveur// ou //sous-serveur//, au sens de Virtualmin, créé à cet effet.

Configuration initiale :
Debian 12
Virtualmin GPL
Apache fournit par les dépôts Debian 12
Multiples version de PHP

La capacité du serveur à fournir des services web administrés par Virtualmin a été validée, au préalable.
===== Particularités de Drupal 10 =====
Drupal 10 peut être installé manuellement((Détaré.)) comme une application web quelconque. C'est jouable pour un test mais vivement déconseillé dès qu'il s'agit d'assurer la sécurité et la disponibilité d'un site web opérationnel. 

Cette fiche décrit les adaptations nécessaires permettant d'installer, maintenir et exploiter un site Drupal 10, en suivant les procédures standard recommandées par Drupal.

===== Composer =====

Source : [[https://getcomposer.org/download/|Download Composer]].

J'ai choisi d'installer //composer// localement((Les arguments dans ce sens dépassent le cadre de cette fiche.)). Dans le cas d'utilisation considéré, //composer// est installé dans l'espace de l'utilisatrice propriétaire du serveur((Car cette utilisatrice souhaite avoir une gestion homogène de //composer// pour l'ensemble de projets/sites (serveur et sous-serveurs). Vous pouvez souhaiter une installation plus générale ou plus spécifique.)) //Virtualmin// ayant vocation à héberger le site sous //Drupal//.

J'installe suivant mes habitudes sous Debian((Il existe plusieurs manières d'arriver au même résultat.)) :

récupération de //composer//…
<code>
~$ cd tmp
~/tmp$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
~/tmp$ php -r "if (hash_file('sha384', 'composer-setup.php') === 'e21205b207c3ff031906575712edab6f13eb0b361f2085f1f1237b7126d785e826a450292b6cfd1d64d92e6563bbde02') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
~/tmp$ php composer-setup.php
~/tmp$ php -r "unlink('composer-setup.php');"
</code>

mise en place et configuration…
<code>
~/tmp$ cd
~$ mkdir .local
~$ mkdir .local/bin
~$ touch .bash_profile
~$ nano .bash_profile

    insertion de : if [ -f ~/.bashrc ]; then
                           . ~/.bashrc
                   fi
                   PATH=$PATH:~/.local/bin

                   export PATH
                   unset USERNAME

~$ mv tmp/composer.phar .local/bin/composer
~$ source ~/.bash_profile
~$ composer --version
</code>
==== Optimisation ====
Sans l'imposer, //Composer// réclame l'installation de PHP-cURL afin d'améliorer sa vitesse de traitement. Sous Debian, la fonctionnalité est apportée sous la forme d'un paquetage additionnel. Après s'être assurée qu'il n'est pas déjà installé, on l'installe avec les précautions d'usage concernant la version :
<code>
# php --version
PHP 8.2.13 (cli) (built: Nov 24 2023 13:10:42) (NTS)
# php8.2 -m | grep curl
# apt install php8.2-curl
</code>

===== Installation d'un site test =====
==== Chargement et implantation ====
<code>
~$ composer create-project drupal/recommended-project public_html
</code>
==== Racine du site web ====
<note>
L'installation via //composer// invite à considérer deux notions distinctes :
  * la racine du __projet__, au sens de //composer//
  * la racine du __site web__, au sens usuel, c'est-à-dire du serveur web((//DocumentRoot// sous //Apache//, //root// sous //Nginx//…)).
La documentation utilisera souvent le seul terme "racine". Il revient à la lectrice de l'interpréter comme l'une ou l'autre, suivant le contexte((Certaines mauvaises pratiques d'installation cherchent à gommer cette distinction en fusionnant les deux répertoires. Sans entrer dans les détails, cela conduit à donner accès à toutes sortes de fichiers qui vous ne souhaitez absolument pas publier sur le web !)).
</note>
Dans l'arborescence standard de //Virtualmin//, la racine du site web est censée être le répertoire //public_html// situé dans le répertoire principal du serveur ou sous-serveur.

Par soucis de régularité et de lisibilité des arborescences gérées par Virtualmin, le répertoire //~/public_html// a été utilisé comme cible de l'installation via //composer//. Cela fait de //public_html// la __racine du projet__, au sens de //composer//. Suivant cette procédure,  la __racine du site web__ se trouve alors dans le sous-répertoire "web" (~/public_html/web) créé lors de l'installation((Pour des raisons de maintenabilité, on écarte toute alternative consistant à __altérer la configuration de l'installateur__ visant à éviter la création du sous-répertoire //web//.)).

La configuration standard((Si on est amenée à gérer plusieurs sites Drupal, on peut souhaiter créer un //template// spécifique.)) du serveur virtuel Apache mise en place par Virtualmin doit donc être adaptée en conséquence :

Virtualmin > my_server > Web Configuration > Website Options > Website documents sub-directory = //public_html/web//
==== Configuration et lancement ====
Au préalable, on aura créé une base de donnée et une utilisatrice disposant des droits sur cette base.
<note>Une installation minimale est suffisante pour conduire le test. Elle est recommandée si l'on souhaite utiliser le site ainsi créé pour y migrer un site motorisé par une ancienne version majeure de Drupal.</note>
Il n'y a plus qu'à pointer un navigateur web sur l'url de base du site :
<code>
http://mon-site.org/
</code>
On remplit le formulaire. On laisse en l'état les valeurs par défaut des "Advanced options".
<note tip>En fin d'installation, il est possible que le serveur //Apache// affiche une erreur d'exécution. Une consultation des logs doit permettre d'identifier la cause. L'opération finale d'installation étant relativement lourde, il est possible que le temps d'exécution alloué aux processus PHP soit dépassé ((La valeur par défaut du template par défaut de Virtualmin est de 30 secondes.)).

Pour accéder à cette valeur et la modifier : Virtualmin > my_server >Web Configuration > PHP Options > Maximum PHP script run time </note>

Une fois l'installation effectuée, Drupal signale un risque de sécurité découlant d'une configuration incomplète dans settings.php((Dans l'exemple : ~/public_html/web/sites/default/settings.php)). Se rendre dans la section "trusted_host_patterns" de ce fichier pour compléter la configuration (L'auto-documentation du fichier est parlante).
===== Drush =====
Sources :
  * [Drush - Install](https://www.drush.org/12.x/install/)
  * [Drupal Compatibility](https://www.drush.org/12.x/install/#drupal-compatibility)

<note important>Il n'existe qu'une méthode officielle((Drush only supports one install method. It requires that your Drupal site be built with Composer and Drush be listed as a dependency.)) d'installation d'une version récente de //drush//((À la date de la rédaction, déc 2023, seule la version 12 de //drush// est maintenue et compatible avec //Drupal 10//.)).</note>

Chaque site/projet //Drupal// est donc muni de sa propre version indépendante de //drush//.

==== Chargement et installation  ====
<code>
~$ cd public_html/
~/public_html$ composer require --dev drush/drush
~/public_html$ ./vendor/bin/drush --version
    Drush Commandline Tool 12.4.3.0
</code>

==== Configuration de l'environnement ====
Le but est de pouvoir lancer la commande "drush" depuis la racine du projet, sans devoir indiquer le chemin.
<code>
~$ cd
~$ nano .bash_profile
    ajout du chemin relatif "./vendor/bin" à la ligne PATH : PATH=$PATH:~/.local/bin:./vendor/bin
~$ source .bash_profile 
    drush peut désormais être appelé depuis la racine du projet
~$ cd public_html/
~/public_html$ drush --version
    Drush Commandline Tool 12.4.3.0
~/public_html$ drush pm-list --status=enabled
    …
</code>
À ce stade, drush est opérationnel sur le site installé précédemment.
==== Versions de PHP ====
//Drush// utilise la version par défaut de PHP, telle que définie au niveau du système((Typiquement, la valeur de renvoie la commande "php --version".)). Or, //Virtualmin// permet de choisir la version de PHP utilisée par chaque serveur ou sous-serveur.

Il faut donc être attentive aux écarts de version. Faute de quoi, le code PHP de //Drupal// peut être exécuté avec des versions différentes de PHP selon qu'il est sollicité par le serveur web ou par //drush//, sans qu'on en ait conscience. Il peut en résulter des écarts de comportement incompréhensibles… Faute de solution universelle, chacune adaptera sa manière de faire à ses besoins et contraintes.

Dans Virtualmin, la version de PHP utilisée par le site web est directement accessible via le lien symbolique "bin/php". En suivant les principes d'organisation utilisés jusqu'ici, la version de PHP que l'on souhaite utiliser se trouve systématiquement dans "../bin", relativement à la racine du projet.