¿Qué hay antes de la programación en Prestashop?

¿Te has preguntado alguna vez cuáles son los pases para desarrollar un módulo en PrestaShop? ¿Te encantaría saber programar pero no sabes por donde empezar? Hoy, te cuento mis primeras experiencia con PrestaShop. No te lo pierdas.

Alabaz
Actualizado: 13/10/2023 597
¿Qué hay antes de la programación en Prestashop?
Compartir:

Soy informático y programador web. Desde pequeño siempre me ha gustado ya no resolver problemas sino encontrar soluciones sencillas y prácticas a problemáticas resueltas anteriormente... Se puede decir que me gusta mi trabajo y le dedico bastantes horas de mi vida aún después de acabar la jornada (uno nunca podrá decir que lo sabe todo).

 

He estado 10 años trabajando en el mundo web que rodea a java y ponerse de cero con php y Prestashop no me resultó complicado, pero hay que dedicarle tiempo para lograr familiarizarte y llegar a dominar y conocer todas las clases, controladores, etc... Es como tirarte 10 años tocando un sólo coche y, de repente coger otro. Sabes para qué sirve cada pedal y aunque consigues que el coche haga lo que quieres, eres consciente de que te cuesta dominar un poco su funcionamiento (el embrague está más duro, o más blando, o las marchas son más cortas o más largas...) y no te sientes tan seguro como estarías en tu viejo coche.

 

Recuerdo que antes de hacer mi primer módulo serio para Prestashop (que por cierto fue para Alabaz , se llama megacanones y me siento muy orgulloso :)), tuve que hacer varios módulos sencillos para realizar pruebas en base a lo que iba aprendiendo (instalación, traducciones, hooks, clases, controladores, overrides...). Me basaba sobre todo en los manuales de Prestashop y en el código que iba encontrando en los otros módulos según el tema que iba investigando (por cierto, viva el código abierto, es la mejor manera de aprender y creo que es por la principal razón por la que se creó).

 

Una vez ya ves que el “coche” parece que funciona, entonces ya te dedicas al planteamiento real del módulo que de verdad se desea hacer.

 

Desarrollar un módulo para PrestaShop conlleva muchas horas de planteamiento e investigación

 

Previamente, tiene que haber una toma de requerimientos y estar plasmada sobre papel, lo típico que se realiza cuando se entrevista a un famoso (qué, cómo, cuándo...) sólo que en este caso para nuestro módulo. Sería algo así como los planos donde mirar en caso de ver que la torre se tuerce. Sobre todo, hay que tener bien claro cuál es la finalidad del módulo, qué procesos debe de realizar para llegar a ello, qué datos recibe y cuáles y cómo son sus resultados (base de datos, pantalla...).

 

Posteriormente, es posible que se vayan añadiendo más requerimientos o se vayan corrigiendo ciertas puntualizaciones de ellos, pero ya hay una base sobre la que ponerse a trabajar y siempre sern modificaciones pequeñas.

 

Siguiendo con el módulo de megacánones , un ejemplo de esta toma de requerimientos sería la siguiente (un poco resumida):

 

1.- Un canon es un incremento en el precio del producto. Este incremento, puede estar incluido en el precio que se visualiza o incluirse después. Además debe de poder tener la opción de añadirle un impuesto. El canon además debe de contener un texto que lo defina. (este punto es el más claro para saber qué datos de entrada necesitamos)

2.- El canon debe de estar visible en el momento de la compra y debe de añadirse junto al producto al realizar la compra, visualizándose que se ha añadido junto con el producto tanto en el carrito como en el checkout para que el cliente sea consciente en todo momento de lo que está pagando (en este punto se reflejan los procesos que realizan los datos introducidos).

3.- Además debe de salir en la factura, en el email y en el pedido (este último punto refleja bastante bien el tema que comentaba del qué y el cómo de los resultados, pues hay tres formas diferentes de plasmarlo).

 

Aún no hemos empezado a tocar código para hacer nuestro módulo y ya hay en el deber de nuestra planificación varias horas empleadas... Y las que faltan, pues antes es conveniente realizar un estudio exhaustivo (plasmándolo en papel también) de:

  • qué datos/resultados hay que mantener y dónde se va a realizar su visualización y conservación (formularios ya sea en backoffice o en el frontoffice, alguna página específica de prestashop...etc). En esta parte, es hasta recomendable hacer un diseño (en papel) del propio formulario o de la visualización.
  • qué páginas de prestashop afectan a nuestra funcionalidad, qué plantillas se utilizan y qué hooks hay disponibles, y ya de modo más experto, las clases y controladores.
  • Realizar esta tarea también con otros sitios a tener en cuenta, tales como otros módulos, envíos de correo... si fuese necesario claro.
  • Sobre todo, intentar abarcar todas las funcionalidades de prestashop para que no se nos escape algo y el módulo no funcione correctamente. Por ejemplo, si estamos realizando una funcionalidad en el checkout hay que tener en cuenta que prestashop tiene una opción por defecto para un paso o para 5 pasos y dependiendo de ello, ejecutará ciertos controladores y clases.

 

