# Implementación de Logging Dinámico por Entorno

## Resumen de cambios

Se ha implementado un sistema de logging **eficiente y escalable** que:
- ✅ Solo registra errores y situaciones anómalas
- ✅ Se adapta automáticamente según el entorno (desarrollo/producción)
- ✅ Minimiza uso de cuota de API y almacenamiento
- ✅ Proporciona información accionable para debugging

## Archivos modificados

### 1. `src/Debug/Debug.php`
- ✅ Convertido el endpoint estático a dinámico mediante el método `getEndpoint()`
- ✅ Detección automática del entorno basada en `$_SERVER['HTTP_HOST']`
- ✅ Endpoint de desarrollo: `http://zoddak-beta.test/api/wp_log/create_log`
- ✅ Endpoint de producción: `https://app.zoddak.com/api/wp_log/create_log`

### 2. `controllers/ApiController.php`
Logging solo en errores:

#### `validateApiToken()`
- ❌ Log de error si falla la conexión a API

#### `get_areas()`
- ❌ Log de error si falla la conexión

#### `get_property_stage()`
- ❌ Log de error si falla la conexión a API

### 3. `controllers/PropertiesController.php`
Logging solo en situaciones de fallo:

#### `renderPropertiesPage()`
- ❌ Log si falla la conexión a API
- ❌ Log si la respuesta JSON es inválida

#### `renderPropertyDetail()`
- ❌ Log si falla la obtención de detalles de propiedad

#### `getPropertiesStage()`
- ❌ Log si falla al obtener etapa individual (sin detener flujo)

### 4. `src/Front/StatsAjax.php`
- ❌ Log solo si falla el envío de estadísticas

### 5. `new-devs.v2.php`
- Movido `Debug.php` al inicio de las inclusiones
- Garantiza que la clase esté disponible antes de otros controladores

## Funcionalidad de detección de entorno

La clase `Debug` utiliza la variable `$_SERVER['HTTP_HOST']` para detectar automáticamente el entorno:

```
Si HTTP_HOST contiene 'wordpress.local' o 'localhost':
  → Usa endpoint: http://zoddak-beta.test/api/wp_log/create_log

Si no coincide:
  → Usa endpoint: https://app.zoddak.com/api/wp_log/create_log
```

## Política de logging

- ✅ Solo se registran **ERRORES** cuando ocurren
- ❌ No se registran operaciones exitosas
- ❌ No se loguea en cada llamada API exitosa
- ❌ No se genera ruido innecesario

## Contextos registrados en errores

Cada log de error incluye:
- `timestamp`: Hora del evento
- `level`: Nivel de severidad (ERROR/WARNING)
- `message`: Descripción del error
- `context`: Datos contextuales:
  - `error`: Mensaje de error específico
  - `url`: URL de la API llamada
  - `reference`: ID de propiedad (si aplica)
  - `event`: Tipo de evento (para stats)
  - `page`: Número de página (para listados)
- `site_url`: URL del sitio
- `request_uri`: URI de la solicitud actual
- `user_agent`: Navegador/cliente
- `ip`: IP del cliente

## Puntos de falla monitoreados

✅ Error de conexión en validación de token API
✅ Error de conexión al obtener áreas/zonas
✅ Error de conexión al obtener etapas de propiedades
✅ Error de conexión al obtener lista de propiedades (con página)
✅ Error al obtener detalles de propiedad (con referencia)
✅ Error al obtener etapas por propiedad individual
✅ Error al enviar estadísticas (con evento y URL)

## Ventajas de esta implementación

✅ **Escalable**: Solo genera logs cuando hay problemas reales
✅ **Eficiente**: No quema cuota de API con eventos innecesarios
✅ **Práctico**: Logs contienen contexto necesario para debugging
✅ **Seguro**: No expone datos sensibles completos
✅ **Dinámico**: Funciona automáticamente en dev y prod

## Próximos pasos recomendados

1. Verificar que el endpoint `wp_log/create_log` existe en ambos entornos
2. Configurar rotación de logs en el servidor
3. Crear alertas para errores frecuentes (mismo error 5+ veces por hora)
4. Monitorear patrones: conexiones rechazadas, timeouts, JSON inválido
