Poniżej zamieszczona jest OK dla jego poprawek 8.4.x> 8.4.y , ale nie OK dla wydawnictw drobnych 8.4.x> 8.5.x . Przejdź do UPDATE 3 poniżej, co według mnie jest „odpowiedzią” na drobne aktualizacje wydań.
1- Wykonaj kopię zapasową wszystkich plików, które zostały dostarczone przez Drupala, które zmodyfikowałeś, takich jak .htaccess, robots.txt itp. (Te 2 są najczęściej zmieniane).
2- [Powiedziano mi, że usunięcie pliku blokady jest nieprawidłowe, patrz AKTUALIZACJA poniżej] Usuń plik composer.lock (w folderze najwyższego poziomu witryny). Zostanie to odtworzone w kroku 5.
3- Sprawdź plik composer.json (w folderze najwyższego poziomu witryny) i upewnij się, że „drupal: core” znajduje się w sekcji wymagającej, a nie w sekcji zastępującej, na przykład
"require": {
"drupal/core": "^8.4"
},
nie
"replace": {
"drupal/core": "^8.4"
},
Jeśli „drupal / core” znajduje się w sekcji zastępowania, przenieś ją do sekcji wymaganej i usuń sekcję zastępującą. Jeśli są inne wpisy w sekcji zamień, po prostu usuń „drupal / core”, a nie całą sekcję zastępowania - ale myślę, że „drupal / core” jest zwykle jedyną rzeczą.
Umieść wersję, którą chcesz zaktualizować, w „drupal / core”, przykłady:
„drupal / core”: „^ 8.5” - zaktualizuje się do najnowszej wersji 8.5. „drupal / core”: „8.4.6” - zaktualizuje się do wersji 8.4.6.
5- Uruchom to (w folderze najwyższego poziomu swojej witryny):
composer update drupal/core --with-dependencies
6- Jeśli nie ma błędów, wykonaj zwykłe czynności, uruchom aktualizacje i wyczyść pamięć podręczną:
drush updatedb
drush cr
Lub jeśli nie używasz drush, przejdź do /update.php, aby uruchomić aktualizacje, a następnie do admin / config / development / performance i naciśnij przycisk „Wyczyść wszystkie pamięci podręczne”.
7- Jeśli utworzyłeś kopię zapasową plików w pierwszym kroku (.htaccess, robots.txt), odłóż je z powrotem. Ale sprawdź, czy Drupal dokonał aktualizacji tych plików i dodaj te zmiany do swoich.
GOTOWY
Jeśli wystąpiły błędy z aktualizacją kompozytora w kroku 5, zwykle jest to spowodowane problemami z wersjami rzeczy w folderze dostawcy.
Jest to świetny post w rozwiązywaniu takich problemów: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update i przeczytaj pozostałe 2 posty Jeffa na Drupal i Composer, aby uzyskać więcej wiedzy na ten temat.
2 osoby na Twitterze powiedzieli mi, że nie należy usuwać pliku composer.lock (krok 2 powyżej). composer update drupal/core --with-dependenciesPolecenie odtwarza plik blokady i tak.
Podczas testowania tej metody okazało się, że działa ona poprawnie dla 8.4.3> 8.4.6 (na przykład), ale dostaję błędy dla 8.4.6> 8.5.x. Zgłosi się, kiedy to wymyślę.
Przykład błędów:
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].
Ten post autorstwa Jeffa Geerlinga dotyczy podobnych problemów, ale jak dotąd nie mam szczęścia: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
Więc ... jedyną rzeczą, która wydaje mi się działać dla 8.4.x> 8.5.x jest „opcja nuklearna”, z której korzysta wielu innych, która jest uruchomiona composer update.
Myślę, że jest OK, o ile masz pewność co do wersji modułów w composer.json. Być może należy je zablokować do bieżącej wersji. Na przykład:
"drupal/address": "1.3"
zamiast:
"drupal/address": "^1.3"
Ale czy właściwa odpowiedź?
OK, odpowiedzią, która wydaje się być wszędzie, jest zrobienie „opcji nuklearnej”:
A. Usuń /vendorfolder.
B. Uruchom composer updatei po prostu zaktualizuj moduły wraz z rdzeniem. Lub zablokuj wersje modułów, composer.jsonjeśli nie chcesz ich aktualizować.
Jedna osoba z Drupal Slack powiedziała: „cała filozofia Composer polega na tym, że zawsze należy aktualizować pakiety tak często, jak to możliwe” . Myślę, że w pakiecie znajdują się moduły. To chyba ma sens.
Kiedy dostałem z 8.4.6 do 8.5.0, to działało dobrze, aby uzyskać z 8.5.0 do 8.5.1, composer update drupal/core --with-dependenciespodobnie jak w 8.4.3 do 8.4.6.
Zaczynam dochodzić do wniosku, że „odpowiedzią” jest to, że usunięcie folderu dostawcy i pliku composer.lock, a następnie użycie composer updatejest w porządku, i że należy po prostu upewnić się, że numery wersji dla zależności w pliku composer.json są takie, jakie chcesz . Nie jest wielkim problemem zarządzanie wersjami modułów, które chcesz zachować lub pozwolić na aktualizację composer.json.
Na przykład:
"drupal/admin_toolbar": "1.18", oznacza trzymać się z 1.18
"drupal/admin_toolbar": "^1.18", oznacza kontynuuj i aktualizuj, ale w ciągu 1.x (nie 2.x)
Potwierdza to komentarz (General Redneck) do tego postu: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
„Jedną z rzeczy, które mam okazało się, że działając w ramach wsparcia, blokowanie wersji modułów i rdzenia jest dobrym pomysłem, dzięki czemu MOŻESZ dokonać termografii, kiedy chcesz, ponieważ są chwile, kiedy niektóre z różnych wtyczek nawet nie chcą zachowywać się poprawnie ”.
Nawiasem mówiąc, plik composer.lock nie jest pomocny, composer updateponieważ zostaje zdmuchnięty (w przeciwieństwie do miejsca, w composer installktórym czytany jest plik blokady):
Uruchomienie composer installbędzie:
- Sprawdź, czy
composer.lockistnieje
- Jeśli nie, wykonaj,
composer updateaby go utworzyć
- Jeśli
composer.lockistnieje, zainstaluj określone wersje z pliku blokady
Uruchomienie composer updatebędzie:
- Czek
composer.json
- Określ najnowsze wersje do zainstalowania na podstawie specyfikacji wersji
- Zainstaluj najnowsze wersje
- Zaktualizuj,
composer.lockaby odzwierciedlić najnowsze zainstalowane wersje
Ref: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file
Widzę, że wspomniano powyżej: https://github.com/drupal-composer/drupal-project . Użyłem tego i jest w porządku, ale nie jest to wymagane do używania Kompozytora z Drupalem. Jest to mylące, ponieważ „brzmi” tak, jakby pochodziło od nazwy. Kiedy zaczynałem od Drupala 8, pomyślałem, że jest to wymagane, więc zbudowałem na nim moją pierwszą stronę D8, uważając, że to najlepsza praktyka.
Ta „wersja” Drupala ma go w folderze / web, a nie w górnym folderze projektu. W porównaniu do zwykłego Drupala dodano wiele rzeczy do .gitignore:
/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/
Tak więc ta wersja Drupala jest bardziej przeznaczona dla stron, które używają ciągłej integracji, aby tworzyć nową kompilację Drupala przy każdym wdrożeniu, używając instalacji kompozytora. Jeśli wdrażasz przy użyciu bardziej normalnej metody, oczywiście musisz zatwierdzić wszystkie powyższe rzeczy do repozytorium git, w przeciwnym razie nie zostanie ono wdrożone na serwerze [1], a wszystko to jest potrzebne do uruchomienia Drupala.
[1] jeśli git jest zaangażowany w twoje wdrożenie - jeśli wdrażasz za pomocą SFTP, zignoruj to.