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-5adccbb3508b1347760050/]
Y lo reemplazamos por este otro:
[crayon-5adccbb3508b9877895783/]
Obviamente, en el punto del código donde pone ‘No’, podemos poner
[crayon-5adccbb3508bc252814775/]
Para descargar la versión más reciente de Magento 1.x lo mejor es utilizar
[crayon-5adccbb350a73530563918/]
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-5adccbb350bc8545960000/]
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-5adccbb350bcf332738233/]
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-5adccbb350d6b978396033/]
para reindexar todas las tablas, o bien, si sólo necesitamos reindexar un conjunto determinado de tablas, podemos hacer:
[crayon-5adccbb350d71116520632/]
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.
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.
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:
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.
Hemos terminado la instalación, aparentemente todo ha ido bien y cuando entramos en la administración de Magento, nos aparece el mensaje: “Your web server is configured incorrectly. As a result, configuration files with sensitive information are accessible from the outside. Please contact your hosting provider”.
La solución es sencilla: en el directorio app crearemos una .htaccess y dentro escribiremos:
Order deny,allow
Deny from all
También vereis soluciones en las que os dicen de tocar la configuración de Apache, pero suele ser más fácil y estar a la alcance de todos crear y modificar un archivo .htaccess.
Cuando afronteis un proyecto en Magento u otra plataforma de comercio electrónico, podeis usar todos los módulos que se os apetezcan, pero cuando llegue la hora de configurar la parte de forma de pago, si os piden configurarlo para un banco, olvidaos de todo e id a los módulos que os ofrecen los chicos de Zhenit. En su web de módulos de pago teneis todo lo necesario para montar el módulo de pago y olvidarse de problemas, incompatibilidades, etc. Y si teneis alguna duda, os atenderán muy amablemente y os guiarán en todo.
El proceso completo es el siguiente, compras el módulo, lo descargas, lo instalas, lo configuras,… y te olvidas.
