¿Dónde pongo los archivos .php, .js, .html, .css de una biblioteca de terceros que interactúa con una extensión que desarrollo?


10

Digamos que quiero desarrollar una extensión de Magento que interactúe, por ejemplo, con un paquete de gráficos de código abierto o una galería de imágenes o lo que NO sea parte de la extensión en sí. Cuando se descarga (aparte de la extensión), la lib de terceros viene en su propio .zip único con todos sus .php, .js, .html y .css juntos.

¿Coloco en el propietario del sitio pobre que desea instalar mi extensión junto con la lib de terceros, la carga de separar el .zip original de terceros y hacer que pongan .js en / js, .php en / lib,. css en / skin, etc.

¿O hay un "vertedero" generalmente aceptado para cualquier .zips de terceros donde uno puede descomprimir convenientemente la descarga TAL CUAL y terminar con ella?

Respuestas:


6

No sé si hay una única respuesta correcta a esta pregunta, ya que realmente depende del código que esté incluyendo.

Si desea incluir una biblioteca php de terceros, por ejemplo, un sdk para una API externa, entonces debe colocarse en el directorio / lib de su proyecto Magento para que pueda incluirla la extensión que lo consume.

Sin embargo, también está utilizando js y css como ejemplos. Si está utilizando js de terceros en su extensión para generar código, por ejemplo, algunos js que representan un gráfico de lienzo, es muy probable que esto se coloque en el directorio / js para que su extensión pueda incluirlo. Para css, probablemente debería agregarse al tema base / predeterminado y los directorios de máscara.

Desafortunadamente, el sistema de extensión Magento 1 no facilita la distribución de este tipo de cosas, ya que los archivos se distribuyen a través de todo el proyecto en lugar de estar autocontenidos en un solo directorio. Herramientas como Magento Composer Installer y Modman ayudan con esto de alguna manera.


4

Cuando se descarga (aparte de la extensión), las extensiones de terceros vienen en su propio .zip único con todos sus .php, .js, .html y .css juntos.

Siempre he sido fanático de adivinar las convenciones desde la propia fuente, aunque puede ser ambiguo con Magento 1.

Siempre que la licencia de la biblioteca de terceros permita la agrupación, debe desempaquetarla y reempaquetarla junto con su extensión, porque no hay un mecanismo nativo para desempaquetar una subbiblioteca separada (podría estar equivocado).

El destino de estos activos depende del tipo y la organización interna de los archivos. Las bibliotecas JS puras deberían ir debajo ./js/. Los archivos que se ejecutan en el lado del servidor pertenecen a ./lib/, señalando que cualquier clase de PHP ./lib/puede cargarse automáticamente mediante el esquema de carga automática (esencialmente PSR-0) (ref. Convención de carga automática de Zend Framework 1). No ./lib/se puede (debe) acceder a nada a través del cliente (ref. ./lib/.htaccess).


Gracias Ben Su respuesta tiene sentido, pero significa que los propietarios del sitio no pueden actualizar fácilmente la biblioteca de terceros a la última versión, independientemente de la extensión de Magento que se conecta a ella. A menos que entiendan íntimamente cómo se mantiene todo junto e incluso entonces es doloroso colocar todos los bits en las ranuras correctas. Esto es una bendición en el sentido de que las versiones de extensión y lib de terceros permanecen consistentes, pero es un dolor cuando las nuevas versiones de lib de terceros ofrecen correcciones de errores y nuevas características mientras continúan la compatibilidad con versiones anteriores.
fris

1
"Esto es una bendición en el sentido de que las versiones de extensión y la biblioteca de terceros permanecen consistentes ..." ¡ Ese es el boleto! Sus cambios son tus cambios. Todo esto es un poco más fácil en Magento 2 gracias a Composer.
Benmarks

1

Por lo tanto, desea crear una extensión y está utilizando un recurso / paquete externo para construirlo. En mi opinión, cualquier paquete que haya utilizado en su extensión, su extensión debe seguir las mejores prácticas de Magento. Eso significa que debe separar todas las imágenes js, css, del recurso externo y colocarlas en base\defaultlos directorios del paquete de temas.

