Деактивирайте E_DEPRECATED в регистъра на грешките на php

Имам производствен сървър, работещ с търговски софтуер, който използва остаряла функционалност. Вече деактивирахме извеждането на грешки в php.ini -- display_errors = Off -- така че потребителите не виждат тези грешки. Все още обаче регистрираме PHP грешки -- log_errors = On -- за да проследим проблемите.

Проблемът: PHP изглежда игнорира директивата error_reporting по отношение на това, което в крайна сметка предава на регистъра на грешките. Без значение каква комбинация от стойности е въведена, регистрирането на файла се извършва, сякаш съм настроен на E_ALL. Моят регистър на грешките следователно е раздут с известия за оттегляне.

Стойността на часовата зона по подразбиране е зададена в php.ini, така че проблемите, свързани с часовата зона, не са от значение.

Все още не са налични надстройки за софтуерния пакет, така че, моля, без препоръки за „просто коригиране на остарелия код“. Търся специално начини да попреча на PHP да изхвърля остарели грешки в регистрационния файл, без да деактивирам изцяло регистрирането на файлове.

Подробности за сървъра:

  • Ubuntu 10.04.2 LTS
  • PHP 5.3.2

php error-log
person Frank Koehl    schedule 11.04.2011    source източник
comment
Просто поправете остарелия код. патици   -  person Lightness Races in Orbit    schedule 12.04.2011
comment
Ти си забавен, забавен човек, Томалак. :P   -  person Frank Koehl    schedule 12.04.2011

Отговори (3)


arrow_upward
25
arrow_downward

Когато PHP работи като модул на Apache, можете да получите достъп/промените всяка конфигурационна настройка, налична в php.ini, като използвате директиви в конфигурационните файлове на Apache. Тези директиви са...

  • php_value
  • php_flag
  • php_admin_value
  • php_admin_flag

Разликата между версиите php_* и php_admin_* е ключът към този проблем. Стойности, зададени с помощта на php_admin_value и php_admin_flag, могат да бъдат зададени само в Apache global и VirtualHost конфигурации; те не могат да бъдат заменени от .htaccess или ini.set().

Функцията error_reporting() е еквивалентна на повикване ini_set() и попада под същите правила.

Така че влязох в конфигурацията на виртуалния хост за въпросния сайт и добавих следните редове...

php_admin_value error_reporting 22527
php_admin_value error_log /custom/log/path/php_errors.log
php_admin_flag  log_errors On
php_admin_flag  display_errors Off

  1. Първият ред е побитовата стойност за error_reporting = E_ALL & ~E_DEPRECATED. Извлякох тази стойност, като създадох прост скрипт:

    ini_set("error_reporting", E_ALL & ~E_DEPRECATED);
echo ini_get("error_reporting");

    Ако искате да пренебрегнете системните известия заедно с предупрежденията за оттегляне -- error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE -- побитовата стойност е 22519.

  2. Вторият ред изпраща всички PHP грешки в персонализиран журнал. По подразбиране PHP ще използва стойността syslog, обикновено /var/log/apache2/error.log или нещо подобно.

  3. Третият ред позволява регистриране на файлове.

  4. Последният изключва показването на грешки на страницата.

Отново, приоритетът и редът на операциите са ключови тук. Тези стойности заместват дефинираните в php.ini и в същото време не могат да бъдат заменени от други промени в приложението или във .htaccess файлове.

Повече подробности относно промяната на конфигурационните стойности извън php.ini можете да намерите в PHP документацията .

person Frank Koehl    schedule 13.04.2011
comment
Благодаря за този отговор. error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE обаче не работи. phpinfo() взима правилната стойност (22519). Но дневникът ми все още е наводнен с E_DEPRECATED. Някаква идея? - person Till; 15.12.2011
comment
@докато някога намериш своя отговор? - person Ascherer; 16.04.2013
comment
@Ascherer И при мен не работи.. Засега се измъквам с: tail -f /custom/log/file | grep -v "is deprecated occured" - person Daveel; 22.08.2014
comment
Съгласен съм, това НЕ работи с Apache 2.4. /var/log/apache2/error.log все още е залят с тези съобщения. - person Adambean; 06.04.2017

arrow_upward
2
arrow_downward

Изглежда, че самият софтуер може да задава нивото на грешка, като по този начин отменя настройката в php.ini.

Ако това е вярно, вие сте SOL.

Между другото, ако използвате Cacti, вижте тук. Дори и да не използвате Cacti, мисля, че той обобщава сценария доста добре.

person Lightness Races in Orbit    schedule 11.04.2011

arrow_upward
-4
arrow_downward

Можете да използвате символа @, за да потискате предупрежденията (освен ако не се използва персонализиран манипулатор на грешки), например:

@unlink("http://something.bad/");

Or:

@require_once('abc.pphp');

Или дори:

$var = @$_GET['something not set'];

Въпреки това, трябва да го използвате разумно, лесно може да причини проблеми и прави отстраняването на грешки по-трудно.

person Christian    schedule 11.04.2011
comment
Не използвайте @! Използвайте настройките за докладване на грешки в PHP, за да покажете или скриете предупрежденията. При използване на @ няма никакво известие. С помощта на настройките за докладване на грешки можете да регистрирате всички грешки в регистъра на грешките, без да ги показвате. По този начин те няма да бъдат загубени. - person Markus Müller; 26.11.2016
comment
Първо, в публикацията ми има доста забележим отказ от отговорност. Второ, между деактивирането на всички грешки и скриването само на една известна грешка, която попълва регистрационни файлове, бих избрал последния подход. Трето... разбирате ли, че това е отговор, който написах преди 5 години? Оттогава имаме 6 основни PHP версии... - person Christian; 26.11.2016
comment
Понякога @ е полезно, особено за файлови операции, където дадена команда може да се провали, без значение колко изпреварваща е тя. Например, човек може да използва file_exists, за да провери за файл, преди да използва file_get_contents, но файлът може да бъде изтрит от друга сесия между тях, така че се издава E_WARNING. - person Patanjali; 14.02.2020