Pregunta:

Soy desarrollador y mantenedor del proyecto CiviCRM. Hemos estado intentando hacer una versión CiviCRM de Drupal 8, y hemos recorrido un largo camino. Nos golpeamos la cabeza contra nuestros teclados colectivos tratando de encontrar un gran obstáculo para el proyecto.

CiviCRM ha usado Symfony por un tiempo, y la versión que se incluye es diferente a la que viene con Drupal.

Podemos instalar CiviCRM con Drupal 8, pero después de instalarlo, no podemos instalar ningún otro módulo Drupal.

Creo que se reduce a una situación en la que de alguna manera la versión CiviCRM de Symfony se carga antes que la versión Drupal, y esto causa problemas.

¿Alguien sabe de un módulo de Drupal 8 que incluye una versión diferente de Symfony a la que viene con Drupal?

Recientemente me encontré con el proyecto Ludwig. Este módulo permite el registro de espacios de nombres en una clase que extiende ServiceProviderBase .

¿Sería posible que la versión Drupal 8 del módulo CiviCRM incluyera un archivo CivicrmServiceProvider.php, que define una clase CivicrmServiceProvider , y un método register() que agrega un espacio de nombres de contenedor para permitir que esto funcione?

Muchos archivos CiviCRM tienen declaraciones de use como Drupal que comienzan con Symfony, como aquí .

De hecho, colocamos CiviCRM Core en la carpeta Drupal doc_root / libraries y usamos el módulo de bibliotecas.

Este es el repositorio para la versión 8.x del módulo CiviCRM Drupal , si alguien quiere ver lo que tenemos hasta ahora. Si alguien tiene el elixir mágico para esto, puedo decirles que habrá mucha gente feliz en nuestra comunidad. Entonces, si sabe cómo ayudarnos, hágalo.

CiviCRM se instala y las páginas de CiviCRM funcionan. Lo que no funciona es que después de instalar CiviCRM, no podemos instalar otros módulos a través de la página de administración / módulos. Hasta donde yo sé, eso es lo único que está roto. También la instalación de módulos con Drush, después de instalar CiviCRM, funciona.

Intentar instalar otro módulo después de instalar CiviCRM provoca el siguiente error:

Error fatal de PHP: llamada al método no definido Symfony \ Component \ DependencyInjection \ Definition :: setFactory () en /var/www/html/civi-for-d8/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php en la línea 206

Eso está en Drupal 8.3.5. Intentar instalar CiviCRM para Drupal 8 en una instancia limpia de Drupal 8.4-dev provoca el siguiente error:

Drupal \ Component \ Serialization \ Exception \ InvalidDataTypeException: El indicador reservado "@" no puede iniciar un escalar simple; debe citar el escalar en la línea 8 (cerca de "argumentos: [@string_translation, @ civicrm.page_state]"). en Drupal \ Component \ Serialization \ YamlSymfony :: decode () (línea 40 de /var/www/html/drupal84/core/lib/Drupal/Component/Serialization/YamlSymfony.php).

Respuesta:

Entonces, creo que si CiviCRM se instaló en Drupal 8 a través del compositor (es decir, el composer require civicrm/civicrm-core en la raíz de Drupal) y el uso de Symfony por parte de CiviCRM fuera compatible con Symfony 2.8 o 3.x (es decir, no usa la funcionalidad obsoleta) , esto podría funcionar.

Esto haría que todo se instalara en el directorio de proveedores de Drupal, en lugar de tener dos, y significaría que CiviCRM usaría la versión de Symfony en Drupal 8. Pero si CiviCRM fuera compatible con versiones posteriores de Symfony (incluso si incluye una versión anterior para Drupal 6 y 7 y otros CMS) debería estar bien.

¿Creo?

ACTUALIZADO: Sí, funciona, lo probé. 🙂 Originalmente publiqué lo siguiente en la cola de problemas de CiviCRM ( CRM-17652 ), pero lo volví a publicar aquí para que esté completo.

La gran idea:

Dado que el compositor es bastante nuevo para mucha gente, intentaré ir paso a paso, desde algunas cosas de compositor de alto nivel hasta una forma en que se podría hacer en CiviCRM:

