Instalación y configuración

Comprender los Permisos de Archivos en Linux

Cada archivo y directorio en un servidor Linux tiene tres conjuntos de permisos: uno para el propietario, uno para el grupo y uno para otros (todos los demás). Cada conjunto controla tres acciones: lectura (r), escritura (w) y ejecución (x). Estos permisos se representan numéricamente usando notación octal, donde lectura equivale a 4, escritura a 2 y ejecución a 1. Los valores se suman para cada conjunto, produciendo un número de tres dígitos como 755 o 644.

Por ejemplo, un permiso de 755 significa que el propietario puede leer, escribir y ejecutar (7 = 4+2+1), mientras que el grupo y otros solo pueden leer y ejecutar (5 = 4+0+1). Un permiso de 644 significa que el propietario puede leer y escribir (6 = 4+2+0), mientras que el grupo y otros solo pueden leer (4 = 4+0+0). Comprender este sistema es fundamental para gestionar una tienda PrestaShop segura y funcional.

Más allá de los permisos numéricos, cada archivo tiene un propietario y un grupo asociado. En un servidor web, el proceso del servidor (Apache o Nginx) se ejecuta como un usuario específico, típicamente www-data en Debian/Ubuntu o apache/nobody en CentOS/RHEL. El servidor web necesita poder leer tus archivos de PrestaShop para servirlos, y necesita acceso de escritura a ciertos directorios para subidas, caché y configuración.

Permisos Correctos para Directorios y Archivos de PrestaShop

La regla general para PrestaShop es sencilla: los directorios deben tener permisos 755 y los archivos deben tener permisos 644. Esto le da al propietario control total, mientras que el grupo y otros pueden leer (y ejecutar/recorrer en el caso de directorios) pero no pueden modificar nada. El usuario del servidor web debería ser el propietario de todos los archivos de PrestaShop, o al menos pertenecer al grupo que los posee.

Para establecer estos permisos en toda tu instalación de PrestaShop, conéctate a tu servidor vía SSH y ejecuta:

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Reemplaza /var/www/html/prestashop con la ruta real de tu instalación de PrestaShop. El primer comando encuentra todos los directorios y los establece a 755. El segundo encuentra todos los archivos y los establece a 644.

Sin embargo, ciertos directorios requieren acceso de escritura por parte del servidor web. Estos directorios necesitan atención especial porque PrestaShop escribe en ellos durante la operación normal:

/var/cache/ — Plantillas compiladas de Smarty y caché de Symfony
/var/logs/ — Archivos de registro de la aplicación
/upload/ — Subidas de archivos de clientes
/download/ — Archivos de productos virtuales
/img/ — Imágenes de productos, categorías y CMS
/modules/ — Instalación y actualización de módulos
/themes/ — Archivos de caché de temas
/translations/ — Archivos de exportación de traducciones
/config/ — Archivos de configuración (parameters.php)
/app/config/ — Configuración de Symfony
/app/Resources/translations/ — Traducciones de Symfony

Si el usuario del servidor web es el propietario de estos archivos (que es la configuración recomendada), entonces los permisos 755/644 son suficientes. Si el servidor web se ejecuta como un usuario diferente, es posible que necesites ajustar los permisos del grupo o la propiedad.

Establecer la Propiedad Correcta con chown

La propiedad es tan importante como los permisos. El comando chown cambia el propietario y el grupo de los archivos. Para un servidor típico Debian/Ubuntu ejecutando Apache o Nginx, el usuario del servidor web es www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

El flag -R aplica el cambio de forma recursiva a todos los archivos y subdirectorios. En sistemas CentOS o RHEL, reemplaza www-data con apache o nginx según tu servidor web.

Un enfoque alternativo común es establecer el propietario como tu usuario SSH/FTP y el grupo como el usuario del servidor web. Esto te permite editar archivos vía FTP o SSH mientras permites que el servidor web los lea:

sudo chown -R tuusuario:www-data /var/www/html/prestashop

En este caso, los directorios que necesitan acceso de escritura por parte del servidor web deben establecerse a 775 (escritura de grupo) y los archivos escribibles a 664:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Hosting Compartido vs VPS vs Servidor Dedicado

