Qual è il flusso di lavoro di aggiornamento core basato sul compositore corretto?


16

Voglio usare il compositore per gestire le dipendenze di Drupal 8, ma non sono sicuro di quale sia il giusto flusso di lavoro di aggiornamento del core. Al momento sto usando Drush per aggiornare core all'ultima versione beta, ma ho anche alcune dipendenze nel mio file composer.json, quindi dopo l'aggiornamento sto usando l'installazione di Composer per installare tutte le dipendenze del fornitore contrib. Sembra che l'esecuzione abbia la precedenza su composer installalcuni file nella directory principale, anche se ho appena aggiornato core all'ultima versione.

Ho anche provato a modificare manualmente il file composer.json e sostituire la riga "drupal / core" con la versione beta specifica, ad esempio "drupal/core": "~8.0-beta14",, ma continua a sovrascrivere i file nella directory principale.

Qual è il flusso di lavoro giusto?

Risposte:


11

Presumo che tu stia usando drupal-compositore / drupal-project come base per il tuo progetto. In caso contrario, dai un'occhiata a quel progetto e confrontalo con il tuo.

Inoltre, hai detto che vuoi usare il compositore per gestire le dipendenze di Drupal 8, quindi presumo che tu abbia selezionato i tuoi moduli contrib composer require drupal/develpiuttosto che drush dl devel.

Se stai facendo tutte queste cose, allora dovresti usare composer updateper aggiornare Drupal core e tutti i tuoi moduli contrib. Finché conservi il tuo composer.lockfile, composer installnon dovresti cambiare la versione di nessuna delle tue dipendenze. Non dovresti usare drush pm-updateaffatto. Non dovrebbe importarti se i file nella coredirectory sono aggiornati o meno, poiché questa directory è gestita da Composer. È meglio non impegnare directory gestite dal compositore nel proprio repository, anche se è possibile se lo si desidera.

Ovviamente, dovresti eseguire drush updatedbogni volta che composer updatesostituisce Drupal core o qualsiasi modulo.

Per evitare di ottenere versioni di sviluppo, imposta la stabilità minima su "beta" nel file composer.json utilizzando i flag di stabilità di Composer .

Se stai usando drupal-compositore / drupal-project per gestire il tuo sito, tutti i file di livello radice come README.txt, .htaccess e index.html diventano di proprietà del tuo progetto. Ciò significa che dovresti controllarli nel tuo repository git; Il compositore non li aggiornerà, devi aggiornarli tu stesso quando cambiano. Questi file dovrebbero cambiare solo raramente, ma drupal-compositore / drupal-project ha uno script per aggiornare questi file .


Supponiamo che sto usando l'aggiornamento del compositore invece di drush pm-update, come posso aggiornare file come README.txt, .htaccess, ecc.? E come mai l'aggiornamento di Drush offre un core diverso rispetto all'aggiornamento del compositore? E dovrei sostituire la versione di drupal nel mio composer.json a 8.0-betaX prima di ogni aggiornamento? Non voglio usare dev. versione ..
rreiss

Aggiornato la risposta.
greg_1_anderson,

+1 greg_1_anderson - questo sembra fantastico, è questo il modo definitivo per fare aggiornamenti di sicurezza per Drupal 8? con D7, è: drupal.stackexchange.com/a/71578
therobyouknow,

Questo sembra funzionare se uno avesse inizialmente installato Drupal 8.1 con questi passaggi: drupal.org/node/2471553 (ho scoperto che funziona senza errori)
therobyouknow,

