Nuestra compañera Silvia Suria ha publicado recientemente un libro sobre comercio electrónico en formato Kindle, titulado Errores comunes en la creación de un comercio electrónico. El enlace de la obra es éste: Ir a Amazon Kindle
En ella explica los problemas recurrentes que normalmente cometen los emprendedores o/y las empresas que deciden abrir una tienda online, y cómo evitarlos, por lo que es una obra recomendada para un amplio abanico de lectores, desde los entusiastas fundadores de una startup, a los directores de departamento que deciden entrar en el mundo digital de las ventas online de empresas más o menos consolidadas en el mercado tradicional.
Comercio electrónico
El error «Unable to serialize value» viene generado por una codificación errónea del archivo CSV para las traducciones. Para los que trabajan con Windows, recordaros que hay que codificar siempre en UTF-8.
Para comprobarlo, hay que ejecutar en la línea de comandosphp -dmemory_limit=5G bin/magento setup:static-content:deploy de_DE --jobs=0 -f
En Magento 1.x el error en el login puede venir por problemas de caché en navegador o por problemas en versiones antiguas de código. Si no es vuestro caso y ya lo habéis chequeado todo, probad a ampliar la RAM de vuestro servidor, seguro que os funciona de nuevo. Y es que la falta de recursos no siempre viene dado por una lentitud en la página.
En Magento 2.x el error de login puede venir dado por problemas con la caché (podéis limpiarla vía línea de comandos o borrando el directorio var/cache), por falta de recursos como en la versión 1.x, o porque has activado la destrucción de datos de sesión al regenerar los ids de sesión. Desactiva esto último y funcionará todo.
En ambos casos, también puede ocurrir que haya alguna extensión instalada recientemente que esté dando problemas. Sería cuestión de desactivarla, limpiar caché y volver a intentarlo, siempre con una ventana de incógnito del navegador para mayor seguridad.
El 3 de junio saltaron las alarmas entre los clientes de PcComponentes: se estaban realizando compras fraudulentas con sus tarjetas. Por lo que se cuenta en esta noticia (ver noticia), parece ser que PcComponentes ha tenido un problema de seguridad y las cuentas de usuarios se han visto comprometidas, aunque más tarde la empresa ha querido desmentirlo. Lo que llama la atención es que se hayan visto implicados clientes de PcComponentes.
Este supuesto robo de información no debería haber supuesto un problema más allá de haber hecho público los datos de los usuarios, si no fuera porque al parecer, PcComponentes guardaba sus números de tarjetas en sus propias bases de datos, lo que ha llevado a los clientes a pensar que ha habido alguna filtración.
Llevamos años insistiendo en contra de guardar los datos bancarios de los usuarios a los clientes que nos piden guardar ellos mismos los números de tarjetas y de CCC con el objeto de hacer más cómoda la compra para sus clientes cuando éste repite. Y nuestra respuesta siempre ha sido la misma: hace falta tener una seguridad muy alta en los sistemas que custodian esos datos (no sólo implican una encriptación de datos, también una seguridad perimetral mayor, un técnico dedicado a los servidores, backups y la seguridad de la plataforma, etc), y esa seguridad es una inversión demasiado cara, por lo menos para un comercio electrónico medio, ya que hoy día no genera tanto margen de beneficio como para costear ese incremento en la seguridad. Un cliente no va dejar de comprar en un comercio electrónico simplemente porque tenga que meter su tarjeta cada vez, sobretodo si se le escribe una nota aclarando que es una medida de seguridad pasiva muy efectiva «¿Por qué no guardamos tu tarjeta bancaria? Porque en caso de hackeo, tus datos bancarios no se verán comprometidos». Al contrario, si se le explica, el comprador se sentirá más seguro en un comercio electrónico que no guarda la tarjeta frente al que sí lo guarda.
Si al entrar en el detalle de cada cliente en el backend de Magento 1.9 os devuelve el mensaje:
error: error in [unknown object].fireEvent():
event name: address_country_changed error message:
cannot read property ‘show’ of undefined.
Lo que debéis hacer es ir a la administración de bases de datos que tengáis (PHPMyAdmin, Adminer, etc) la tabla de eav_attribute y buscar el elemento postcode. Lo editáis y cambiáis el valor del campo is_required de 0 a 1, ya que es un campo necesario para los envíos.
A veces me he encontrado con que ha habido que corregir a mano la url o el nombre de la imagen de algún producto en una base de datos de Magento. Cuando esto pasa, hemos de saber que hay que trabajar con 2 tablas:
catalog_product_entity_varchar
catalog_product_entity_media_gallery
A veces nos ha ocurrido que aunque la plataforma Magento (versión 1.9) funciona perfectamente y las URLs van bien, cuando hemos querido instalar desde el Downlader una extensión con la URL del Marketplace de Magento, nos ha dado el error:
En este caso, tenemos un cliente que quiere que sólo los atributos con valor a «Sí» (o TRUE, o «Verdadero», como queráis). ¿Cómo lo conseguimos?
Nos iremos al archivo attribute.phtml del paquete del tema que estamos utilizando, cuya ruta es:
/app/design/frontend/nuestro_tema/paquete_usado/template/catalog/product/view/attribute.phtml
Y buscamos este código:
[crayon-5f2c764f2c9d8490223347/]
Y lo reemplazamos por este otro:
[crayon-5f2c764f2c9df623569795/]
Obviamente, en el punto del código donde pone ‘No’, podemos poner
[crayon-5f2c764f2c9e3654616069/]
Para descargar la versión más reciente de Magento 1.x lo mejor es utilizar
[crayon-5f2c764f2cd9e467130913/]
Cuando sacaron la actualización de Woocommerce a la versión 2.0, oí muchas críticas y quejas, y he decidido que lo mejor es que explique qué ocurrió. Como bien nos explican en este artículo en inglés, el problema fue no respetar la compatibilidad hacia atrás (sus razones tenían, pero fue algo doloroso para la comunidad de usuarios), unido a que los usuarios de WordPress están muy mal acostumbrados (porque todo suele ir bien, claro), e instalan las actualizaciones sin testear previamente en una plataforma aparte. Y ahí llegó el problema: muchos carritos y tiendas dejaron de vender.
Así que, como moraleja: antes de actualizar una plataforma en producción, instalen las actualizaciones en una plataforma aparte, que sea exactamente igual a la de producción, testeen, y cuando estén seguros de que todo funciona, hagan una copia de seguridad de la plataforma y la BD antes de actualizar. Mas vale tardar 6 horas en actualizar, que 6 días en echar a andar de nuevo una plataforma.
A veces sucede que cuando se instala un plugin en MAgento, o lo desinstalamos, o actualizamos la plataforma de alguna forma, la parte del front se ve perfectamente y funciona todo, pero al intentar entrar en el backend, no podemos acceder al mismo.
Nos ponemos un poco nerviosos, porque aunque no es la pantalla de mantenimiento, no podemos acceder al backend de nuestro comercio electrónico. Si después de hacer lo que te recomiendan en foros y webs, que suele ser «borrar el contenido del directorio de var/cache de Magento», «borrar el contenido del directorio var/sessions de Magento» y ver que sigue igual, y después de poner el código correspondiente al modo desarrollador:
[crayon-5f2c764f2d10d178278863/]
y comprobar que seguimos sin ver nada, ni en los archivos de log propios de Apache ni en los de var/log y var/reports de Magento, y tampoco has conseguido ver qué ocurre al desactivar la compilación, es que ha llegado el momento de utilizar este código, que devolverá qué clase es la que da el error, y por lo tanto, nos dará pistas de qué está ocurriendo (por ejemplo, que no se ha instalado / desintalado el plugin correctamente, o que la instalación ha encontrado algún problema a la hora de volcar todos los archivos de la actualización, y alguno no lo ha hecho, o se ha corrompido algún archivo, etc).
[crayon-5f2c764f2d115875767380/]