Me encuentro con un problema totalmente predecible pero increíblemente molesto y difícil de resolver.
He estado trabajando en un marco PHP para desarrollar complementos de WordPress. Está utilizando Composer para la gestión de dependencias. Por supuesto, el problema es que si tiene dos instancias de mi marco en la misma instalación de WordPress, tiene dos carpetas de proveedores y dos copias de los paquetes requeridos por el marco. Lo que conduce a un error.
El marco funciona como un complemento separado que luego es heredado por cualquier aplicación/complemento que se cree en él.
¿Mover la carpeta del proveedor a la carpeta del marco central?
Problemas: no sé qué sucedería si tengo dos archivos composer.json y dos archivos composer.phar escribiendo en la misma carpeta del proveedor y usando el mismo cargador automático. Presumiblemente no sería bueno. Además de eso, no resuelve el problema de las colisiones con los paquetes del compositor que podría usar cualquier otro script o complemento fuera de lo que estoy tratando de manejar.
Así que estoy atascado. ¿Es este un problema que se puede resolver, o es simplemente inherente a PHP?
Composer no está realmente diseñado para usarse varias veces en el mismo proyecto. Por otro lado, tampoco tiene nada de malo, sin embargo, pierde sus características de dependencias y necesita tratar esto como un caso genérico de dependencias en el entorno de WordPress.
En otras palabras, si no está haciendo dependencias a la manera de Composer y WordPress no está haciendo dependencias en absoluto, se convierte en su problema personal cómo lidiar con eso.
No sé qué pasaría si tengo dos archivos composer.json y dos archivos composer.phar escribiendo en la misma carpeta del proveedor y usando el mismo cargador automático.
No entiendo por qué la carpeta del proveedor sería la misma si está utilizando varias instalaciones de compositores… ¿Podría dar más detalles sobre cómo la estructura y si es para uso público o privado?
-
Sí. Lo que estoy construyendo se amplía con otros complementos. Esos complementos secundarios podrían implementar Composer en sus proyectos. Entonces, si se incluyeran dos complementos secundarios, por ejemplo, Twig, se rompería. Me preguntaba en voz alta si funcionaría si ambos complementos usaran la misma carpeta de proveedores y convergieran la lista de sus dependencias.
– jdp
14/08/2013 a las 21:09
-
Usar la misma carpeta del proveedor es claramente una mala idea, los árboles de archivos no coincidirán, los cargadores automáticos escanearán cosas incorrectas, etc. Con las instalaciones normales de Composer, los cargadores automáticos probablemente se apilarán y el primero “ganará” y servirá clases en conflicto, sin embargo, cualquier función sin espacio de nombres generará un error fatal. como de costumbre, ya que PHP no se autocarga para ellos. Como arriba, su única opción es hacer sus propios controles y su lógica de prueba de errores.
– Raro
14/08/2013 a las 21:17
No estoy muy familiarizado con Composer o el marco de complemento que está utilizando, pero en general, evitar las colisiones de nombres de funciones/clases en los complementos de WordPress se hace de la siguiente manera:
-
Suponiendo que su complemento (por ejemplo, MyCoolPlugin) está escrito orientado a objetos, por ejemplo, como una clase llamada MyCoolPlugin, puede incluir la clase/biblioteca auxiliar como una subclase de MyCoolPlugin.
-
clase_existe(), esta es la forma de PHP de averiguar si se ha definido una clase. Suponiendo que su clase de ayuda sea lo siguiente:
class MyHelperClass{
}
Puede usar la siguiente verificación antes de declarar la clase en cada uno de sus complementos:
if(!class_exists('MyHelperClass')){
class MyHelperClass{
}
}
Por supuesto, aquí hay una compensación, porque solo se usará la primera instancia de la clase a través de nuestro WordPress. Por ejemplo, si tiene dos complementos con dos versiones diferentes de la clase auxiliar, solo uno de ellos estará activo y disponible en un momento dado.
- Una variable global – por ejemplo
define('MY_HELPER_IS_LOADED', true);en los archivos auxiliares (en caso de que los incluya a través deinclude()orequire()). Luego, al comienzo de cada archivo de ayuda incluido, verifique conif(defined('MY_HELPER_IS_LOADED')) return;lo que hará que el archivo actualmente solicitado para incluir/requerir NO se incluya.
Nuevamente, las tácticas anteriores se usan en PHP en general, no estoy seguro de cómo se configura exactamente el marco de su complemento.
Por que lo harias necesitar dos vendedores en primer lugar? Solo edita el
composer.jsonarchivo de la principalvendorcarpeta, agregue las dependencias que necesita allí, una por una. Elimine el archivo composer.lock y ejecutephp composer.phar installotra vez. El cargador automático se actualizará y todas las dependencias se agregarán al directorio principal de proveedores. En caso de colisión de nombres, use un prefijo o edite y altere los archivos manualmente, si es necesario. Solo tendrá que copiar estas dependencias que no tienen un repositorio disponible (es decir, sus propias dependencias)– Elías Van Ootegem
9 de agosto de 2013 a las 7:23
@jdp: ¿Por qué no usar un instalador de plugins de WordPress para Composer? Entonces no solo tiene una carpeta de proveedor central, sino que también logra instalar los complementos con composer. Si usa composer solo como una sub-infraestructura, esto no funciona bien. Así que busque instaladores personalizados al menos: github.com/compositor/instaladores — hakre.wordpress.com/2013/08/03/… — compositor.rarst.net — y si te unes al stackexchange de wordpress el lazo chatear, es posible que conozcas a Rarst, que sabe mucho sobre el tema.
– hakré
14 de agosto de 2013 a las 7:19