El entorno de hosting afecta drásticamente cómo funcionan los permisos de archivos en la práctica. Comprender las diferencias es crítico para configurar los permisos correctamente.

Hosting Compartido

En hosting compartido, típicamente accedes a los archivos vía FTP o un administrador de archivos en cPanel/Plesk. El modelo de ejecución de PHP varía según el proveedor, pero la mayoría de los hostings compartidos modernos usan PHP-FPM o suPHP, lo que significa que PHP se ejecuta como tu cuenta de usuario en lugar del usuario global del servidor web. Esto simplifica significativamente los permisos: dado que PHP se ejecuta como tu usuario, ya puede leer y escribir en tus archivos con los permisos estándar 755/644. Rara vez necesitas cambiar la propiedad en hosting compartido porque todo ya pertenece a tu cuenta.

Si encuentras errores de permisos en hosting compartido, consulta con tu proveedor si usan suPHP o PHP-FPM. Si usan el modelo antiguo mod_php, es posible que necesites establecer algunos directorios a 777 temporalmente (aunque esto no es recomendable por razones de seguridad). La mayoría de los proveedores de hosting confiables han abandonado mod_php precisamente por estas complicaciones con los permisos.

VPS (Servidor Privado Virtual)

En un VPS tienes control total. Esta es la configuración más común para tiendas PrestaShop serias. Debes asegurarte de que el usuario del servidor web sea propietario de los archivos de PrestaShop o, como mínimo, pertenezca a un grupo que tenga acceso de lectura. La configuración recomendada es:

Establecer el propietario a www-data:www-data (o tu usuario del servidor web)
Usar 755 para directorios y 644 para archivos
Usar SSH con sudo para hacer cambios, o añadir tu usuario SSH al grupo www-data

Para añadir tu usuario SSH al grupo del servidor web:

sudo usermod -a -G www-data tuusuario

Luego establece el bit de escritura de grupo en los directorios que necesites editar:

chmod g+w /var/www/html/prestashop/themes/tu-tema/

Servidor Dedicado

Los servidores dedicados siguen los mismos principios que las configuraciones VPS. La diferencia principal es el rendimiento: tienes más recursos, por lo que puedes ejecutar PHP-FPM con pools dedicados por sitio. Cada pool puede ejecutarse como un usuario diferente, proporcionando mejor aislamiento si alojas múltiples tiendas PrestaShop en el mismo servidor.

Modelos de Ejecución PHP: suPHP vs mod_php vs PHP-FPM

La forma en que PHP se ejecuta en tu servidor determina directamente qué usuario escribe los archivos y, por lo tanto, qué permisos se necesitan.

mod_php (módulo Apache)

Este es el modelo más antiguo y simple. PHP se ejecuta como parte del proceso Apache, lo que significa que todo el código PHP se ejecuta como el usuario Apache (típicamente www-data o apache). El problema es que los archivos creados por PHP (caché, subidas, etc.) son propiedad del usuario del servidor web, no de tu cuenta. Esto puede dificultar la gestión por FTP y crea problemas de seguridad en hostings compartidos porque todos los sitios se ejecutan como el mismo usuario.

Con mod_php, los archivos de PrestaShop deben ser propiedad del usuario Apache, y los permisos 755/644 funcionan correctamente. Sin embargo, este modelo está en gran parte obsoleto en servidores modernos.

suPHP

suPHP ejecuta PHP como el propietario del archivo en lugar del usuario del servidor web. Esto significa que si tus archivos son propiedad de tuusuario, PHP también se ejecuta como tuusuario. Esto es más seguro en hosting compartido porque cada cuenta está aislada. Los permisos estándar 755/644 funcionan perfectamente con suPHP porque el proceso PHP y el propietario del archivo son el mismo usuario.

Una advertencia importante: suPHP en realidad rechaza los archivos con permisos 777 o archivos propiedad de otros usuarios. Si estableces 777 en un servidor suPHP, PHP se negará a ejecutar esos archivos, mostrando un error 500 Internal Server Error en su lugar.