es decir, no existe una ubicación única para colocar recursos de paquetes de terceros. En última instancia, cuando entregas una extensión genial, todas las js, css e imágenes relacionadas con tu extensión deben mantenerse en un lugar donde normalmente se va a buscar otro desarrollador y que en casi todos los casos es el base/defaultpaquete de temas.

En breve

Todas tus extensiones js deberían estar bajo

skin\frontent\base\default\js\[your_extension]\[all_of_your_js_files]
skin\frontent\base\default\css\[your_extension]\[all_of_your_css_files]
skin\frontent\base\default\images\[your_extension]\[all_of_your_images]

//for third parties, you can create an inner directory, to specify it
skin\frontent\base\default\js\[your_extension]\[your_external_resource]\[resource_js_files]
skin\frontent\base\default\css\[your_extension]\[your_external_resource]\[resource_css_files]
skin\frontent\base\default\images\[your_extension]\[your_external_resource]\[resource_image_files]

De esta forma, otro desarrollador puede encontrar fácilmente js, css e imágenes (de sus recursos externos también) de su extensión muy fácilmente. Como está utilizando un subdirectorio adicional para indicar los archivos de recursos externos dentro de su directorio de nombre de extensión, dará a los demás una mejor pista de que su extensión depende de algunos paquetes de terceros.

Por lo tanto, le recomiendo que separe los paquetes externos y los haga parte de su extensión para que otro desarrollador pueda encontrar fácilmente sus dependencias. :-)

EDITAR - 1

No debe hacer su carga de extensión para el propietario de su sitio. Puede evitar esta dificultad alineando adecuadamente su extensión. Eso significa que si guarda todos los archivos relacionados en las ubicaciones de directorio especificadas, entonces todo lo que debe hacer un propietario del sitio es tomar su extensión y luego Fusionar su extensión desde el directorio raíz de la aplicación. es decir, alinee su extensión correctamente. Debe tener un aspecto como este.

/app
|_____code\community\Namespace\Module\...
|_____design
|        |_____frontend\base\defalt\...
|        |_____adminhtml\base\defalt\...

/skin
|_____frontend\base\default\js|css|images\[your_extension]\all_theme_related_files
|_____frontend\base\default\js|css|images\[your_extension]\all_theme_related_files

EDITAR - 2

Si hay algunos paquetes, que deberían compartirse en todas las aplicaciones de Magento (como una biblioteca javascript, o un paquete php, etc.), puede colocarlos en el \libdirectorio.

Es cierto que puede existir un archivo duplicado si dos extensiones se basan en los mismos paquetes de recursos. También pueden usar versiones diferentes del mismo paquete de recursos. Pero, básicamente, su extensión debe usar solo el recurso de su extensión (y puede confiar en los recursos predeterminados de Magento) y no debe depender de los recursos de otra extensión, a menos que su extensión sea una "versión extendida" de una extensión de terceros.


Gracias. Su respuesta favorece el punto de vista del desarrollador, en lugar del lado del propietario del sitio. Pero supongo que así es en Magento. Sé de otros CMS que han acordado lugares para descomprimir archivos / bibliotecas de terceros, manteniendo todos los archivos juntos tal como están en el original.
fris

1
Si. Sé que es frustrante separar un recurso de paquete. Magento lo exige. No hay forma fácil de hacerlo. Las mejores prácticas de Magento dicen "Deberías mantener todo js, css, imagesen el base\defaultpaquete". También vea mi código de edición
Rajeev K Tomy

Hola Rajeev ... Otra consecuencia de colocar los archivos de recursos externos / lib bajo "your_extension" es que no pueden compartirlo otras extensiones que también puedan usar el recurso / lib. Entonces terminas con múltiples copias, posiblemente diferentes versiones de CLASHING, cargadas en la misma página. ¡Ay!
fris

mira mis ediciones por favor
Rajeev K Tomy

0

Magento tiene su propio administrador de paquetes llamado Magento Connect. Debe consultar esta guía de la documentación oficial para comprender completamente cómo debe verse el paquete. Puede empaquetar su módulo desde una instalación de Magento una vez que comprenda la estructura.