• Composer permite que las aplicaciones requieran las bibliotecas que necesita (y las bibliotecas, por supuesto, pueden requerir otras bibliotecas).
• Las bibliotecas tienen un archivo composer.json que dice qué otras bibliotecas necesita y con qué versiones es compatible (pero no necesariamente una versión única específica, generalmente un rango de versiones, como ^2.4.3 que dice un mínimo de 2.4.3 y superiores a (pero sin incluir) 3.0.0)
• Las aplicaciones tienen un composer.json que describe de manera similar las bibliotecas necesarias y la compatibilidad con un rango de versiones, pero el rango es realmente para ayudar con la actualización. Una aplicación también tendrá un composer.lock, que es un conjunto específico de versiones individuales.
• Las bibliotecas también pueden tener un composer.lock para su propia prueba o distribución (como construir el tarball de lanzamiento con las dependencias incluidas), pero esto se ignora cuando una aplicación requiere la biblioteca dada (consulte https://getcomposer.org/doc/02 -libraries.md # archivo-bloqueo )
• Cuando una aplicación quiere requerir una nueva biblioteca, el compositor encuentra una intersección de compatibilidad de versiones entre todas las cosas que la aplicación requiere (incluidas todas las bibliotecas ya instaladas y sus dependencias) y la nueva biblioteca, posiblemente haciendo algunas actualizaciones para que todo se alinee ( o error si no puede encontrar una combinación compatible de versiones)
• En este caso, CiviCRM es una biblioteca, y un sitio particular de Drupal 8 es la aplicación (el núcleo de Drupal en sí es una biblioteca)
• CiviCRM podría decir que "requiere" Symfony ^2.5 en su composer.json, lo que significa que es compatible con las versiones 2.5.0 hasta (pero sin incluir) 3.0.0
• Cuando un sitio de Drupal 8 quiere usar CiviCRM, el administrador del sitio usa composer require civicrm/civicrm-core para requerir la biblioteca CiviCRM y todas sus dependencias. Si CiviCRM es compatible con Symfony 2.8 (como se usa en Drupal 8.3.x) todo se instalará y funcionará bien, usando el único Symfony 2.8 de Drupal. Todas las dependencias terminan en el directorio de proveedores de Drupal.
• Sin embargo, CiviCRM podría mantener Symfony 2.5 en su composer.lock, lo que significa que las pruebas lo usarían, y los tarballs para Drupal 6 y 7 y otros CMS incluirían Symfony 2.5

La propuesta:

1. Actualice composer.json de CiviCRM para que pueda ser utilizado como biblioteca por CMS basados ​​en compositores como Drupal 8 (pero probablemente otros podrían moverse de esa manera en el futuro; el compositor se está volviendo bastante popular)
2. Asegúrese de que el núcleo de CiviCRM sea compatible con Symfony 2.8 y 3.0 (usado por Drupal 8.3.xy 8.4.x respectivamente) pero mantenga la versión "oficialmente soportada" (actualmente Symfony 2.5) en composer.lock para probar y el tarball para distribución. Ser compatible con varias versiones de Symfony puede no ser tan difícil como parece: hay varias bibliotecas compatibles con Symfony 2.8 y 3.0. ¡Puede ser solo una cuestión de evitar métodos / clases / características obsoletas! El composer.json deberá actualizarse para reflejar esto
3. Utilice Composer para instalar la biblioteca CiviCRM en Drupal 8 en lugar de copiar en el directorio de bibliotecas. Esta se está convirtiendo en la forma normal de instalar bibliotecas PHP de terceros en Drupal 8 (esto es utilizado ampliamente por Drupal Commerce, por ejemplo)

Para los CMS basados ​​en compositores, realmente creo que este es el camino correcto. Si bien este problema afecta actualmente a Symfony y Drupal, a medida que la comunidad PHP comienza a usar más y más bibliotecas de terceros a través del compositor, esto podría afectar muy bien a otros CMS con conflictos de otras versiones.

Algún código de trabajo para probar:

Entonces, como prometí, de hecho hice que esto funcionara en un grado limitado 🙂 Estoy totalmente de acuerdo con esto desde una perspectiva de Drupal / Composer / Symfony: no tengo mucha experiencia con CiviCRM, por lo que probablemente haya algo mejores formas de hacer mi proceso a continuación. ¡Agradezco cualquier consejo!

1. Descargue e instale Drupal 8.3.5 (¡o el último desarrollador de Drupal 8.4.x!)
2. Vaya al directorio raíz en el shell y ejecute estos comandos para instalar CiviCRM a través del compositor: https://gist.github.com/dsnopek/56311dbea347874e75180883efabb620
3. Si usa Apache, elimine el archivo vendor / .htacess. Esta es una medida de seguridad de Drupal, que evita que se carguen recursos como CSS / JS. Esto necesitará alguna colaboración con el proyecto Drupal para encontrar una solución adecuada porque eliminar este archivo por completo es una mala idea en producción. Ver: proveedor / .htaccess que bloquea los activos CSS / JS de las bibliotecas del compositor .
4. Vaya al directorio / modules y haga git clone https://github.com/dsnopek/civicrm-drupal.git --branch composer-library
5. Vaya a la página "Extender" ( /admin/modules ) e instale el módulo CiviCRM
6. Borrar caché de drupal a través de Drush ( drush cr )
7. Cierre la sesión y vuelva a iniciarla según CRM-19878
8. ¡CiviCRM funciona! 🙂

Después de todo esto, CiviCRM está usando Symfony 2.8 de Drupal y las dependencias en el directorio de proveedores de Drupal, y no carga nada desde su propio directorio de proveedores. ¡Hurra!

Probé la habilitación del módulo "Teléfono" que falló antes de estos cambios (vea mis pasos para reproducir ), pero funciona bien con ellos. 🙂