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-dependencies
comando 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 /vendor
cartella.
B. Esegui composer update
e aggiorna semplicemente i tuoi moduli insieme a core. In alternativa, bloccare le versioni del modulo composer.json
se 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-dependencies
proprio 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 update
va 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 update
quanto viene spazzato via (al contrario di composer install
dove viene letto il file di blocco):
Esecuzione composer install
sarà:
- Controlla se
composer.lock
esiste
- In caso contrario, esegui a
composer update
per crearne uno
- Se
composer.lock
esiste, installa le versioni specificate dal file di blocco
Esecuzione composer update
sarà:
- Dai un'occhiata
composer.json
- Determinare le ultime versioni da installare in base alle specifiche della versione
- Installa le ultime versioni
- Aggiorna
composer.lock
per 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.