dpm（）は画面に結果を表示しません

23

file_scan_directory（）の実行に約10秒かかるのと同じ問題があります。dpm(func_get_args())提案を試みたところ、残念ながら何も表示されません。

すべてのキャッシュをクリアし、cronタスクを実行しました。私は何が欠けていますか？

7 debugging

— ジミー
ソース

2

開発者情報へのアクセス許可が

— ユーザー

28

テンプレートファイルに含まprint $messages;れていることを確認してくださいpage.tpl.php。デフォルトでは、devel（dpm）はサイトのメッセージ領域にコンテンツを印刷するように構成されています。何らかの理由でテンプレートがのコンテンツをレンダリングしない場合、$messages何も表示されません。

— スヴェトリオ
ソース

13

動作しないkrumo($variable)場合もあるかもしれdpm($variable)ません。
動作しないprint dpm($variable)場合もあるかもしれdpm($variable)ません。
1. もうprint $messagesあなたにpage.tpl.phpないときの解決策かもしれません。たぶんあなたはそれを再び追加することができます。

— レイマンクス
ソース

9

Develにアクセスするための適切な権限でDrupalサイトにログインする必要があります。管理者がログインする必要があります。

— Powdermonkey1850
ソース

7

匿名ユーザーに適切な権限がある場合、ログインする必要はありません。

— キアムルノ

3

この許可は、「開発者情報へのアクセス」の下の「admin / people / permissions」で見つけることができます。

— Citricguy

9

devel_debug_logを強くお勧めします。develモジュールが必要で、ddl（）関数を提供します。ddlは設定でレポートにページを追加するので、ウォッチドッグに印刷するのと似ていますが、デバッグメッセージを送信できるきれいなページがあり、メッセージがある前にクリアされる可能性のある競合タイプの状態を心配する必要はありませんそれらを見るチャンス-または、あなたの場合のように、テーマの問題。

（これは、何らかのAPIを構築しようとする場合にも非常に便利なツールです。これらのすべてのリクエストでは、dpm（）メッセージが表示されることはありません。）

— 不安定な傾向
ソース

1

これは私にとって最高の全体的なソリューションでした。

— rrirower

1

Ajaxリクエストをデバッグする際にも非常に貴重です。

— フェリックスイブ

8

このモジュールで宣言されている関数と同様に、Develモジュールを有効にしてインストールしたことを確認してくださいdpm()。

dpm()ここからの説明。

drupal_set_message（）を使用して、ページの「メッセージ」領域に変数を出力します。この関数を使用すると、サイトを実行するコードで作業しているときに1つ以上の変数を追跡できます。DevelモジュールにはKrumoが付属しているため、出力はコンパクトで目立たなくなります。

dpm($input, $name = NULL)

何らかの理由でKrumoを使用していない場合は、$ nameパラメーターを使用して、dpm（）のさまざまな呼び出しを区別できます。

Develをダウンロードして有効にしたら、file_scan_directory（）からの回答を再試行するのに約10秒かかります。

— チャパブ
ソース

同じままです。develモジュールをインストールして有効にし、すべてのキャッシュをクリアし、cronを実行しても、dpm（func_get_args（））には何も表示されません。

— ジミー

どこに置きdpm(func_get_args());ますか？

— チャパブ

bootstrap.incファイル内：dpm（func_get_args（））; $ matches = drupal_system_listing（ "/ ^"。DRUPAL_PHP_FUNCTION_PATTERN。 "\。$ extension $ /"、$ dir、 'name'、0）; ...

— ジミー

に変更dpm(func_get_args());してみてくださいdie(print_r(func_get_args());-今のところDevelをバイパスしてください。

— チャパブ

3

Chapabuが推奨する2番目のコマンドが何も変更しない場合、コードが呼び出されておらず、同じ問題の影響を受けていないことを意味します。

— ベルディール

5

テンプレートファイルに触れない（または持たない）関数内から印刷する場合は、これを試してください。

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

— ギャビン・マクドノウ
ソース

3

これは、ページ上のリソースが404を返す結果である場合があります。

Drupalは404ページをレンダリングし、その際にセッションからメッセージをフェッチ（およびクリア）し、表示されていない404ページにそれらを配置します。次に、メインページがメッセージを取得すると、何も残りません。

ネットワークタブを開いて、404ステータスのリソースがあるかどうかを確認できます。

ここでの簡単な解決策は、settings.phpのこの行のコメントを外して、高速404を有効にすることです。

# drupal_fast_404();

ここでのもう1つの良い解決策は、SlakeFistcrunchで提案されているようにdevel_debug_logを使用することです。

— フェリックスイブ
ソース

2

AJAXの場合、メッセージが切り取られたり、機能しないことがあります。

より信頼性の高い方法は、ただ行うことです（終了後に削除します）：

var_dump($data); die();

または、dd()（同様にDevelの一部）を使用できます。例えば

dd(func_get_args());

次に、ログファイル（一時フォルダー内）を確認します。

$ tail -f /tmp/drupal_debug.txt

上記の方法を使用すると、より便利で迅速になり、現在のサイトレンダリングを中断することなくAJAXまたはその他のリクエストをサポートできます。

まだ好きな場合はdpm()、使用してみてくださいkint()（変数のきれいな印刷のために、付属のKintサブモジュールを有効にしてください）。

— ケノーブ
ソース

1

一部のdpm()コールのみが機能しない場合は、dpm()クラッシュが原因である可能性があります。カスタムフォーム送信ハンドラーの次のシナリオで発生しました。

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

dpm()ページが正常に表示されていたため、WSODなどがなく、dpm()メッセージも表示されなかったため、エラー条件はの例外ハンドラーによってキャッチされたと思います。ddl($form_state)代わりにを使用すると、Devel Debug Logモジュールによって生成されたレポート内の対応するオブジェクトを見るときに、メモリがブラウザで最大になるため、エラーはおそらく検出されない再帰です。

回避策として、dpm($form_state['values'])またはなどのオブジェクトの（関連する）部分のみを印刷してみてくださいdpm(array_keys($form_state))。

— タニウス
ソース