PHP-FPM (FastCGI Process Manager)

PHP-FPM es el estándar moderno. Ejecuta PHP como un proceso separado del servidor web, con usuario/grupo configurable por pool. En un VPS, PHP-FPM típicamente se ejecuta como www-data. En hosting compartido con CloudLinux o similar, cada cuenta obtiene su propio pool PHP-FPM ejecutándose como el usuario de esa cuenta.

PHP-FPM combinado con Nginx es la configuración recomendada para el rendimiento de PrestaShop. El esquema de permisos estándar 755/644 funciona bien. Asegúrate de que el usuario del pool PHP-FPM coincida con el propietario del archivo o tenga el acceso apropiado a través del grupo.

Por Qué los Permisos 777 Son Peligrosos

Establecer los permisos a 777 significa que cualquier persona en el sistema puede leer, escribir y ejecutar el archivo. En hosting compartido, esto significa que otras cuentas en el mismo servidor podrían potencialmente leer las credenciales de tu base de datos desde parameters.php o inyectar código malicioso en tus archivos PHP.

Incluso en un VPS donde eres el único usuario, 777 es innecesario e indica una configuración incorrecta. Si el servidor web no puede escribir en un directorio con permisos 755, la solución es corregir la propiedad, no abrir los permisos a todos. Esto es lo que deberías hacer en lugar de usar 777:

Verifica qué usuario ejecuta el servidor web: ps aux | grep -E "apache|nginx|httpd"
Verifica la propiedad de los archivos: ls -la /var/www/html/prestashop/
Corrige la propiedad: sudo chown -R www-data:www-data /ruta/al/directorio
Establece los permisos correctos: chmod 755 /ruta/al/directorio

Si encuentras un tutorial o post en un foro recomendando 777 para PrestaShop, es un consejo obsoleto y peligroso. El único uso legítimo de 777 es para directorios /tmp que tienen el bit sticky establecido (mostrado como 1777), que es una configuración a nivel de sistema, no algo que se aplique a los archivos de PrestaShop.

Consideraciones de Docker para PrestaShop

Ejecutar PrestaShop en Docker introduce complejidad adicional a los permisos de archivos. Dentro del contenedor, el servidor web se ejecuta como www-data con un UID específico (frecuentemente 33 en imágenes basadas en Debian). En el sistema host, tu usuario tiene un UID diferente. Cuando usas bind mounts de Docker para montar tus archivos de PrestaShop en el contenedor, la propiedad de los archivos se determina por el UID numérico, no por el nombre de usuario.

Esto significa que los archivos creados en el host como tu usuario (por ejemplo, UID 1000) aparecerán dentro del contenedor como UID 1000, que no es www-data (UID 33). El servidor web dentro del contenedor puede no ser capaz de escribir en estos archivos.

Las soluciones para los problemas de permisos en Docker incluyen:

Coincidencia de UIDs: Crea un usuario dentro del contenedor con el mismo UID que tu usuario del host, o cambia el servidor web para ejecutarse con tu UID.
Usar chown en el entrypoint: Añade un comando de inicio que ejecute chown -R www-data:www-data /var/www/html cuando el contenedor arranca. Esto es simple pero puede ser lento para instalaciones grandes.
Establecer permisos de grupo: Añade tu usuario del host y www-data al mismo grupo (por GID), luego usa permisos 775/664.
Volúmenes nombrados: Usa volúmenes nombrados de Docker en lugar de bind mounts. Docker gestiona los permisos automáticamente, pero pierdes el acceso directo al sistema de archivos desde el host.

Para entornos de desarrollo con bind mounts, el enfoque más práctico es ejecutar un comando chown después de sincronizar o desplegar archivos:

docker exec tu-contenedor chown -R www-data:www-data /var/www/html/modules/tu-modulo/

Ten en cuenta que las operaciones dentro del contenedor (como instalar un módulo) pueden crear archivos como www-data, mientras que las operaciones en el host crean archivos como tu usuario del host. Esta discrepancia constante de UID es la fuente más común de problemas de permisos en configuraciones PrestaShop dockerizadas.

