Jaki jest prawidłowy obieg aktualizacji podstawowych opartych na kompozytorze?

Chcę używać kompozytora do zarządzania zależnościami Drupala 8, ale nie jestem pewien, jaki jest prawidłowy przepływ pracy podstawowej aktualizacji. W tej chwili używam drush do aktualizacji rdzenia do najnowszej wersji beta, ale mam również pewne zależności w moim pliku composer.json, więc po aktualizacji używam kompozytora install, aby zainstalować wszystkie zależności dostawcy contrib. Wygląda na to, że uruchomienie composer installzastępuje niektóre pliki w katalogu głównym, chociaż właśnie zaktualizowałem rdzeń do najnowszej wersji.

Próbowałem także ręcznie edytować plik composer.json i zastąpić wiersz „drupal / core” konkretną wersją beta, np "drupal/core": "~8.0-beta14",. Nadal jednak zastępuje on pliki w katalogu głównym.

Jaki jest prawidłowy przepływ pracy?

Zakładam, że używasz drupal-kompozytor / drupal-project jako podstawy swojego projektu. Jeśli nie, spójrz na ten projekt i porównaj go ze swoim.

Powiedziałeś też, że chcesz używać kompozytora do zarządzania zależnościami Drupala 8, więc zakładam, że wybrałeś moduły contrib composer require drupal/develraczej niż drush dl devel.

Jeśli robisz wszystkie te rzeczy, powinieneś użyć composer updatedo aktualizacji rdzenia Drupala i wszystkich modułów contrib. Tak długo, jak zachowujesz swój composer.lockplik, composer installnie powinien zmieniać wersji żadnej z twoich zależności. Nie powinieneś w ogóle używać drush pm-update. Nie powinno mieć znaczenia, czy pliki w corekatalogu są aktualizowane, czy nie, ponieważ katalog ten jest zarządzany przez Composer. Lepiej jest nie polecać katalogów zarządzanych przez kompozytora do swojego repozytorium, chociaż możesz, jeśli chcesz.

Oczywiście powinieneś uruchamiać się drush updatedbzawsze, gdy composer updatezastępuje rdzeń Drupala lub dowolny moduł.

Aby uniknąć pobierania wersji programistycznych, ustaw minimalną stabilność na „beta” w pliku composer.json przy użyciu flag stabilności Composer .

Jeśli używasz drupal-composer / drupal-project do zarządzania witryną, wszystkie pliki na poziomie głównym, takie jak README.txt, .htaccess i index.html, stają się własnością twojego projektu. Oznacza to, że powinieneś sprawdzić je w swoim repozytorium git; Kompozytor nie zaktualizuje ich, musisz je zaktualizować samodzielnie, gdy się zmienią. Pliki te powinny zmieniać się tylko rzadko, ale drupal-composer / drupal-project ma skrypt do aktualizacji tych plików .

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.

Za pomocą pakietu drupal / core na packagist.org możemy faktycznie zarządzać rdzeniem, modułami contrib (, motywami i profilami) oraz innymi dostawcami za pośrednictwem kompozytora.

Skonfigurowałem następujące pliki w moim katalogu głównym i uruchomiłem 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

Cieszyć się :)

Tak, możesz zarządzać rdzeniem Drupala za pomocą kompozytora. Jest jednak kilka rzeczy, o których należy pamiętać.

Prawdopodobnie dostaniesz limity czasu z powodu wielu elementów, przez które kompozytor musi przejść, szczególnie jeśli uruchomisz na lokalnej maszynie wirtualnej. Jeśli uruchomisz composer install, prawdopodobnie pojawi się błąd kompozytora:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Upewnij się, że używasz wymagają

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

Dodaj także rozszerzenie limitu czasu w konfiguracji

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

Również jeśli to nie zadziała, możesz uruchomić instalację kompozytora spoza SSH na maszynie wirtualnej .

Spowoduje to ominięcie limitów czasu udziału NFS i rozpakowanie Drupala we właściwym miejscu.

„drupal / core”: „~ 8.0-beta14” oznacza dowolne wydanie większe niż 8.0-beta14 i mniejsze niż 9! Będziesz chciał usunąć tyldę, aby zablokować ją w określonym wydaniu. Następnie upewnij się, że zaktualizowałeś plik blokady, uruchamiając kompozytora, aw systemie docelowym użyj instalacji kompozytora.

Łatwym sposobem na rozpoczęcie jest zbudowanie bazy kodu za pomocą https://github.com/drupal-composer/drupal-project .

Kiedy potrzebujemy zaktualizować coś takiego jak uaktualnienie rdzenia, uruchamiasz „kompozytora w górę” lokalnie. Spowoduje to zaktualizowanie pliku composer.lock.

Gdy inni programiści rozwijają lub wykonują skrypt instalacyjny, uruchomilibyście „instalację kompozytora”, która używa pliku blokady.

Linia w naszym rdzeniu composer.json dla Drupal to:

"drupal/core": "~8.0",

Tylda () oznacza dowolne wydanie w ramach liczby 8 (ale nie 9) .

Jeśli chcesz zablokować go do określonej wersji, nie powinieneś używać tyldy.

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

następnie uruchom „kompozytora w górę” lokalnie, zatwierdź plik composer.json i composer.lock, a następnie uruchom „kompozytor instalacji” w innych instalacjach po rozwinięciu bazy kodu.