# تفعيل WP_DEBUG وقراءة سجل الأخطاء
Source: https://docs.webgee.com/ar/hosting/wordpress/how-to-view-enable-and-view-errors-on-a-wordpress-installation-wp-debug







يجعل `WP_DEBUG` ووردبريس يسجّل الأخطاء التي كان سيخفيها. وهو أول خطوة في تشخيص
شاشة بيضاء أو خطأ فادح أو إضافة لا تسلك سلوكها. ينطبق على كل مواقع ووردبريس.

وتُكتَب الأخطاء في ملف سجل لا تُعرَض في الصفحة — وهو ما يجعل هذا آمنًا على موقع
حي.

## حرّر wp-config.php [#حرّر-wp-configphp]

ملف `wp-config.php` في المجلد الجذر لموقعك، وعادةً `public_html`. افتحه بـ
**File Manager** في cPanel أو بعميل FTP.

<img alt="فتح wp-config.php للتحرير" src="__img0" />

اعثر على السطر القائم:

```php
define( 'WP_DEBUG', false );
```

واستبدله بـ:

```php
// تفعيل وضع WP_DEBUG
define( 'WP_DEBUG', true );

// تسجيل الأخطاء في wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// عدم عرض الأخطاء للزوار
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
```

<img alt="ثوابت التنقيح مضافة إلى wp-config.php" src="__img1" />

<Callout type="warn">
  يجب أن تذهب هذه الأسطر **فوق** التعليق `/* That's all, stop editing! */`. فكل
  ما بعده يُتجاهَل، والسبب الأشيع لظهور أن التنقيح لا يعمل هو إضافة الثوابت في
  أسفل الملف.
</Callout>

وإن لم يكن `WP_DEBUG` معرَّفًا في أي مكان في الملف، فأضف الكتلة أعلاه فوق ذلك
التعليق.

### يجب أن يبقى WP\_DEBUG\_DISPLAY على false [#يجب-أن-يبقى-wp_debug_display-على-false]

فضبط `WP_DEBUG_DISPLAY` على `true` يطبع الأخطاء داخل HTML الصفحة لكل زائر، بما
في ذلك مسارات الملفات، وفي بعض الأخطاء تفاصيل قاعدة البيانات. اتركه `false`
واقرأ السجل.

### SCRIPT\_DEBUG [#script_debug]

تضيف بعض الأدلة `define( 'SCRIPT_DEBUG', true );`. وذلك يجعل ووردبريس يحمّل
جافاسكربت وCSS النواة غير مصغَّرين، وهو مفيد فقط إن كنت تنقّح ملفات النواة نفسها.
واتركه خارجًا فيما عدا ذلك — فهو يبطّئ كل تحميل صفحة.

## أعد إنتاج المشكلة [#أعد-إنتاج-المشكلة]

احفظ الملف، ثم عد إلى الموقع وافعل ما سبّب الخطأ. فلا يُسجَّل شيء حتى يحدث الخطأ
من جديد.

## اقرأ السجل [#اقرأ-السجل]

افتح `wp-content/debug.log`.

ويعطي كل مدخل الخطأ ومسار الملف ورقم السطر. اعمل من المدخل **الأقدم** لا الأحدث
— فالخطأ الفادح الواحد يتسلسل عادةً إلى عدة تحذيرات تابعة، والأول يسمّي السبب
الحقيقي.

والمسار تحت `wp-content/plugins/some-plugin/` يشير إلى تلك الإضافة. عطّلها وانظر
إن توقف الخطأ.

## أوقفه بعد ذلك [#أوقفه-بعد-ذلك]

أعد `WP_DEBUG` إلى `false` و&#x2A;*احذف `wp-content/debug.log`**.

<Callout type="warn">
  يقع `debug.log` داخل جذر الويب وقد يكون قابلًا للقراءة عبر الإنترنت على
  `example.com/wp-content/debug.log`. وهو يحوي مسارات ملفات وقد يحوي أجزاء
  استعلامات. احذفه حين تنتهي، ولا تترك التنقيح مفعَّلًا على موقع حي إلى ما لا
  نهاية — فالملف ينمو بلا حد.
</Callout>

## اقرأ أيضًا [#اقرأ-أيضًا]

* [معالجة موقع عالق في وضع الصيانة](/ar/hosting/wordpress/wordpress-my-site-is-showing-a-maintenance-page-how-do-i-disable-it)
* [إعادة ضبط روابط ووردبريس الدائمة](/ar/hosting/wordpress/how-to-reset-your-wordpress-permalinks)