He roto accidentalmente mi archivo .htaccess. ¿Cómo lo arreglo?

Un archivo .htaccess roto puede romper friendly URLs, redirecciones, gestión de assets estáticos o incluso el acceso al back office. PrestaShop puede regenerar sus propias reglas rewrite, pero las reglas de servidor personalizadas deben respaldarse primero.

PrestaShop escribe sus reglas generadas dentro de sus marcadores gestionados y conserva el código personalizado fuera de ese bloque. Si el archivo está muy roto, renombra el archivo actual, crea un .htaccess nuevo vacío y luego regenera las reglas de friendly URL desde el back office guardando los ajustes SEO & URLs / friendly URL. Limpia caché después.

# Temporary minimal Apache rewrite block - not a full PrestaShop .htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
</IfModule>

Ese fragmento es solo una ayuda de recuperación. Un .htaccess real de PrestaShop incluye reglas generadas de dispatcher, imágenes, assets y redirecciones para la URI base de la tienda. Si la tienda está en un subdirectorio, el RewriteBase regenerado debe coincidir con esa ruta. Si el archivo vuelve a romperse justo después de regenerarlo, busca reglas personalizadas de un tema, módulo, CDN, plugin de seguridad o panel de hosting.

Antes de regenerar, guarda el archivo roto como copia fechada para poder recuperar cualquier redirección personalizada, regla CDN o cabecera de seguridad que estuviera fuera del bloque gestionado por PrestaShop. Después de regenerar, compara la copia y restaura solo las reglas personalizadas que entiendes. Pon las redirecciones personalizadas encima o debajo del bloque generado según su propósito, pero evita editar dentro de los marcadores de PrestaShop porque el back office puede sobrescribir esa sección otra vez.

Si la regeneración falla, comprueba que Apache tenga mod_rewrite activado y que el usuario del servidor web pueda escribir en la raíz de la tienda. En Nginx, .htaccess se ignora por completo, así que la solución pertenece al bloque de servidor Nginx en lugar de a este archivo. Prueba siempre una URL de producto, URL de categoría, URL de imagen, asset CSS/JS e inicio de sesión de back office después de reparar, porque un archivo rewrite puede parecer correcto mientras una clase de URLs sigue rota.