"Ovviamente, dovresti eseguire drush updatedbogni volta che l'aggiornamento del compositore sostituisce il core di Drupal o qualsiasi modulo." - grazie e se inizialmente hai installato drupal con questi passaggi, drupal.org/node/2471553 allora hai bisogno del percorso completo per quel particolare drush con la tua installazione di Drupal 8 (come usavano per eseguire l'installazione come passaggio finale). Devi prima effettuare il cd in web e una volta in / web il comando per aggiornare il db con il percorso completo sarebbe quindi: ../vendor/drush/drush/drush updatedb(ho scoperto che questo funziona).
therobyouknow,

2

Quanto segue è OK per i rilasci di patch 8.4.x> 8.4.y , ma non OK per minori rilasci 8.4.x> 8.5.x . Vai all'AGGIORNAMENTO 3 di seguito per quella che credo sia "la risposta" per gli aggiornamenti delle versioni minori.

1- Effettua il backup di tutti i file forniti con Drupal che hai modificato, come .htaccess, robots.txt, ecc. (Questi 2 sono i più comunemente modificati).

2- [Mi è stato detto di eliminare il file di blocco è sbagliato, vedere AGGIORNAMENTO di seguito] Elimina il file composer.lock (nella cartella di livello superiore del tuo sito). Questo viene ricreato nel passaggio 5.

3- Controlla il tuo composer.json (nella cartella di livello superiore del tuo sito) e assicurati che "drupal: core" sia nella sezione richiesta e non in una sezione di sostituzione, ad esempio

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

non

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

Se "drupal / core" è nella sezione di sostituzione, spostalo nella sezione richiesta ed elimina la sezione di sostituzione. Se ci sono altre voci nella sezione di sostituzione, basta rimuovere "drupal / core" non l'intera sezione di sostituzione - ma penso che "drupal / core" sia normalmente l'unica cosa lì.

Inserisci la versione che desideri aggiornare in "drupal / core", esempi:

"drupal / core": "^ 8.5" - verrà aggiornato all'ultima versione di 8.5. "drupal / core": "8.4.6" - verrà aggiornato alla versione 8.4.6.

5- Esegui questo (nella cartella di livello superiore del tuo sito):

composer update drupal/core --with-dependencies

6- Se non ci sono errori, fai il solito, esegui gli aggiornamenti e svuota la cache:

drush updatedb
drush cr

Oppure, se non usi drush, vai su /update.php per eseguire gli aggiornamenti, quindi su admin / config / development / performance e premi il pulsante "Cancella tutte le cache".

7- Se nel primo passaggio è stato eseguito il backup dei file (.htaccess, robots.txt), ripristinarli. Ma controlla se Drupal ha apportato aggiornamenti a quei file e aggiungi quelle modifiche alle tue.

FATTO

Se si sono verificati errori con l'aggiornamento del compositore nel passaggio 5, ciò è generalmente dovuto a problemi con le versioni degli elementi nella cartella del fornitore.

Questo è un ottimo post per affrontare tali problemi: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update e leggi gli altri 2 post di Jeff su Drupal e Composer per ottenere più conoscenza a riguardo.

2 persone su Twitter mi hanno detto che composer.lock non deve essere eliminato (passaggio 2 sopra). Il composer update drupal/core --with-dependenciescomando ricrea comunque il file di blocco.

Nel testare questo metodo trovo che funzioni bene per 8.4.3> 8.4.6 (per esempio) ma ottengo errori per 8.4.6> 8.5.x. Riferirò quando lo capirò.

Esempio di errori:

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

Questo post di Jeff Geerling affronta problemi simili, ma finora nessuna fortuna per me: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update

Quindi ... l'unica cosa che sembra funzionare per me per 8.4.x> 8.5.x è l '"opzione nucleare" che molti altri sembrano usare, che viene eseguita composer update.

Immagino che vada bene fintanto che sei sicuro delle versioni del modulo in composer.json. Forse uno dovrebbe bloccarli alla versione corrente. Per esempio:

"drupal/address": "1.3"

piuttosto che:

"drupal/address": "^1.3"

Ma è la risposta giusta?

OK, la risposta che sembra essere ovunque è fare "l'opzione nucleare":

A. Elimina la /vendorcartella.

B. Esegui composer updatee aggiorna semplicemente i tuoi moduli insieme a core. In alternativa, bloccare le versioni del modulo composer.jsonse non si desidera aggiornarle.

Una persona di Drupal Slack ha affermato che "l'intera filosofia di Composer è che dovresti sempre aggiornare i pacchetti, il più frequentemente possibile" . Il pacchetto include moduli che penso. Quindi ha un senso suppongo.

Una volta che ho ottenuto da 8.4.6 a 8.5.0, questo ha funzionato bene per passare da 8.5.0 a 8.5.1 composer update drupal/core --with-dependenciesproprio come ha fatto per 8.4.3 a 8.4.6.

Sto iniziando a concludere che "la risposta" è che l'eliminazione della cartella del fornitore e del file composer.lock, quindi l'utilizzo composer updateva bene, e che si dovrebbe semplicemente assicurarsi che i numeri di versione per le dipendenze nel file composer.json siano ciò che si desidera . Non è un grosso problema gestire le versioni dei moduli che vuoi conservare o consentire di aggiornare composer.json.

Per esempio:

"drupal/admin_toolbar": "1.18", significa bastone con 1.18

"drupal/admin_toolbar": "^1.18", significa andare avanti e aggiornare ma entro 1.x (non 2.x)

Questo è supportato da un commento (General Redneck) su questo post: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update "Una delle cose che ho trovato come lavoro a supporto è che bloccare le versioni di moduli e core è una buona idea in modo che PUOI termonuke la cosa quando vuoi perché ci sono momenti in cui alcuni dei vari plugin non vogliono nemmeno comportarsi correttamente ".

A proposito, il file composer.lock non è di aiuto in composer updatequanto viene spazzato via (al contrario di composer installdove viene letto il file di blocco):

Esecuzione composer installsarà:

  • Controlla se composer.lockesiste
  • In caso contrario, esegui a composer updateper crearne uno
  • Se composer.lockesiste, installa le versioni specificate dal file di blocco

Esecuzione composer updatesarà:

  • Dai un'occhiata composer.json
  • Determinare le ultime versioni da installare in base alle specifiche della versione
  • Installa le ultime versioni
  • Aggiorna composer.lockper riflettere le ultime versioni installate

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

Vedo che questo è menzionato sopra: https://github.com/drupal-composer/drupal-project . L'ho usato ed è perfetto, ma non è un requisito per l'utilizzo di Composer con Drupal. È fonte di confusione in quanto "suona" come se fosse dal nome. Quando ho iniziato con Drupal 8 ho pensato che fosse necessario, quindi ho costruito il mio primo sito D8 con quello, pensando che fosse la migliore pratica.

Quella "versione" di Drupal ha docroot in una cartella / web, non nella cartella principale del progetto. Inoltre c'è un sacco di cose aggiunte a .gitignore rispetto al normale Drupal:

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

Quindi, questa versione di Drupal è davvero più pensata per i siti che utilizzano l'integrazione continua per fare una nuova build di Drupal su ogni distribuzione, usando l'installazione del compositore. Se esegui una distribuzione con un metodo più normale, devi ovviamente eseguire il commit di tutti i suddetti elementi nel tuo repository git o non verranno distribuiti sul tuo server [1] e tutto ciò sarà necessario per l'esecuzione di Drupal.

[1] se git è coinvolto nella tua distribuzione - se esegui la distribuzione con SFTP, ignoralo.


composer update drupal/core symfony/config webflo/drupal-core-strict --with-dependenciesnon mi ha mai deluso ancora. Funziona su diverse versioni minori, ad esempio 8.3 -> 8.6
Clive

1

Usando il pacchetto drupal / core su packagist.org possiamo effettivamente gestire il core, i moduli contrib (, temi e profili) e gli altri venditori tramite compositore.

Ho installato i seguenti file nella mia directory principale ed eseguito 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

Godere :)


