Hoy traigo un pequeño HOWTO de cómo balancear las visitas de un sitio web entre varios servidores, eligiendo exactamente qué visitas van a qué servidores. Se trata unas pocas directrices para configurar CloudFront y así redirigir las peticiones web.
Con esto puedes controlar qué subdirectorios, o que zonas de tu aplicación web se gestionan desde qué servidores. Balancear en función de la carga se puede hacer con un ELB (Elastic Load Balancer), pero estas configuraciones a nivel de CloudFront balancean las peticiones de forma permanente. Por ejemplo:
Montar una web con lo imprescindible, ponerle el contenido y diseño, y olvidarnos de ella.. sería como comprarnos un coche y ya no preocuparnos nunca por pasarle una revisión. Sería como si nos diera igual si hay una bajada de potencia del motor, que las ruedas no estuvieran bien hinchadas. Quizá una bujía deja de dar los chispazos al 100%..
Y no sólo están los problemas de mal-funcionamiento, sino que quizá también hay algunas mejoras extras. No todo viene de casa, y puedes hacer que el coche vaya mejor. ¿Porqué no entonces dedicarle ese tiempo a nuestra web para revisar esas cosas? Es más, ¿porqué no poner a un mecánico que sepa lo que está haciendo? Está claro que nos podemos quedar tal cual, nuestro coche andará. Pero queremos que no le falte esa alegría, que responda sin pereza. Resumiendo, queremos que la maquinaria esté bien engrasada, sacando el 100% de su rendimiento. Entonces necesitaremos a un especialista que toque, pero no de oídas, sino que sepa lo que está tocando.
Es ingente la cantidad de cosas que se pueden hacer en un Magento recién instalado. Es un CMS orientado al eCommerce muy completo. También muy orientado a la optimización para motores de búsqueda (SEO). Tiene muchas características que le dotan de gran flexibilidad. Entre ellas es la «sencilla» forma de ampliar funcionalidades sin que nada se rompa. Siempre claro, que hagamos lo que en programación se llama overriding. De esta forma, no tocaremos los ficheros originales, ampliando o modificando su funcionamiento en otro espacio de trabajo.
Qué es hacer overriding
Es la forma correcta de hacer las cosas. Si queremos modificar o ampliar funcionalidades de un CMS, lo que siempre debemos de hacer es overriding. Por ejemplo, en WordPress es bastante habitual encontrarte con plantillas que se han modificado. Si se han modificado con el editor que te trae WordPress en el mismo panel de control, sin antes haber hecho una plantilla hija de la original, el problema es que esto no es hacer overriding. Y cuando vamos a actualizar la plantilla.. ¡zasca! se borran todos los cambios hechos.
Hoy traigo un pequeño HOWTO para ver el estado de los precios del catálogo de productos. Está hecho sobre un Magento 1.9. La idea es la misma que vengo exponiendo en posts anteriores. Es decir, cogemos la colección de productos y vamos imprimiendo por pantalla los datos. Esto si queremos lo guardamos en un fichero y a trabajar con los datos.
Para mejorar la eficiencia de una empresa, debemos de darle especial atención a la cantidad de activos que tenemos disponibles. Los activos de una empresa son los productos que se venden. Saber cuántos hay exactamente, cuántos hay que pedir a proveedores, si permitimos ventas infinitas, si estamos en rotura de stock.. Todo esto es información muy importante para mejorar los procesos de una empresa. Si esto mejora, debería de mejorar también el trato con el cliente, la percepción que tiene de nosotros, la cantidad de incidencias que podamos tener. Podemos pensar que tenemos un producto en stock que luego hay que pedir a proveedores. O puede pasar que no se esté vendiendo un producto que tenemos en stock. O simplemente para minimizar la cantidad de stock en almacén también es interesante automatizar todo lo que se pueda. Aquí llegamos al ciclo de vida de los pedidos y stocks en Magento.
Todo esto es un tema muy grande, y a la par divertido. Ir viendo cómo con cada ajuste todo mejora. Ir viendo cómo con cada batida de inventario el catálogo va mejorando día a día. Los productos se crean, suben los stocks. Bajan hasta llegar a cero, se pone a fuera de existencia.. Pedidos por debajo de cero creando necesidades de compra al suministrador.. Limitando existencias dejando al cliente que sepa que se lo podemos pedir..
Todo este control es un clásico de un ERP. Un ERP es un programa muy muy complejo de poner en marcha. Las muy pequeñas y pequeñas empresas no los suelen tener porque necesita mucho esfuerzo para ponerlo en marcha y revisarlo. Pero una vez más, Magento trae parte de esta gestión incorporada en el sistema. Es decir, Magento no es un ERP, pero te trae parte de la gestión de existencias ya incorporada de casa.
Ya puedes tener la estrategia de marketing mejor del mundo, la mejor campaña publicitaria, los mejores anuncios. Unas publicaciones excelentes en blogs, una gran inversión en SEM, o un SEO de contenidos inmejorable. Que si la infraestructura informática subyacente no acompaña de poco servirá. Aquí es donde entra el estar o no en la nube. Y nunca mejor dicho, poner tu aplicación web por las nubes.
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!
En una reunión en un café con unos colegas de trabajo estábamos hablando de CMSs, citando Magento, llegaron algunas preguntas como: ¿qué tiene Magento de especial? Pues una de las peculiaridades que le dan una gran potencia a Magento es la gestión de tareas programadas.
Magento nos obliga a disponer de un servidor en el que podamos configurar un programa, en este caso el cron de Magento, para que se ejecute cada x tiempo. Yo lo estoy instalando para que se ejecute a cada minuto. Este programa interno de Magento se llama cron igual que en Linux tenemos también el cron. Es el programador de tareas, no es el Crom de Conan el bárbaro que me comentaba un compañero de trabajo xDD
En las últimas versiones se ha pasado incluso el envío de emails transaccionales como tarea programada. Es decir, los emails transaccionales se envían a una cola de envío de emails y en la siguiente ejecución del cron se envían los que haya encolados. Estas tareas llevan un seguimiento, registro, etc.. A cada ejecución del cron de Magento le llamamos los desarrolladores heart beat en inglés, que significa el latir del corazón. Es decir, que Magento tiene un corazón, que late, y en cada latido puede que haga muchas cosas.. qué freak que suena esto, pero así es..
Hola de nuevo. Esta semana he seguido avanzando sobre todo esto de Magento. Creando unos trabajos de cron, después de haber probado las tareas cron a ejecutar mediante scripts externos a Magento. Me he encontrado con que las fechas no me funcionaban como yo esperaba dando malos resultados.
Probando probando, llegué a la conclusión de que tratando las fechas mediante cadenas de caracteres podía aplicarles las modificaciones que necesitaba.
Este estupendo CMS orientado a la venta online de productos hace las delicias de los vendedores, de igual modo de los maquetadores, y cómo no, también de los programadores.
Como analista programador llevaba ya un tiempo queriendo meterle mano a las entrañas de Magento. Así que poco a poco, he ido cogiendo los manuales para el usuario, luego el del diseñador, y ahora tengo entre manos el del programador. Ahora según van surgiendo las necesidades voy haciendo incursiones cada vez más a fondo en el código fuente de esta humongous web application.
La verdad es que lo estoy disfrutando porque Magento está desarrollado con una buena estructura y sobre un gran framework de desarrollo PHP, el Zend Framework. Incorporando técnicas de programación que le dan una gran flexibilidad sin añadir demasiada complejidad.
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.
