Quel est le flux de travail de mise à jour de base basé sur le composeur correct?

Je veux utiliser Composer pour gérer les dépendances de Drupal 8, mais je ne sais pas quel est le bon flux de travail de mise à jour de base. Pour le moment, j'utilise drush pour mettre à jour le noyau vers la dernière version bêta, mais j'ai également quelques dépendances dans mon fichier composer.json, donc après la mise à jour, j'utilise composer installer pour installer toutes les dépendances des fournisseurs de contrib. Il semble que l'exécution composer installremplace certains fichiers dans le répertoire principal, bien que je viens de mettre à jour le noyau vers la dernière version.

J'ai également essayé de modifier manuellement le fichier composer.json et de remplacer la ligne "drupal / core" par la version bêta spécifique, par exemple "drupal/core": "~8.0-beta14",, mais elle remplace toujours les fichiers du répertoire core.

Quel est le bon workflow?

Je suppose que vous utilisez drupal-composer / drupal-project comme base de votre projet. Sinon, jetez un œil à ce projet et comparez-le avec le vôtre.

De plus, vous avez dit que vous vouliez utiliser composer pour gérer les dépendances de Drupal 8, donc je suppose que vous avez sélectionné vos modules contrib via composer require drupal/develplutôt que drush dl devel.

Si vous faites toutes ces choses, vous devez utiliser composer updatepour mettre à jour le noyau Drupal et tous vos modules contrib. Tant que vous conservez votre composer.lockfichier, composer installvous ne devez modifier la version d'aucune de vos dépendances. Vous ne devriez pas utiliser drush pm-updatedu tout. Peu importe que les fichiers du corerépertoire soient mis à jour ou non, car ce répertoire est géré par Composer. Il vaut mieux ne pas engager de répertoires gérés par le compositeur dans votre référentiel, bien que vous puissiez le faire si vous le souhaitez.

Bien sûr, vous devez exécuter drush updatedbchaque fois que composer updateremplace le noyau Drupal ou tout module.

Pour éviter d'obtenir des versions de développement, définissez votre stabilité minimale sur «beta» dans votre fichier composer.json à l' aide des indicateurs de stabilité de Composer .

Si vous utilisez drupal-composer / drupal-project pour gérer votre site, tous les fichiers de niveau racine tels que README.txt, .htaccess et index.html deviennent la propriété de votre projet. Cela signifie que vous devez les archiver dans votre référentiel git; Composer ne les mettra pas à jour, vous devez les mettre à jour vous-même lorsqu'ils changent. Ces fichiers ne devraient changer que rarement, mais drupal-composer / drupal-project dispose d'un script pour mettre à jour ces fichiers .

Ce qui suit est OK pour les versions de patch 8.4.x> 8.4.y , mais pas OK pour les versions mineures 8.4.x> 8.5.x . Passez à la MISE À JOUR 3 ci-dessous pour ce que je crois être "la réponse" aux mises à jour mineures des versions.

1- Sauvegardez tous les fichiers fournis avec Drupal que vous avez modifiés, tels que .htaccess, robots.txt, etc. (ces 2 sont les plus souvent modifiés).

