El mundo de los ecommerce ha evolucionado mucho en la última década junto con el crecimiento del mundo tecnológico. Por ello, se ha de estar en continua evolución en todos los ámbitos y es de vital importancia escoger correctamente un producto que nos permita extender las funcionalidades de nuestra tienda mucho mas allá de cualquier caso estándar que se pueda presentar.
En esta ocasión vamos a crear un sencillo módulo el cual eliminará del dashboard del backoffice el botón tan molesto de «demo», que siempre vamos a querer quitar cuando se trata de una tienda que se encuentra en funcionamiento. Esto nos permitirá explorar el mundo de los módulos en PrestaShop, para aumentar las funcionalidades que nos brinda, así como resolver problemas no existentes hasta la fecha. A través de este sencillo caso, vamos a exponer como se crea un módulo y como podemos hacer un override de un controlador del backoffice. Del mismo modo, podremos hacer un override de un controlador del frontoffice o de cualquier clase de PrestaShop.
El correcto desarrollo de módulos en prestashop nos puede ayudar a paliar o desarrollar módulos completamente personalizados bien para nuestra tienda o bien para clientes que necesitan una solución concreta a un problema o que necesitan una funcionalidad específica. Esto nos permite personalizar de mejor medida la solución de Prestashop a las diferentes necesidades de los clientes.
¿Cuál es el primer paso para crear un módulo?
En primer lugar lo que haremos será crear una carpeta con el nombre del módulo, en este caso «disabledemo». Lo siguiente que vamos a hacer es añadir un logo como indican en esta página de configuración de PrestaShop:
El siguiente paso será añadir este archivo index.php a todos y cada uno de los directorios de nuestro módulo. PrestaShop lo tiene en todos los subdirectorios, para evitar que queden al descubierto y que puedan ser listados. El archivo quedaría tal que así:
Lo siguiente que vamos a hacer es crear el archivo propio del módulo que será el encargado de manejar la lógica, instalar y desinstalar entre otros. Para ello haremos una sobreescritura del método __construct del padre, así como el método install. En este primero, como se aprecia en el código, solo le hemos añadido las propiedades de name, version y author (posteriormente aparecerá toda esta información en el listado de módulos), pero PrestaShop nos brinda una gran cantidad de opciones de configuración para modificar el comportamiento del módulo. Invocamos al constructor del padre, y acto seguido, modificaremos las propiedades de displayName, description y ps_versions_compliancy. Sin entrar en mucho detalle, para las dos primeras (nombre y descripción), estamos usando el traductor, para que las muestre traducidas en función del idioma del backoffice, y para la tercera (versión), le estamos indicando que versión de PrestaShop se requiere para poder instalar nuestro módulo. Por último, usaremos la función install para actualizar el valor de la configuración de PrestaShop PS_DASHBOARD_SIMULATION, que se encarga de decidir si debe mostrar o no datos de una simulación en las gráficas y bloques del dashboard.
Ahora, vamos a hacer un override del controlador que muestra el botón de demo, para evitar que el administrador pueda activar la funcionalidad. Para hacer un override en PrestaShop, todo debe residir en la carpeta override dentro del módulo que queramos crear. Hay limitaciones con esta versión 1.7, puesto que todas las clases que posean namespace no son objeto de override a través del mecanismo común propio de PrestaShop. Esto es porque están cargadas a través del autoloading de composer. Hay que tener en cuenta, que este mecanismo no permite hacer dos o mas overrides del mismo método de un objeto, desde PrestaShop nos instan a realizarlo de forma manual. En este caso, vamos a hacer un override del controlador AdminDashboardController, que podrás encontrar en al ruta /controllers/admin. Esto es así también para las clases. Un aspecto importante a tener en cuenta es que la clase se ha de llamar como se llama el archivo de PrestaShop, pero tiene que heredar de la clase con terminación «Core». Si abres el controlador de PrestaShop, verás que el nombre del archivo no coincide con el nombre de la clase. A continuación mostramos como queda el override:
A continuación se muestra, como quedaría la estructura de ficheros tras haber creado el fichero del módulo(disabledemo.php), el override del controlador del backoffice(AdminDashboardController.php) y el logo junto con los archivos index.php en cada uno de los directorios.
Ahora solo nos queda ir a módulos > catálogo de módulos > buscar nuestro módulo e instalarlo.
Si todo ha ido bien, verás un aviso en la parte superior derecha en color verde, confirmando que el módulo está activo y funcionando. Para comprobarlo iremos al dashboard del backoffice para asegurarnos que ha desaparecido el botón y la tienda no tiene activado el modo demo.
Conclusión
Con este artículo hemos comentado muy brevemente de que forma podemos crear un módulo. Aunque breve se han dado algunas pinceladas del flujo de PrestaShop en algunos temas muy importantes relacionados con el override, así como, su estructura de archivos por lo que a clases y controladores respecta. A partir de aquí se puede seguir investigando para desarrollar módulos que sean capaces de suplir carencias por lo que a requisitos de negocio se refiere. Quedan otros tantos temas como, override de plantillas, o la forma de crear un child theme.
Ahora queda en el campo de desarrollador, seguir investigando. Pero, sobretodo, lo mas importante, sin dejar atrás la documentación, es muy aconsejable, siempre que usamos un framework, leer su código y también sus test. Esto último nos ayudará a comprender en profundidad los casos de uso de cada una de las partes de la aplicación.
Cloudflare es una plataforma que nos permite mejorar el rendimiento de nuestras webs con sus características de CDN y protegerlas utilizando sus características de seguridad. En este artículo vamos a seguir el sencillo proceso de configuración de Cloudflare, paso a paso con el plan gratuito. Como solución básica el plan gratuito es más que suficiente, aunque si tenemos necesidades un poco más avanzadas podemos pasar a los planes de pago y activar las características extra que ofrecen.
¿Por qué configurar Cloudflare?
Clouflare nos permite servir nuestra web en menos tiempo aprovechando su red de entrega de contenido (CDN) formada por 180 centros de datos en 80 países, esto quiere decir que a un visitante americano se le servirán los recursos estáticos o elementos cacheados por Cloudflare desde el centro de datos más cercano a su ubicación en lugar del servidor español en el que está alojada la web, reduciendo así las latencias y por tanto el tiempo total de carga.
Además Cloudflare incluye algunas optimizaciones sobre los recursos como la minificación de javascript o la optimización de imágenes para incrementar esa mejora en el rendimiento de nuestra web. No vamos a comentar en este artículo la optimización de imágenes u otras funcionalidades que no están incluidas en el plan gratuito, porque se pueden utilizar otras herramientas para optimizar las imágenes como ya os contamos en un artículo anterior.
Desde Cloudflare también indican que su servicio de DNS es uno de los más rápidos, es evidente que todos los servicios que ofrecen están enfocados a optimizar al máximo una porción del tiempo necesario para cargar una web. Con todas esas optimizaciones, en algunos casos, podremos apreciar grandes mejoras.
Junto a los servicios de optimización también cuenta con servicios enfocados a la disponibilidad, por ejemplo un servicio de caché que podría servir nuestra web incluso en momentos en los que nuestro servidor se encuentre caído llamado Always Online.
Por último, además del rendimiento y disponibilidad, Cloudflare ofrece funcionalidades para mejorar la seguridad de nuestras webs como la mitigación de ataques DDoS y el WAF dedicado a proteger las webs de las vulnerabilidades más comunes que podrían exponer datos privados de los usuarios o poner nuestro servidor al servicio de actividades maliciosas.
Una de las características clave de Cloudflare es que se trata de un servicio totalmente independiente de las tecnologías usemos para desarrollar nuestra web, no importa el lenguaje o el CMS que usemos, y aunque existan paquetes específicos como el plugin para WordPress no es necesario instalarlos para poder aprovechar sus servicios, únicamente nos aportan la comodidad de poder realizar ciertas acciones desde el panel de nuestra web en lugar de tener que acceder al panel de Cloudflare.
¿Cómo activar Cloudflare en nuestra web?
#Paso 1: registra una cuenta
Lo primero que tendremos que hacer es registrar una cuenta en la web, una vez estemos registrados podremos añadir el dominio que queremos configurar, debemos tener en cuenta que no permite introducir únicamente un subdominio, por lo que tendremos que configurar el dominio raíz donde esté alojada la web.
Una vez añadido el dominio, Cloduflare nos indicará que va a configurar automáticamente las entradas de DNS que tenemos ya configuradas en nuestro servicio para que no tengamos que introducirlas manualmente.
#Paso 2: selecciona el plan que tu web necesite
Lo siguiente que tendremos que hacer es seleccionar el plan que queremos utilizar para nuestra web, en este caso vamos a usar el plan gratuito que nos permite utilizar las funcionalidades de CDN y mitigación de DDoS junto a alguna característica adicional más.
Lo próximo que veremos será una lista similar a la de la captura que hay a continuación con nuestras entradas de DNS y el estado de la configuración de Cloudflare indicado con nubes grises y naranjas, si se trata de la primera vez que configuramos el servicio lo mejor es que dejemos la configuración que se ha generado automáticamente y que por lo general se trata de activar DNS y proxy HTTP para servir el tráfico a través de Cloudflare en las entradas que corresponden a la web y únicamente CDN para el resto.
#Paso 3: cambia los servidores de DNS
Para activar la configuración que acabamos de crear tendremos que cambiar los servidores de DNS del dominio a los indicados de Cloudflare (este proceso depende de nuestro proveedor pero en todos es similar) y esperar a que los cambios se propaguen. Una vez hecho esto, si Cloudflare no ha detectado que hemos actualizado la configuración de manera automática, podremos pulsar el botón Re-check now en el dashboard de nuestro dominio para validar la nueva configuración.
¿Qué posibilidades nos ofrece Cloudflare?
Con las DNS correctamente configuradas ya podremos personalizar los servicios que queremos utilizar en nuestra web, desde el propio dashboard además tendremos acceso a un conjunto de acciones rápidas que nos permiten activar y desactivar o ejecutar fácilmente las siguientes características:
El modo desarrollador para desactivar temporalmente la caché de Cloudflare, útil para poder ver los cambios instantáneamente reflejados en nuestra web mientras estamos trabajando en ella.
El modo Under Attack que permite añadir un captcha a cualquier usuario que intente acceder a la web para bloquear las peticiones que no sean realizadas por usuarios legítimos.
Purgar la caché es un acceso directo a la sección de caché donde podremos eliminar los contenidos cacheados por Cloudflare, bien por completo o bien definiendo qué contenidos queremos eliminar para mantener otros. Por ejemplo si solo queremos purgar la caché correspondiente a una url ésta opción nos lo permite.
Configuración de DNS, este último enlace es un acceso directo a la sección DNS de la configuración.
Además de activar las características que consideremos oportunas de manera global como las que ya hemos mencionado: caché, modo Always Online, minificado de estáticos podremos definir reglas dinámicas por url. La sección page rules nos permitirá configurar unas acciones, limitadas en cantidad y tipo por el tipo de plan contratado, dependiendo de la url.
Por ejemplo, nos permite desactivar el auto minificado de nuestro dominio a nivel global, ya que, puede ser fuente de problemas con nuestro ecommerce y activarlo únicamente para el blog tras comprobar que todo funciona correctamente añadiendo una regla como la de la siguiente captura.
Como hemos visto Cloudflare puede ser una herramienta que nos permita mejorar el rendimiento de nuestra web pero no sustituye un buen plan de WPO en el que tengamos en cuenta las características concretas del proyecto. Como con todas las herramientas hay que realizar una configuración adecuada a las necesidades existentes ya que las optimizaciones automáticas no siempre son la solución y nos traen algún problema nuevo. Lo ideal es optimizar al máximo nuestra web y revisar una a una las características de Cloudflare para ver en qué estamos interesados y en qué no, por ejemplo podemos encargarnos nosotros desde la web de generar los recursos estáticos optimizados y utilizar Cloudflare como CDN para servirlos desde puntos cercanos al usuario.
PrestaShop es una plataforma eCommerce que cuenta con una gran comunidad de usuarios y un ecosistema en lo que a módulos se refiere, que suplen una gran cantidad de necesidades diversas, además cuenta con una licencia Open Software License v.3.0. Nos brinda una gran cantidad de opciones, que van desde tarifas para transportistas de diferentes zonas geográficas, stock avanzado e incluso la posibilidad de hacer una multitienda. Pero, si queremos interactuar con el core PrestaShop sin necesidad de hacerlo de forma manual o a través de las vías habituales haciendo uso del del backoffice. ¿Cómo lo hacemos? Para este propósito se creó el webservice, el cual, a través de la exposición de un recurso, nos permite realizar acciones para automatizar tareas, integrar la información en otros sistemas, etc. Entre los cuales, podemos ver que hay recursos para «orders», «products» o «customers» entre otros.
¿Qué vamos a hacer?
En este artículo, vamos a ver como podemos explotar el recurso de «orders» con los permisos de «Ver» a través del webservice. Anteriormente, comentamos que era un API REST, te dejamos aquí un link por si todavía no sabes qué es. Además, en este otro artículo, comentamos el uso de composer, que usaremos para instalar una librería que nos facilitará el trabajo. Vamos a suponer que se dispone de un servidor apache o nginx para ejecutar los archivos que a continuación se presentan.
Para comenzar con las pruebas, vamos a utilizar un paquete llamado guzzle, que instalaremos a través de composer. En la documentación del paquete nos instan a que instalemos composer, paso que nos saltaremos, suponiendo que ya lo tenemos instalado. El siguiente comando lo que hará entre otras cosas, es descargar el paquete con sus respectivas dependencias en la carpeta vendor, generar los autoloaders, etc, para que podamos usarlo.
¿Cómo crear el api key en PrestaShop?
En primer lugar, lo que necesitamos para poder iniciar las pruebas es tener una clave de webservice. Para ello, nos dirigimos a parámetros avanzados > Webservice. Si nunca lo hemos usado, tendremos que activar el servicio con el switch correspondiente antes de añadir el key. Tras pulsar sobre añadir, se nos muestra una tabla, con los recursos a la izquierda, y las acciones en la parte superior. Nosotros sólo activaremos el recurso «orders» con la acción GET, para poder llevar a cabo consultas, como hemos comentado anteriormente. El resto de acciones, se pueden usar para crear, borrar y modificar un recurso, cosa que queda fuera de este artículo.
Es importante remarcar, que tanto el resultado, como la introducción de datos al webservice se hace en formato xml. Así pues, para tratar la información que nos devuelva, como también la información que le proporcionemos al crear o editar, será necesario que esté en formato xml correcto. Para ello hay opciones que trae el propio core de PHP, como podría ser SimpleXML. Nosotros recomendamos una alternativa mejor llamada serializer, la cual tiene mucha versatilidad por la cantidad de formatos que pueden usarse y cuenta con una documentación de excelente calidad.
Ahora que tenemos creada nuestra api key, podemos hacer una prueba rápida de que funciona, accediendo a la url: . Esto devolverá un listado de elemento en formato xml con todos los permisos que la cuenta tiene sobre ese recurso. Revisa que en el xml, el atributo get es true, para el recurso «orders». En caso de que no sea correcta la configuración, PrestaShop te mostrará el siguiente mensaje de error: «405 Method Not Allowed».
La estructura para acceder a los recursos es la siguiente: /api/[recurso]/[?identificador]?ws_key=[clavegenerada]. Si introducimos un identificador nos mostrará los datos relevantes al elemento, por el contrario, si obviamos ese identificador, devolverá un listado de todos los elementos que hay en ese recurso.
Obtención de un listado de elementos
Para llevar a cabo el primer cometido, vamos a crear un archivo, como el siguiente para obtener un listado de elementos, que forman parte del recurso «orders»:
Y a continuación, la respuesta:
Como podemos observar, el listado de elementos, a parte de tener una propiedad id, nos muestra la url absoluta donde podemos consultar la información de ese elemento en concreto. No se puede obtener mas de uno a la vez, es necesario hacer una petición por cada elemento a consultar.
*Si accedes al archivo a través de un navegador, es probable que no veas la respuesta del servidor, puesto que el navegador va a detectar que se trata de xml y lo intentará parsear. En tal caso, puedes usar un lector de xml usando alguna extensión para el navegador, o simplemente ver el código fuente de la página. En caso de usar otras herramientas como curl o httpie para realizar la petición, verás el contenido correctamente.
Obtención de un listado de elementos de forma paginada
Ahora vamos a hacer uso de un parámetro que nos permite realizar una paginación simple, solo para los listados de elementos, ya que al consultar la información de un elemento, carece de sentido. Para ello vamos a utilizar el parámetro limit que tiene el siguiente formato: limit=[inicio],[cantidad]:
Y esta es la respuesta:
Como se puede observar, la respuesta muestra un listado, pero esta vez, con el número de elementos y el inicio que le solicitamos. Esto es un aspecto clave a tener en cuenta a la hora de hacer uso de la api, para optimizar los recursos. Nos permite obtener cantidades de información mayores con la misma petición.
Obtención de la información relativa a un elemento
Para ello vamos a crear el siguiente archivo:
La respuesta:
Hemos omitido parte de la respuesta, ya que son datos irrelevantes para el objetivo de la prueba. Aquí podemos observar como los recursos que cuentan con su propia uri para acceder, nos indica su url absoluta, y no nos proporciona la información de dicho recurso. En caso de necesitar, por ejemplo, el elemento del carrito (cart), deberíamos hacer una nueva petición a esa url. En nuestro caso, no podríamos tener acceso a él, sin habilitar los permisos al menos de «Ver» para dicho recurso.
Conclusión
Hemos configurado el acceso al webservice de prestashop para hacer posteriormente un uso en los tres casos que se nos pueden presentar por lo que a consulta se refiere: listar elementos, paginar listado de elementos y consultar la información relacionada con cada elemento. Además hemos hecho uso de composer para utilizar el paquete de un tercero.
Cuando tenemos un tienda en PrestaShop y necesitamos extraer y/o actualizar información, este es un buen punto de partida para conseguir la interoperabilidad entre sistemas. Si bien es cierto, que carece de algunos aspectos que facilitarían la obtención de datos, como por ejemplo, extracción de la información de los elementos en bloque, pues estamos limitados a consultar los elementos de uno en uno. Es posible llevar a cabo una integración al tratarse de una API REST, que nos puede permitir realizar cualquier automatización de tareas o la extracción de información. En todo caso, es una herramienta útil, que deberemos tener siempre en cuenta, para cuando tengamos unas necesidades que no podemos realizar por otras vías.
Una vez nos hemos decidido a desarrollar nuestra aplicación con Symfony y la tenemos lista para desplegar en producción debemos tener en cuenta una serie de cosas tanto cuando se trata de un primer despliegue como cuando se trata de una actualización.
¿Qué opciones tenemos para desplegar los cambios en una aplicación?
Actualmente hay 2 alternativas principales, por un lado podemos ver la aplicación como un conjunto de ficheros de código, configuración, base de datos, dependencias y demás artefactos. En ese caso necesitaremos tener una estrategia clara para que los nuevos cambios en el conjunto de nuestra aplicación que se suele describir mediante build scripts.
Otra aproximación que se está extendiendo rápidamente son las aplicaciones empaquetadas en contenedores.
Actualmente es docker la herramienta que se ha posicionado como estándar de facto y que nos permite, en lugar de utilizar scripts que manejan los cambios en la aplicación, empaquetar la aplicación en una imagen que contiene todas las dependencias y aísla la ejecución de otras aplicaciones que se estén ejecutando en el servidor.
La ventaja es que para cada versión de nuestro software podemos construir la imagen necesaria en nuestro servidor de CI/CD y publicarla en el registro correspondiente para que la actualización sea tan sencilla como levantar otro contenedor que sirva la aplicación en base a la imagen nueva y detener la ejecución del contenedor con la versión antigua.
Normalmente durante el desarrollo se debe tener en cuenta si el objetivo será usar docker ya que puede condicionar algunas decisiones que tomemos para facilitar después el uso de contenedores. Por ejemplo cuando usamos contenedores las aplicaciones deben ser stateless (no deben mantener estado, es decir, debe poder destruirse el contenedor de un nodo del clúster y levantarse otro usando la misma imagen sin que el servicio se vea afectado).
¿Qué vamos tratar nosotros en este artículo?
Vamos a seguir la aproximación clásica, tenemos un servidor en el que reside la aplicación, con un estado actual y queremos poder desplegar nuestras nuevas versiones de la manera más sencilla y automatizada posible.
Para ello, como ya hemos anticipado, no vamos a entrar en las posibilidades del mundo de los contenedores porque se trata de un tema algo más avanzando, tampoco en los zero downtime deployments en los que el servicio no se interrumpe.
Lo que sí pretendemos es sentar las bases de qué cambios son los más comunes que sufre una aplicación cuando está en desarrollo o mantenimiento y necesita ser actualizada para que a partir de ahí cada equipo profundice en las técnicas avanzadas relacionadas con sus necesidades.
¿Qué piezas componen una aplicación cuando afrontamos su despliegue?
Código de la aplicación
Es el código que nosotros escribimos y por tanto del que nos responsabilizamos, en nuestro caso se trata fundamentalmente del contenido de las carpetas assets, config, src y templates.
Cuando queremos desplegar una nueva funcionalidad por lo general tendremos nuevo código o modificaciones en el código de nuestra aplicación y transmitir estos cambios desde nuestro entorno de trabajo al servidor de producción puede ser tan sencillo como subir mediante FTP los ficheros correspondientes. Esto es un proceso manual y como todo proceso manual es propenso a errores, es por ello que si ponemos en una balanza simplicidad, comodidad y calidad del proceso (que sea repetible, fiable, la posibilidad de rollback) una opción sólida que equilibra las cualidades que queremos maximizar es el uso de git.
Ya deberíamos estar utilizando git como pieza central en nuestro flujo de desarrollo y como sistema de control de versiones distribuido nos va a permitir tener otro repositorio en producción que utilizaremos únicamente para desplegar cambios.
Esto puede hacerse de manera más o menos automatizada según queramos complicar el proceso. Si usamos un servicio de CI/CD podemos automatizar el envío a nuestro servidor de producción de los cambios, pero si no queremos dar el paso podemos trabajar con 2 remotes en nuestro proyecto, uno para nuestro repositorio central (github, gitlab, etc) y otro para el servidor de producción..
Para cambiar la versión del código de producción lo único que tendremos que hacer es pushear los nuevos commits al remote que tengamos configurado.
Configuración
Los parámetros que configuramos en una aplicación Symfony deberían encontrarse en los ficheros .env*, es cierto que al desplegar los cambios en el código habremos actualizado nuestro fichero .env pero tendremos que realizar manualmente cualquier cambio en .env.local.
A pesar de ser un paso manual en entornos en los que queremos tener un flujo sencillo no debería ser un problema ya que es una de las zonas de la aplicación que menos cambia. Además por la propia naturaleza de la información almacenada muchas veces no podemos incluirla en nuestros repositorios por lo que las opciones disponibles no son muchas, prácticamente nos quedan los gestores de secretos como vault o la configuración manual.
Si a esto le sumamos un esfuerzo por nuestra parte en tener valores por defecto sensatos nos encontraremos muchas veces sin la necesidad de sobrescribir el valor por defecto de .env y por tanto no tendremos que realizar ninguna acción manual. En otras ocasiones tendremos que configurar los valores de manera obligatoria, por ejemplo cuando tenemos que añadir un token de autenticación de un sistema de terceros.
Bases de datos
En una aplicación basada en Symfony es muy común que cuando estemos trabajando en nuevas funcionalidades nos encontremos trabajando con nuevas entidades o cambios en las ya existentes. Para ese caso de uso hay una opción muy potente, se trata del paquete doctrine/doctrine-migrations-bundle.
Una vez empecemos a utilizar migraciones nuestro flujo de trabajo durante el desarrollo contará con un paso más, cada vez que modificamos la persistencia de las entidades generaremos una migración. Esto se traducirá en un nuevo fichero php con la habilidad de ejecutar el SQL necesario para hacer el cambio en la entidad y el SQL necesario para deshacer el cambio.
Por tanto tendremos en nuestro sistema de control de versiones un sistema de control de versiones de la estructura de la base de datos. Podemos dejar que sea el paquete quien se encargue de generar el SQL necesario pero también podemos modificarlo para reflejar otro tipo de cambios o generar migraciones vacías en las que seremos nosotros quien defina el cuerpo de los métodos up y down.
Cuando esas nuevas migraciones se encuentren en el servidor de producción tendremos que ejecutarlas para que realice los cambios necesarios a en la base de datos.
Dependencias
Si estamos usando Symfony y Webpack Encorecontaremos con 2 gestores de paquetes, por un lado Composer para las dependencias php y por otro Yarn para las correspondientes al front.
Cada vez que realicemos cambios en los ficheros que describen las dependencias que maneja Composer tendremos que ejecutar en nuestro servidor composer install –no-dev –optimize-autoloader para que la herramienta descargue las versiones correctas de nuestras dependencias y las instale teniendo en cuenta las optimizaciones que se pueden llevar a cabo en producción.
De igual manera, cada vez que realicemos cambios en los ficheros correspondientes a Yarn tendremos que ejecutar yarn install en nuestro servidor.
Artefactos
En el caso que planteamos, y siguiendo la misma filosofía que con las dependencias, si hay cualquier cambio en nuestros assets éste debería reflejarse en los artefactos construidos con Webpack.
Para ello tenemos 2 opciones, construir esos artefactos en otra máquina y enviarlos al servidor de producción o construirlos en el propio servidor de producción. La decisión aquí implica cambios en cómo instalamos nuestras dependencias con Yarn en el servidor de producción, si queremos utilizar Webpack en el servidor de manera que lancemos yarn encore production en producción para generar nuestros artefactos no podremos utilizar el flag –production con valor true, de lo contrario no tendremos instalados los paquetes necesarios
Caché
Por último cuando tenemos una aplicación Symfony configurada para ejecutarse en modo producción tanto el framework como algunos paquetes almacenan información en caché, cuando hacemos cambios es posible que tengamos que purgar la caché de Symfony para que realmente se ejecute nuestro nuevo código.
Desde cambios en las entidades a los cambios en las plantillas que se almacenan en caché precompiladas pasando por las traducciones forman parte de la lista de elementos que hacen uso intensivo de la caché del proyecto. Para esto solo tendremos que ejecutar php bin/console cache:clear en el entorno de producción, la caché quedará purgada y a partir de ese momento empezará a cachearse información en base a nuestro nuevo código.
Conclusión
Como hemos visto el proceso de manera global puede ser todo lo sencillo o todo lo complejo que queramos optando por diferentes técnicas y herramientas. Además cada paso del proceso de manera individual puede a su vez automatizarse en mayor o menor medida dependiendo del tipo de herramientas que usemos.
Con el planteamiento que realizamos debería ser suficiente escribir un script para que todas las partes automatizables se realicen de manera autónoma, a partir de ahí podemos saltar hacia el uso de herramientas especializadas como deployer, a servidores de CI/CD que orquesten el proceso y a flujos de trabajo basados en contenedores que es la dirección que está tomando la industria.
Dependiendo del tamaño de nuestros proyectos y de la cantidad de recursos que tengan asignados tendremos que tomar las decisiones que consideremos, nuestro consejo es que analicéis siempre en qué estado se encuentra vuestro proyecto en cuanto a proceso y defináis cuales son los puntos críticos para automatizarlos e ir avanzando.
En esta segunda entrada que realizo, os voy a escribir sobre algo un poco menos técnico, pero que no deja de ser importante a la hora de plantear y desarrollar un sitio, ya sea tienda online, web, etc.
La tan malograda UX o experiencia de usuario, la fea de la película. Pero me enfocaré en la parte de diseño y el apartado técnico, ya que la experiencia de usuario en sí es un ente bastante complicado de resumir y que engloba muchos otros aspectos a la hora de presentar un proyecto a un cliente.
Vale, no corras ¿podrías explicar un poco que es eso de la UX?
Una de las definiciones globales que más me gusta podría ser que “la experiencia de usuario es lo que siente una persona cuando está interactuando con un producto, ya sea digital o físico y que se ve afectado por elementos y factores ambientales”.
Me he quedado a gusto, ¿eh? Enfocándolo más todavía al aspecto digital, la UX sería el cómo se siente esa persona, pero interactuando con un sistema. Que web más fácil, no sé dónde comprar, esta app es más lenta que «el caballo del malo», esto no funciona (no viene mucho al caso, pero viene implícito en el 90 y pico por ciento de quejas de un sitio cuando no te gusta). Este resumen incluye una página web, una aplicación web, una aplicación móvil o de escritorio…, básicamente cualquier tipo de interacción humano/dispositivo.
Ojo, que no hay que confundir la experiencia de usuario con la usabilidad …
Porque, aunque estén relacionados, no es lo mismo. UX es la experiencia, emoción, intuición y conexión que un usuario siente al usar un sitio o un producto, el feel. Mientras que la usabilidad es más acerca de la efectividad del diseño de un sitio y cómo usarlo de manera amigable. Podemos decir que la usabilidad es un componente clave de la experiencia general del usuario.
¿Existe la fórmula mágica para hacer una fantástica UX?
Pues no. No existe la piedra filosofal de la UX, a cada uno nos satisfacen cosas diferentes y que un producto puede tener a la mayoría contentos es bastante difícil.
Lo más importante que hay que recordar a la hora de diseñar e implementar tu sitio web o app, es que tú no eres tus usuarios. No asumas nunca que conoces lo que quieren o necesitan.
Entonces, ¿cómo se puede definir una gran experiencia? Intenta acércate a ellos, observa, escucha y pregunta.
¿Y por qué crees que es tan importante?
La experiencia de usuario es tan importante porque trata de satisfacer las necesidades del usuario, y un usuario satisfecho es la clave del éxito. Con la UX se intenta proporcionar experiencias positivas que mantengan a los usuarios atentos y que se vuelvan leales al producto o marca. Además, es más propicio para el éxito empresarial … y el tuyo propio.
¿Conoces métodos para dar un poco de caña a esto del proceso de UX?
Digamos que hay unos 8 pasos básicos para lidiar con la experiencia de usuario. Arremangaos que vamos al tajo:
Perfiles de usuario y personas
El primer paso en todo este proceso es conocer a tu audiencia. Esto te permite desarrollar experiencias que se relacionan con la voz y las emociones de tus usuarios. Para comenzar, querrás crear lo que se conoce como “una persona”: una representación semi-ficticia de tu cliente ideal basado en la audiencia que has investigado. No es el Tinder, tranquilo.
Cuando termines de trabajar con tu persona (o personas), tendrás el perfil de la (s) persona (s) con la que está hablando tu aplicación. Crear una persona consiste en sumergirse en el análisis de tu sitio y en otros datos de clientes mientras realizas entrevistas y encuestas tanto internas como externas (o como hacer que te odien tus compañeros de trabajo).
Incluso puedes hablar con audiencias «parecidas» que reflejen los mismos rasgos que tus usuarios actuales. Algunos de los rasgos comunes que deberías considerar al desarrollar tu persona incluyen:
Demografía (edad, ubicación, estado familiar, carrera, etc.)
Y cualquier tipo de información que te ayude a conocer a tus usuarios.
Estas entidades de personas te tomarán (y deberían tomarte) un tiempo para desarrollarse. Hay muchos pasos que se deben seguir para asegurarse de que tienes una mejor comprensión de ese ente. Y ten en cuenta que pueden cambiar a lo largo del tiempo y que las base de clientes evolucionan (hoy tu cliente trabaja para X y mañana le entran Y clientes diferentes, por ejemplo).
Testeo de la interfaz
Cuando creas una interfaz de usuario, cuantos más datos puedas recopilar, mejor. Lleva a cabo un estudio para comparar la efectividad y la calidad de la experiencia entre diferentes interfaces de usuario, incluido tu sitio actual tal y como se ve.
Algo tan pequeño como cambiar una sola palabra, o el color de una fuente, podría afectar a la efectividad de tu página. Una poderosa herramienta para probar la interfaz es la plataforma “Optimize” de Google.
Con Optimize, puede dividir las impresiones de tu sitio web en dos grupos y mostrar a cada uno de estos grupos una versión diferente de las páginas de tu sitio (A/B Testings). Una vez que tengas un tamaño de muestra estadísticamente significativo, puedes ver qué versión está superando a la otra y hacer los ajustes correspondientes.
Encuestas de usuario
Va, que ya va quedando poco …. Ahora, entrevista a los usuarios existentes y potenciales del sistema para obtener una idea de cuál sería el diseño más efectivo. Debido a que la experiencia del usuario es subjetiva, la mejor manera de obtener información directamente es estudiar e interactuar con los usuarios. Un elemento de la página que pensabas que estaba funcionando muy bien, el botón de la app que pensabas que era superefectivo, podría parecerle completamente invisible a tu usuario final, por lo que una vista de primera mano de la forma en que interactúan con el sitio web puede proporcionar información valiosa.
Analiza a las personas de tu público objetivo cuando realices estas encuestas, ya que su propio grupo puede interactuar con el sitio web de manera diferente a las personas a las que deseas llegar. Haz preguntas como: ¿Cómo te hace sentir el sitio web? ¿Dónde te confundiste? ¿Cómo harías una compra? ¿El idioma te dice algo? Es posible que te sorprenda con la cantidad de comentarios constructivos que vas recibir.
Utiliza diagramas de flujo
Haz un diagrama de flujo que muestre cómo deben moverse los usuarios a través del sistema. Comienza por decidir cómo esperas que se muevan a través del sitio, luego compáralo con la forma en que realmente interactúan con él. Las personas de usuario de antes te ayudarán aquí: cuando entienda el perfil del usuario en el sitio web, podrás planificar mejor la experiencia óptima para ellos.
Además, una serie de herramientas analíticas pueden permitirte ver cómo los usuarios se relacionan con tu página en tiempo real. Plataformas como Mouseflow pueden incluso rastrear dónde se encuentra el mouse de un visitante en la página en un momento dado. También puedes ver mapas de calor de las áreas en la página que atraen la mayor atención.
Cuando hayas aprendido cómo las personas usan el sitio, entonces ponte a cambiar las cosas. Las aplicaciones más efectivas son aquellas que hacen que la experiencia del usuario sea una prioridad máxima.
Mapas del sitio o aplicación
Una vez que hayas estudiado el flujo de usuarios que esperas, es esencial realizar una planificación exhaustiva. Comienza por construir un mapa del sitio para las páginas que deseas crear. Un mapa del sitio es una jerarquía claramente organizada de todas las páginas, subpáginas y apartados del sitio o aplicación.
La creación de un mapa hace que sea más fácil imaginar cómo un usuario podrá ir desde el punto A al punto B, y cuántos clics realizará. En lugar de implementar cambios estructurales una vez que se construye el sitio, un mapa ayuda a tu equipo a eliminar las malas ideas rápidamente y, al mismo tiempo, te muestra toda la estructura que eventualmente necesitarás para diseñar y escribir contenido. Es una buena herramienta para agregar eficiencia al proceso de creación de sitios web.
Prototipos y wireframes
Los elementos visuales de cada página son tan importantes como la estructura del sitio, así que invierte tiempo en crear wireframes, que son guías visuales que representan el marco esquelético y brindan una vista previa de la apariencia del proyecto. Con un marco visual, puedes eliminar los problemas de usabilidad antes de que cualquier página llegue a la pantalla. Esto puede ahorrarte tiempo de desarrollo para realizar los ajustes necesarios en el futuro.
Una herramienta que ayuda es Adobe XD (no, no me pagan por anunciarlo, lástima). Seguro que hay muchas otras, pero por experiencia te diré que solo necesitarás un lienzo, un marcador y muchas ideas de diseño y contenido para comenzar. Una vez que el diseño se ve bien en tinta, te montará un enlace con un prototipo interactivo que muestre cómo se verá en vivo. La mayoría de las veces, lo que faltará será que el equipo haga pocos ajustes durante el siguiente paso creativo.
Patrones de diseño
Los patrones brindan consistencia y una forma de encontrar el diseño más efectivo para el trabajo. Con los patrones de diseño de la interfaz de usuario, por ejemplo, seleccionar los elementos correctos de la interfaz de usuario (por ejemplo, pestañas de módulos, rutas de exploración, presentaciones de diapositivas) para ciertas tareas basadas en su efectividad conduce a experiencias mejores y más familiares.
Una herramienta que te brindará una valiosa ayuda para mantener la consistencia de la interfaz de usuario, son los mosaicos de estilo. Los mosaicos de estilo son entregables que muestran el diseño de todos los módulos en un sitio, hasta los tamaños y colores de fuente. Este documento incluye cosas como botones, diseño de tipos e incluso interactividad. Los mosaicos de estilo aseguran que el usuario tendrá una experiencia fluida en todo el sitio para poder reconocer mejor cómo interactuar con los elementos del sitio.
Seguir unas guias de estilo
La consistencia es fundamental para diseñar una experiencia de usuario buenísima a través de una marca. Las guías de estilo brindan a los escritores y diseñadores un marco en el cual trabajar al crear contenido y desarrollar un diseño, y también aseguran que la marca y los elementos de diseño se alineen con los objetivos del propietario.
Haz que esa guía de estilo sea fácilmente accesible para cualquier persona que trabaje en un nuevo sitio web. Un elemento en una página que no coincide con la imagen o la voz de tu marca puede ser una espina clavada en todo el trabajo realizado. Si no tienes una guía de estilo, considera en crear una, en serio. ¡Te sorprenderás de lo útil que será, incluso más allá del diseño de UX de la aplicación!
Zzz… Vale, y después de este rollo, ¿cómo me va a ayudar a cumplir mis objetivos?
Te ayuda a averiguar cómo es tu audiencia
Una vez que descubras tus metas, puedes enfocarte en tu audiencia. La mejor manera de hacer esto es investigar tu base de clientes y crear personas.
Un sitio web puede tener múltiples personas y cada persona puede tener diferentes antecedentes, personalidades, necesidades y objetivos finales.
Éstos son el público objetivo, y hay que descubrir lo que necesita para lograr la mejor experiencia posible que les permita cumplir sus objetivos, comprometerse con el sitio y, finalmente, convertirse en un cliente potencial. El verdadero éxito de tu aplicación se produce cuando descubres cómo hacer felices a los usuarios y a las partes interesadas.
Te ayuda con la organización y la creación de contenido
Conocer tus objetivos y tu público objetivo te ayudará a imaginarte qué será exactamente lo que las personas están buscando cuando te visitan. Esta información influirá tanto en el mapa del sitio como en la estructura de la página.
Debes de saber lo que la gente está buscando, no puedes simplemente dejar un diseño curioso y bonito y ya está, sitio hecho. La verdadera razón por la que las personas van a visitar tu página web es porqué están buscando cierto tipo de información que les puedes dar, y tiene que ser de interés para ellos.
Por eso el contenido es tan importante. Si tu audiencia no obtiene algo útil de tu sitio, lo encontrarán en otra parte. Que crudo, pero que simple. Que esta afirmación se te quede.
El contenido de tu sitio web implica esencialmente dos cosas: primero está la voz y segundo el tono. Esto es esencialmente cómo vas a hablar con la gente. ¿Eres divertido y juguetón, inteligente e informativo, charlatán o directo al grano? Se trata de la marca de tu cliente y cómo la gente ve la empresa. El contenido también implica lo que dices. Esto puede parecer fácil, pero es arte en estado puro. Las personas tienen períodos de atención cada vez más cortos, y más y más opciones. Tienes que ser único y hacerte oír.
Con esto en mente, debes involucrar a las personas rápidamente y darles la información que necesitan sin dudarlo. Esto es más que solo el texto del párrafo. Se trata de titulares, botones, iconos e incluso metadatos intuitivos (las cosas ocultas en el código que ponemos los frikis de esto de la informática).
Te ayuda a ahorrar dinero
Toda esta planificación que estás realizando te aseguro que no quedará en saco roto. Si se hace bien, tu sitio puede tener un impacto duradero. Tomando decisiones inteligentes basadas en la investigación realizada en la aplicación que estás realizando, harás que esta tenga una “vida” más larga: más que si dejaras caer algo y lo presentaras.
Si deseas realizar un diseño iterativo (repetitivo), puedes aprender de tus decisiones anteriores y del rendimiento del sitio, realizar mejoras continuas, en lugar de centrarte en un rediseño tras otro que solo te hará gastar más dinero.
Y cómo no … ayuda a ganar dinero
No dejemos de lado lo obvio, queremos que se gane dinero con el producto del cliente y que esté contento, si no nos esforzamos tanto. Al realizar una investigación y planificación, puedes crear un sitio web que funcione tanto para sus potenciales clientes como para la organización.
Si conoces a tu cliente, necesitas llegar al lugar correcto. Cuando esto suceda, obtendrás un gran retorno de todo el tiempo y el esfuerzo invertidos en la construcción de la aplicación.
Y para despedirme de vosotros, una pequeña conclusión
Como ya he dicho antes de tanto parrafazo, UX es un arte en sí mismo. Inicialmente no podrás predecir a ciencia cierta cómo será percibida la aplicación o página web que desarrolles. Lo que si puedes hacer es utilizar herramientas para tomar las buenas decisiones durante el proceso de diseño. No pares de hacer / rehacer / deshacer / destruir / maldecir… wireframes, mock ups, prototipos y testearlos.
No hay nada más importante que dar con la tecla que haga que el usuario encuentre ideal el hecho de utilizar la aplicación, y que la encuentre cómoda, fácil y amigable.
Si deseas garantizar una gran UX, debes de aprender a cumplir los deseos de tus usuarios, con el mínimo esfuerzo.
Sin importar el tamaño de la empresa, los recursos disponibles y el tamaño de cartera de clientes disponible; todas las empresas que trabajan realizando proyectos a multi-cliente tienen una misma necesidad básica: una buena organización.
El poder organizar todos los recursos de la empresa (refiriéndonos a recursos como todo lo que puede usarse y gastarse para la ejecución de un trabajo como ordenadores, licencias, energía y tiempo) de la forma más óptima posible es lo que diferencia la competitividad de una entidad en el mercado.
La base lógica de la investigación operativa es poder sacar el máximo rendimiento con los mínimos recursos sin llegar a afectar a la calidad del servicio. Y es por ello que este artículo está enfocado a la figura de Project Manager (COO) de medianas y grandes empresas, en el que analizamos 7 errores comunes que pueden darse a la hora de organizar el trabajo.
1. No involucrar a todos los miembros del proyecto en la planificación
Aunque parezca una obviedad, en muchas ocasiones (puede que debido a saturación de trabajo o por intentar agilizar los procesos previos) se planifica un proyecto sin tener en cuenta la opinión de los ejecutores del proyecto, y por lo tanto pueden llegar marcarse tiempos erróneos o prometer servicios imposibles.
Hay que aprovecharse de la especialización de nuestros compañeros en sus campos para diseñar la mejor planificación. Todo influye, desde su experiencia previa hasta sus problemas personales.
2. Realizar una comunicación poco eficiente entre todas las partes
El trabajo de un gestor de proyectos no termina cuando el proyecto está planificado y los especialistas informados. Una de las tareas más importantes es trabajar como motor de comunicación entre el cliente y el técnico, permitiendo así una comunicación fluida y un entendimiento entre todos los participantes del proyecto.
Si esta parte falla, puede que el proyecto esté muy avanzado y el cliente no sea consciente de ello; o puede que el proyecto tenga más prioridad e importancia de la que el técnico le da debido a la desinformación.
3. Realizar una gestión de cambios poco o demasiado flexible
No es sorpresa que un proyecto (en nuestro caso de diseño o desarrollo web) sufra cambios en mitad del proceso; bien sea por necesidades técnicas generadas desde la empresa o bien por cambios de idea comentadas por el cliente final.
Es ahí cuando el designado como Project Manager debe realizar diferentes tomas de decisiones en base a su criterio: ¿Es viable el cambio? ¿Afecta a los tiempos de plazo o al presupuesto base? ¿Lo puede generar el especialista actual?
Si la sensibilidad al cambio es poco flexible, se corre el riesgo de ofrecer un servicio por debajo de la calidad deseada y las necesidades del cliente; pero al mismo tiempo, demasiada flexibilidad al cambio puede rebotar en mayores dificultades para el equipo de trabajo.
4. No realizar un seguimiento periódico de los proyectos
En este caso no hay mucho que profundizar. Cuanto antes se pueda detectar un error, menos podrá escalar y más fácil será subsanarlo y redirigir el proyecto por el camino correcto, habiendo malgastado la menor cantidad de recursos.
Ya pueda ser porque se estaba realizando un trabajo alejado de lo que pedía el cliente, o bien sea un problema que afecte únicamente a los “deadlines” marcados; es vital averiguarlo lo antes posible. Y ésto es imposible si no se mantiene un continuo estado de revisión de los proyectos y su cronología.
5. No se está utilizando la tecnología apropiada
En este caso, podemos dividir este error en dos secciones:
Por un lado, el no utilizar la tecnología apropiada para crear el proyecto. Es importante trabajar con las herramientas más actualizadas posibles para que el trabajo pedido por el cliente tarde en quedar desfasado. O por ejemplo, en el caso del desarrollo web; si el cliente necesita gestionar cambios internos por él mismo, habrá que utilizar un tipo de plataforma u otra en torno a las necesidades.
Por otro lado, el no utilizar la tecnología apropiada para gestionar el proyecto. Ninguna persona por si sola puede retener en su mente todos los estados, anomalías, trazabilidades, agentes asignados y plazos de múltiples proyectos, por eso es vitar escoger una plataforma que facilite la gestión diaria y agilice el recopilar información.
No es lo mismo trabajar apuntando datos en una libreta que utilizando una plataforma online que te genere datos visuales con un solo botón.
6. Entregar el proyecto sin una revisión total
Puede que sea uno de los errores más comunes que hay en empresas de servicios. Aunque haya habido una gestión periódica y constante del proyecto siempre existen flecos que no han podido pulirse en su momento (ya sea culpa de la empresa o culpa del cliente).
Es importante que el COO tenga en mente todos esos vacíos a completar antes de dar por terminado un trabajo, ya que eso puede marcar una gran diferencia entre un cliente más o menos contento y un cliente realmente satisfecho.
Para ello existen los programas que comentábamos al final del punto anterior.
7. Haberse alejado de la valoración inicial del proyecto
Sin dudarlo, este es el error más complicado de gestionar. Una vez tenemos el proyecto terminado, con todas las necesidades del cliente cubiertas, podemos plantearnos: ¿Se ha hecho un buen trabajo?
Una buena gestión implica mucho más que satisfacer al cliente (lo cual sigue siendo lo primario), también tiene que generar unos beneficios internos a la empresa.
¿Se quedó corta la valoración inicial? ¿Se han realizado más horas de las que se contempló? ¿Se ha tenido que retrasar algún plazo debido a problemas internos? Si algunas de las respuestas es sí, quiere decir que hay algún punto que analizar y mejorar para seguir mejorando, creciendo como empresa y resultar más atractivos a futuros clientes potenciales.
Hola a tod@s. Como mi primera entrada en este blog de acceseo, me gustaría empezar escribiendo sobre un tema que es muy sencillo de implementar y que fue una de las novedades más solicitada por toda la comunidad de Prestashop para su última versión: cómo instalar un child theme en Prestashop 1.7.
Hasta la versión 1.6 la configuración de la plantilla era algo tediosa: se podía crear un clon, pero aún así el tener que realizar modificaciones sobre el tema se antojaba un poco pesado. Con la última gran actualización de Prestashop, con este tipo de temas heredados, se nos permite realizar modificaciones sobre el mismo, sin afectar a la estructura del tema principal.
Los child themes no son ni mucho menos una novedad en el panorama de diseño web: desde hace bastante tiempo ha estado implementada en WordPress y, a finales del año, pasado llegó a Prestashop.
Ventajas de utilizar temas hijos
Entre las más significativas encontramos:
Todas las modificaciones que realicemos sobre el hijo no afectarán al padre, de este modo no modificaremos la estructura principal.
Luego está el caso contrario: cualquier actualización del tema padre no afectará a las modificaciones realizadas sobre el child theme. Se realizarán las mejoras pertinentes al core sin reducir un ápice de los cambios realizados al hijo. Así no se verá afectada nuestra personalización.
Cómo implementar el child theme en Prestashop 1.7
Es una tarea muy sencilla y veréis como en unos pocos pasos tendréis listo y configurado vuestro tema hijo. Como Prestashop viene con un tema por defecto denominado classic, utilizaremos ese para nuestras pruebas.
Pasos para crear un tema hijo:
Crea un directorio nuevo dentro del directorio de themes de tu tienda online, llámale como quieras, yo recomendo que tenga la palabra child por algún lado. De esta manera lo podremos localizar fácilmente.
El primer archivo mínimo necesario para que corra el nuevo tema hijo es: el archivo de imagen preview.png. Lo ideal es que hagáis una captura de pantalla cuando se cambie el aspecto del mismo así tendréis una imagen previa del tema hijo similar a lo que ves en pantalla. No es lógico copiar y pegar el preview del padre y que se quede el diseño del mismo.
Necesitaréis de una carpeta config, porque dentro de este es necesario que tengamos el archivo theme.yml. Así que vais al theme del padre, copiáis el directorio config y lo pegáis en vuestro child theme. La gracia de todo esto es saber cómo adaptar ese fichero.
Este archivo (voy a mostraros una imagen del archivo que hemos copiado del padre) veréis que tiene una serie de campos
Sólo os voy a enseñar parte de su estructura, la básica, que es la suficiente para poder empezar a trabajar con tu child theme.
-El nombre que tendrá tu tema, así como el nombre que aparecerá en el back. Su gestión de versiones, así como los datos del autor.
-La meta compatibilidad: la compatibilidad entre temas. Ya sabéis que los del 1.6 no son compatibles con el 1.7 y viceversa.
-Luego tenemos los layouts disponibles para este tema que vienen heredados del padre.
-Seguimos con un apartado de assets, y el que más nos interesa de este archivo, el use_parent_assets. Este nos indica si queremos utilizar los assets originales que provienen del padre. Muy recomendable porqué seguro que trae estilos personalizados, javascripts propios, etc… Otra cosa, si le llamas igual que el archivo del padre (es decir, classic theme tiene custom.css y creas un archivo igual en el child theme, respetando la misma estructura de directorios del mismo) Prestashop interpretará que tiene que utilizar el del hijo. Él interpretará de que estamos intentando sobreescribir el comportamiento de ese fichero.
Una vez tenemos clara la estructura de este archivo, lo primero que haremos es ir a assets y descomentar la línea de use_parent_assets.
Luego, incluiremos una línea (la primera normalmente) que sea parent: nombre_del_tema_padre (nombre del directorio que vayas a utilizar como padre). Si queréis podéis modificar el autor, y el display_name que es lo que aparecerá en el backoffice.
Y aquí, os dejo una captura del theme.yml modificado en un tema hijo de ejemplo para que veáis como queda.
Daros cuenta que hay un archivo .htaccess en el directorio donde está el theme.yml, coged el del tema padre. Se utiliza para proteger el directorio mediante una serie de directivas de Apache (2.2 y 2.4).
Una vez lo tengáis todo preparado, podréis ir al backoffice de nuevo de Prestashop y pasaros por el apartado de los temas. Os daréis cuenta que debajo del tema classic que es el por defecto seleccionado en Prestashop, os aparecerá un nuevo elemento en la parte inferior que es el Child Theme que acabáis de crear.
Pulsad en la opción que os dice que vais a utilizar ese tema. A partir de ese momento estaréis utilizando los recursos que vayáis insertando y configuréis en el child theme.
>> Os recomendaría primero un vaciado de la caché de Prestashop, luego crearos un par de directorios y subdirectorios para probar que todo funciona correctamente.
Dentro del child theme cread un directorio llamado assets, y dentro de este otro que se llame css. Entrad a este de css y cread el fichero custom.css, o copiad y pegad el que hay en el directorio padre. Si no se os crea automáticamente dentro del directorio assets que habéis creado la carpeta “cache”, creadla también.
>> Poned dentro lo que queráis, por ejemplo, añadidle al body un color de background.
Refrescad vuestra página (o volved a vaciar caché si no ocurre nada) y veréis que ahora, inspeccionando el código fuente, aparte de coger los archivos que necesita del tema padre, ha recogido un archivo de vuestro tema hijo: /themes/childtheme/assets/css/custom.css
De esta forma tenemos el principio de un tema hijo, y ya podremos implementar modificaciones dentro del child de archivos tpl, css, javascript… lo que sea necesario.
Espero que este mini tutorial haya sido de vuestro agrado y hayáis conseguido implementar el child theme en vuestra web. ¡Hasta la próxima!
[et_pb_section admin_label=»section»]
[et_pb_row admin_label=»row»]
[et_pb_column type=»4_4″]
[et_pb_text admin_label=»Text»] WordPress es una herramienta muy versátil gracias a su ecosistema, utilizando este CMS podemos crear todo tipo de páginas web, blogs, tiendas y casi cualquier cosa que se nos ocurra. ¿Pero qué sucede si quieremos integrar el CMS con otro proyecto y no nos basta con los plugins existentes? ¿Y si lo que queremos es extender las funcionalidades que nos brinda? Históricamente se han desarrollado plugins o integrado aplicaciones accediendo a la base de datos de WordPress pero actualmente gozamos de una alternativa mucho mejor, más desacoplada y sencilla de utilizar que sin duda es una de las grandes mejoras en los últimos tiempos en el mundo WordPress, la inclusión de una API REST que nos ofrece endpoints para tratar con la información que alberga el sistema.
¿Qué es una API REST?
REST es el acrónimo de Representational State Transfer, se trata de un conjunto de principios de arquitectura para la comunicación de información. Por tanto una API REST (o RESTful) es cualquiera que cumpla los principios que se definen. Normalmente el término se suele utilizar de manera amplia para definir cualquier webservice que no mantenga estado (stateless), que utilice HTTP y sus verbos para la comunicación y que disponga de cierta estructura para las URIs que referencian de manera única a cada entidad.
Los principios que se deben cumplir para que una API sea considerada RESTful van todos enfocados a mejorar el rendimiento, escalabilidad, simplicidad y en general el sistema. A continuación los resumimos brevemente:
Arquitectura Cliente-Servidor: Este punto está enfocado a optimizar los recursos separando claramente las responsabilidades y optimizando cada parte para su finalidad.
Carencia de estado: La API debe ser stateless, para ello no debe existir ninguna información que se comparta entre peticiones a modo de contexto. No se establecerá un contexto en el servidor que perdure la primera vez que cliente y servidor se comuniquen sino que cada petición será independiente del resto que se realicen.
Posibilidad de uso de caché: Se debe tener en cuenta el uso de caché y definir las respuestas como cacheables o no de manera que el cliente no tengan información errónea y a la vez se pueda minimizar el número de peticiones a realizar.
Arquitectura por capas: El cliente no debe ser capaz de diferenciar una respuesta servida directamente por el servidor o por un intermediario de modo que por ejemplo se podrán utilizar balanceadores de carga para permitir al servicio escalar.
Scripting en el cliente: Se menciona como punto opcional el hecho de que el servidor tenga la capacidad de enviar scripts al cliente para poder extender su funcionalidad.
Interfaz uniforme: Es una parte fundamental de REST y define varios puntos.
Un recurso debe ser identificable por una petición, es decir la URI del recurso lo identifica y es independiente de la representación del mismo que el servidor nos entregue en la respuesta (que podría ser xml o json como el caso de la API de WordPress).
Cuando el cliente obtiene la representación del recurso ésta contiene suficiente información como para poder modificarlo o borrarlo.
Cada mensaje tiene suficiente información para describir cómo debe ser manipulado.
HATEOAS (Hypermedia as the engine of application state): Tras recibir la representación de un elemento el cliente debe poder descubrir las acciones disponibles y los recursos necesarios a partir de enlaces que el propio servidor proveerá.
Una vez claros los fundamentos vamos a ver de manera muy sencilla cómo podemos utilizar la API que nos ofrece WordPress. Para los ejemplos de este artículo vamos a crear pequeñas aplicaciones en PHP o lanzar peticiones con la herramienta HTTPie por lo que es recomendable tener al menos uno instalado aunque las peticiones se pueden lanzar desde cualquier aplicación que nos lo permita, como curl, Postman, cualquier lenguaje de programación que nos permita hacer peticiones HTTP o nuestro navegador web.
Primeros pasos con la API
Podemos empezar a utilizar la API REST de WordPress simplemente lanzando peticiones HTTP a los endpoints disponibles en /wp-json/wp/v2/ que nos responderán con un objeto JSON. Para algunas opciones eso será suficiente pero en otras necesitaremos autenticarnos. Para empezar podemos lanzar en nuestro terminal el comando http http://localhost/wp-json/wp/v2/posts y veremos como la respuesta contiene el listado de posts de nuestro WordPress.
Empezar a hacer algo útil con la API es tan sencillo como utilizar la respuesta que nos da el servidor, podríamos por ejemplo parsear y listar todos los posts con el título, la fecha y el enlace a la web.
Como hemos mencionado anteriormente para utilizar según qué endpoints es necesario autenticarse. Por defecto se incluye la autenticación con cookies, con este tipo de autenticación una vez hagamos login podremos utilizar la APIdesde la propia página. Este tipo de autenticación es muy útil para desarrollar plugins y temas que desean trabajar con la API.
En nuestras pruebas vamos a simular un sistema algo más complejo, imaginemos que tenemos una aplicación completamente independiente desde la que queremos gestionar nuestra instancia de WordPress, existe un plugin enfocado al desarrollo con la API que nos permite utiliza basic auth, únicamente tendremos que enviar en las peticiones nuestro usuario y contraseña. Es por eso que está enfocado al desarrollo ya que es inseguro, pero existen alternativas como plugins para autenticar con Oauth o JWT que son sistemas listos para producción.
Con el plugin instalado vamos a crear nuestra primera aplicación usando php para comunicarnos con la API usando la autenticación y comprobar que todo funciona correctamente. Para ello vamos a utilizar composer y requeriremos los paquetes guzzlehttp/guzzle y symfony/console. Existe una manera muy sencilla de crear comandos en un único fichero utilizando el componente symfony/console de manera que tendremos todas las ventajas que nos ofrece el paquete sin tener que crear todo un proyecto o utilizar el framework completo. Para la comunicación con la API utilizaremos guzzle que nos simplifica el uso de HTTP.
Así pues utilizando el endpoint /wp-json/wp/v2/users/me podemos crear una pequeña aplicación que nos confirme nuestra identidad de manera que sabremos que la comunicación con la API está siendo exitosa. El siguiente código ilustra cómo realizar la petición GET HTTP al endpoint para leer los datos de la respuesta.
Al ejecutar el comando desde nuestro terminal con php whoami.php obtendremos una salida similar a la siguiente:
Una vez hemos comprobado que todo funciona bien podríamos extraer una lista con los posts más recientes, para ello podemos sacar partido de los parámetros que nos permite enviar la API para modificar la respuesta. Haremos una petición GET a /wp-json/wp/v2/posts filtrando los post ya publicados, con 2 resultados por página y la primera página de resultados. Esto sería equivalente a la petición incluyendo el siguiente querystring: /wp-json/wp/v2/posts?status=publish&per_page=2&page=1, a continuación podemos ver el código resultante al enviar la petición con guzzle.
En este caso hemos utilizado el helper table de symfony/console para mostrar los resultados en una tabla de modo que el resultado de ejecutar nuestro comando será algo parecido a lo siguiente:
Hasta ahora hemos visto de qué manera podemos obtener información desde la API sea necesaria o no la autenticación, en el siguiente ejemplo vamos a crear un post enviando una petición POST con el título y el cuerpo de la publicación, si no incluimos estado WordPress por defecto lo dejará como borrador. Como podemos ver a continuación el código para automatizar la creación de artículos es muy sencillo y una vez creado nos notifica del id del post y su título.
Por último vamos a publicar esos post que hemos ido dejando como borradores. Para ello debemos combinar los comandos que hemos creado anteriormente como indica el código que sigue al párrafo. Primero obtendremos los post que estén como borradores utilizando status=draft y posteriormente uno a uno realizaremos peticiones POST a /wp-json/wp/v2/posts/POSTID cambiando el valor de status a publish.
Conclusión
Una de las grandes características de las API REST es su facilidad de uso, como hemos podido ver podemos ejecutar todas las operaciones básicas (incluyendo el borrado pese a no estar ejemplificado podemos consultarlo en la documentación y ver que no alberga ninguna complejidad extra) sobre los recursos de nuestro WordPress con código muy sencillo. Esto nos puede servir tanto para crear herramientas para migraciones como para integraciones en otros sistemas o la creación de herramientas propias que nos ayuden a automatizar nuestras tareas del día a día en la gestión de nuestro WordPress.
Podéis consultar el código completo del proyecto en el gist.
[/et_pb_text]
[/et_pb_column]
[/et_pb_row]
[/et_pb_section]
¿Alguna incidencia?
Cuéntanos qué ocurre y nos pondremos con ello lo antes posible.