Gracias por su respuesta, pero no es exactamente lo que estaba preguntando. No se trata de cómo empaquetar mi extensión, se trata de en qué lugar del árbol de archivos de Magento colocar archivos de terceros que NO son parte del núcleo o de mi extensión, pero deben incluirse como parte del sistema. ¿Dónde les digo a los usuarios que pongan esos archivos? ¿Hay un lugar estándar (o puntos) para archivos de terceros?
fris

En realidad está relacionado con el enlace que te envié. Js y css tienen sus propias carpetas para paquetes como cualquier otro archivo de extensión. Los archivos PHP pueden estar debajo de la carpeta lib raíz o dentro de la carpeta del módulo dentro de una carpeta lib.
mbalparda

Ok, gracias. Entonces su respuesta es: Sí, los creadores de sitios de Magento deben descomprimir el archivo de terceros, extraer las partes PHP, JS, HTML y CSS de ese archivo y redistribuir esos archivos en las ranuras apropiadas en el árbol de archivos de Magento. NO se considera una buena práctica permitir que el creador del sitio descomprima simplemente todo el archivo de terceros en algún directorio comúnmente acordado designado para este propósito desde donde las extensiones asociadas incluirán los archivos de terceros según sea necesario.
fris

Si. Todo lo que describió ya está cubierto en el proceso de empaque descrito en la documentación.
mbalparda

Bueno, he leído esa documentación, pero no dice nada sobre mi pregunta. Solo habla de archivos que son parte de la extensión que desarrollas y quieres empaquetar. No dice dónde colocar los archivos de terceros que NO son parte de la extensión, como un calendario o una galería de imágenes o un paquete de gráficos. Es posible que no desee empaquetarlos con la extensión que está desarrollando, para que puedan actualizarse de forma independiente. ¿Entonces la pregunta es dónde colocar los archivos de terceros? ¿Cuál es el enfoque de mejores prácticas para aquellos?
fris

0

Básicamente Magento utiliza su propia estructura de retención .php, .phtml, js, css, imagesarchivos.

Para el desarrollador de extensiones de magento es muy importante que sigas el camino de magento. Mira este enlace .

Entonces,

  1. Tus .phparchivos deben ir debajo de la app/code/communitycarpeta
  2. Sus jsarchivos pueden ir a la jscarpeta o en la skin/frontend or adminhtml/your_theme_pack/your_theme/jscarpeta
  3. Tus cssarchivos pueden ir a la skin/frontend or adminhtml/your_theme_pack/your_theme/csscarpeta
  4. Tus imagesarchivos pueden ir a la skin/frontend or adminhtml/your_theme_pack/your_theme/imagescarpeta
  5. Su files should go tocarpeta 'html app / design / frontend o adminhtml / template`

PS frontend significa si su extensión es para front store y adminthml significa si su extensión es para el área de administración.

Hay una forma específica de mantener estos archivos en magento, por lo que debe seguirlos.

También verificaría si sus funciones deseadas / copia ya están disponibles en magento / zend framework. Por ejemplo, crear pdf, enviar correos electrónicos, leer xml, etc., ya están construidos en magento.

Espero que esto ayude.

Actualización 1

Si desea mantener sus archivos en algún lugar, puede hacerlo en cualquier lugar. Incluso puede crear una nueva carpeta dentro de la raíz de magento. Pero esta no es la mejor práctica para magento, que cargará su servidor cuando ejecute esos archivos. Desea verificar esto https://magentotherightway.com/


Gracias por el enlace y la explicación. Pero no estoy preguntando sobre la extensión en sí. Le pregunto dónde colocar el código de terceros no incluido en la extensión. ¿Existe una ubicación ÚNICA comúnmente aceptada?
fris

Si desea mantener sus archivos en algún lugar, puede hacerlo en cualquier lugar. Incluso puede crear una nueva carpeta dentro de la raíz de magento. Pero esta no es la mejor práctica para magento, que cargará su servidor cuando ejecute esos archivos. Desea verificar esto magentotherightway.com
Adarsh ​​Khatri

Las extensiones distribuidas nunca deberían instalarse en la localagrupación de códigos.
Benmarks
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.