jueves, 5 de febrero de 2015

Módulo Google Analytics Enhanced Ecommerce (Comercio Electrónico Mejorado)

Os presento mi primer módulo comercial de Prestashop.

Se trata de un módulo indispensable para todos aquellos que quieran conocer al detalle como interactúan los visitantes los productos de tu tienda online y si hay alguna fuga o piedra que impida que tus visitantes se conviertan en clientes.

El módulo está realizado siguiendo la guía de Enhanced Ecommerce de Google al pie de la letra.

¿Que se consigue con este módulo?

Lo principal, es que consigue datos muy valiosos de tu tienda, mucho más que con cualquier otro módulo de seguimiento y analítica para Prestashop. Con este módulo exprimiendo toda la potencia de Google Analytics es posible medir e interpretar los datos de mil formas para que nos ayude a mejorar el rendimiento de nuestras ventas con mucha más precisión.

Pero mejor que lo veamos en acción.

Una vez instalado y configurado tanto el módulo como Analytics podremos acceder al siguiente menú de Google Analytics.

Este menú lo encontraremos dentro del panel de Conversiones "abajo del todo" desplegamos el menú de Comercio electrónico y tendremos a nuestra disposición toda la artillería pesada.

El menú cuenta con muchas opciones interesantes, pero en este post vamos a tratar únicamente aquellas más interesantes para que os hagáis una idea de los beneficios del seguimiento con comercio electrónico mejorado.

Los puntos que vamos a repasar son:

1 - Comportamiento de compra
2 - Rendimiento del producto
3 - Rendimiento de la lista de productos











1 - Comportamiento de compra

Uno de los puntos más interesantes es saber que ocurre en el proceso de compra, podrás ver los métodos de pago más utilizados, los transportistas y métodos de pago más seleccionados y lo más importante, los abandonos en tu proceso de compra.



1 - Viendo esta imagen, podemos concluir que el resumen de cesta tiene una alta tasa de abandono "75,69%", pero también vemos que cuando se inicia el proceso de compra la conversión es buena y hay una baja tasa de abandono. Esto ya nos avisa de que en el proceso de compra el problema está en el primer paso de la cesta. Habría que revisar este punto al detalle y mirar de realizar algunas acciones cómo test A/B y acciones promocionales como cupones descuentos, etc.. para ver si mejorar la tasa de abandono.

2 - En esta pantalla también seremos capaces de filtrar toda esta información por transportista o método de pago, (En mi caso no dispongo de la página de selección de transportista por eso no aparece). Para visualizar los métodos de pagos y conocer que pagos son los más utilizados pulsaremos en la pequeña flecha blanca y nos aparecerá un cuadro con un desglose de métodos de pagos.

2 - Rendimiento del Producto

Otro punto muy interesante es el rendimiento del producto tu catálogo. Podrás saber que tipo de categorías tienen mejor conversión y donde se añaden más productos a la cesta.


Gracias a este informe podemos saber que productos (1) han comprado más veces los visitantes, cuantas unidades se han vendido en el total de ventas y la media de unidades de ese artículo por compra, (2) además, seremos capaces de averiguar cuantas devoluciones ha tenido cada artículo. (3) Por último sabremos la relación de veces que ese producto a sido visto y añadido a la cesta o comprado.

Fuera del informe (4) vemos más dimensiones primarias que generan nuevos informes, como la de Categoría de producto (Comercio electrónico seguro) Esta dimensión nos da la oportunidad de visualizar el rendimiento de las categorías de productos, ofreciéndonos la valiosa información de las categoría que más ventas generan.

Con toda esta información podremos hacernos un idea más clara de que les gusta a los clientes de nuestro catálogo, de la misma forma podremos averiguar si un artículo tiene muchas devoluciones y actuar en consecuencia, ya que si un artículo genera ventas y muchas devoluciones nos puede afectar en una mala reputación.

Esta información nos ayuda a tener una visión de aquellos productos más rentables y nos permite tomar decisiones en nuestro almacén ya sea para acumular stock o para descartar artículos problemáticos.

3 - Rendimiento de la lista de productos

En este último punto vamos a ver por donde se mueven más nuestros usuarios y como interactuan con nuestro catálogo, solemos tener la mala costumbre de pensar que los clientes hacen las compras tal y como lo haríamos nosotros. nada mejor que tener los datos reales para salir de dudas y mejorar esas zonas de la web.



