it-swarm.com.de

Was ist der richtige composer-basierte Core-Update-Workflow?

Ich möchte composer verwenden, um Drupal 8 Abhängigkeiten zu verwalten, bin mir aber nicht sicher, was der richtige Kern-Update-Workflow ist. Im Moment verwende ich) Drush, um den Kern auf die neueste Beta-Version zu aktualisieren, aber ich habe auch einige Abhängigkeiten in meiner Datei composer.json. Nach dem Update verwende ich composer install, um alle Abhängigkeiten des Contrib-Anbieters zu installieren scheint, dass läuft composer install überschreibt einige Dateien im Kernverzeichnis, obwohl ich den Kern gerade auf die neueste Version aktualisiert habe.

Ich habe auch versucht, die Datei composer.json manuell zu bearbeiten und die Zeile "drupal/core" durch die spezifische Beta-Version zu ersetzen, z. "drupal/core": "~8.0-beta14",, überschreibt jedoch weiterhin Dateien im Kernverzeichnis.

Was ist der richtige Workflow?

16
rreiss

Ich gehe davon aus, dass Sie drupal-composer/drupal-project als Grundlage für Ihr Projekt verwenden. Wenn nicht, schauen Sie sich das Projekt an und vergleichen Sie es mit Ihrem.

Außerdem haben Sie gesagt, dass Sie composer zum Verwalten von Drupal 8 Abhängigkeiten) verwenden möchten. Ich gehe also davon aus, dass Sie Ihre Contrib-Module über composer require drupal/devel statt drush dl devel.

Wenn Sie all diese Dinge tun, sollten Sie composer update Verwenden, um Drupal Core und alle Ihre Contrib-Module zu aktualisieren. Solange Sie Ihren composer.lock Datei, composer install sollte die Version Ihrer Abhängigkeiten nicht ändern. Sie sollten drush pm-update überhaupt nicht verwenden. Es sollte Ihnen egal sein, ob Dateien in core-Verzeichnisse werden aktualisiert oder nicht, da dieses Verzeichnis von Composer verwaltet wird. Es ist besser, keine von Composer verwalteten Verzeichnisse in Ihr Repository zu übertragen, obwohl Sie dies können, wenn Sie dies wünschen.

Natürlich sollten Sie drush updatedb Immer dann ausführen, wenn composer update Drupal Core oder ein beliebiges Modul) ersetzt.

Um zu vermeiden, dass Entwicklungsversionen abgerufen werden, setzen Sie Ihre Mindeststabilität in Ihrer composer.json-Datei mit Composer-Stabilitätsflags auf 'beta'.

Wenn Sie Ihre Site mit drupal-composer/drupal-project verwalten, werden alle Dateien auf Stammebene wie README.txt, .htaccess und index.html Eigentum Ihres Projekts. Das bedeutet, dass Sie sie in Ihr Git-Repository einchecken sollten. Composer aktualisiert sie nicht, Sie müssen sie selbst aktualisieren, wenn sie sich ändern. Diese Dateien sollten sich nur selten ändern, aber drupal-composer/drupal-project verfügt über ein Skript zum Aktualisieren dieser Dateien .

11
greg_1_anderson

Das Folgende ist für Patch-Releases 8.4.x> 8.4.y in Ordnung, für kleinere Releases jedoch nicht in Ordnung. 8.4. x> 8.5.x . Wechseln Sie zu UPDATE 3 unten, um zu erfahren, was meiner Meinung nach "die Antwort" für kleinere Release-Updates ist.

1- Sichern Sie alle Dateien, die mit Drupal geliefert wurden, die Sie geändert haben, wie z. B. .htaccess, robots.txt usw. (diese 2 werden am häufigsten geändert).

2- [Mir wurde gesagt, dass das Löschen der Sperrdatei falsch ist, siehe UPDATE unten] Löschen Sie die Datei composer.lock (im obersten Ordner Ihrer Site). Dies wird in Schritt 5 neu erstellt.

3- Überprüfen Sie Ihre composer.json (im obersten Ordner Ihrer Site) und stellen Sie sicher, dass sich "drupal: core" im erforderlichen Bereich befindet und nicht in einem Ersetzungsabschnitt zum Beispiel

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

nicht

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

Wenn sich "drupal/core" im Ersetzungsabschnitt befindet, verschieben Sie ihn in den erforderlichen Abschnitt und löschen Sie den Ersetzungsabschnitt. Wenn es andere Einträge im Ersetzungsabschnitt gibt, entfernen Sie einfach das "Drupal/Core", nicht den gesamten Ersetzungsabschnitt - aber ich denke, "Drupal/Core" ist normalerweise das einzige, was dort vorhanden ist.

Geben Sie in "drupal/core" an, auf welche Version Sie aktualisieren möchten. Beispiele:

