A continuación está bien para parche libera 8.4.x> 8.4.y , pero no está mal para versiones menores 8.4.x> 8.5.x . Vaya a la ACTUALIZACIÓN 3 a continuación para ver lo que creo que es "la respuesta" para actualizaciones de lanzamiento menores.
1- Haga una copia de seguridad de cualquier archivo que venga con Drupal que haya modificado, como .htaccess, robots.txt, etc. (esos 2 son los que se cambian más comúnmente).
2- [Me dijeron que eliminar el archivo de bloqueo es incorrecto, vea ACTUALIZAR a continuación] Elimine el archivo composer.lock (en la carpeta de nivel superior de su sitio). Esto se recrea en el paso 5.
3- Verifique su composer.json (en la carpeta de nivel superior de su sitio) y asegúrese de que "drupal: core" esté en la sección de requisitos y no en una sección de reemplazo, por ejemplo
"require": {
"drupal/core": "^8.4"
},
no
"replace": {
"drupal/core": "^8.4"
},
Si "drupal / core" está en la sección de reemplazo, muévalo a la sección requerida y elimine la sección de reemplazo. Si hay otras entradas en la sección de reemplazo, simplemente elimine "drupal / core", no toda la sección de reemplazo, pero creo que "drupal / core" es normalmente lo único que hay.
Ponga a qué versión desea actualizar en "drupal / core", ejemplos:
"drupal / core": "^ 8.5" - se actualizará a la última versión de 8.5. "drupal / core": "8.4.6" - se actualizará a la versión 8.4.6.
5- Ejecute esto (en la carpeta de nivel superior de su sitio):
composer update drupal/core --with-dependencies
6- Si no hay errores, haz lo habitual, ejecuta las actualizaciones y borra la memoria caché:
drush updatedb
drush cr
O si no usa drush, vaya a /update.php para ejecutar actualizaciones, luego a admin / config / development / performance y presione el botón "Borrar todas las cachés".
7- Si ha realizado una copia de seguridad de los archivos en el primer paso (.htaccess, robots.txt), vuelva a colocarlos. Pero verifique si Drupal realizó actualizaciones a esos archivos y agregue esos cambios a los suyos.
HECHO
Si hubo errores con la actualización del compositor en el paso 5, generalmente se debe a problemas con las versiones de las cosas en la carpeta del proveedor.
Esta es una gran publicación para tratar estos problemas: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update y lea las otras 2 publicaciones de Jeff en Drupal y Composer para obtener más conocimiento sobre eso.
2 personas en Twitter me dijeron que composer.lock no debería eliminarse (Paso 2 anterior). El composer update drupal/core --with-dependenciescomando recrea el archivo de bloqueo de todos modos.
Al probar este método, encuentro que funciona bien para 8.4.3> 8.4.6 (por ejemplo) pero obtengo errores para 8.4.6> 8.5.x. Informaré cuando lo resuelva.
Ejemplo de errores:
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].
Esta publicación de Jeff Geerling aborda problemas similares, pero hasta ahora no tuve suerte: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
Entonces ... lo único que parece funcionar para mí para 8.4.x> 8.5.x es la "opción nuclear" que muchos otros parecen usar, que se ejecuta composer update.
Supongo que está bien siempre que esté seguro de las versiones del módulo en composer.json. Tal vez uno debería bloquearlos a la versión actual. Por ejemplo:
"drupal/address": "1.3"
más bien que:
"drupal/address": "^1.3"
¿Pero es la respuesta correcta?
OK, la respuesta que parece estar en todas partes es hacer la "opción nuclear":
A. Eliminar la /vendorcarpeta.
B. Ejecute composer updatey simplemente actualice sus módulos junto con core. O bloquee las versiones del módulo composer.jsonsi no desea actualizarlas.
Una persona en Drupal Slack dijo que "toda la filosofía de Composer es que siempre debe actualizar los paquetes, con la mayor frecuencia posible" . Empaquetado incluye módulos, creo. Entonces tiene sentido, supongo.
Una vez que pasé de 8.4.6 a 8.5.0, funcionó bien para pasar de 8.5.0 a 8.5.1 composer update drupal/core --with-dependenciestal como lo hizo para 8.4.3 a 8.4.6.
Estoy empezando a concluir que "la respuesta" es que eliminar la carpeta del proveedor y el archivo composer.lock, luego usarlo composer updateestá bien, y que uno simplemente debe asegurarse de que los números de versión para las dependencias en el archivo composer.json sean lo que desea . No es tan importante administrar las versiones de módulos que desea mantener o permitir actualizar composer.json.
Por ejemplo:
"drupal/admin_toolbar": "1.18", significa quedarse con 1.18
"drupal/admin_toolbar": "^1.18", significa seguir adelante y actualizar, pero dentro de 1.x (no 2.x)
Esto está respaldado por un comentario (General Redneck) en esta publicación: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
"Una de las cosas que he descubrí que trabajar como soporte es que bloquear las versiones de los módulos y el núcleo es una buena idea para que PUEDAS avisar cuando lo desees porque a veces algunos de los diversos complementos incluso no quieren comportarse correctamente ".
Por cierto, el archivo composer.lock no ayuda composer updateporque se vuela (en lugar de composer installdonde se lee el archivo de bloqueo):
Correr composer install:
- Comprobar si
composer.lockexiste
- Si no, realice una
composer updatepara crear uno
- Si
composer.lockexiste, instale las versiones especificadas del archivo de bloqueo
Correr composer update:
- Cheque
composer.json
- Determine las últimas versiones para instalar según las especificaciones de su versión
- Instala las últimas versiones
- Actualización
composer.lockpara reflejar las últimas versiones instaladas
Ref: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file
Veo que esto se menciona anteriormente: https://github.com/drupal-composer/drupal-project . Lo he usado y está bien, pero no es un requisito para usar Composer con Drupal. Es confuso ya que "suena" como si fuera del nombre. Cuando comencé con Drupal 8, pensé que era necesario, así que construí mi primer sitio D8 con eso, pensando que era la mejor práctica.
Esa "versión" de Drupal tiene docroot en una carpeta / web, no en la carpeta superior del proyecto. También hay un montón de cosas agregadas a .gitignore en comparación con Drupal normal:
/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/
Por lo tanto, esta versión de Drupal está realmente más destinada a sitios que utilizan la integración continua para hacer una nueva compilación de Drupal en cada implementación, utilizando la instalación del compositor. Si implementa con un método más normal, obviamente tiene que enviar todo lo anterior a su repositorio git o no se implementará en su servidor [1], y todo eso es necesario para que Drupal se ejecute.
[1] si git está involucrado en su implementación, si implementa con SFTP, ignórelo.