J'ai un module personnalisé et un modèle pour modifier l'apparence de mes formulaires de soumission de nœuds, à la suite de ces instructions .
Mon module comprend trois fonctions:
- Un
hook_form_alter()
qui fonctionne bien - Un
hook_theme()
qui ne fait rien d'autre que renvoyer un tableau, même si vous entrez un autre code avantreturn
(pas sûr que ce soit par conception) - A
hook_preprocess_HOOK()
qui est actuellement vide
dpm()
ne semble pas faire quoi que ce soit dans hook_preprocess_HOOK()
, bien que krumo()
sur les mêmes variables genre de travaux. Il définit un message Drupal qui lit Array: [n] items
mais ne peut pas être développé ou inspecté du tout.
Dans mon modèle, print_r($form);
imprime le tableau de formulaires comme prévu. dpm('self-aware roomba');
définit un message Drupal de "roomba conscient de soi" comme prévu. mais dpm($form)
; ne fait rien et ne lance aucune erreur.
Tout sauf mon hook_form_alter()
est exactement comme il apparaît dans le tutoriel lié. J'ai même essayé de retirer l'ensemble hook_form_alter()
pour voir si cela fonctionne sans lui; ce n'est pas le cas.
Qu'est-ce qui pourrait causer dpm()
/ krumo()
échouer silencieusement?
dpm('self-aware roomba');
ne fonctionnerait pas autrement etkrumo()
ne reviendrait pasArray: [n] items
, cela provoquerait juste une erreur PHP fatale, ce qui empêcherait mes journaux d'être vides.Réponses:
J'ai rencontré un problème où
dpm()
et certains autres messages ont été absorbés par une demande 404 en arrière-plan.Explication:
Si
dpm()
oudrupal_set_message()
est appelé avant que les messages soient imprimés avectheme_status_messages()
, alors vous pouvez les voir sur la même page.Si
dpm()
oudrupal_set_message()
est appelé aprèstheme_status_messages()
, ces messages sont retardés$_SESSION
jusqu'à la prochaine demandetheme_status_messages()
.Certains types de demandes ne se déclenchent PAS
theme_status_messages()
. Par exemple, un formulaire soumis ne fera que le traitement du formulaire, puis fera une redirection, de sorte que les messages restent dans le$_SESSION
.En outre, il ne se déclenchera que sur les demandes du même visiteur / client (c'est pourquoi il est enregistré dans la session, qui est spécifique au client).
Cependant, certaines requêtes qui se produisent en arrière-plan se déclenchent
theme_status_messages()
et peuvent gruger vos messages.Dans mon cas, il s'agissait de demandes d'images manquantes, ce qui a abouti à des pages HTML 404 à part entière AVEC des messages (et je n'ai pas pu voir tout cela, évidemment).
Solution:
La solution était d'activer la fonction "fast 404".
la source
tester cela mon ami
la source