Одна из самых страшных вещей, которые могут возникнуть с пользователем WordPress, заключается в том, что вы устанавливаете плагин, а после активации вы получаете белый экран смерти.
Этот экран, где когда -то жил ваш красиво изготовленный веб -сайт, теперь простен белый или производит одну или две строки неформатированного текста.
Конфликт плагина — это когда у вас установлено два плагина, и, хотя они оба работают нормально, запуск их вместе ломает сайт.
Обычно это происходит, когда плагины работают в тандеме, и они оба поставляются с одинаковыми или похожими библиотечными функциями. Есть конфликт именования, и PHP допускает ошибку.
В этой статье будет обсуждаться, как их исправить.
Содержание
Конфликты плагинов становятся более редкими
Прежде всего, конфликт плагина: где кто -то устанавливает плагин, который противоречит другому плагину, становится более редким.
WordPress, в последние несколько лет, ввел настройку защиты, что означает, что если возникает ошибка, а не полностью активировать плагин, он автоматически отступит, предоставит ошибку и оставит деактивированный плагин.
Для большинства пользователей это то, что они видят.
На данный момент следует провести исследование в стадии с этим плагином, но если это не уникальный плагин, может потребоваться найти альтернативу, которая не противоречит вашей настройке.
Конфликты плагина, как правило, возникают при установке необходимого использования плагина (MU) через такую службу, как FTP, обновление одного или нескольких плагинов происходит, или у вас есть пользовательский плагин, активированный, и изменения направляются на сервер.
Я проведу вас через свой процесс разрешения конфликтов плагина.
У вас есть доступ к WordPress?
Для начала, первый вопрос, который вы должны задать, — это если у вас есть доступ к WordPress.
Если вы это сделаете, обычная мудрость диктует, что ход действия, который нужно предпринять, заключается в том, чтобы деактивировать все плагины и переключение на тему по умолчанию, чтобы попытаться устранение неполадок, где возникает проблема.
Если вы делаете это на живом сайте, это не идеально, так как у сайта все еще может быть много функциональности.
Другой подход — установить Проверка здоровья и устранение неполадок плагин. Установка этого плагина позволит вам запустить версию сайта с темой по умолчанию, и плагинов не установлены.
Просто активируйте каждый плагин по очереди, пока вы не определите тот, который вызывает проблему, а затем не оставите его деактивированным.
Убедитесь, что тема является последней вещью активированной, поскольку пользовательские темы могут использовать функциональность в плагинах, которые могут сбить сайт.
Если у вас нет доступа к WordPress
Если у вас нет доступа к WordPress, то может быть немного процесса, чтобы диагностировать и решить проблему.
Этот подход — это то, что я принимаю как можно лучше при диагностике конфликтов плагина. Это может быть сделано в любом порядке, в зависимости от ваших знаний и того, к чему у вас есть доступ.
У вас есть доступ к административному письму? Вы можете получить электронное письмо
Если у вас есть доступ к электронной почте администратора с WordPress (установите Настройки> Общие), вы можете получить электронное письмо.
Это позволит вам поместить сайт в Режим восстановленияПолем Оттуда вы можете войти в систему, и он определит плагин, который имеет проблему, и вы можете деактивировать его.

Проверьте файл журнала хостов
Первым шагом было бы проверить файл журнала хоста.
В зависимости от хоста, его можно легко заметить на панели панели вашего хоста или из CPanel, но если у вас есть только файловый браузер, они, как правило, выставляются за пределы / public_html / или / www / (которые общедоступны). Обычно на один уровень в файле с названием / журналом / ведет, как правило, находится там, где он находится.
Если вы найдете файл (он должен иметь имя, такое как error_log), загрузите его и искате любую фатальную ошибку в документе, может быть, вниз.
В сообщении об ошибке у вас должна быть пара местоположений файлов, которые будут определять, где возникают проблемы с файлами.
Нет журналов? Вам может потребоваться активировать их
Если у вас есть доступ FTP/SFTP на сайт, но нет журналов, вам может потребоваться активировать их.
В корневом каталоге WordPress добавьте следующие строки в файл wp-config.php.
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
Это создаст файл debug.log в WP-контенте/ папке. Оттуда вы можете увидеть ошибки в этом файле.
Совет по безопасности: Debug.Log будет общедоступным, поэтому, как только вы исправите проблему, удалите эти строки из wp-config.php и удалите файл debug.log.
Разрешение этих конфликтов плагинов
Какой бы метод вы ни использовали, ваши журналы должны создавать такие строки ниже:-
Fatal error: Cannot redeclare hello_dolly_get_lyric() (previously declared in/wp-content/plugins/broken-plugin/index.php:17) in /wp-content/plugins/hello-dolly/hello.php on line 46
Каждый элемент означает:
- «Фактальная ошибка» Определяет ошибку. Фактальная ошибка в PHP означает, что сайт немедленно перестает работать. Вы можете получить другие ошибки или предупреждения.
- «Не удается восстановить hello_dolly_get_lyric ()» — фатальная ошибка. В этом случае есть две функции PHP с тем же именем (hello_dolly_get_lyric ()). Это основа конфликта плагина.
- «/Wp-content/plugins/hello-dolly/hello.php на линии 46 « сообщает вам, где происходит эта ошибка. Хотя номер строки не важен (если вы не кодируете себя), он говорит вам плагин, где возникает ошибка плагина-в данном случае «Hello-Dolly».
Следующий шаг — вручную изменить плагин.
В выбранной программе FTP или диспетчера файлов, перейдите в папку плагина в WordPress-/WP-content/Plugins/в этом случае-и переименовать папку плагина (в этом случае измените «Hello-Dolly» на «Broken-Hello-Dolly»). Это будет деактивировать плагин, когда вы выйдете в следующее войну в WordPress.

Хорошей идеей не удалять плагин WordPress, если вы можете предотвратить его. Это заставит деактивацию рассматриваемого плагина.
Оттуда вы можете исследовать два плагина и определить, почему две функции называются дважды.
Для разработчиков: хорошая практика может предотвратить конфликты плагина
Если вы являетесь разработчиком, создающим сайты WordPress, следующая надлежащая практика может предотвратить конфликты плагина.
Вот несколько советов по предотвращению того, чтобы ваш плагин или сайты WordPress были конфликты плагинов с другими плагинами:
- Если вы не используете пространства имен PHP, то я бы рекомендовал назвать ваши классы или функции с префиксом. Что -то вроде plugin_name_function_name может предотвратить аналогичное функциональность иметь одинаковое имя функции. Постарайтесь сделать их уникальными (так что не используйте WP_ в качестве префикса).
- С использованием function_exists Вокруг ваших функций, чтобы предотвратить загрузку ваших функций, если они уже существуют.
- Если вы импортируете функциональность, используя class_exists Можно проверить, был ли класс уже загружен.
- Загрузка вашей функциональности поздно, поэтому полезно, поэтому именование папки плагинов поздней буквой алфавита. Не каждый разработчик следует тому же подходу, что и вы!
- Если вы строите на одном сайте, убедитесь, что настройка вашего сервера такая же (или настолько близка к тому же), что и в живой среде.
Вы никогда не будете полностью гарантировать, что ваш плагин или тема не противоречат миллионам плагинов, которые существуют в пространстве WordPress.
Однако, выполнив вышеуказанные шаги, вы можете как можно больше минимизировать конфликт, и простые изменения в написании кода могут предотвратить мир отладки ада позже.
Больше ресурсов:
Показанное изображение: Whiskerz/Shutterstock