Una vez hemos aclarado estos puntos, simplemente hay que añadir al documento que estamos realizando nuestro propio estudio de lo que vamos a realizar. En esta fase, ya estamos analizando los puntos críticos desde nuestra perspectiva y conocimientos y, por tanto, definiremos la solución más factible para realizar cada una de las funcionalidades; ya sea enganchar a un hook, realizar un override... o simplemente definir nuestras propias clases y los datos contenidos en ellas (sin desarrollarlas claro).

 

Por ejemplo (sin llegar a aspectos muy técnicos), en el módulo de megacanon que os comentaba se podría identificar lo siguiente:

  • los datos del canon. Clase definida por nosotros => Canon.php
  • debía tener un formulario para introducir los datos del canon y asociarlo al producto (formulario en el backoffice): Esta parte se va a implementar con el hook adminproductsextra y un formulario helperform.
  • Su visualización principal era en la página del producto (frontoffice): Product.php, ProductController.php, product.tpl
  • Debe de añadirse al carrito junto con el producto: Cart.php y CartController.php
  • pero posteriormente debía visualizarse junto con el producto en el carrito, checkout, pedidos, facturas, envíos de correo..etc. (Esta parte la dejo pues se me puede extender demasiado).

 

Siempre hay que buscar la mejor solución aunque no para todos sea la misma

 

Este último estudio siempre será muy personal, pues cada desarrollador tiene sus preferencias y sus metodologías (aunque algunas no sean lo más correctas), y siempre habrá alguien que lo vea y diga - “yo lo haría así” . Por supuesto, debemos estar abiertos a opiniones, gustos e incluso a cualquier comentario, pues es posible que todo esto nos ayude a mejorar o ver una problemática con la que no habíamos contado. Por ejemplo, yo no soy partidario de sobreescribir plantillas smarty (tpl) ya definidas por prestashop; aunque en parte, es la forma más fácil y en tiempo no nos costaría apenas, pero estamos un poco pillados y limitados ante cualquier modificación de esta plantilla de manera externa.

 

Un ejemplo claro de lo que comento es la visualización del canon en el carrito, en el cual la forma más sencilla, era sobreescribiendo la plantilla relacionada y añadirle dos o tres simples líneas en las que salía el canon y su importe. Al final, y como he dicho, debido a mi forma de pensar (seguro que alguien hubiese optado por la otra opción), aproveché un hook que tenía ya definido para hacerlo todo por javascript, cosa que me hizo escribir más código e incluso dobló considerablemente mi esfuerzo y mi tiempo; pero mi objetivo no era acabar antes, sino independizar esta parte un poco de prestashop.

 

Todo esto que a priori parece una pérdida de tiempo, nos facilitará mucho a posteriori la programación del módulo pues estamos plasmando sobre el papel aquello que vamos a tocar/crear posteriormente. Evidentemente, es posible que en el momento del desarrollo en sí, nos encontremos con alguna problemática o duda que no nos habíamos planteado, y nos veamos obligados a variar parte de los requerimientos y/o del planteamiento para poder solucionar esta problemática. Pero os garantizo que siempre será una problemática pequeña en comparación con cualquier otra forma de programar (la de ensayo-prueba-error está bien cuando se está aprendiendo pero después su uso pierde efectividad cuando ya se domina un poco el sistema).

 

He intentado no llegar a tecnicismos pues quiero que este post sea leído ya no por informáticos, sino por personas que les gusta este mundo de Prestashop y les pica el interés y la curiosidad de poder dar un paso más.

 

Espero vuestros comentarios.

Un saludo,

Módulo de cánones para productos en Prestashop  - Addons PrestaShop

Módulo de cánones para productos en Prestashop

Este módulo nos permite la asignación de cánones u opciones extras a nuestros productos de Prestashop, configurándolos por completo en función de nuestras necesidades y las de nuestros productos.

Ver pantallasVer pantallas
360,25 €
AWPrime 435,90 € info Ver más
Buscar en el blog...
Últimos artículos
Más vistos
Síguenos en redes
0 comentarios

Escribe un comentario

¿Qué te ha parecido?