krumo () / dpm () non funziona


8

Ho un modulo personalizzato e un modello per modificare l'aspetto dei moduli di invio del mio nodo, in queste istruzioni .

Il mio modulo è composto da tre funzioni:

  • A hook_form_alter()che funziona bene
  • A hook_theme()che non fa altro che restituire un array, anche se in precedenza è stato inserito altro codice return(non sono sicuro che questo sia di progettazione)
  • A hook_preprocess_HOOK()che è attualmente vuoto

dpm()non sembra fare nulla hook_preprocess_HOOK(), anche se krumo()sulle stesse variabili funziona in qualche modo . Imposta un messaggio Drupal che legge Array: [n] itemsma non può essere espanso o ispezionato affatto.

Nel mio modello, print_r($form);stampa l'array di moduli come previsto. dpm('self-aware roomba');imposta un messaggio Drupal di "roomba autocosciente" come previsto. ma dpm($form); non fa nulla e non genera errori.

Tutto tranne il mio hook_form_alter()è esattamente come appare nel tutorial collegato. Ho anche provato a tirare fuori l'intero hook_form_alter()per vedere se funziona senza di essa; non lo fa.

Cosa potrebbe causare dpm()/ krumo()fallire silenziosamente?


è installato il modulo Devel? dpm () proviene dal modulo Devel
Mohammad Ali Akbari

Sì, Devel è installato. dpm('self-aware roomba');non funzionerebbe diversamente e krumo()non ritornerebbe Array: [n] items, causerebbe solo un errore irreversibile di PHP, che renderebbe i miei registri non vuoti.
Bet

quindi per favore inserisci il tuo codice nella tua domanda e fammi riprodurre nuovamente gli errori;)
Mohammad Ali Akbari

È esattamente identico al codice nel tutorial collegato. È un po 'lungo pubblicare tutto nella finestra delle domande. Tutto il codice è qui: drupal.org/node/1092122
Bet

in quale funzione (dove) stai provando dpm ()?
Mohammad Ali Akbari,

Risposte:


6

Ho riscontrato un problema in cui dpm()e alcuni altri messaggi sono stati divorati da una richiesta 404 in background.

Spiegazione:

Se dpm()o drupal_set_message()viene chiamato prima che i messaggi vengano stampati theme_status_messages(), è possibile vederli nella stessa pagina.

Se dpm()o drupal_set_message()viene chiamato dopo theme_status_messages(), tali messaggi vengono ritardati $_SESSIONfino alla successiva richiesta che lo fa theme_status_messages().

Alcuni tipi di richieste NON si attivano theme_status_messages(). Ad esempio, l'invio di un modulo eseguirà solo l'elaborazione del modulo, quindi eseguirà un reindirizzamento, quindi i messaggi rimarranno nel file $_SESSION.

Inoltre, si attiverà solo su richieste dello stesso visitatore / client (ecco perché viene salvato in sessione, che è specifico del client).

Tuttavia, alcune richieste che si verificano in background si attivano theme_status_messages()e possono consumare i tuoi messaggi.

Nel mio caso si trattava di richieste di immagini mancanti, che hanno portato a messaggi HTML 404 completi con messaggi (e ovviamente non ho visto nulla di tutto ciò).

Soluzione:

La soluzione era di attivare la funzione "veloce 404".


È davvero un bel pezzo di debug, ben fatto. Il mio problema era che avevo un file SVG 404ing, che non era coperto nelle estensioni di file predefinite. Grazie per un'ottima risposta!
John McCollum,

Principali voti positivi per la tua ricerca, @zhilevan! Il 404 veloce non mi ha risolto questo problema per qualche motivo, ma questa è stata sicuramente la causa, poiché la correzione dei 404 ha causato immediatamente la visualizzazione del mio dpm ().
joe_flash,

1

prova questo amico mio

ob_start();
krumo($yourparameter);
$output = ob_get_contents();
ob_end_clean();
drupal_set_message($output);

Funziona ma ho diverse versioni dello stesso messaggio di registro. Se ho capito bene, tutto ciò che sta facendo è raccogliere insieme l'output e quindi renderizzarlo tramite un buffer php? È giusto?
Marblegravy

@marblegravy sì, giusto
Yuseferi
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.