krumo () / dpm () no funciona

8

Tengo un módulo personalizado y una plantilla para alterar la apariencia de mis formularios de envío de nodos, según estas instrucciones .

Mi módulo consta de tres funciones:

  • A hook_form_alter()que funciona bien
  • A hook_theme()que no hace nada más que devolver una matriz, incluso si ingresa otro código antes return(no estoy seguro si esto es por diseño)
  • A hook_preprocess_HOOK()que está actualmente vacío

dpm()no parece hacer nada en hook_preprocess_HOOK(), aunque krumo()en las mismas variables tipo de obras. Establece un mensaje de Drupal que se lee Array: [n] itemspero no se puede expandir ni inspeccionar en absoluto.

En mi plantilla, print_r($form);imprime la matriz de formularios como se esperaba. dpm('self-aware roomba');establece un mensaje de Drupal de "roomba autoconsciente" como se esperaba. pero dpm($form); no hace nada y no arroja ningún error.

Todo excepto mi hook_form_alter()es exactamente como aparece en el tutorial vinculado. Incluso intenté sacar todo hook_form_alter()para ver si funciona sin él; no lo hace

¿Qué podría estar causando dpm()/ krumo()fallar en silencio?

beth
fuente
está instalado el módulo Devel? dpm () proviene del módulo Devel
Mohammad Ali Akbari
Sí, Devel está instalado. dpm('self-aware roomba');no funcionaría de otra manera y krumo()no regresaría Array: [n] items, solo causaría un error fatal de PHP, lo que haría que mis registros no estén vacíos.
beth
así que por favor coloque su código en su pregunta y permítame reproducir los errores;)
Mohammad Ali Akbari
Es exactamente idéntico al código en el tutorial vinculado. Es un poco largo publicarlo todo en la ventana de preguntas. Todo el código está aquí: drupal.org/node/1092122
beth
¿en qué función (dónde) estás intentando dpm ()?
Mohammad Ali Akbari

Respuestas:

6

Me he encontrado con un problema donde dpm()y algunos otros mensajes fueron consumidos por una solicitud 404 en segundo plano.

Explicación:

Si se llama dpm()o drupal_set_message()antes de que se impriman los mensajes theme_status_messages(), podrá verlos en la misma página.

Si dpm()o drupal_set_message()se llama después theme_status_messages(), esos mensajes se retrasan $_SESSIONhasta la próxima solicitud que lo haga theme_status_messages().

Algunos tipos de solicitudes NO se activan theme_status_messages(). Por ejemplo, el envío de un formulario solo procesará el formulario y luego realizará una redirección, de modo que los mensajes permanezcan en el $_SESSION.

Además, solo se activará en las solicitudes del mismo visitante / cliente (es por eso que se guarda en la sesión, que es específica del cliente).

Sin embargo, algunas solicitudes que suceden en segundo plano se disparan theme_status_messages()y pueden consumir sus mensajes.

En mi caso, se trataba de solicitudes de imágenes faltantes, lo que resultó en páginas html 404 completas con mensajes (y obviamente no pude ver nada de esto).

Solución:

La solución fue activar la función "404 rápido".

Don Quijote
fuente
Esa es una muy buena pieza de depuración, bien hecho. Mi problema fue que tenía un archivo SVG 404ing, que no estaba cubierto en las extensiones de archivo predeterminadas. Gracias por una gran respuesta!
John McCollum
¡Grandes votos positivos para su investigación, @zhilevan! Fast 404 no me resolvió esto por alguna razón, pero esta fue definitivamente la causa, ya que arreglar los 404 instantáneamente causó que mi dpm () comenzara a aparecer.
joe_flash
1

prueba esto mi amigo

ob_start();
krumo($yourparameter);
$output = ob_get_contents();
ob_end_clean();
drupal_set_message($output);
Yusef
fuente
Esto funciona pero obtengo varias versiones del mismo mensaje de registro. Si entiendo correctamente, todo lo que está haciendo es recopilar la salida y luego renderizarla a través de un búfer php. ¿Está bien?
marblegravy
@marblegravy sí, cierto
Yusef