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.