Resolución de Errores de Permisos Comunes

"Failed to open stream: Permission denied"

Este error significa que PHP no puede leer o escribir un archivo. Verifica la propiedad y los permisos del archivo mencionado en el error. La causa más común es que el usuario del servidor web no es propietario del archivo o directorio. Corrígelo con:

sudo chown www-data:www-data /ruta/al/archivo
sudo chmod 644 /ruta/al/archivo

"Unable to write to cache directory"

El motor de plantillas Smarty de PrestaShop y el framework Symfony escriben archivos de caché. Si el directorio var/cache/ no es escribible, verás este error. El directorio de caché debe ser propiedad del usuario del servidor web:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

Después de corregir los permisos, vacía la caché existente eliminando el contenido de los directorios de caché:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" o "Cannot install module"

Las subidas de imágenes van al directorio img/, y las instalaciones de módulos escriben en el directorio modules/. Ambos deben ser escribibles por el usuario del servidor web. Además, verifica que las configuraciones PHP upload_max_filesize y post_max_size sean lo suficientemente grandes para tus archivos, ya que estas pueden producir errores de apariencia similar.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" durante las actualizaciones

El actualizador automático de PrestaShop necesita acceso de escritura a casi todos los archivos de la instalación. Antes de ejecutar una actualización, establece la propiedad de toda la instalación al usuario del servidor web. Después de completar la actualización, puedes restaurar una propiedad más restrictiva si lo deseas.

Página en blanco después de cambiar los permisos

Si ves una página en blanco después de cambiar los permisos, es posible que hayas eliminado accidentalmente el permiso de ejecución de los directorios. Los directorios necesitan el bit de ejecución para ser recorridos. Un directorio con permiso 644 (sin ejecución) es efectivamente inaccesible. Usa siempre 755 para directorios, nunca 644.

También puedes consultar el registro de errores de PHP para más detalles:

sudo tail -50 /var/log/apache2/error.log
# o para Nginx:
sudo tail -50 /var/log/nginx/error.log

Los permisos se restablecen después de la subida FTP

Algunos clientes FTP establecen sus propios permisos predeterminados al subir archivos. Verifica la configuración de tu cliente FTP buscando una opción de "permisos predeterminados" o "umask". Configúralo para crear archivos como 644 y directorios como 755. Alternativamente, ejecuta los comandos de corrección de permisos después de cada subida FTP.

Mejores Prácticas de Seguridad Más Allá de los Permisos

Los permisos de archivos correctos son solo una capa de seguridad. Considera estas medidas adicionales:

Restringe el acceso a los archivos de configuración: El archivo app/config/parameters.php contiene las credenciales de tu base de datos. Asegúrate de que solo sea legible por el usuario del servidor web (permiso 640), no por todos.
Desactiva el listado de directorios: Añade Options -Indexes a tu configuración de Apache o autoindex off; a Nginx para evitar que los visitantes naveguen por el contenido de los directorios.
Protege los archivos .htaccess: PrestaShop coloca archivos .htaccess en directorios sensibles. No los elimines.
Elimina el directorio de instalación: Después de la instalación, elimina completamente el directorio /install/. PrestaShop te advierte sobre esto, pero vale la pena enfatizarlo.
Establece el umask correcto: Configura tu servidor web y PHP-FPM con un umask de 0022 para que los nuevos archivos se creen con permisos 644/755 por defecto.

Al comprender los permisos de Linux, adaptarlos a tu entorno de hosting y seguir las directrices de este artículo, evitarás los problemas de permisos más comunes de PrestaShop manteniendo una configuración de servidor segura.

Leer respuesta completa

Cuando las actualizaciones de módulos salen mal

Actualizaste un módulo PrestaShop y ahora algo está roto. Quizás el checkout dejó de funcionar, la página principal muestra errores, o el panel de administración dejó de responder. Las actualizaciones de módulos pueden fallar por muchas razones - versiones PHP incompatibles, conflictos con otros módulos, errores de migración de base de datos, o simplemente bugs en la nueva versión. Cualquiera sea la causa, necesitas revertir rápidamente para restaurar la funcionalidad de tu tienda.

