Im Folgenden ist OK für Patch - Versionen 8.4.x> 8.4.y , aber nicht OK für kleinere Releases 8.4.x> 8.5.x . Wechseln Sie zu UPDATE 3 , um die Antwort auf kleinere Release-Updates zu finden.
1- Sichern Sie alle Dateien, die mit Drupal geliefert werden und die Sie geändert haben, z. B. .htaccess, robots.txt usw. (die beiden am häufigsten geänderten).
2- [Mir wurde mitgeteilt, 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 Bereich require und nicht in einem Ersetzungsbereich befindet
"require": {
"drupal/core": "^8.4"
},
nicht
"replace": {
"drupal/core": "^8.4"
},
Wenn sich "Drupal / Core" im Ersetzungsabschnitt befindet, verschieben Sie es in den erforderlichen Abschnitt und löschen Sie den Ersetzungsabschnitt. Wenn es andere Einträge im Ersetzungsabschnitt gibt, entfernen Sie einfach den "Drupal / Core", nicht den gesamten Ersetzungsabschnitt - aber ich denke, "Drupal / Core" ist normalerweise das einzige, was dort vorhanden ist.
Tragen Sie in "drupal / core" die Version ein, auf die Sie updaten 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 aufgetreten sind, führen Sie die Updates wie gewohnt aus und leeren Sie den Cache:
drush updatedb
drush cr
Wenn Sie drush nicht verwenden, gehen Sie zu /update.php, um Updates auszuführen, dann zu admin / config / development / performance und klicken Sie auf die Schaltfläche "Alle Caches löschen".
7- Wenn Sie im ersten Schritt Dateien gesichert hatten (.htaccess, robots.txt), setzen Sie sie zurück. Überprüfen Sie jedoch, ob Drupal Aktualisierungen an diesen Dateien vorgenommen hat, und fügen Sie diese Änderungen zu Ihren hinzu.
ERLEDIGT
Wenn beim Composer-Update in Schritt 5 Fehler aufgetreten sind, liegt dies normalerweise an Problemen mit den Versionen des Materials im Herstellerordner.
Dies ist ein großartiger Beitrag im Umgang mit solchen Problemen: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update und lies Jeffs andere 2 Beiträge auf Drupal und Composer, um sie zu erhalten mehr Wissen darüber.
Auf Twitter wurde mir von 2 Leuten gesagt, dass composer.lock nicht gelöscht werden soll (Schritt 2 oben). Der composer update drupal/core --with-dependenciesBefehl erstellt die Sperrdatei trotzdem neu.
Wenn ich diese Methode teste, finde ich, dass sie für 8.4.3> 8.4.6 (zum Beispiel) gut funktioniert, aber ich bekomme Fehler für 8.4.6> 8.5.x. Werde zurück berichten, wenn ich es herausgefunden habe.
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 bei 8.4.x> 8.5.x zu funktionieren scheint, ist die "nukleare Option", die so viele andere zu nutzen scheinen und 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 beschränken. Beispielsweise:
"drupal/address": "1.3"
eher, als:
"drupal/address": "^1.3"
Aber ist das die richtige Antwort?
OK, die Antwort, die überall zu sein scheint, ist die "nukleare Option":
A. Löschen Sie den /vendorOrdner.
B. Führen composer updateSie die Module zusammen mit dem Core aus und aktualisieren Sie sie einfach. Oder sperren Sie die Modulversionen, composer.jsonwenn Sie sie nicht aktualisieren möchten.
Eine Person auf Drupal Slack sagte: "Die ganze Philosophie von Composer ist, dass Sie Pakete immer so häufig wie möglich aktualisieren sollten . " Paket beinhaltet Module, denke ich. Es macht also einen Sinn, denke ich.
Sobald ich von 8.4.6 auf 8.5.0 kam, funktionierte dies einwandfrei, um von 8.5.0 auf 8.5.1 zu kommen, composer update drupal/core --with-dependenciesgenauso wie es bei 8.4.3 auf 8.4.6 der Fall war.
Ich fange an zu folgern, dass "die Antwort" darin besteht, dass das Löschen des Vendor-Ordners und der composer.lock-Datei und die anschließende Verwendung composer updatein Ordnung sind und dass man einfach sicherstellen sollte, dass die Versionsnummern für Abhängigkeiten in der composer.json-Datei Ihren Wünschen entsprechen . Es ist keine große Sache, zu verwalten, welche Modulversionen Sie behalten oder ein Update zulassen möchten composer.json.
Beispielsweise:
"drupal/admin_toolbar": "1.18", bedeutet bei 1.18 bleiben
"drupal/admin_toolbar": "^1.18", Also mach weiter und aktualisiere aber innerhalb von 1.x (nicht 2.x)
Dies wird durch einen Kommentar (General Redneck) zu diesem Beitrag untermauert
: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update "Eines der Dinge, die ich habe Während ich im Support arbeite, ist es eine gute Idee, die Versionen der Module und des Kerns zu sperren, damit Sie das Ding thermonuken können, wenn Sie wollen, weil es Zeiten gibt, in denen sich einige der verschiedenen Plugins nicht richtig verhalten wollen. "
Übrigens ist die Datei composer.lock keine Hilfe, composer updateda sie weggeblasen wird (im Gegensatz zu composer installdem Ort, an dem die Sperrdatei gelesen wird):
Laufen composer installwird:
- Überprüfen Sie, ob ein
composer.lockvorhanden ist
- Wenn nicht, führen Sie eine aus, um eine
composer updatezu erstellen
- Falls
composer.lockvorhanden, installieren Sie die angegebenen Versionen aus der Sperrdatei
Laufen composer updatewird:
- Prüfen
composer.json
- Bestimmen Sie die neuesten zu installierenden Versionen anhand Ihrer Versionsspezifikationen
- Installieren Sie die neuesten Versionen
- Aktualisieren Sie
composer.lock, um die neuesten installierten Versionen zu berücksichtigen
Ref: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file
Ich sehe, dass dies oben erwähnt wird: 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 sich so "anhört", als wäre es vom Namen. Als ich mit Drupal 8 anfing, dachte ich, es sei erforderlich, und baute meine erste D8-Site damit auf.
In dieser "Version" von Drupal befindet sich docroot in einem / web-Ordner, nicht im obersten Ordner des Projekts. Außerdem wurde .gitignore im Vergleich zu normalem Drupal einiges hinzugefügt:
/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 mithilfe der Composer-Installation eine neue Drupal-Version zu erstellen. Wenn Sie mit einer normaleren Methode bereitstellen, müssen Sie natürlich alle oben genannten Dinge für Ihr Git-Repo festschreiben, oder es wird nicht auf Ihrem Server bereitgestellt [1], und diese Dinge werden alle benötigt, damit Drupal ausgeführt werden kann.
[1] Wenn Git an Ihrer Bereitstellung beteiligt ist - Wenn Sie mit SFTP bereitstellen, ignorieren Sie dies.