Уведомление: Константа уже определена в wp-config.php на (несуществующей) строке?

22 февр. 2017 г., 14:29:58
Просмотры: 29K
Голосов: 1

Мне поручили перенести сайт на новый домен, и я столкнулся с этой странной проблемой.
На главной странице я всегда вижу следующее:

Notice: Constant AUTOSAVE_INTERVAL already defined in /home/gturnat/public_html/wp-config.php on line 99

Notice: Constant WP_POST_REVISIONS already defined in /home/gturnat/public_html/wp-config.php on line 100


Что я пробовал:

  • Notice: Constant WP_POST_REVISIONS already defined предлагает закомментировать константы в default-constants.php, но это не работает.
  • Установка display_errors в 0, '0' или 'Off' ничего не меняет.
  • Запуск error_reporting(0) все равно отображает ошибки.
  • Создание mu-plugin (Как предложено в "Как остановить появление PHP-уведомлений в WordPress?").
    Ничего не происходит, и плагин даже не загружается.
    Ошибки продолжают появляться.
  • Пробовал закомментировать строки в wp-config.php, но не помогло. Уведомления все еще там.
  • Полностью удалил строки и перемещал их в wp-config.php, но предупреждения по-прежнему указывают на строки 99 и 100.
    Создание синтаксической ошибки внутри wp-config.php приводит к записи ошибки в лог, что означает, что файл не кэшируется.
  • Пробовал включать и отключать режим отладки, устанавливать display_errors в false, 0, '0' и 'Off', но не работает.
  • Запустил grep -1R WP_POST_REVISIONS * и grep -1R AUTOSAVE_INTERVAL * со следующим результатом:

    root@webtest:# grep -lR WP_POST_REVISIONS *
    wp-config.php
    wp-includes/default-constants.php
    wp-includes/revision.php
    root@webtest:# grep -lR AUTOSAVE_INTERVAL *
    wp-config.php
    wp-includes/script-loader.php
    wp-includes/default-constants.php
    wp-includes/class-wp-customize-manager.php

У меня действительно больше нет идей, что можно попробовать.


Я использую WordPress 4.7.2, работающий на PHP 5.4 со следующими загруженными модулями:

загруженные модули PHP

На сервере не работает op-cache. Только эти опции.

PHP был сконфигурирован со следующими параметрами:

'./configure' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/opt/alt/php54' '--exec-prefix=/opt/alt/php54' '--bindir=/opt/alt/php54/usr/bin' '--sbindir=/opt/alt/php54/usr/sbin' '--sysconfdir=/opt/alt/php54/etc' '--datadir=/opt/alt/php54/usr/share' '--includedir=/opt/alt/php54/usr/include' '--libdir=/opt/alt/php54/usr/lib64' '--libexecdir=/opt/alt/php54/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/opt/alt/php54/usr/share/man' '--infodir=/opt/alt/php54/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/opt/alt/php54/etc' '--with-config-file-scan-dir=/opt/alt/php54/link/conf' '--with-exec-dir=/usr/bin' '--with-layout=GNU' '--disable-debug' '--disable-rpath' '--without-pear' '--without-gdbm' '--with-pic' '--with-zlib' '--with-bz2' '--with-gettext' '--with-gmp' '--with-iconv' '--with-openssl' '--with-kerberos' '--with-mhash' '--with-readline' '--with-pcre-regex=/opt/alt/pcre/usr' '--with-libxml-dir=/opt/alt/libxml2/usr' '--with-curl=/opt/alt/curlssl/usr' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-shmop' '--enable-calendar' '--enable-xml' '--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pcntl' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--enable-dbx=shared,/usr' '--enable-dom=shared' '--enable-fileinfo=shared' '--enable-intl=shared' '--enable-json=shared' '--enable-mbstring=shared' '--enable-mbregex' '--enable-pdo=shared' '--enable-phar=shared' '--enable-posix=shared' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sqlite3=shared,/opt/alt/sqlite/usr' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-sysvmsg=shared' '--enable-wddx=shared' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--enable-zip=shared' '--with-gd=shared' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-t1lib=/opt/alt/t1lib/usr' '--with-imap=shared' '--with-imap-ssl' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--enable-ucd-snmp-hack' '--with-xsl=shared,/usr' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/opt/alt/sqlite/usr' '--with-mssql=shared,/opt/alt/freetds/usr' '--with-interbase=shared,/usr' '--with-pdo-firebird=shared,/usr' '--with-pdo-dblib=shared,/opt/alt/freetds/usr' '--with-mcrypt=shared,/usr' '--with-tidy=shared,/usr' '--with-recode=shared,/usr' '--with-enchant=shared,/usr' '--with-pspell=shared' '--with-unixODBC=shared,/usr' '--with-icu-dir=/opt/alt/libicu/usr' '--with-sybase-ct=shared,/opt/alt/freetds/usr'

