# Incidente: Newsletter y formulario de contacto (demo-business-consulting)

## Resumen

En el demo `demo-business-consulting`, el newsletter y algunos formularios de contacto no funcionaban correctamente por una combinación de incompatibilidades entre frontend legacy (Porto) y backend Laravel actual.

## Sintomas observados

- Newsletter: `POST /newsletter-subscribe` devolviendo `419` en produccion (`CSRF token mismatch`).
- Contacto: validaciones fallidas al enviar desde bloques de contacto embebidos (home/about).
- Respuestas AJAX no interpretadas por scripts legacy (esperaban formato distinto).

## Causas raiz

### 1) CSRF en newsletter (error 419)

- El submit AJAX del newsletter no enviaba token CSRF de forma consistente.
- En produccion, el middleware `VerifyCsrfToken` rechazo la peticion.

### 2) Incompatibilidad de payload entre frontend y backend

- JS legacy del tema enviaba `email`.
- El controlador Laravel validaba `newsletterEmail`.
- Habia mismatch de nombres de campo.

### 3) Incompatibilidad de formato de respuesta

- JS legacy esperaba `response: "success"`.
- Backend devolvia principalmente `success: true/false`.

### 4) Validacion estricta en contacto para bloques simplificados

- `contactStore` exigia `phone` y `subject`.
- Formularios de `welcome` y `about` del demo enviaban solo `name`, `email`, `message`.

## Cambios aplicados

## Backend

- `app/Modules/CdBase/Newsletter/Controllers/Frontend/NewsletterController.php`
  - Acepta `newsletterEmail` y tambien `email` (compatibilidad).
  - Normaliza input y mantiene validacion de email unico.
  - Devuelve `response: "success" | "error"` ademas de `success`.

- `app/Modules/CdBase/Controllers/Frontend/HomepageController.php`
  - `phone` y `subject` pasan a `nullable`.
  - Si no llega `subject`, usa valor por defecto.
  - Respuesta JSON incluye `response: "success"` para compatibilidad con scripts legacy.

## Frontend

- `public/template/js/theme.js`
  - Newsletter AJAX ahora envia:
    - `newsletterEmail`
    - `email` (compat legacy)
    - `_token`
  - Manejo de error AJAX con mensaje visible en `#newsletterError`.

- `resources/views/layout/front/partials/_scripts.blade.php`
  - Se agrego `$.ajaxSetup(...)` global para enviar:
    - `X-CSRF-TOKEN` (desde `<meta name="csrf-token">`)
    - `X-Requested-With: XMLHttpRequest`

## Por que funcionaba local y no en produccion

Factores frecuentes (y observados en este caso):

- Menor severidad de cache y sesion en local.
- Diferencias de cookies/sesion bajo HTTPS, dominio y proxy en produccion.
- Assets o scripts cacheados en produccion sin cambios recientes.

## Verificacion recomendada en produccion

1. Limpiar cache de Laravel:
   - `php artisan optimize:clear`
2. Purgar cache de CDN/proxy y hacer hard refresh del navegador.
3. En DevTools (Network), validar en `POST /newsletter-subscribe`:
   - Header `X-CSRF-TOKEN` presente.
   - Cookie de sesion presente.
   - Payload con `newsletterEmail`.
4. Verificar respuestas esperadas:
   - `200` suscripcion correcta.
   - `422` email duplicado o invalido.
   - No deberia aparecer `419`.

## Lecciones y estandarizacion

- Unificar contratos frontend/backend para formularios (`field names` y `response schema`).
- Evitar depender solo de scripts legacy de tema para formularios criticos.
- Mantener compatibilidad temporal cuando hay demos con implementaciones heterogeneas.
- Incluir prueba manual de CSRF y formularios en checklist de deploy.