En esta captura podéis ver los siguientes datos (1) Las veces que se visualiza en pantalla un producto de nuestras categorías, y al lado cuantas veces los usuarios han realizado clic para entrar en la ficha del producto. (2) esta columna nos muestra las veces que un cliente a añadido un artículo a la cesta desde la vista de categoría. (3) Finalmente tenemos la cantidad de artículos que han participado en un proceso de compra (con y sin finalizar la venta) y las compras realizadas desde ese listado.

Disponemos de otras dimensiones primarias muy interesantes (4) como la posición de productos y producto, en la primera tendremos la información de la posición natural del artículo, de esta forma podemos sacar conclusiones del orden que aparece en el listado de productos, puede que tengamos más de una categoría donde los primeros artículos no sean los más comprados y sería muy interesante colocar en primer lugar siempre los artículos más vendidos.

Como vemos en el ejemplo los usuarios prefieren navegar por los listados de fabricantes antes que el de categorías y un número poco significativo se ha paseado por el listado de proveedores. con todo esto podemos tomar muchísimas decisiones más encaminadas a los intereses de nuestros usuarios, como organizar mejor los fabricantes, poner ofertas de algún fabricante con más visitas o compras o incluso si pensamos en preparar una acción de emailing puede ser más efectivo enfocar el mail utilizando las categorías de fabricantes antes que de alguna categoría en la que se mezclen fabricantes.

Como os podéis imaginar os he comentado la punta del iceberg, y estas estadísticas ofrecen enormes posibilidades que podéis integrar fácilmente en vuestra tienda con el módulo Premium Google Analytics Enhanced Ecommerce para Prestashop 1.5 y 1.6

Podéis adquirir el módulo Google Analytics para Prestashop en Prestashop Addons por 69,99€

martes, 28 de enero de 2014

Tutorial .htacess para Prestashop



Sé que existen miles de tutoriales sobre htaccess, en todos los idiomas y con un millón de ejemplos. A veces he tenido que leer 10 o 15 tutoriales para encontrar la forma de solucionar el problema y la verdad es que uno se desespera, esa abrumadora cantidad de información es la que me ha empujado a realizar este tutorial centrado a solucionar los problemas que pueden surgir en Prestashop.

Sin duda una parte fundamental para cuidar y mejorar nuestra tienda online es dominar un poco el .htaccess, ese archivo que nos encontramos en la raíz de nuestra web, que puede parecer poca cosa, pero en realidad es como el sheriff y lleva la voz de mando en el tema de accesos de nuestra web.

El .htaccess puede hacer muchas cosas como bloquear robots maliciosos que se saltan el robots.txt, filtrar IP’s, activar la compresión de archivos del servidor, controlar el acceso a carpetas, y un montón de cosas más, pero en este tutorial nos vamos a centrar en la función de redireccionamiento o rewriterules, que es la función más utilizada y la que nos ayudará a solucionar rápidamente todos los errores 404, eliminar páginas antiguas o redireccionar esas páginas antiguas a una página actualizada.

Puede parecer un poco duro al principio pero si le pilláis el tranquillo, incluso le cogeréis cariño al htaccess y veréis cómo podréis solucionar muchas cosas, entre ellos todos los errores que aparecen en vuestro webmastertools o migraciones de urls.

Pondré un ejemplo básico y luego explicaremos el código paso a paso.

Redirección Sencilla

El siguiente ejemplo hace que la página antigua y eliminada www.mitienda.com/pagina-ant-1.html se redireccione a la página principal.

<IfModule mod_rewrite.c>

            RewriteEngine on
            RewriteCond %{HTTP_HOST} ^www.mitienda.com$            
            RewriteRule ^pagina-ant-1$ http://www.mitienda.com/ [R=301,L]

</IfModule>

Repasemos ahora el código.

<IfModule mod_rewrite.c>
Lo primero que hacemos es abrir un condicional. Comprueba si existe el módulo mod_rewite.c en el servidor y si es así comprobará el código anidado.

RewriteEngine on
Activa esta función en el servidor

RewriteCond %{HTTP_HOST} ^www.mitienda.com$
Condición a cumplirse. Si la variable del servidor %{HTTP_HOST} es igual a www.mitienda.com comprobaremos la Rewrite Rule.

NOTA:
^ - Indica el principio de la palabra a buscar
$ - Indica el final de la palabra a buscar

RewriteRule ^pagina-ant-1$ http://www.mitienda.com/ [R=301,L]
Cuando la url sea http://www.mitienda.com/pagina-ant-1 redirecciona a la página http://www.mitienda.com/

