لا يعرض dpm () أي نتائج على الشاشة

تأكد من وجود print $messages; في ملف القالب page.tpl.php. بشكل افتراضي ، يتم تكوين devel (dpm) لطباعة المحتوى الخاص به في منطقة الرسالة بالموقع. لذا ، إذا كان نموذجك لسبب ما لا يعرض محتويات $messages ، فلن ترى أي شيء.

1. في بعض الأحيان قد يعمل krumo($variable) عندما لا يعمل dpm($variable).

2. في بعض الأحيان قد يعمل print dpm($variable) عندما لا يعمل dpm($variable).

3. 2. قد يكون الحل أيضًا عندما لا يكون هناك print $messages في page.tpl.php بعد الآن. ربما يمكنك إضافته مرة أخرى.

يجب عليك تسجيل الدخول إلى Drupal ، مع الأذونات الصحيحة للوصول إلى Devel. قم بتسجيل الدخول كمسؤول يجب أن يفعل ذلك.

سأكون في غاية يوصي devel_debug_log . يتطلب وحدة devel ، ويعطيك وظيفة ddl (). يضيف ddl صفحة إلى تقاريرك في التهيئة ، لذا فهي مشابهة للطباعة إلى الوكالة الدولية للطاقة ، ولكن لديك صفحة لطيفة ونظيفة حيث يمكنك إرسال رسائل التصحيح الخاصة بك ، ولا تقلق بشأن شروط نوع السباق حيث قد يتم مسح رسائلك قبل أن فرصة لرؤيتها - أو ، كما هو الحال في حالتك ، مشكلات في الموضوع.

(هذه أيضًا أداة مفيدة للغاية إذا كنت تحاول إنشاء أي نوع من واجهات برمجة التطبيقات ، لأن جميع هذه الطلبات لن تعرض لك أي نوع من رسائل dpm ().)

تأكد من أنك قمت بتمكين وتثبيت Devel الوحدة النمطية لأن dpm() هي وظيفة معلن عنها في هذه الوحدة.

dpm() الوصف مأخوذ من هنا .

طباعة متغير لمنطقة "الرسالة" في الصفحة باستخدام drupal_set_message (). يمكنك استخدام هذه الوظيفة لتتبع متغير واحد أو أكثر عند العمل على التعليمات البرمجية التي تشغل موقعك. نظرًا لأن وحدة Devel تأتي الآن مع Krumo ، فإن الإخراج مدمج وغير مزعج.

dpm($input, $name = NULL)

إذا كنت لا تستخدم Krumo لسبب ما ، يمكنك استخدام المعلمة $ name للتمييز بين المكالمات المختلفة لـ dpm ().

بعد تنزيل Devel وتمكينه ، جرب الإجابة من يستغرق file_scan_directory () حوالي 10 ثوانٍ للتنفيذ مرة أخرى ويجب أن تعمل.

إذا كنت تريد طباعته من داخل وظيفة دون لمس (أو امتلاك) ملف قالب ، فجرّب ما يلي:

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

يكون هذا في بعض الأحيان نتيجة لمورد على الصفحة يعرض 404.

يعرض دروبال صفحة 404 وبذلك يجلب (ويمسح) الرسائل من الجلسة ويضعها في صفحة 404 التي لا تراها. ثم عندما تجلب الصفحة الرئيسية الرسائل ، لن يتبقى منها شيء.

يمكنك فتح علامة تبويب الشبكة والتحقق لمعرفة ما إذا كانت أي موارد لها حالة 404.

الحل السهل هنا هو تمكين 404 السريع من خلال إلغاء تثبيت هذا الخط في الإعدادات. php:

# drupal_fast_404();

حل آخر جيد هنا هو استخدام devel_debug_log كما اقترح SlakeFistcrunch.

في بعض الأحيان يمكن قطع الرسالة أو لن تعمل في حالة AJAX.

الطريقة الأكثر موثوقية هي القيام فقط (ثم الإزالة بعد الانتهاء):

var_dump($data); die();

أو يمكنك استخدام dd() (جزء من Devel أيضًا) ، على سبيل المثال.

dd(func_get_args());

ثم تحقق من ملف السجل الخاص بك (في مجلد مؤقت) ، على سبيل المثال.

$ tail -f /tmp/drupal_debug.txt

يعد استخدام الطريقة المذكورة أعلاه أكثر ملاءمة وسرعة وقد يدعم AJAX أو طلب آخر دون كسر عرض الموقع الحالي.

إذا كنت لا تزال تحب dpm() ، فحاول أيضًا استخدام kint() (مكّن وحدة Kint الفرعية المضمنة لهذه الطباعة الجميلة للمتغيرات).

إذا لم تعمل بعض مكالمات 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)).