2- [On m'a dit que supprimer le fichier de verrouillage est incorrect, voir MISE À JOUR ci-dessous] Supprimer le fichier composer.lock (dans le dossier de niveau supérieur de votre site). Cela est recréé à l'étape 5.

3- Vérifiez votre composer.json (dans le dossier de niveau supérieur de votre site) et assurez-vous que le "drupal: core" est dans la section require et non dans une section replace, par exemple

"require": {
"drupal/core": "^8.4"
},

ne pas

"replace": {
"drupal/core": "^8.4"
},

Si "drupal / core" se trouve dans la section de remplacement, déplacez-le dans la section requise et supprimez la section de remplacement. S'il y a d'autres entrées dans la section de remplacement, supprimez simplement "drupal / core" et non la totalité de la section replace - mais je pense que "drupal / core" est normalement la seule chose là-bas.

Mettez la version à mettre à jour dans "drupal / core", exemples:

"drupal / core": "^ 8.5" - sera mis à jour vers la dernière version de 8.5. "drupal / core": "8.4.6" - sera mis à jour vers la version 8.4.6.

5- Exécutez ceci (dans le dossier de niveau supérieur de votre site):

composer update drupal/core --with-dependencies

6- S'il n'y a pas d'erreur, faites comme d'habitude, exécutez les mises à jour et videz le cache:

drush updatedb
drush cr

Ou si vous n'utilisez pas drush, accédez à /update.php pour exécuter les mises à jour, puis à admin / config / development / performance et appuyez sur le bouton "Effacer tous les caches".

7- Si vous aviez sauvegardé des fichiers dans la première étape (.htaccess, robots.txt), remettez-les en place. Mais vérifiez si Drupal a mis à jour ces fichiers et ajoutez ces modifications aux vôtres.

TERMINÉ

S'il y a eu des erreurs avec la mise à jour du composeur à l'étape 5, cela est généralement dû à des problèmes avec les versions des éléments dans le dossier du fournisseur.

C'est un excellent article sur ces problèmes: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update et lisez les 2 autres articles de Jeff sur Drupal et Composer pour obtenir plus de connaissances à ce sujet.

Deux personnes m'ont dit sur Twitter que composer.lock ne devait pas être supprimé (étape 2 ci-dessus). La composer update drupal/core --with-dependenciescommande recrée de toute façon le fichier de verrouillage.

En testant cette méthode, je trouve que cela fonctionne bien pour 8.4.3> 8.4.6 (par exemple) mais j'obtiens des erreurs pour 8.4.6> 8.5.x. Je ferai rapport quand je le découvrirai.

Exemple d'erreurs:

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
    - symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
    - symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
    - drupal/core 8.5.0 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
    - Installation request for drupal/core 8.5.0 -> satisfiable by drupal/core[8.5.0].
    - Installation request for symfony/console (locked at v3.2.8, required as ~3.2.8) -> satisfiable by symfony/console[v3.2.8].

Cet article de Jeff Geerling traite de problèmes similaires, mais jusqu'à présent, pas de chance pour moi: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update

Donc ... la seule chose qui semble fonctionner pour moi pour 8.4.x> 8.5.x est "l'option nucléaire" que tant d'autres semblent utiliser, qui est exécutée composer update.

Je suppose que c'est OK tant que vous êtes sûr des versions du module dans composer.json. Peut-être que l'on devrait les verrouiller dans la version actuelle. Par exemple:

"drupal/address": "1.3"

plutôt que:

"drupal/address": "^1.3"

Mais est-ce la bonne réponse?

OK la réponse qui semble être partout est de faire "l'option nucléaire":

A. Supprimez le /vendordossier.

B. Exécutez composer updateet mettez simplement à jour vos modules avec le noyau. Ou, verrouillez les versions du module composer.jsonsi vous ne souhaitez pas les mettre à jour.

Une personne sur Drupal Slack a déclaré que "toute la philosophie de Composer est que vous devriez toujours mettre à jour les packages, aussi souvent que possible" . Packaged comprend des modules je pense. Donc, cela a du sens, je suppose.

Une fois que je suis passé de 8.4.6 à 8.5.0, cela a bien fonctionné pour passer de 8.5.0 à 8.5.1 composer update drupal/core --with-dependenciestout comme pour 8.4.3 à 8.4.6.

Je commence à conclure que "la réponse" est que la suppression du dossier du fournisseur et du fichier composer.lock, puis l'utilisation composer updateest très bien, et que l'on doit simplement s'assurer que les numéros de version des dépendances dans le fichier composer.json sont ce que vous voulez . Ce n'est pas si grave de gérer les versions de modules que vous souhaitez conserver ou autoriser à mettre à jour composer.json.

Par exemple:

"drupal/admin_toolbar": "1.18", signifie rester avec 1,18

"drupal/admin_toolbar": "^1.18", signifie aller de l'avant et mettre à jour mais dans 1.x (pas 2.x)

Ceci est soutenu par un commentaire (Général Redneck) sur ce post: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update "L'une des choses que j'ai trouvé que je travaille dans le support est que le verrouillage des versions des modules et du noyau est une bonne idée afin que vous puissiez thermonuke la chose quand vous le souhaitez car il y a des moments où certains des différents plugins ne veulent même pas se comporter correctement. "

Soit dit en passant, le fichier composer.lock n'est d'aucune aide composer updatecar il est emporté (par opposition à l' composer installendroit où il verrouille le fichier est lu):

Courir composer install:

• Vérifier s'il composer.lockexiste
• Sinon, effectuez un composer updatepour en créer un
• S'il composer.lockexiste, installez les versions spécifiées à partir du fichier de verrouillage

Courir composer update:

• Vérifier composer.json
• Déterminez les dernières versions à installer en fonction des spécifications de votre version
• Installer les dernières versions
• Mettre composer.lockà jour pour refléter les dernières versions installées

Réf: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file

Je vois que cela est mentionné ci-dessus: https://github.com/drupal-composer/drupal-project . Je l'ai utilisé et c'est bien mais ce n'est pas une condition pour utiliser Composer avec Drupal. C'est déroutant car cela "sonne" comme si cela venait du nom. Quand j'ai commencé avec Drupal 8, je pensais que c'était nécessaire, alors j'ai construit mon premier site D8 avec cela, pensant que c'était la meilleure pratique.

Cette "version" de Drupal a sa docroot dans un dossier / web, pas dans le dossier supérieur du projet. Il y a aussi un tas de choses ajoutées à .gitignore par rapport à Drupal normal:

/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/

Ainsi, cette version de Drupal est vraiment plus destinée aux sites qui utilisent l'intégration continue pour faire une nouvelle version de Drupal à chaque déploiement, en utilisant l'installation de composer. Si vous déployez avec une méthode plus normale, vous devez évidemment valider toutes les choses ci-dessus dans votre dépôt git ou il ne sera pas déployé sur votre serveur [1], et toutes ces choses sont nécessaires pour que Drupal s'exécute.

[1] si git est impliqué dans votre déploiement - si vous déployez avec SFTP, ignorez cela.

En utilisant le package drupal / core sur packagist.org, nous pouvons réellement gérer le core, les modules contrib (, thèmes et profils) et les autres fournisseurs via composer.

J'ai installé les fichiers suivants dans mon répertoire racine et exécuté composer install

composer.json

{
  "require": {
    "composer/installers": "^1.0.20",
    "drupal/core": "8.0.*"
  },
  "extra": {
    "installer-paths": {
      "core": ["type:drupal-core"],
      "modules/contrib": ["type:drupal-module"],
      "profiles/contrib": ["type:drupal-profile"],
      "themes/contrib": ["type:drupal-theme"]
    }
  },
  "scripts": {
    "post-install-cmd": [
      "./post_install.sh"
    ]
  }
}

post_install.sh

#!/usr/bin/env bash
export RAW_DRUPAL="https://raw.githubusercontent.com/drupal/drupal/8.0.x"
curl $RAW_DRUPAL/example.gitignore > example.gitignore
curl $RAW_DRUPAL/.gitattributes > .gitattributes
curl $RAW_DRUPAL/.htaccess > .htaccess
curl $RAW_DRUPAL/.csslintrc > .csslintrc
curl $RAW_DRUPAL/.editorconfig > .editorconfig
curl $RAW_DRUPAL/.eslintrc > .eslintrc
curl $RAW_DRUPAL/.eslintignore > .eslintignore
curl $RAW_DRUPAL/index.php > index.php
curl $RAW_DRUPAL/update.php > update.php
curl $RAW_DRUPAL/web.config > web.config
curl $RAW_DRUPAL/autoload.php > autoload.php
curl $RAW_DRUPAL/robots.txt > robots.txt
mkdir -p sites/default
curl $RAW_DRUPAL/sites/example.sites.php > sites/example.sites.php
curl $RAW_DRUPAL/sites/development.services.yml > sites/development.services.yml
curl $RAW_DRUPAL/sites/example.settings.local.php > sites/example.settings.local.php
curl $RAW_DRUPAL/sites/default/default.services.yml > sites/default/default.services.yml
curl $RAW_DRUPAL/sites/default/default.settings.php > sites/default/default.settings.php

Prendre plaisir :)

Oui, vous pouvez gérer Drupal core avec composer. Il y a cependant deux choses à savoir.

Vous obtiendrez probablement des délais d'attente en raison d'un certain nombre d'éléments que le compositeur doit exécuter, surtout si vous exécutez sur une machine virtuelle locale. Si vous exécutez, composer installvous obtiendrez probablement l'erreur de composition:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Assurez-vous d'utiliser

{
  "require": {
   "drupal/core": "8.3.*"

Ajoutez également une extension au délai d'expiration dans la configuration

    "installer-paths": {
        "core": ["type:drupal-core"],
        "modules/contrib/{$name}": ["type:drupal-module"],
        "profiles/contrib/{$name}": ["type:drupal-profile"],
        "themes/contrib/{$name}": ["type:drupal-theme"],
        "drush/contrib/{$name}": ["type:drupal-drush"],
        "modules/custom/{$name}": ["type:drupal-custom-module"],
        "themes/custom/{$name}": ["type:drupal-custom-theme"]
    }
},

"config":{
            "process-timeout": 1600
       },

De plus, si cela ne fonctionne pas, vous pouvez exécuter l'installation de composer depuis l'extérieur SSH dans votre machine virtuelle .

Cela contournera tous les délais d'attente de partage NFS et décompressera Drupal au bon endroit.

"drupal / core": "~ 8.0-beta14" signifie toute version supérieure à 8.0-beta14 et inférieure à 9! Vous souhaiterez supprimer le tilde pour le verrouiller sur une version spécifique. Assurez-vous ensuite de mettre à jour votre fichier de verrouillage en exécutant Composer, et sur le système cible, utilisez Installer Composer.

Un moyen simple de commencer est de créer la base de code à l'aide de https://github.com/drupal-composer/drupal-project .

Lorsque nous devons mettre à jour quelque chose comme la mise à niveau du noyau, vous exécutez "composer up" localement. Cela mettra à jour le fichier composer.lock.

Lorsque d'autres développeurs tirent vers le bas, ou dans un script de déploiement, vous exécutez "installer le compositeur", qui utilise le fichier de verrouillage.

La ligne dans notre composer.json pour le noyau Drupal est:

"drupal/core": "~8.0",

Le tilde () signifie toute version dans le nombre 8 (mais pas 9) .

Si vous souhaitez le verrouiller sur une version spécifique, vous ne devez pas utiliser le tilde.

"drupal/core": "8.0-beta14",

exécutez ensuite "composer up" localement, validez les fichiers composer.json et composer.lock, puis exécutez "composer install" sur d'autres installations après avoir déroulé la base de code.