Al final del código hay unos Flags [R=301,L] esto indica a la norma de reescritura las siguientes opciones.

R=301 – R= Redirección 301 permanente. Existen varios tipos de redirecciones, pero salvo alguna excepción utilizaremos siempre la 301.
L – Al cumplirse esta norma, para el código y no ejecuta ninguna condición más.

</IfModule>
Cierra el condicional principal. Siempre que queramos añadir una nueva redirección asegurarse de colocar el código antes del cierre del IfModule.

Comodines y Variables

Adentrándonos un poco más en htaccess vamos a conocer los comodines y variables utilizadas en redirecciones, son tremendamente útiles y nos ayudarán a solucionar muchos problemas de forma sencilla.

Repasemos primero los valores más utilizados.

. – Cualquier carácter a excepción del espacio.
* El carácter anterior puede repetirse 0 o más veces.
 () – Agrupa el contenido y lo guarda en una variable $1 para que podamos utilizarla en caso de ser necesaria en la dirección de destino.
| – Se utiliza dentro de los () para separar opciones de cadenas de url, viene a ser un “OR” Ej. (pag-x|pag-y) será verdadero si la url contiene la cadena pag-x o pag-y.
\ – Código de escape, utilizaremos la barra invertida para poder utilizar el punto como texto de la cadena pag-z\.html

Como ejercicio miraremos de redireccionar la url 1 a la url 2.

1.- http://www.mitienda.com/categoria-antigua/3487-producto.html
2.- http://www.mitienda.com/categoria-nueva/3487-producto.html

<IfModule mod_rewrite.c>

            RewriteEngine on
            RewriteCond %{HTTP_HOST} ^www.mitienda.com$            
            RewriteRule ^categoria-antigua/(.*)$ http://www.mitienda.com/categoria-nueva/$1 [R=301,L]

</IfModule>

Teniendo en cuenta el ejemplo anterior únicamente explicaremos los nuevos elementos.
Lo significativo de este código es el ^categoria-antigua/(.*)$ esto indica que si la url solicitada contiene categoría-antigua/(y lo que sea) lo enviará a categoría-nueva/(y lo que sea).

Supongo que el concepto ha quedado claro ¿no?

Otro ejemplo.

Tengo varias categorías antiguas y he terminado agrupándolas en una

<IfModule mod_rewrite.c>

            RewriteEngine on
            RewriteCond %{HTTP_HOST} ^www.mitienda.com$            
            RewriteRule ^(categoria-antigua-1|categoria-antigua-2|categoria-antigua-3)/(.*)$ http://www.mitienda.com/categoria-nueva/$2 [R=301,L]

</IfModule>

En este ejemplo hemos creado un grupo que redirecciona cualquier url que contenga esa categoría antigua y en el segundo grupo anida cualquier contenido.

Fijaros que ahora en la url de salida ya no pone $1 que sería el contenido del primer grupo de () dando un resultado erróneo como: http://www.mitienda.com/categoria-nueva/categoria-antigua-x

Utilizando $2 devolverá el contenido del segundo grupo de (.*) que ya sabemos que será un lo que sea.

URL’s Con consultas

De forma menos habitual podemos encontrarnos errores de urls con consultas, que serán todas las direcciones que Prestashop por ahora no las convierte en amigables como al paginar en el listado de productos. Para explicarme mejor pondré un Ejemplo.

Imaginemos un error en Webmastertools de Google que indica la siguiente url, nuestra misión es redireccionarla a la homme.

http://www.mitienda.com/mi-categoria?p=2

Estas no se pueden solucionar como lo hemos hecho antes, y lo que tenemos que hacer es añadir un nuevo RewriteCond que contemple la variable del servidor QUERY_STRING

El carácter “?” es un carácter reservado con lo que la opción rápida de poner la url entera en el rewrite rule es viable, además de que una url con consulta no es una url clásica ya que la cadena de la consulta se almacena en la variable del servidor %{QUERY_STRING}.


<IfModule mod_rewrite.c>

RewriteCond %{HTTP_HOST} ^www.garamo.com$
RewriteCond %{QUERY_STRING} ^p =(2|3|4)$
RewriteRule ^(categoria-antigua-1|categoria-antigua-2)$ http://www.mitienda.com? [R=301,L]

</IfModule>

Que hay que tener en cuenta en el ejemplo.