Immagino che avrò bisogno di tutta quella magia a ricciolo che hai fatto. Mi aspettavo che tutti questi file necessari fossero messi in atto dal compositore.
dxvargas,

@hiphip I file al di fuori della directory principale non cambiano spesso, quindi quanto sopra potrebbe essere uno script che esegui manualmente quando gli aggiornamenti drupal da una versione minore alla successiva (ovvero da 8.1 a 8.2)
Eyal

1

Sì, puoi gestire Drupal core con il compositore. Tuttavia, ci sono un paio di cose da tenere presente.

Probabilmente otterrai timeout a causa del numero di elementi che compositore deve eseguire, soprattutto se esegui una VM locale. Se corri composer installprobabilmente otterrai l'errore del compositore:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Assicurati di usare richiedi

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

Aggiungi anche un'estensione al timeout nella configurazione

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

Inoltre, se non funziona, puoi eseguire l'installazione di Composer dall'esterno di SSH nella tua VM .

Questo eviterà qualsiasi timeout di condivisione NFS e spacchetterà Drupal nel posto giusto.


0

"drupal / core": "~ 8.0-beta14" indica qualsiasi versione superiore a 8.0-beta14 e inferiore a 9! Ti consigliamo di rimuovere la tilde per bloccarla su una versione specifica. Quindi assicurati di aggiornare il tuo file di blocco eseguendo il compositore e sul sistema di destinazione usa l'installazione del compositore.

Un modo semplice per iniziare è costruire la base di codice usando https://github.com/drupal-composer/drupal-project .

Quando abbiamo bisogno di aggiornare qualcosa come l'aggiornamento del core, esegui "compositore" localmente. Ciò aggiornerà il file composer.lock.

Quando altri sviluppatori si ritirano o in uno script di distribuzione, si esegue "installazione compositore", che utilizza il file di blocco.

La linea nel nostro core composer.json per Drupal è:

"drupal/core": "~8.0",

La tilde () indica qualsiasi rilascio all'interno del numero 8 (ma non 9) .

Se vuoi bloccarlo su una versione specifica, non dovresti usare la tilde.

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

quindi esegui "compositore" localmente, esegui il commit del file composer.json e composer.lock, quindi esegui "installazione compositore" su altre installazioni dopo aver rimosso la base di codice.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.