dpm () non visualizza alcun risultato sullo schermo

Ho lo stesso problema di file_scan_directory () richiede circa 10 secondi per essere eseguito . Ho appena provato il dpm(func_get_args())suggerimento e sfortunatamente non mi mostra nulla.

Ho cancellato tutte le cache ed eseguito le attività cron. Cosa mi sto perdendo?

Assicurati di avere print $messages;nel tuo page.tpl.phpfile modello. Per impostazione predefinita, devel (dpm) è configurato per stampare il suo contenuto nell'area dei messaggi del sito. Quindi, se il tuo modello per qualche motivo non visualizza il contenuto di $messages, non vedrai nulla.

1. A volte krumo($variable)potrebbe funzionare quando dpm($variable)non lo fa.

2. A volte print dpm($variable)potrebbe funzionare quando dpm($variable)non lo fa.

3. 2. potrebbe anche essere la soluzione quando non c'è più print $messagesnel tuo page.tpl.php. Forse puoi aggiungerlo di nuovo.

Devi aver effettuato l'accesso al sito Drupal, con le autorizzazioni corrette per accedere a Develop. Accedi come admin dovrebbe farlo.

Consiglio vivamente devel_debug_log . Richiede il modulo devel e ti dà la funzione ddl (). ddl aggiunge una pagina ai rapporti nella configurazione, quindi è simile alla stampa su watchdog, ma hai una bella pagina pulita in cui puoi inviare i tuoi messaggi di debug e non preoccuparti delle condizioni del tipo di gara in cui i tuoi messaggi potrebbero essere cancellati prima di un'occasione per vederli - o, come nel tuo caso, problemi a tema.

(Questo è anche uno strumento ESTREMAMENTE utile se stai cercando di creare qualsiasi tipo di API, poiché tutte quelle richieste non ti mostrerebbero mai alcun tipo di messaggi dpm ().)

Assicurarsi di aver abilitato e installato il modulo Devel come dpm()è una funzione dichiarata in questo modulo.

dpm()descrizione presa da qui .

Stampa una variabile nell'area 'message' della pagina usando drupal_set_message (). È possibile utilizzare questa funzione per tenere traccia di una o più variabili quando si lavora sul codice che esegue il sito. Poiché il modulo Devel ora viene fornito con Krumo, l'output è compatto e discreto.

dpm($input, $name = NULL)

Se, per qualche motivo, non stai usando Krumo, puoi usare il parametro $ name per distinguere tra diverse chiamate a dpm ().

Dopo aver scaricato e abilitato Develop, provare a rispondere da file_scan_directory () impiega circa 10 secondi per eseguire nuovamente e dovrebbe funzionare.

Se vuoi stamparlo dall'interno di una funzione senza toccare (o avere) un file modello, prova questo:

$nid = 3;
$node = node_load($nid);
dpm($node);
print theme('status_messages'); 

Questo a volte è il risultato di una risorsa nella pagina che restituisce un 404.

Drupal esegue il rendering della pagina 404 e in questo modo recupera (e cancella) i messaggi dalla sessione e li inserisce nella pagina 404 che non vedi. Quindi quando la pagina principale recupera i messaggi non ne rimane più nessuno.

È possibile aprire la scheda di rete e verificare se le risorse hanno uno stato 404.

Una soluzione semplice qui è abilitare il 404 veloce decommentando questa riga in settings.php:

# drupal_fast_404();

Un'altra buona soluzione qui è usare devel_debug_log come suggerito da SlakeFistcrunch.

A volte il messaggio può essere tagliato o non funziona in caso di AJAX.

Il metodo più affidabile è quello di fare solo (quindi rimuovere dopo il completamento):

var_dump($data); die();

Oppure puoi usare dd()(anche parte di Devel), ad es

dd(func_get_args());

quindi controlla il tuo file di registro (nella cartella temp), ad es

$ tail -f /tmp/drupal_debug.txt

L'uso del metodo sopra è più conveniente, più rapido e può supportare AJAX o altre richieste senza interrompere il rendering del sito corrente.

Se ancora ti piace dpm(), prova anche a usare kint()(abilita il sottomodulo Kint incluso per questa bella stampa di variabili).

Se solo alcune dpm()chiamate non funzionano, può essere dovuto al dpm()crash. L'ho visto accadere nel seguente scenario in un gestore di invio di moduli personalizzati:

function mymodule_formid_submit($form, &$form_state) {
  dpm($form_state);
}

Credo che la condizione di errore sia stata rilevata da un gestore di eccezioni dpm(), perché la pagina visualizzava bene, nessun WSOD o qualcosa del genere, ma nemmeno un dpm()messaggio. L'errore è probabilmente una ricorsione non rilevata, poiché l'utilizzo ddl($form_state)invece ha comportato l'esaurimento della memoria del browser durante la visualizzazione dell'oggetto corrispondente nel report generato dal modulo Registro debug di Devel.

Per ovviare a questo problema, prova a stampare solo una parte (rilevante) dell'oggetto, come dpm($form_state['values'])o dpm(array_keys($form_state)).