Recordemos la url de ejemplo: http://www.mitienda.com/mi-categoria?p=2

RewriteCond %{QUERY_STRING} ^p =(2|3|4)$
De igual forma que con la variable del host, La variable QUERY_STRING guarda el contenido de cualquier consulta en url, lo que va después del ?. Comprobamos que la consulta contenga “p=2”, o “p=3”, o “p=4”

RewriteRule ^(categoria-antigua-1|categoria-antigua-2)$ http://www.mitienda.com? [R=301,L]
En esta sección del código vemos filtramos que la condición de reescritura se realizará si la url contiene “categoría-antigua-1” o “categoría-antigua-2”.

Si en la url tenemos alguna de estas 2 categorías y además incorpora la consulta del RewriteCond entonces realizará la redirección a http://www.mitienda.com

NOTA: Finalizar la URL con el símbolo “?” evita que la consulta original se sume a la url final.

Creo que hasta aquí podemos entender lo básico para crear cualquier redirección de nuestra web.

En un próximo post pondremos ejemplos concretos y útiles de redireccionamiento con Prestashop.

Si tenéis alguna duda o una redirección que necesitáis y no os sale, comentarlo en el post y le daremos solución.

viernes, 27 de diciembre de 2013

Mejora tu indexación utilizando rel="nofollow"

Cuando queremos conseguir enlaces externos hacia nuestra web siempre nos han aconsejado que esos enlaces no tengan el rel="nofollow" para que nos puedan pasan "link juice" eso está bien, aunque de hecho es aconsejable tener enlaces con rel="nofollow" para tener un linkbuilding más natural.

Para explicar el link juice de una forma muy sencilla imaginemos que la pagina tiene cierta autoridad y la representamos con un valor imaginario 100, en esta página existen 12 enlaces y 4 de ellos son rel="nofollow", bien cuando entre el robot de google, verá todos los enlaces y valorará cada uno con su algoritmo, el robot accederá a dentro de cada enlace que no tienen el rel="nofollow", lo analizará y hará un traspaso de link juice, dividirá las 100 unidades de autoridad entre 8 enlaces, repartiéndolo bajo el criterio de su algoritmo.

Es algo más complejo pero espero que se haya entendido el concepto, ¿Ahora te preguntarás y eso que tiene que ver con mi indexación?

Bien una de las cosas que hace el robot es acceder al enlace y lo analiza, si te pones a pensar en tu web verás que hay demasiadas formas para acceder al mismo contenido desde distintos lugares de la web.

Un mismo producto te lo puedes encontrar en la home, en el apartado de accesorios de otro producto, en el apartado de otros clientes también compraron, o en cualquier otro hook de la web. Como te podrás imaginar el robot de google no está todo el día mirando tu web, y puede pasar 2 o 4 veces por semana y examina únicamente una pequeña cantidad de páginas de tu web, así que lo mejor será allanar el terreno al robot.

¿Cómo hacemos eso?

Si generamos un camino único para que los robots tengan menos url's "duplicadas" que investigar, estos accederán más rápidamente a todos los rincones de la web y transferiremos mucho mejor el linkjuice a las páginas interiores.

Será tan sencillo como incluir rel="nofollow" en cada <a href... que aparece en cada acceso "duplicado" del producto.



Por ejemplo, en la home podemos hacer rel="nofollow" en todos los productos destacados ya que estos mismos artículos estarán en su categoría por defecto.

Teniendo en cuenta el concepto nos armamos de paciencia y en una tarde lo tenemos todo hecho.

Otros enlaces susceptibles de hacer un rel="nofollow" los encontraremos en los siguientes lugares.


Categorías laterales, si ya están en el menú de arriba no es necesario hacer que los robots se mareen con otro menú duplicado.


En el pie nos encontramos lo mismo, las categorías repetidas por 3a vez, y los enlaces a cualquier zona del backoffice del usuario no tienen ningún sentido que un robot se meta por ahí, y las redes sociales tampoco son necesarias.

Como depende de cómo está diseñada cada página lo mejor es pensar que accesos alternativos tenemos a un mismo contenido y limitarlos, quedándonos con un único acceso para los robots.

martes, 3 de diciembre de 2013

Cantidad de productos por páginas

En este post quiero comentar la posibilidad de cambiar la cantidad de productos que podemos seleccionar desde el selector de paginación del product list.