"drupal/core": "^ 8.5" - wird auf die neueste Version von 8.5 aktualisiert. "drupal/core": "8.4.6" - wird auf Version 8.4.6 aktualisiert.

5- Führen Sie dies aus (im obersten Ordner Ihrer Site):

composer update drupal/core --with-dependencies

6- Wenn keine Fehler vorliegen, führen Sie die üblichen Schritte aus, führen Sie die Updates aus und löschen Sie den Cache:

drush updatedb
drush cr

Wenn Sie drush nicht verwenden, gehen Sie zu /update.php, um Updates auszuführen, gehen Sie zu admin/config/development/performance und klicken Sie auf die Schaltfläche "Alle Caches löschen".

7- Wenn Sie im ersten Schritt Dateien gesichert haben (.htaccess, robots.txt), legen Sie sie zurück. Überprüfen Sie jedoch, ob Drupal Aktualisierungen an diesen Dateien vorgenommen hat, und fügen Sie diese Änderungen Ihren hinzu.

ERLEDIGT

Wenn in Schritt 5 Fehler mit dem Update composer aufgetreten sind, liegt dies normalerweise an Problemen mit Versionen des Materials im Herstellerordner.

Dies ist ein großartiger Beitrag zur Behandlung solcher Probleme: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update und lesen Sie Jeffs andere 2 Beiträge auf Drupal und Composer, um mehr darüber zu erfahren.

Mir wurde von 2 Leuten auf Twitter gesagt, dass composer.lock nicht gelöscht werden sollte (Schritt 2 oben). Der Befehl composer update drupal/core --with-dependencies Erstellt die Sperrdatei trotzdem neu.

Beim Testen dieser Methode finde ich, dass sie für 8.4.3> 8.4.6 (zum Beispiel) gut funktioniert, aber ich erhalte Fehler für 8.4.6> 8.5.x. Werde zurückmelden, wenn ich es herausfinde.

Beispiel für Fehler:

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].

Dieser Beitrag von Jeff Geerling befasst sich mit ähnlichen Problemen, aber bisher kein Glück für mich: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update =

Also ... das einzige, was für mich für 8.4.x> 8.5.x zu funktionieren scheint, ist die "nukleare Option", die so viele andere zu verwenden scheinen, die ausgeführt wird composer update.

Ich denke, das ist in Ordnung, solange Sie sich über die Modulversionen in composer.json sicher sind. Vielleicht sollte man sie auf die aktuelle Version sperren. Zum Beispiel:

"drupal/address": "1.3"

eher, als:

"drupal/address": "^1.3"

Aber ist die richtige Antwort?

OK, die Antwort, die überall zu sein scheint, ist die "nukleare Option":

A. Löschen Sie den Ordner /vendor.

B. Führen Sie composer update Aus und aktualisieren Sie einfach Ihre Module zusammen mit dem Kern. Oder sperren Sie die Modulversionen in composer.json, Wenn Sie sie nicht aktualisieren möchten.

Eine Person auf Drupal Slack sagte "Die ganze Philosophie von Composer ist, dass Sie Pakete immer so oft wie möglich aktualisieren sollten". Das Paket enthält Module, denke ich. Es macht also Sinn, denke ich.

Sobald ich von 8.4.6 auf 8.5.0 gekommen bin, hat dies gut funktioniert, um von 8.5.0 auf 8.5.1 composer update drupal/core --with-dependencies Zu kommen, genau wie bei 8.4.3 auf 8.4.6.

Ich fange an zu folgern, dass "die Antwort" darin besteht, dass das Löschen des Herstellerordners und der Datei composer.lock und die Verwendung von composer update In Ordnung ist und dass man einfach die Versionsnummern für Abhängigkeiten im Komponisten sicherstellen sollte. JSON-Datei sind, was Sie wollen. Es ist keine große Sache, zu verwalten, welche Modulversionen Sie behalten oder in composer.json Aktualisieren möchten.

Zum Beispiel:

"drupal/admin_toolbar": "1.18", Bedeutet, bei 1.18 zu bleiben

"drupal/admin_toolbar": "^1.18", Bedeutet, dass Sie fortfahren und aktualisieren, jedoch innerhalb von 1.x (nicht 2.x).

Dies wird durch einen Kommentar (General Redneck) zu diesem Beitrag unterstützt: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update = "Eines der Dinge, die ich bei meiner Arbeit im Support festgestellt habe, ist, dass das Sperren der Versionen von Modulen und Kern eine gute Idee ist, damit Sie das Ding thermonukieren können, wenn Sie möchten, weil es Zeiten gibt, in denen einige der verschiedenen Plugins wollen sich nicht einmal richtig verhalten. "

Übrigens ist die Datei composer.lock keine Hilfe bei composer update, Da sie weggeblasen wird (im Gegensatz zu composer install, Wo die Sperrdatei gelesen wird):