Для тестирования я попробовал запустить его на PHP 5.6 с теми же результатами, со следующими модулями:

модули php 5.6

4
Комментарии

Возможно, ошибка была там всё время на предыдущем сервере/домене — но уровень отчетов об ошибках PHP теперь установлен по-другому на новом сервере. Иногда приходится решать: бороться с этим или закопать проблему... хотя бы чтобы сайт заработал, а потом продолжать отладку в другом месте.

C C C C
22 февр. 2017 г. 15:04:05

@CC Честно говоря, я просто хочу закопать её. Я могу копаться дальше, но понятия не имею, где именно.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 17:13:21

Сделай find in files во всей директории для AUTOSAVE_INTERVAL, очевидно что-то другое его переопределяет. Также закомментируй важную константу вроде DB_NAME, посмотри, продолжает ли сайт работать. Возможно, ты изменяешь не тот файл wp-config.php.

Fayaz Fayaz
22 февр. 2017 г. 18:52:18

@Fayaz Я уже всё проверил. Поиск по файлам ("find in files") уже был выполнен (последний пункт в списке), и я даже запустил find ./ | grep wp-config - нашел только 2 файла. Второй - это образец. Я даже проследил путь от index.php до wp-config.php.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 19:22:38
Все ответы на вопрос 2
7

Если у вас нет плагина, который управляет этими определениями, скорее всего, проблема вызвана тем, что две константы определены ниже строки в файле config.php, где написано:

/* На этом всё, прекратите редактирование! Удачного ведения блога. */

Относительно высокие номера строк подтверждают эту идею.

22 февр. 2017 г. 15:46:12
Комментарии

Нет, не получается. Я тоже пробовал. Они на строчках 90 и 91. Но каким-то образом предупреждение появляется на строках 99 и 100.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 16:32:34

значит, скорее всего, вы смотрите не в тот wp-config

Mark Kaplun Mark Kaplun
22 февр. 2017 г. 17:02:02

... а мой практически чистый wp-config из версии 4.7 заканчивается на строке 89, так что даже 90-я строка кажется подозрительной

Mark Kaplun Mark Kaplun
22 февр. 2017 г. 17:04:15

Вы можете посмотреть мой файл на http://pastebin.com/HZhENpMu (в свое оправдание скажу, что не знал, что он содержит 100 строк). Строки 90 и 91 закомментированы, как вы можете видеть.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 17:37:43

выглядит хорошо, что возвращает нас к варианту, что это не тот файл, который нужно смотреть. Вы уверены, что нет, например, wp-config в директории уровнем выше? Простой способ проверить - добавить die или внести синтаксическую ошибку в файл, который вы сейчас смотрите

Mark Kaplun Mark Kaplun
22 февр. 2017 г. 18:58:32

Я уже пробовал это. Это 6-й пункт. Действительно приводит к белой странице, если написать случайный текст внутри файла.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 19:18:47