No sé por qué PS no pone solución a esto pero lo que está claro es que tal cual viene por defecto (10, 20, 50) no ayuda a la usabilidad de nuestra tienda, ya que para una correcta visualización con esas opciones implicaría tener configurado una visualización de 2 o 5 productos por línea, si en tu caso usas una cantidad diferente de productos por línea verás que con las configuración de (10,20,50) irás dejando espacios finales en tu lista de productos.

Cualquiera que vea la siguiente imagen pensará que ya no existen más productos en esa categoría y puede dejar de seguir viendo o buscando productos, cuando en realizad hay muchas más páginas.



Lo primero que podemos hacer es cambiar la configuración desde el backoffice, pero esta configuración únicamente afecta a la visualización principal, pero se mantendrán las opciones de ver 10, 20, o 50 productos por página.



La solución es bien sencilla, un override que cambie esos valores por los que nosotros queramos.

Realizaremos un sencillo override a la función "public function pagination($nbProducts = 10)" de la clase "mitienda.com/classes/controller/FrontController.php"

Una vez tengamos preparado nuestro override donde toca "mitienda.com/override/classes/controller/FrontController.php" editaremos la función "public function pagination($nbProducts = 10)" que hemos copiado.

Es muy fácil ya que solo hemos de editar una sola línea

Bien buscamos la siguiente línea

$nArray = (int)Configuration::get('PS_PRODUCTS_PER_PAGE') != 10 ? array((int)Configuration::get('PS_PRODUCTS_PER_PAGE'), 10, 20, 50) : array(10, 20, 50);

Lo cambiaremos por

$nArray = (int)Configuration::get('PS_PRODUCTS_PER_PAGE') != 10 ? array((int)Configuration::get('PS_PRODUCTS_PER_PAGE'), (int)Configuration::get('PS_PRODUCTS_PER_PAGE')*2, (int)Configuration::get('PS_PRODUCTS_PER_PAGE')*3) : array(10, 20, 50);

¿Qué hemos hecho?
Para que PS calcule la cantidad que aparecerá en las opciones de productos por página hemos hecho que coja la variable "PS_PRODUCT_PER_PAGE" (Que configuramos en el backoffice) y la multiplique por "X" en este caso 2 y 3 ya está bien, de esta forma siempre tendremos en todas las opciones una cantidad acorde y nunca tendremos huecos vacíos.

Podéis descargaros el Override desde este enlace. Descargar





martes, 1 de octubre de 2013

Overrides en Prestashop



En el post de Rich Snippets tuvimos que hacer un Override a la clase Tools.php y no expliqué en detalle en que consiste y por qué es conveniente saber hacer un Override a la hora de hacer cambios en Prestashop.

Un Override es la fórmula que nos ofrece Prestashop para sobrescribir funciones y archivos sin tener que modificar los originales, la idea es que copiamos o creamos un archivo con el mismo nombre en la carpeta indicada para su propósito y Prestashop detectará dicho archivo y lo cargará obviando las funciones originales.

Existen distintos tipos de overrides que nos pueden ayudar a flexibilizar las personalizaciones y librarnos de quebraderos de cabeza frente a nuevas actualizaciones.

Desconozco desde que versión se empezaron a utilizar los overrides, pero al menos desde la versión 1.4.2 que es con la que descubrí Prestashop ya estaban disponibles.

Los tipos de Override que podemos hacer son de Core o de Módulo

Override de Core

Podemos modificar las Clases y Controladores, que principalmente son las funciones centrales de Prestashop.

Los Overrides se realizan desde la carpeta mitienda.com/override/(classes o controllers según necesitemos)

Partiendo de la carpeta Override, hay que respetar tanto la estructura interna de cada carpeta así como los nombres de archivo originales que queramos modificar.

Ej práctico.

Para realizar un Override a la Classe original Tools.php que está en “mitienda.com/classes/”, crearemos un archivo llamado Tools.php en la carpeta “mitienda.com/override/classes/”

Dicho archivo empezará con un código concreto para dar cuenta a Prestashop de que ese archivo contiene funciones que sustituyen las originales o tendrá nuevas funciones que amplían las capacidades de Prestashop.


Class Tools (Es el nombre de nuestra nueva clase) extends ToolsCore (Es la clase a la que apunta nuestra nueva clase)
Si luego creamos funciones con el mismo nombre que las que contiene ToolsCore las de ToolsCore se desactivarán y ejecutará las nuestras, si la función no existe será una nueva funcionalidad que podremos utilizar)