Wenn Sie composer install Ausführen, wird:

  • Überprüfen Sie, ob ein composer.lock Vorhanden ist
  • Wenn nicht, führen Sie einen composer update Aus, um einen zu erstellen
  • Wenn composer.lock Vorhanden ist, installieren Sie die angegebenen Versionen aus der Sperrdatei

Wenn Sie composer update Ausführen, wird:

  • Überprüfen Sie composer.json
  • Bestimmen Sie anhand Ihrer Versionsspezifikationen die neuesten zu installierenden Versionen
  • Installieren Sie die neuesten Versionen
  • Aktualisieren Sie composer.lock, Um die neuesten installierten Versionen wiederzugeben

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

Ich sehe, dass dies oben erwähnt wurde: https://github.com/drupal-composer/drupal-project . Ich habe das verwendet und es ist in Ordnung, aber es ist keine Voraussetzung für die Verwendung von Composer mit Drupal. Es ist verwirrend, da es so klingt, als ob es vom Namen stammt. Als ich mit Drupal 8 anfing, dachte ich, dass es erforderlich ist, also baute ich meine erste D8-Site damit und dachte, es sei eine bewährte Methode.

Diese "Version" von Drupal hat die Docroot in einem/web-Ordner, nicht im obersten Ordner des Projekts. Außerdem gibt es eine Reihe von Dingen, die .gitignore im Vergleich zu normalem Drupal hinzugefügt wurden:

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

Daher ist diese Version von Drupal eher für Sites gedacht, die eine kontinuierliche Integration verwenden, um bei jeder Bereitstellung mit Drupal install einen neuen Build von composer zu erstellen. Wenn Sie mit einer normaleren Methode bereitstellen, müssen Sie offensichtlich alle oben genannten Dinge in Ihr Git-Repo übertragen, sonst wird es nicht auf Ihrem Server bereitgestellt [1], und diese Dinge werden alle für Drupal benötigt Lauf.

[1] Wenn Git an Ihrer Bereitstellung beteiligt ist. Wenn Sie mit SFTP bereitstellen, ignorieren Sie dies.

2
Richard Hood

Ja, Sie können Drupal Core mit Composer verwalten. Es gibt jedoch einige Dinge zu beachten.

Sie werden wahrscheinlich Zeitüberschreitungen aufgrund einer Reihe von Elementen erhalten composer muss durchlaufen werden, insbesondere wenn Sie in einer lokalen VM ausgeführt werden. Wenn Sie composer install Ausführen, erhalten Sie wahrscheinlich das = composer Fehler:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Stellen Sie sicher, dass Sie erfordern

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

Fügen Sie dem Timeout in der Konfiguration auch eine Erweiterung hinzu

    "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
       },

Auch wenn dies nicht funktioniert, können Sie composer install von außerhalb von SSH in Ihrer VM ausführen.

Dadurch werden alle NFS-Freigabe-Timeouts umgangen und Drupal an der richtigen Stelle entpackt).

1
BigEd

Mit dem Paket drupal/core auf packagist.org können wir den Core, die Contrib-Module (, Themes und Profile) und die anderen Anbieter über Composer verwalten.

Ich habe die folgenden Dateien in meinem Stammverzeichnis eingerichtet und composer install Ausgeführt.

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

Genießen :)

1
Eyal

"drupal/core": "~ 8.0-beta14" bedeutet jede Veröffentlichung größer als 8.0-beta14 und kleiner als 9! Sie möchten die Tilde entfernen, um sie für eine bestimmte Version zu sperren. Stellen Sie dann sicher, dass Sie Ihre Sperrdatei aktualisieren, indem Sie composer up) ausführen und auf dem Zielsystem composer install) verwenden.

Ein einfacher Weg, um loszulegen, besteht darin, die Codebasis mit https://github.com/drupal-composer/drupal-project zu erstellen.

Wenn wir beispielsweise ein Upgrade des Kerns durchführen müssen, führen Sie "Composer Up" lokal aus. Dadurch wird die Datei composer.lock aktualisiert.

Wenn andere Entwickler herunterfahren oder ein Bereitstellungsskript ausführen, führen Sie "Composer Install" aus, bei dem die Sperrdatei verwendet wird.

Die Zeile in unserer composer.json für Drupal core ist:

"drupal/core": "~8.0",

Die Tilde () bedeutet jede Veröffentlichung innerhalb der 8-Zahl (aber nicht 9) .

Wenn Sie es für eine bestimmte Version sperren möchten, sollten Sie die Tilde nicht verwenden.

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

führen Sie dann "composer up" lokal aus, schreiben Sie die Dateien composer.json und composer.lock fest und führen Sie dann "composer install" für andere Installationen aus, nachdem Sie die Codebasis heruntergezogen haben.

0
oknate