Desafortunadamente, PrestaShop no incluye un botón "deshacer" integrado para actualizaciones de módulos. No hay historial de versiones nativo ni mecanismo de rollback automático para módulos individuales.

Antes de comenzar - Seguridad primero

Pon tu tienda en modo mantenimiento
Crea un respaldo de la base de datos
Documenta el error actual

Método 1 - Reinstalar la versión anterior desde el Back Office

Navega a Módulos > Gestor de módulos
Encuentra el módulo problemático y haz clic en Desinstalar (NO "Eliminar")
Haz clic en Subir un módulo
Sube el ZIP de la versión anterior funcional
Instala y configura el módulo

Dónde obtener la versión anterior

Tu email - La mayoría de vendedores envían enlaces de descarga con cada compra
Cuenta del marketplace - En PrestaShop Addons y marketplaces de terceros como mypresta.rocks, puedes descargar versiones anteriores del historial de pedidos
Tus respaldos - Extrae la carpeta del módulo de un archivo de respaldo
Contacta al desarrollador - Los desarrolladores pueden proporcionar versiones anteriores

Método 2 - Reemplazo de archivos vía FTP/SFTP

Conéctate al servidor vía FTP/SFTP
Navega a /modules/
Encuentra la carpeta del módulo
Renombra la carpeta actual - ej. mymodule a mymodule_roto
Sube los archivos de la versión anterior
Establece permisos correctos - directorios a 755, archivos a 644
Limpia la caché de PrestaShop

Método 3 - Desde la línea de comandos

# Conectar por SSH
ssh user@tuservidor.com

# Navegar a la raíz de PrestaShop
cd /var/www/html/prestashop

# Respaldar el módulo roto
mv modules/mymodule modules/mymodule_roto_$(date +%Y%m%d)

# Extraer la versión anterior
unzip /ruta/a/mymodule_v1.2.3.zip -d modules/

# Establecer permisos correctos
find modules/mymodule -type d -exec chmod 755 {} \;
find modules/mymodule -type f -exec chmod 644 {} \;
chown -R www-data:www-data modules/mymodule

