Verificación y problemas habituales - Drupal
El evento de prueba
En el formulario /admin/config/development/dock-ray pulsa Enviar evento de prueba. El resultado y su fecha quedan en el área de estado, y el evento debería aparecer en el panel, en la sección Errores del proyecto al que apunta el token.
Verificación mediante el registro
Como el módulo funciona como canal de logger, la prueba real es una entrada de registro normal con una severidad al menos igual a la configurada:
drush php:eval "\Drupal::logger('dock_ray_test')->error('Entrada de control DockRay');"La entrada debería llegar a DockRay como mensaje. Si no llega y el evento de prueba del formulario sí funciona, el problema es el nivel de registro, no la conexión.
Problemas habituales
El evento de prueba funciona pero los errores reales no llegan
Revisa minimum_level. Con 3 (Error) los avisos y notices se omiten a propósito. Comprueba también si el error llega al registro de Drupal: el módulo informa de lo que ve el logger, no de lo que ocurre a su lado.
He puesto un token en el formulario pero el módulo usa otro
En settings.php está $settings['dock_ray'] mientras el origen de la configuración está en Auto: entonces la clave del archivo gana para su campo. El área de estado muestra el valor que realmente rige e indica de dónde viene.
Los campos de token y clave están bloqueados
Significa que el valor viene de settings.php. Guardar el formulario en ese estado no borra nada: la Form API envía el valor predeterminado de un campo bloqueado junto con el resto. Para escribirlos en la interfaz, cambia el origen a Solo este formulario.
Faltan transacciones
Las transacciones solo se generan con traces_sample_rate mayor que cero y se cierran en kernel.terminate. Una petición que termina antes de esa fase - cortada por exit o servida por la capa de caché de páginas - no deja transacción.
Los errores de JavaScript no llegan
El recolector está desactivado por defecto y deliberadamente no entra en las páginas de administración. Si tras activarlo no llega nada, comprueba que /dock-ray/collector.js sirva realmente el archivo: en una instalación con caché agresiva o un docroot poco habitual esa suele ser la primera causa. Recuerda también el límite de 20 informes por dirección IP y hora, y que el receptor responde 202 incluso cuando rechaza uno.
Caché de configuración tras editar settings.php
Después de editar settings.php vacía la caché (drush cr). El formulario lee las sobrescrituras al construirse, así que hasta que se reconstruya el contenedor el área de estado puede mostrar el estado anterior.
El panel responde 200 pero no aparece el evento
Una respuesta 200 {"success": false} significa que la cuenta ha agotado su cupo mensual de errores. La integración no lo trata como una avería, y hace bien. El cupo se ve en el panel de la cuenta; hasta fin de mes se calcula a partir del consumo registrado, así que borrar errores no lo reinicia.
Sigue sin funcionar
Repasa la lista de comprobación de falta de datos y, si no ayuda, escríbenos. Indica el nombre del proyecto, la versión de la integración y la hora aproximada de la prueba: acorta el camino a la respuesta.