¿Cuál es el flujo de trabajo de actualización de núcleo basado en compositor correcto?

Quiero usar Composer para administrar las dependencias de Drupal 8, pero no estoy seguro de cuál es el flujo de trabajo de actualización central correcto. En este momento estoy usando drush para actualizar el núcleo a la última versión beta, pero también tengo algunas dependencias en mi archivo composer.json, así que después de la actualización estoy usando la instalación de composer para instalar todas las dependencias de los proveedores contrib. Parece que la ejecución composer installanula algunos archivos en el directorio central, aunque acabo de actualizar el núcleo a la última versión.

También he intentado editar manualmente el archivo composer.json y reemplazar la línea "drupal / core" con la versión beta específica, por ejemplo "drupal/core": "~8.0-beta14",, pero aún anula los archivos en el directorio central.

¿Cuál es el flujo de trabajo correcto?

Supongo que está utilizando drupal-composer / drupal-project como base para su proyecto. Si no, eche un vistazo a ese proyecto y compárelo con el suyo.

Además, dijo que desea utilizar el compositor para administrar las dependencias de Drupal 8, por lo que supongo que ha seleccionado sus módulos contrib a través de en composer require drupal/devellugar de hacerlo drush dl devel.

Si está haciendo todas estas cosas, debe usar composer updatepara actualizar Drupal core y todos sus módulos contrib. Siempre y cuando conserve su composer.lockarchivo, composer installno debe cambiar la versión de ninguna de sus dependencias. No debes usar drush pm-updateen absoluto. No debería importarle si los archivos en el coredirectorio se actualizan o no, ya que Composer administra este directorio. Es mejor no comprometer directorios administrados por el compositor en su repositorio, aunque puede hacerlo si lo desea.

Por supuesto, debe ejecutar drush updatedbsiempre que composer updatereemplace el núcleo de Drupal o cualquier módulo.

Para evitar obtener versiones de desarrollo, establezca su estabilidad mínima en 'beta' en su archivo composer.json utilizando las banderas de estabilidad Composer .

Si está utilizando drupal-composer / drupal-project para administrar su sitio, todos los archivos de nivel raíz como README.txt, .htaccess e index.html serán propiedad de su proyecto. Eso significa que debe registrarlos en su repositorio git; Composer no los actualizará, debe actualizarlos usted mismo cuando cambien. Estos archivos deberían cambiar solo en raras ocasiones, pero drupal-composer / drupal-project tiene un script para actualizar estos archivos .

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.

Usando el paquete drupal / core en packagist.org podemos administrar el núcleo, los módulos contrib (temas y perfiles) y los otros proveedores a través del compositor.

He configurado los siguientes archivos en mi directorio raíz y ejecuté 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

Disfruta :)

Sí, puedes administrar el núcleo de Drupal con el compositor. Sin embargo, hay un par de cosas a tener en cuenta.

Probablemente obtendrá tiempos de espera debido a la cantidad de elementos que el compositor debe ejecutar, especialmente si se ejecuta en una VM local. Si ejecuta, composer installes probable que obtenga el error del compositor:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Asegúrate de usar require

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

Agregue también una extensión al tiempo de espera en la configuración

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

Además, si eso no funciona, puede ejecutar la instalación del compositor desde fuera de SSH en su VM .

Esto evitará cualquier tiempo de espera de compartir NFS y desempaquetará Drupal en el lugar correcto.

"drupal / core": "~ 8.0-beta14" significa cualquier versión mayor que 8.0-beta14 y menor que 9. Deberá eliminar la tilde para bloquearla en una versión específica. Luego, asegúrese de actualizar su archivo de bloqueo ejecutando Composer Up, y en el sistema de destino use la instalación de Composer.

Una manera fácil de comenzar es construir la base de código usando https://github.com/drupal-composer/drupal-project .

Cuando necesitamos actualizar algo como actualizar core, ejecutas "composer up" localmente. Esto actualizará el archivo composer.lock.

Cuando otros desarrolladores despliegan, o en una secuencia de comandos de implementación, ejecuta "instalación del compositor", que utiliza el archivo de bloqueo.

La línea en nuestro composer.json para Drupal core es:

"drupal/core": "~8.0",

La tilde () significa cualquier liberación dentro del número 8 (pero no 9) .

Si desea bloquearlo a una versión específica, no debe usar la tilde.

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

luego ejecute "composer up" localmente, confirme el archivo composer.json y composer.lock, y luego ejecute "composer install" en otras instalaciones después de desplegar la base de código.