Aquí estoy de nuevo con otro code-kata sobre Symfony. Este post es un repaso en Symfony Flex con respecto a la traducción de una web hecha en Symfony a varios idiomas. Es decir, en este post voy a tratar de ser conciso, sin demasiados detalles aunque es un tema muy extenso, para tratar el tema de tener una página traducida en varios idiomas. Es decir, una vez más, siguiendo la planificación sobre el repaso a Symfony, que llegamos a este tema un poco complicado, la internacionalización, que abreviado es I18N.
Con este post, si lo sigues mientras construyes tu proyecto, en cuestión de minutos podrás tener el esqueleto de una web multidioma totalmente funcional. Doy por sentado que llevamos bien el resto de temas como Doctrine, los controladores, el maker, diseño y gestión de bases de datos, etc.. Abordar la internacionalización de una página no es trivial.
Una de las bondades que tienen Magento es su flexibilidad. En este post vamos a ver el tema de los atributos de producto, cual es su scope o alcance. En general, esto se facilita mucho con su uso interno del modelo de datos EAV. Gracias a EAV que podemos gestionar muchos valores de atributos de cada elemento sin tener que modificar la base de datos. Es decir, no tenemos que hacer una columna nueva para cada atributo nuevo. Sino que se da de alta el atributo en una tabla, y en otra se guardan los valores de los atributos sin haber hecho absolutamente ninguna modificación en la estructura de la base de datos.
Disponemos de tres niveles de configuración normalmente, aunque realmente hay cuatro, para configurar muchas de las cosas que hay dentro de un Magento. Tenemos el nivel de website, de store y de store view. Traducidos son sitio web, tienda, y vista de tienda; y además tenemos el nivel global. Por ejemplo, si vamos a las configuraciones de tiendas podemos tener varios nombres de dominio (uno por website), cada uno con sus configuraciones, plantillas distintas, productos distintos, incluso clientes distintos asignados a cada website o compartidos entre todos los websites. Dentro de un website podemos tener varias tiendas o stores. Y de cada tienda podemos tener varias vistas de tienda, incluso pudiendo cambiar las plantillas o muchas de sus configuraciones de productos, categorías, etc..
El caso de los productos
Volviendo a los productos, primero tenemos que los podemos asignar a cada website. Es decir, un producto puede publicarse en uno de los websites mientras que en otro no. Si vamos al listado de productos nos encontramos en un Magento 1.9 arriba con un desplegable como el de la imagen de al lado, donde podemos configurar los productos a nivel de store view.
Los productos se trabajan al más bajo nivel, al de store view. Esto es así porque el nivel de store view se suele usar para traducir la web. Es decir, publicamos un producto en un website, y configuramos a nivel de vista de tienda cómo lo va a ver el usuario. Si tenemos una vista de tienda por cada idioma, podremos configurar su nombre, descripción, características, etc.. traduciéndolas para cada idioma.
El nivel de los atributos de producto
Podemos dar de alta y configurar nuevos atributos, en la zona de gestión de atributos. Un listado de atributos de ejemplo podría ser tal que así:
Si el valor del atributo es el mismo en todas las tiendas o vistas de tienda, entonces debería de ser global. Si el valor es distinto, traducible para cada store view, debe de tener el nivel de store view. Es importante saber que todas las etiquetas que se muestran siempre se pueden traducir para cada store view, independientemente de los valores que tome dichos atributos. Es decir, no confundamos las etiquetas que podemos traducirlas con los valores que también podemos traducirlos, no te lleve a confusión.
El atributo de producto ‘status’ es de sistema
Todos los atributos del listado anterior no son de sistema, con lo que no tienen limitación para configurarlos como queramos. Pero los de sistema sí que están limitados. Para este post vamos a trabajar con un atributo que ya viene configurado en Magento que es el estado (status). El estado puede estar habilitado o deshabilitado, y viene configurado a nivel de sitio web. Este atributo puede configurarse para que esté a nivel de website o nivel global. Si lo tenemos a nivel de website entonces podremos habilitar o deshabilitar un producto independientemente en cada website de nuestro Magento.
Esta flexibilidad está bien, pero sólo en ciertos casos. Si tenemos varios websites, de cada uno por lo menos una store, y dentro de cada store podemos tener varias store views para traducir las tiendas.. se puede reducir la cantidad de configuraciones si ponemos el nivel adecuado para cada atributo. Volviendo al caso del atributo status, si me interesa que cuando deshabilite un producto lo haga para todos los websites, entonces debemos de tenerlo a nivel global. De lo contrario, si tenemos 3 sitios web, para estar seguros de que deshabilitamos o habilitamos correctamente el productos en todos los websites deberemos de entrar en la configuración de producto varias veces y comprobarlo.
Así que vamos a ponerlo a nivel global y asegurarnos de que no quedan valores personalizados a nivel de website. Y en tal caso los borramos. Así evitaremos esta excesiva navegación por las fichas de producto. Y así nos aseguramos de que un producto deshabilitado, lo está realmente en todos los websites.
Finalmente, pasando a global el atributo status
Entramos en la configuración del atributo y lo modificamos para que sea global:
Sólo nos falta entrar a la base de datos y, en este caso, borrar todas las configuraciones del atributo a nivel de website que se hayan hecho para que sólo se aplique la configuración global en cada producto. Si se nos quedara en la base de datos algún valor personalizado sin borrar, Magento cogería dicho valor personalizado, en caso de no encontrar valores personalizados de nivel más bajo entonces cogería el valor global.
Encontrando el identificador del atributo
Para esto no tenemos más que entrar a la base de datos e ir a la tabla eav_attribute. Aquí tenemos definidos los atributos que gestionamos en el panel de control. De forma que, tenemos dos columnas con las que identificamos el atributo status: la columna attribute_code, y la columna attribute_id. Aquí buscamos el código que le hemos puesto al atributo, en este caso ‘status’, que no lo hemos creado nosotros porque es de sistema y ya viene configurado.
Ya hemos encontrado el identificador del atributo, que es el 96. Ahora ya podemos ir a revisar los valores que ha ido tomando el atributo para las distintas vistas de tienda. Para esto vamos a la tabla catalog_product_entity_int que es donde se guardan los ‘valores enteros de los atributos de entidades de productos’ como su nombre indica en inglés.
Como podemos ver en la imagen, el atributo 96 está cogiendo los valores 1, 2.. para el status el valor 1 es de producto habilitado, el 2 es deshabilitado. Según vemos en la imagen y haciendo un par de consultas podemos ver que la store_id es cero siempre en mi caso. A saber, la store_id cero es el valor del atributo global, es el que coge Magento en caso de encontrar ninguno personalizado. Si tenemos guardados valores distintos para las vistas de tienda, entonces habrían valores con store_id distintos, donde cada store_id corresponde con el identificador de la store.
Cómo listar los stores de una tienda lo cité en el post este, en donde se listan primero los store_id para luego ir recorriendo los productos y asignándolos a todas las stores. Podemos coger aquel script y listar los store_id y así poder editar o simplemente borrar las configuraciones de algunas de las stores.
Borrando valores de atributo personalizados
En este caso, si quisiéramos borrar todas los valores de status personalizados en cada store view bastaría con ejecutar la consulta siguiente y vemos si hay dichos valores personalizados:
SELECT * FROM magento_maxmovil.catalog_product_entity_int
WHERE attribute_id = 96 AND store_id != 0;
Si los hay simplemente modificamos la anterior consulta para borrarlos:
DELETE FROM magento_maxmovil.catalog_product_entity_int
WHERE attribute_id = 96 AND store_id != 0;
Con esto ya nos aseguramos que no vaya a haber problema y hemos pasado el atributo status a scope global. Esto mismo se puede hacer para cualquier otro atributo.
Con esto queda terminado 🙂 otro día más 😉 Un saludo!
De todos las soluciones de tienda online que he conocido hasta la fecha, Magento es de lo más robusto y potente que he visto de código abierto. Estoy conociendo poco a poco los entresijos de Magento 1 en el trabajo, y es buen momento de ver las mejoras que trae Magento 2 y así cotejar.
Es un sistema de información dedicado a la venta robusto, flexible y muy personalizable. Alrededor de Magento se mueve todo un ecosistema de soluciones empresariales de la más alta gama. Todo esto es posible gracias a las características de Magento.
Para explicar todo lo que tiene Magento necesitamos mucho tiempo, terminaríamos antes buscando qué no tiene. Pero también encontrar qué no tiene va a ser difícil porque Magento es todo un referente mundial de las soluciones eCommerce existentes.
Un poco de historia
Nació como proyecto de código abierto en el 2007. Ya en el 2008 fue premiado como mejor nuevo proyecto de código abierto del año. En el año 2009 la empresa Varien lanzó la versión Enterprise con el modelo de negocio de suscripción anual. Ahora mismo es propiedad de Ebay, la cual es propietaria del 100% de la empresa.
Lanzaron también una versión Profesional, pero no debe de haber tenido mucho éxito esta segmentación porque ahora mismo sólo disponemos de la Community Edition y la Enterprise Edition.
Requisitos para la instalación
Se necesita de una buena máquina para correr Magento, por lo menos se recomiendan 2 Gigas de RAM y échale CPUs que cuantos
más mejor. Yo le he puesto una máquina virtual con Vagrant de 4 Gigas de RAM y 2 CPUs. Se ha dejado instalar después de preparar un poco el servidor sin demasiadas configuraciones.
Instalando
Haciendo unas pruebas jugueteando con Vagrant, me ha quedado un script bien sencillo. Ejecutando lo siguiente tenemos automatizada la instalación de todo lo necesario en un servidor Linux para poder instalar Magento 2. Dejo aquí el script para Ubuntu Server con todo en el mismo servidor, Apache y MySQL:
sudo sed -i «s/bind-address\s*=\s*127.0.0.1/bind-address = 0.0.0.0/» ${mysql_config_file}
# Permitir acceso como root desde cualquier host echo «GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘root’ WITH GRANT OPTION» | mysql -u root –password=root echo «GRANT PROXY ON »@» TO ‘root’@’%’ WITH GRANT OPTION» | mysql -u root –password=root
sudo service mysql restart
echo «CREATE DATABASE magento2» | mysql -u root –password=root
Hay quien preferiría Nginx porque en sus inicios ejecutaba en multiples hilos de ejecución las peticiones HTTP, es ligero y sencillo. Ha llovido mucho desde que Nginx era el servidor más rápido del mercado con creces, viendo las últimas estadísticas comparativas entre Apache2 y Nginx más o menos van a la par en la fecha en que les escribo. No es objetivo hacer una comparativa Nginx-Apache en esta entrada así que lo dejaremos para otro momento si cabe.
A partir de aquí ya tenemos el servidor web Apache configurado con PHP, y una base de datos MySQL con la base de datos magento2 ya creada que usaremos para instalar nuestro nuevo Magento. También tenemos instalado globalmente en el sistema Composer, que cuando recién descomprimamos el nuevo magento y vayamos a instalar nos va a pedir que instalemos todas las librerías de PHP.
Tras esto podemos ver conectándonos a la base de datos que partimos de las no pocas 308 tablas, para empezar. Esto nos da una idea de la magnitud del programa que tenemos entre manos ¿cierto?
Las tareas cron, cachés..
El cron del sistema es el programador de tareas. Cuando recién hemos hecho la instalación, el panel de control nos notificará que instalemos las tareas automáticas para que funcione Magento o que las lancemos manualmente.
Esto hace necesario que tengamos acceso como root, como administradores del sistema, para que podamos configurar estas tareas en el servidor. No podemos instalar Magento en cualquier alojamiento web. O mejor dicho, sí que podemos, pero el funcionamiento va a ser una castaña si no hacemos los ajustes necesarios.
Otro tema que hace necesario un host con acceso como root son las cachés. En un sistema web tenemos caché de base de datos, compilación a bytecodes de PHP, generación de páginas HTML a partir de vistas. Y el gran Varnish, otro elemento a instalar y configurar para sacar el máximo partido a las prestaciones de nuestro servidor, aunque no es imprescindible tenerlo (al contrario de lo que dicen muchos administradores de sistemas). Evitar Varnish si no es necesario, como escuché a un experto en Magento en el último Meet Magento en España, nos puede aliviar las configuraciones ya que a veces este proxy inverso se mete en medio necesitando de más y más configuraciones a medida que instalamos extensiones o personalizamos nuestro Magento.
El sistema de cifrado SSL
En el script de instalación se crea un certificado autofirmado y se guarda en /etc/ssl/. A fecha de hoy ya queda poco para poder crear nuestros propios certificados 100% funcionales, para el entorno de producción o desarrollo, tantos como queramos, con Letsencrypt, pero mientras este sistema nos servirá.
Es de buena costumbre poner el cifrado en la zona de administración (back-end) y en el front-end. Para ello tenemos que configurar las URL base seguras y no seguras poniéndole el https delante. Por defecto se cifrará toda la navegación desde el momento en que haya datos personales de los usuarios. En el back-end se cifrará en todo momento.
Si vas a instalarlo en producción asegúrate de que esté todo funcionando antes de activar SSL en todo el sitio. Tener SSL mejorará el posicionamiento del sitio en los buscadores, pero me ha pasado que una extensión te fastidie todo porque no funcione correctamente, así que más vale probar y probar antes de dejarlo activado definitivamente. Aquí dejo la información para el que le sirva 😉
Características principales
Las bondades de Magento son una larga lista de características así que de entre las principales tenemos:
Multi-sitio web (varios dominios), multi-almacén y multi-vista de almacén, todo con un mismo panel de administración.
Multi-idioma, con packs de idiomas disponibles para instalar como extensiones.
Gestión total del catálogo; categorías y productos.
Gestión muy potente de atributos de productos.
Filtrado de productos para mejorar la navegación basado en atributos y características muy avanzado.
Integración con pasarelas de pago para poder instalar como extensiones.
Registro detallado que nos informa del estado actual con todo lujo de detalles: últimas ventas, ingresos, productos más vendidos..
Gestión de datos de clientes, registro, modificación.
Gestión de los usuarios que acceden al panel de administración.
Herramientas de marketing como emails transaccionales configurables, reglas de precios de catálogo o de carrito, herramientas SEO integradas.
Gestión de promociones basadas en características de productos o de carritos de la compra. Se pueden utilizar atributos personalizados para las reglas de promociones.
Temas para instalar; sistemas de páginas estáticas, bloques y widgets para personalizar.
También tenemos inteligencia de negocio con muchos informes detallados listos para ver en tiempo real.
Un sistema de gestión de índices y caché.
Muchas extensiones para personalizar nuestro Magento en su marketplace.
Por supuesto, acceso para interconectar con otros sistemas mediante punto de entrada a una API.
Magento es enorme, parece el SAP de las soluciones eCommerce Open Source. Soy sincero, no conozco SAP en sus entrañas, pero ya sólo ver que tenemos 300 tablas para guardar los datos necesarios para funcionar me hice una idea. Entrar a detallar las características de cada zona de su panel de administración es una tarea interminable así que será mejor ir directamente a su funcionamiento, empaparse de su documentación, o ir buscando lo que necesites. Recomiendo dar una lectura rápida a las guías de usuario disponibles en su página oficial.
Terminando
Lo que destaca de esta solución eCommerce es su robustez y fiabilidad. Estoy viendo muchas mejoras en la versión 2 con respecto a la 1: aumento de velocidad, sistema totalmente cacheado, compatible con HHVM.. Destaca la integración de la herramienta de consola de Symfony. Tenemos disponible la integración con Odoo mediante la instalación de una extensión en Magento, se abre el acceso al Webservice, e instalando los módulos correspondientes en Odoo podremos sincronizar catálogo, stocks, clientes, pedidos, carros abandonados, etc.. esto último está disponible hasta para la versión 1.9, espero que pronto esté también para Magento 2 😉
Al instalar los códigos me sorprendió que me pidiera ejecutar un ‘composer install’ para comenzar a correr la aplicación. Composer es una herramienta que organiza las librerías PHP, algo que venía haciendo falta. Es una herramienta PHP muy nueva, que están usando frameworks de desarrollo de la talla de Symfony o Laravel. Esto me hace preveer que el código fuente de Magento 2 puede incorporar pronto muchas nuevas mejoras del mundo PHP. Estaremos atentos.
Si has estado probando soluciones como Virtuemart, WooCommerce o Prestashop. Esta solución de código libre es más que interesante. Habrá que valorar qué es lo que necesitas para tu caso, pero lo que si puedo asegurar es que Magento es una gran solución.
El único inconveniente que le veo es que, por lo menos aquí en Spain donde resido, hay muy pocos desarrolladores especializados en Magento. Así que toma el dato, si quieres asegurarte el trabajo, aprende a desarrollar para Magento y no te faltará el trabajo.
Ya estoy de nuevo por aquí frikeando un poco con el software. Estoy en estos días poniéndome al día con Magento. Es la gran solución de Código Libre para trabajar de forma económica montando una web. Entre las tres principales soluciones es la que de momento ostenta la primera posición, la segunda viene a ser Prestashop y la tercera WooCommerce.
Estoy hablando de las soluciones económicas, Open Source, PHP, robustas y estables. Ya si nos centramos sólo en España veremos que el despunte de tiendas online es para Prestashop. Espero no equivocarme con los datos, los puedes comprobar rápidamente haciendo un par de búsquedas y dejar un comentario abajo para corregir.
Situación
Resulta que tenemos entre manos ahora un Magento, pero no podemos entrar al panel de administración que lo tenemos en: https://nombredominio.com/index.php/admin
Pero sí que tenemos acceso a la base de datos. Es imprescindible tenerlo porque si no entonces tendremos que descartar éste mecanismo de recuperación. Necesitamos entonces acceso mediante phpMyAdmin, Mysql Workbench, línea de comandos..
Dónde tenemos que tocar
Ahora bien, los administradores están en la tabla admin_user y la contraseña de cada uno es la columna password. Si le hemos puesto un prefijo a las tablas entonces la tabla será de la forma prefijo_admin_user. Jeje, parece fácil pero ahora bien ¿qué cifrado se usa en Magento? Pues MD5, y se le añade una semilla al cifrado para hacerlo mejor.
Cómo cifra Magento las claves de administrador
Resumiendo, la estrategia es que pone una semilla delante de la contraseña. Si por ejemplo la semilla va a ser la palabra ‘semilla’ y la contraseña ‘thepass’ lo que hace es cifrar con MD5 la cadena ‘semillathepass’ y luego al resultado le añade después ‘:semilla’ y lo guarda.
Simplemente tenemos que ejecutar lo siguiente que hace esto que explico aquí arriba en el cliente de la base de datos Mysql y tendremos entonces la contraseña cambiada: UPDATE basededatos.prefijo_admin_user SET password=CONCAT(MD5(‘semillathepass’), ‘:semilla’) WHERE username=’administrador’;
Simplemente ejecutamos esto y se actualizará la clave del administrador ‘administrador’ poniéndole de clave ‘thepass’. Ya lo modificas a tu gusto y a correr 😉
¿Y las claves de usuarios clientes de la tienda?
Ahora bien, vamos a ir un paso más allá. Porque ¿dónde están las claves de los clientes? Éstas las tenemos en la tabla prefijo_customer_entity_varchar, y en prefijo_customer_entity tenemos los valores principales de los usuarios. Y en mi instalación estoy viendo que el atributo de identificador 12 corresponde a las claves de clientes. Que a su vez están cifradas de forma similar a las de administrador.
¿Pero qué tenemos aquí? ¿Porqué tenemos tantas tablas? ¿No sería mas sencillo una supertabla con una fila para cada usuario? Lo que ocurre es que Magento usa el modelo de datos EAV. Es un modelo de datos con el que los atributos que van a tener unos elementos se definen en una tabla, en otras se definen los principales valores de dichos elementos, y los valores disponibles se definen en otra tabla. Esto es engorroso para programar pero proporciona que se puedan definir en ejecución tantos valores como queramos de forma de que no se tengan que modificar ni códigos fuentes ni base de datos. Es muy potente, flexible, pero es engorroso y aumenta la complejidad.. a la hora de tocar base de datos o hacer consultas.
Es muy sencillo verlo de la siguiente forma. Tenemos la tabla de atributos prefijo_eav_attribute, si vemos un listado de algunos atributos podemos tener algo tal que así:
Fíjate que el atributo 12 es el password_hash. Ahora si vamos a los atributos de los customers que tenemos en la tabla prefijo_customer_entity_varchar y vemos los valores de las filas con attribute_id que sea 12 veremos que se parecen a contraseñas como las de los administradores ¿verdad?
Jeje, pues ya tenemos ahí las contraseñas. Parece que tenemos también la semilla después de los dos puntos concatenada con la clave. Será fácil entonces hacer otra consulta que actualice la contraseña de los usuarios de igual manera que la de los administradores.
UPDATE basededatos.prefijo_customer_entity_varchar SET password=CONCAT(MD5(‘semillathepass’), ‘:semilla’) WHERE value_id=1030;
Esta última consulta se supone que modificará la contraseña del cliente con identificador 175, es el valor 1030. A su vez el cliente que tendrá su email en la tabla prefijo_customer_entity y otros datos repartidos por sus tablas correspondientes.
Terminando
Ya lo dejo aquí, con el modelo de datos EAV, que es muy potente, tendremos disponibles todos los datos y podremos andar modificando no sólo las contraseñas de los clientes. Habrá que tener especial cuidado de no sobrecargar de consultas la base de datos, o hacerlo bien optimizándolas con JOINs en vez de concatenando tablas, no creando demasiados bucles que consultan datos y a su vez vuelven a consultar más datos con los resultados, etc.. porque fácilmente podemos relentizar en funcionamiento de nuestro Magento. Pero por otro lado tendremos un sistema muy potente para ir añadiendo lo que necesitemos si crear más y más tablas cada 2 por 3, con el consecuente peligro a la hora de actualizar cuando se añaden tablas o se modifica la base de datos.
En estos días he estado haciendo una copia de seguridad de una base de datos compatible con MySQL. En concreto de MariaDB, un ‘replace’ que funciona muy pero que muy bien. Para éste ejemplo he usado un servidor Linux, supongo que en otros sistemas operativos también tendremos disponibles estos comandos.
MariaDB es un fork de la conocida base de datos MySQL que ha seguido más y más desarrollándose e incorporando más y más funcionalidades.
Vamos al grano, es sencillo exportar a un fichero SQL desde línea de comandos con un comando como el siguiente: $ mysqldump nombreBaseDeDatos -uuser -ppassword > nombreFichero.sql
Lo que hay después de -u es un nombre de usuario, después de -p la contraseña, debe ser un usuario y contraseña válidos y que tengan permiso de acceso a toda la base de datos.
Si queremos hacer pruebas antes de guardar a un fichero el contenido podemos omitir lo último del comando para ver lo que hay en la BD.
$ mysqldump nombreBaseDeDatos -uuser -ppassword
A continuación, si queremos importar el fichero SQL ejecutamos lo siguiente en línea de comandos:
$ mysql nombreBaseDeDatos -uuser -ppassword < nombreFichero.sql