# Limpiar caché
rm -rf var/cache/prod/* var/cache/dev/*

Método 4 - Rollback completo de base de datos

Si la actualización del módulo incluía migraciones de base de datos, necesitarás restaurar un respaldo anterior.

Cuándo necesitas un rollback de base de datos

El módulo creó nuevas tablas
El módulo alteró estructuras de tablas existentes
El módulo insertó o modificó valores de configuración

Método 5 - Limpieza manual de la base de datos

// Busca archivos como:
// modules/mymodule/upgrade/upgrade-2.0.0.php

public function upgrade($version)
{
    if (version_compare($version, '2.0.0', '<')) {
        Db::getInstance()->execute('ALTER TABLE `' . _DB_PREFIX_ . 'mymodule` 
            ADD COLUMN `new_field` VARCHAR(255)');
    }
}

Después del downgrade - Limpieza esencial

Caché Smarty
OPcache - Reiniciar PHP-FPM o Apache
Caché CDN
Caché del navegador - Probar en ventana privada

Verificar la versión del módulo

Después del downgrade, verifica que PrestaShop reconozca la versión correcta.

Probar exhaustivamente

La funcionalidad específica del módulo
El proceso de checkout de inicio a fin
Las páginas admin donde el módulo agrega contenido
Vistas móvil y escritorio
Rendimiento

Prevenir futuros problemas de actualización

Siempre respaldar antes de actualizar
Probar actualizaciones en un entorno de staging
Leer el changelog
Conservar versiones anteriores
Verificar compatibilidad

Cuándo contactar al desarrollador del módulo

Si ninguno de los métodos anteriores resuelve el problema, contacta al desarrollador con tu versión de PrestaShop, versión de PHP, versiones del módulo y mensajes de error exactos.

Leer respuesta completa

Cómo probar un módulo PrestaShop en staging antes de instalarlo en producción

Instalar un módulo no probado en una tienda PrestaShop en producción es una de las causas más comunes de tiempo de inactividad, flujos de pago rotos y pérdida de ingresos. Un entorno de staging te proporciona un sandbox seguro para validar cada módulo antes de que toque tu tienda de producción. Esta guía te lleva a través del proceso completo - desde la creación de una copia staging de tu tienda hasta las pruebas exhaustivas del módulo y el despliegue seguro en producción.

Por qué necesitas un entorno de staging

Un entorno de staging es una copia exacta de tu tienda en vivo que no es accesible al público. Refleja tu base de datos de producción, archivos, tema, configuración y módulos instalados. Probar en staging te permite detectar problemas que de otro modo afectarían a tus clientes.

Esto es lo que puede salir mal cuando te saltas el staging:

Conflictos de módulos - El nuevo módulo puede entrar en conflicto con un módulo existente, causando pantallas en blanco, errores JavaScript o funcionalidad rota en páginas específicas.
Incompatibilidad de tema - Las plantillas del módulo pueden no renderizarse correctamente con tu tema, especialmente si usas un tema personalizado o muy modificado.
Degradación del rendimiento - Algunos módulos añaden consultas pesadas a la base de datos, archivos CSS/JS adicionales o llamadas API externas que ralentizan los tiempos de carga.
Corrupción de la base de datos - Los módulos mal escritos pueden modificar tablas principales, añadir columnas sin gestión de migración adecuada, o crear triggers que interfieren con los datos existentes.
Interrupción de pagos - Si un módulo rompe el proceso de checkout o interfiere con tu pasarela de pago, pierdes ventas desde el momento de la instalación hasta que descubres y solucionas el problema.

Opción 1 - Configuración manual del staging (subdominio)

Este es el enfoque más común y funciona con cualquier proveedor de hosting. Creas un subdominio como staging.tutienda.com y copias allí tus archivos y base de datos de producción.

Paso 1 - Crear el subdominio

En tu panel de control de hosting (cPanel, Plesk o DirectAdmin), crea un nuevo subdominio. Apúntalo a un nuevo directorio.

Paso 2 - Copiar archivos de producción

# Vía SSH (método más rápido)
cp -r /home/tuusuario/public_html/* /home/tuusuario/staging.tutienda.com/

# O crea primero un archivo comprimido
cd /home/tuusuario/public_html
tar czf /tmp/prestashop-backup.tar.gz --exclude='var/cache' --exclude='var/logs' .
cd /home/tuusuario/staging.tutienda.com
tar xzf /tmp/prestashop-backup.tar.gz

Paso 3 - Exportar e importar la base de datos

# Exportar la base de datos de producción
mysqldump -u dbuser -p production_db > /tmp/production_dump.sql

# Crear la base de datos staging
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p -e "GRANT ALL ON staging_db.* TO 'dbuser'@'localhost';"

# Importar en staging
mysql -u dbuser -p staging_db < /tmp/production_dump.sql

Paso 4 - Actualizar la configuración de PrestaShop

# Editar app/config/parameters.php (PrestaShop 1.7+/8.x)
'database_name' => 'staging_db',

# Actualizar la URL de la tienda en la base de datos
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url 
  SET domain = 'staging.tutienda.com', 
      domain_ssl = 'staging.tutienda.com' 
  WHERE id_shop_url = 1;"

mysql -u dbuser -p staging_db -e "
  UPDATE ps_configuration 
  SET value = 'staging.tutienda.com' 
  WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');"

Paso 5 - Limpiar cachés

rm -rf var/cache/prod/* var/cache/dev/*
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

Paso 6 - Restringir acceso

AuthType Basic
AuthName "Acceso Staging"
AuthUserFile /home/tuusuario/.htpasswd
Require valid-user

Header set X-Robots-Tag "noindex, nofollow"

Opción 2 - Staging basado en Docker (Recomendado para desarrolladores)

Docker proporciona el entorno de staging más fiable porque puedes replicar exactamente tu versión PHP de producción, versión MySQL y configuración del servidor.

# docker-compose.yml
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.1
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=prestashop
      - DB_PASSWD=tu_contrasena
    depends_on:
      - db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=contrasena_root
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=tu_contrasena
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data:

Lista de verificación de pruebas para nuevos módulos

Fase 1 - Verificaciones pre-instalación

Leer la documentación del módulo - Comprende qué hace el módulo, qué hooks usa y cuáles son sus requisitos.
Verificar el contenido de los archivos - Antes de instalar, descomprime el módulo y revisa el código.
Crear una copia de seguridad de la base de datos - Incluso en staging, haz un backup antes de instalar.

Fase 2 - Pruebas de instalación

Instalar el módulo a través del Back Office (Módulos > Gestor de módulos > Subir un módulo).
Verificar errores de instalación - Después de la instalación, comprueba que el módulo aparece en la lista.
Verificar cambios en la base de datos - Compara las tablas antes y después de la instalación.

Fase 3 - Pruebas funcionales

Página de configuración - ¿Puedes acceder y guardar todas las configuraciones sin errores?
Visualización front office - ¿El módulo se muestra correctamente en todas las páginas relevantes?
Responsividad móvil - Prueba en viewports móviles.
Soporte multilingüe - Si tu tienda usa varios idiomas, verifica la visualización correcta en cada uno.
Compatibilidad multitienda - Si usas la función multitienda, prueba el comportamiento en diferentes tiendas.

Fase 4 - Pruebas de conflictos

Verificar la consola del navegador - Abre las herramientas de desarrollo (F12) y busca errores JavaScript.
Probar el proceso de checkout - Añade un producto al carrito, recorre cada paso y completa un pedido de prueba.
Probar el procesamiento de pagos - Realiza pedidos de prueba con cada método de pago.
Verificar la funcionalidad de módulos existentes - Asegúrate de que los módulos críticos siguen funcionando.

Fase 5 - Pruebas de rendimiento

# Antes de instalar el módulo, medir la línea base
curl -o /dev/null -s -w "Tiempo: %{time_total}s\n" https://staging.tutienda.com/

# Después de la instalación, medir de nuevo y comparar
curl -o /dev/null -s -w "Tiempo: %{time_total}s\n" https://staging.tutienda.com/

Un módulo bien escrito debería añadir menos de 100ms a los tiempos de carga. Si ves un aumento de 500ms o más, investiga las consultas a la base de datos y la carga de assets del módulo.

Fase 6 - Prueba de desinstalación

Desinstala el módulo desde el Back Office
Verifica que todas las tablas específicas del módulo se eliminan
Comprueba que no quedan hooks, archivos CSS o JavaScript huérfanos
Verifica que el front office vuelve a su estado pre-módulo

Mover un módulo probado a producción

Paso 1 - Planificar el despliegue

Elige un período de bajo tráfico. Consulta tu Google Analytics para identificar cuándo tu tienda tiene menos visitantes.

Paso 2 - Crear una copia de seguridad de producción

mysqldump -u dbuser -p production_db > /tmp/production_backup_$(date +%Y%m%d_%H%M%S).sql

Paso 3 - Instalar en producción

Sube exactamente el mismo archivo ZIP del módulo que probaste en staging. No descargues una nueva versión.

Paso 4 - Aplicar la misma configuración

Configura el módulo con exactamente las mismas configuraciones que en staging.

Paso 5 - Monitorear durante 24-48 horas

Después del despliegue, monitorea activamente los logs de errores PHP, Google Analytics y la tasa de conversión de pedidos.

Trampas comunes del staging a evitar

Olvidar actualizar las URLs - Si copias la base de datos pero olvidas actualizar ps_shop_url, tu sitio staging redirigirá a producción.
Pasarelas de pago en modo live - Siempre cambia las pasarelas de pago a modo sandbox/test en staging.
Notificaciones por email enviadas a clientes - Desactiva el envío de emails en staging o redirige todos los emails a una dirección de prueba.
Indexación por motores de búsqueda - Siempre bloquea el staging para los motores de búsqueda.
Trabajos cron ejecutándose en staging - Desactiva todos los trabajos cron copiados de producción.

Leer respuesta completa

Cookie	Proveedor	Finalidad	Duración
PrestaShop-*	PrestaShop	Gestión de sesión y funcionalidad del carrito	Sesión
PHPSESSID	PHP	Identificador de sesión PHP	Sesión
mprcr_consent	MPR Cookies Revolution	Almacena las preferencias de consentimiento de cookies	365 día(s)
mprcr_version	MPR Cookies Revolution	Rastrea la version de la configuración del consentimiento	365 día(s)

Cookie	Proveedor	Finalidad	Duración
TawkConnectionTime	Tawk.to	Rastreo del tiempo de conexion de la sesion de chat	Sesión
__tawkuuid	Tawk.to	Identifica a los visitantes recurrentes del chat	6 mes(es)

Cookie	Proveedor	Finalidad	Duración
_ga	Google Analytics	Distingue usuarios únicos asignando un número generado aleatoriamente	2 año(s)
_ga_*	Google Analytics	Utilizado para mantener el estado de la sesión entre solicitudes de página	2 año(s)
_gid	Google Analytics	Distingue usuarios únicos durante 24 horas	24 hora(s)

Instalación y configuración

Comprender los Permisos de Archivos en Linux

Permisos Correctos para Directorios y Archivos de PrestaShop

Establecer la Propiedad Correcta con chown

Hosting Compartido vs VPS vs Servidor Dedicado

Hosting Compartido

VPS (Servidor Privado Virtual)

Servidor Dedicado

Modelos de Ejecución PHP: suPHP vs mod_php vs PHP-FPM

mod_php (módulo Apache)

suPHP

PHP-FPM (FastCGI Process Manager)

Por Qué los Permisos 777 Son Peligrosos

Consideraciones de Docker para PrestaShop

Resolución de Errores de Permisos Comunes

"Failed to open stream: Permission denied"

"Unable to write to cache directory"

"Cannot upload image" o "Cannot install module"

"index.php is not writable" durante las actualizaciones

Página en blanco después de cambiar los permisos

Los permisos se restablecen después de la subida FTP

Mejores Prácticas de Seguridad Más Allá de los Permisos

Cuando las actualizaciones de módulos salen mal

Antes de comenzar - Seguridad primero

Método 1 - Reinstalar la versión anterior desde el Back Office

Dónde obtener la versión anterior

Método 2 - Reemplazo de archivos vía FTP/SFTP

Método 3 - Desde la línea de comandos

Método 4 - Rollback completo de base de datos

Cuándo necesitas un rollback de base de datos

Método 5 - Limpieza manual de la base de datos

Después del downgrade - Limpieza esencial

Verificar la versión del módulo

Probar exhaustivamente

Prevenir futuros problemas de actualización

Cuándo contactar al desarrollador del módulo

Cómo probar un módulo PrestaShop en staging antes de instalarlo en producción

Por qué necesitas un entorno de staging

Opción 1 - Configuración manual del staging (subdominio)

Paso 1 - Crear el subdominio

Paso 2 - Copiar archivos de producción

Paso 3 - Exportar e importar la base de datos

Paso 4 - Actualizar la configuración de PrestaShop

Paso 5 - Limpiar cachés

Paso 6 - Restringir acceso

Opción 2 - Staging basado en Docker (Recomendado para desarrolladores)

Lista de verificación de pruebas para nuevos módulos

Fase 1 - Verificaciones pre-instalación

Fase 2 - Pruebas de instalación

Fase 3 - Pruebas funcionales

Fase 4 - Pruebas de conflictos

Fase 5 - Pruebas de rendimiento

Fase 6 - Prueba de desinstalación

Mover un módulo probado a producción

Paso 1 - Planificar el despliegue

Paso 2 - Crear una copia de seguridad de producción

Paso 3 - Instalar en producción

Paso 4 - Aplicar la misma configuración

Paso 5 - Monitorear durante 24-48 horas

Trampas comunes del staging a evitar

Otras categorías

¿Aún tiene preguntas?