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:

Leer más

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-5bef843e34fbb015791055/]
Y lo reemplazamos por este otro:
[crayon-5bef843e34fc2332185828/]
Obviamente, en el punto del código donde pone ‘No’, podemos poner
[crayon-5bef843e34fc5808801409/]

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-5bef843e353aa416180945/]

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-5bef843e353b3564438933/]

Cuando, después de una actualización vía código de los productos y/o sus categorías y atributos, necesitamos reindexar de nuevo las tablas implicadas en el proceso, podemos hacer:
[crayon-5bef843e355bb653375540/]
para reindexar todas las tablas, o bien, si sólo necesitamos reindexar un conjunto determinado de tablas, podemos hacer:
[crayon-5bef843e355c4117506592/]
 

Probablemente muchos de vosotros habréis tenido dificultades para acceder a los enlaces del footer de Magento. Esto se debe, una vez más, a la particular distribución/dispersión de los archivos en esta plataforma. A grandes rasgos, los enlaces del pie de Magento pueden estar en dos lugares bien diferentes: en un bloque estático del back-end, o repartidos por una serie de archivos XML.

Bloque estático Footer links

Para acceder al contenido de este bloque estático, ingresamos en el back-end de Magento y nos vamos a CMS > Bloques estáticos.

magento - bloques estaticos

Dentro de la lista de bloques aparecerá uno llamado Footer links. Hacemos doble clic sobre su fila para acceder al código HTML que contiene.

magento - footer links

Esto nos llevará a una pantalla que en su parte inferior tiene un editor WYSIWYG que nos permitirá editar el código de los enlaces a nuestro gusto.

Pero no todos los enlaces se encuentran aquí. Probablemente también tengamos que acceder a otros enlaces que se encuentran repartidos en varios archivos XML.

Archivos XML

El número de los archivos implicados puede variar según la versión de Magento, aunque en general suelen ser casi siempre los mismos, y deberemos acceder a ellos por FTP. Su ruta de acceso es app/design/frontend/default/default/layout.

En nuestro caso (nosotros estamos trabajando con la 1.7.0.2), los archivos que hemos tocado son los siguientes:

  • sales.xml
  • catalogsearch.xml
  • catalog.xml
  • contacts.xml

Si lo que queremos es eliminar los enlaces del pie (bien porque queremos prescindir de alguno, bien porque vamos a crearlos manualmente en el editor del back-end que vimos en el punto anterior), deberemos localizar la etiqueta <reference name=”footer_links”> y marcarla (desde su apertura hasta su cierre) como comentario, para desactivarla. Procederemos del mismo modo con todas las etiquetas con el mismo atributo name de estos archivos.

Como comentamos, los archivos a editar pueden variar según el caso, por lo que puede que también aparezcan etiquetas similares en los archivos rss.xml, page.xml, cms.xml y customer.xml.