Ahora podemos copiar funciones originales de Tools.php y modificarlas a nuestro antojo, o crear nuevas funciones que utilizaremos sin miedo de perder las funcionalidades después de una actualización.
Del Override del Core únicamente veo una pequeña pega, es que por ahora no podemos realizar Overrides a los java script del core, así que habrá que modificar los originales si es necesario, lo mejor es hacer una copia antes de hacer nada.

Override de Módulo

Podemos modificar el aspecto de un módulo para adecualro a nuestro tema y necesidades, además realizar un Override de módulo es muy sencillo. Tan solo hemos de copiar el archivo original en la ruta que corresponda y modificarlo a nuestro antojo.

Las rutas a usar son las siguientes.


Plantillas (tpl)

mitienda.com/themes/mi-tema/modules/nombre-modulo/nombre-archivo.tpl

JavaScript (js)

mitienda.com/themes/mi-tema/js/modules/nombre-modulo/

Css (css)

mitienda.com/themes/mi-tema/css/modules/nombre-modulo/


Hasta aquí dejo la explicación de los Overrides, si tenéis cualquier duda comentar y haré lo que esté en mí mano.

martes, 24 de septiembre de 2013

Solucionar pantalla blanca en Prestashop



A veces Prestashop se vuelve un poco loco y peta mostrando un pantallazo blanco, otras veces lo hace con toda la razón del mundo, sobre todo si hemos estado metiéndole mano a funciones, plantillas u otros maltratos que le hacemos al código de vez en cuando.

Si es porque hemos estado trasteando seguramente localizaremos rápidamente el problema, pero si surge por amor al arte es cuando nos puede desesperar un poco, sobre todo cuando lo hace a las 00:45 de la noche.

Voy a poner un par de consejos básicos que seguramente ya habréis visto en mil páginas y luego una que fue mi solución y no encontré por ningún lado.

Los pantallazos en blanco los podemos separar en diferentes casos.

Pantalla blanca en el Frontend con acceso al Backoffice: El problema estará en algún módulo instalado, en algún archivo de la raíz o tema o una mala compilación de smarty.

Pantalla blanca en el Backoffice con acceso al Frontend: Esto suele ser debido a errores de código en la carpeta del backoffice.

Pantalla blanca en Frontend y Backoffice: Errores de base de datos, de clases, de cache, de htaccess, o diferentes errores que los afecten por separado.

Creo que con esto seremos capaces de acotar el problema y solucionarlo más rápidamente.
Si nos encontramos en algún caso de estos y en la pantalla blanca no aparece ningún mensaje activaremos el modo debug manualmente.

Activar el Modo Debug de Prestashop

Lo más fácil es conectar a la FTP y descargar los archivos indicados, que editaremos en local y los subiremos de nuevo al dominio.

Para versiones inferiores a la 1.5.3 realizaremos los Pasos 1 y 2 y para versiones igual o superiores a la 1.5.3 haremos únicamente el Paso 2.

Paso 1
Buscamos el archivo www.mitienda.com/config/config.inc.php
Encontramos el siguiente código @ini_set('display_errors', 'off');
Y lo activamos, quedará así @ini_set('display_errors', 'on');

Paso 2
Ahora abrimos el archivo www.mitienda.com/config/defines.inc.php
Buscamos esto define('_PS_MODE_DEV_', false);
Y lo activamos de la siguiente forma define('_PS_MODE_DEV_', true);

Analizando errores.

Ahora si intentamos abrir la tienda nos mostrará los errores y seremos capaces de ver en qué línea está fallando. Los errores los veremos de uno en uno, así que cuando solucionemos uno y actualicemos la página no te alarmes si van apareciendo uno detrás de otro, claro está que dependerá del caso de cada uno y tendremos que realizar unas acciones u otras, aunque lo mejor será sustituir dichos archivos por una copia de seguridad, o si se trata de un módulo desinstalarlo, o eliminarlo.

Existe un caso en el que el debug no mostrará ningún error y la pantalla seguirá blanca tanto en el Backoffice como en el Frontend, esto suele ocurrir por una mala compilación de la cache o como en mi caso seguramente será por culpa del archivo class_index.php que encontraremos en la carpeta www.mitienda.com/cache/
 
Este archivo se genera automáticamente y a veces se trunca por la buenas, dejando la tienda inoperativa, si nos fijamos en la fecha del archivo veremos que será justo el momento en el que dejo de funcionar la tienda. Lo eliminamos y al actualizar la página todo funcionará correctamente.