WP_DEBUG ayarlanmadı, ancak hala uyarı alıyorum

WP_DEBUG ayarlanmadıysa, anladığım gibi, asla uyarı görmemelisiniz. Ancak bazı sunuculardaki bazı sitelerde hala birkaç tane görüyorum. WP_DEBUG ayarlanmışsa görüntülenecek tüm uyarılar değil, birkaçını seçin.

Ben php.ini hata seviyesini değiştirmeye çalıştım, ama bu uyarıların görünüp görünmeyeceği üzerinde hiçbir etkisi var gibi görünüyor, ama farklı sunucularda farklı miktarlarda (yani geliştirme konusunda hiçbir uyarı, evreleme üzerinde bir uyarı ve üretim konusunda birkaç uyarı daha).

WP_DEBUG'ın PHP hata çıktısı üzerinde etkisi yoktur. Error_reporting ayarına ek olarak, php.ini dosyanızda display_errors = 0 olarak ayarlayın. Geliştirme için varsayılan olarak etkindir. Ancak bunu üretim sunucularında kullanmak istemezsiniz.

değiştirmek

define('WP_DEBUG', false);

Bununla:

ini_set('log_errors','On');

ini_set('display_errors','Off');

ini_set('error_reporting', E_ALL );

define('WP_DEBUG', false);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

Bu satırın zaten false değerine ayarlanmış olması da mümkündür. Bu durumda, aşağıdaki kodu görürsünüz:

define('WP_DEBUG', false);

Her iki durumda da, bu satırı aşağıdaki kodla değiştirmeniz gerekir:

ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

Değişikliklerinizi kaydetmeyi ve wp-config.php dosyanızı sunucuya geri yüklemeyi unutmayın.

WordPress ortamları için genellikle kullanmak ini_setiçin bir neden yoktur, çünkü WordPress Core tarafından sağlanan tanımlanmış sabitler zaten bunu başarır. PHP'nin çalışma şekli, belirli ayarların CMS'niz (WordPress) içinde, tek tek komut dosyalarında ve hatta kullanıcı başına veya dizin başına esasında (web barındırıcılarının ve ajanslarının hayal kırıklığı için) geçersiz kılınabilmesidir .

WordPress'de hataların sayfada görüntülenmesini devre dışı bırakmak için gerçekten ihtiyacınız olan tek ayar:

define('WP_DEBUG', false);

... çünkü WP_DEBUGdevre dışı bırakıldığında, alt seçenekler devre dışı olur:

define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);

Kafa karıştırıcı WP_DEBUG_LOGseçeneğin yalnızca debug.logdizinde oluşturulmasını ifade ettiğini wp-contentve diğer günlük ayarlarını vb. Etkilemediğini unutmayın.

Yine, WordPress'teki ayarlar varsayılan PHP ayarlarını geçersiz kılabilir, bu nedenle PHP ayarlarınız wp-config.phpdosyanızda diğer WP bileşenlerinden önce yüklenen doğru ayarlara sahip olmak kadar önemli değildir .

Bununla birlikte, üretimde aşağıdaki gibi varsayılan ayarları uygulamak iyi bir fikirdir:

error_reporting = E_ERROR | E_WARNING | E_PARSE
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/www/logs/error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
report_memleaks = On
xmlrpc_errors = 0
html_errors = Off

Tam bir örnek için Nginx ve PHP-FPM için optimize edilmiş SlickStack php.ini dosyasına bakın .

Bir olayda, araştırmanın saat sonra, bir eklenti fark (veya tema) daha önceden belirlenen çeşitli hata işleme ayarları baskın oldu php.inive wp-config.php. Bunu önlemenin tek yolu, PHP ayarlarınızı "hacklemeye" çalışan WordPress eklentisini veya temasını kaldırmak veya kaldırmasını söylemektir, çünkü bu, uzantıların CMS'nizin hata ayıklama seçeneklerini geçersiz kılması için çok kötü bir uygulamadır.

SlickStack'ta, WP Yönetici Panosunda bu tür "hack'lerin" bir listesini görüntüleyen bir MU Plugin (PHP betiği) kullanarak bu tür örnekleri vurgulayarak ve dizinlerindeki PHP dosyalarından herhangi birini ini_setve error_reportingsatırları "işaretleyen" bir Bash betiği oluşturduk ./themes//plugins/

(Üstte) içindeki tüm hata uyarılarını / bildirimlerini devre dışı bırakmayı / bastırmayı deneyin wp-config.php. Her neyse: Hatalar kötü bir şey değildir. Size kodunuzu düzeltmek için bir şans verir.