Просто чтобы немного прояснить ситуацию, я изменил третью строку на define('WP_MEMORY_LIMIT', '512M');die(WP_MEMORY_LIMIT);, и она вывела ожидаемое значение 512M.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 19:34:13
Показать остальные 2 комментариев
8

tl;dr: Очистите ваш (Comet) кеш!


Подробный ответ:

У меня всего два слова: Comet Cache!

Comet Cache был включен.
Проверка исходного кода показала мне заметку такого вида после закрывающего тега </html>:

<!-- *´¨)
     ¸.•´¸.•*´¨) ¸.•*¨)
     (¸.•´ (¸.•` ¤ Comet Cache Notes ¤ ´¨) -->

<!-- Соль версии кеш-файла:       n/a -->

<!-- URL кеш-файла:                http://<my-domain> -->
<!-- Путь к кеш-файлу:               /cache/comet-cache/cache/http/<my-domain>/index.html -->

<!-- Кеш-файл сгенерирован через:      HTTP запрос -->
<!-- Кеш-файл сгенерирован:       Feb 22nd, 2017 @ 5:37 pm UTC -->
<!-- Время генерации кеш-файла:       4.59149 секунд -->

<!-- Кеш-файл истекает:         Mar 1st, 2017 @ 5:37 pm UTC -->
<!-- Автоматическое обновление кеш-файла:    Mar 1st, 2017 @ 5:37 pm UTC -->

<!-- *´¨)
     ¸.•´¸.•*´¨) ¸.•*¨)
     (¸.•´ (¸.•` ¤ Comet Cache полностью функционален ¤ ´¨) -->

<!-- Загружено из кеша:    Feb 22nd, 2017 @ 5:37 pm UTC -->
<!-- Время загрузки из кеша:    0.03472 секунд -->

Ручное удаление файла /cache/comet-cache/cache/http/<my-domain>/index.html (путь относительно директории /wp-content/) решило проблему.


Я чувствую себя глупо, предполагая, что кеширование не было включено. Всегда вините кеш!

22 февр. 2017 г. 19:45:24
Комментарии

Ха-ха, да, если происходит что-то настолько странное, что это вообще необъяснимо, в 99 случаях из 100 это какой-то вид кеша :)

Fayaz Fayaz
22 февр. 2017 г. 19:54:24

@Fayaz Урок усвоен. Потратил около 9 часов на это :/ Я действительно предполагал, что там вообще нет кеширования, так как иногда изменения происходили... Ну что ж, в следующий раз повезёт больше.

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 20:19:54

лол, даже не подумал про кеш

Mark Kaplun Mark Kaplun
22 февр. 2017 г. 21:19:00

@MarkKaplun Я тоже. Я имею в виду, я смотрел со стороны PHP, но кэширование было на стороне Wordpress :/

Ismael Miguel Ismael Miguel
22 февр. 2017 г. 21:55:32

Надеюсь, ты усвоил урок: кэшированием должны заниматься серверы, а не плагины ;) Лучше научись настраивать сервер для этой задачи, чем навешивать сверху приложение. Бонус: ты получишь больше контроля и гораздо больше мощности кэширования, так как запросы, доступные в кэше, вообще не будут доходить до твоего PHP FPM или FCGI сервера приложений.

kaiser kaiser
6 мар. 2017 г. 00:42:15

@kaiser Ты прав. Мне стоит поискать пример .htaccess по этому поводу. Я немного читал, но не совсем уверен в самостоятельной реализации, так как почти ничего не знаю о Wordpress.

Ismael Miguel Ismael Miguel
6 мар. 2017 г. 12:58:30

Кэширование не имеет ничего общего с WordPress (и не связано с доступом пользователей, как это делает .htaccess для веб-сервера Apache) или с вашим сервером.

kaiser kaiser
6 мар. 2017 г. 15:41:37

Теперь я совершенно запутался...

Ismael Miguel Ismael Miguel
6 мар. 2017 г. 16:06:59
Показать остальные 3 комментариев