Как исправить ошибку в wordpress

Как увидеть уведомления вордпресс об ошибках?

Делается это с помощью debug режима. Открываем wp-config.php и ищем строку: define(‘WP_DEBUG’, false)

и меняем её на:

define(‘WP_DEBUG’, true);

define(‘WP_DEBUG_LOG’, true);

define(‘WP_DEBUG_DISPLAY’, true);

Тогда WordPress в шапке консоли будет сообщать Вам об ошибках. Эти ошибки разнообразные и устранение их не всегда понятное, если не владеешь PHP. Например, я беру ошибку:

Notice: Функция add_custom_background с версии 3.4 считается устаревшей! Используйте add_theme_support( ‘custom-background’, $args ). in /home/31264/public_html/wp-includes/functions.php on line 3201 

Обращаюсь на форум WordPress.org, где модератор форума, и многие в интернете, уточняют, что Notice — это не ошибка, а уведомление о несовпадении атрибутов новой версии вордпресс с функциями старой темы или плагина.

Иду  на хостинг. А на хостинге в техподдержке сказали, что именно это предупреждение порождает последующие ошибки и поэтому не работают комментарии, не загружаются медиафайлы, не добавляются новые посты.

В интернете нашел, что это связано с файлом functions.php темы. А именно, ищем в этом файле функцию add_custom_background :

Заменяете на

Но у меня в теме ничего менять не надо, там всё правильно написано. Открываю файл functions.php в WordPresse и в строке 3201 ничего не нахожу, чтобы исправить? А честно сказать, не знаю что править.

Вновь роюсь в недрах интернета и нахожу следующее. Умные головы советуют проверить файлы на наличие пробелов в коде перед < ?php и после ?>, наличие пустых строк в начале и конце файла, проверить кодировку UTF8 на наличие BOM и перекодировать файлы wp-config.php, functions.php темы и ворпресс, а затем сохранить и залить снова на хостинг.

Сделал всё как сказали. Проверил, перекодировал, перезалил. Но блог толком не работает.

Снова начинаю ходить по интернету и искать нужную информацию на форуме WordPress. Модератор форума предложил следующее:

Перезалил тему, перезалил ворпресс – ноль по вдоль. Вот, думаю влип. Это хорошо для тех кто понимает в программировании на PHP.

А я-то просто пользователь со своим блогом. Уже как три недели ничего исправить не могу. Сайт упал в посещениях. Я в полном трансе. Злость на весь интернет и свою беспомощность.

У меня не загружаются медиафайлы, не публикуются комментарии, не сохраняются изменения статей и не публикуются новые, зарегистрированные пользователи не могут получить пароль для входа и так далее.

Тогда я стал переводить все сообщения, которые выдает вордпресс. Оказалось очень много сообщений о плагинах WPPage и WP Super Cache.

Я решил их деактивировать и посмотреть на работу движка. Оказалось, что действительно эти два плагина конфликтуют с вордпрессом. Больше всего WP Super Cache.

Резюме:

1. Делаем режим просмотра сообщений об ошибках define(‘WP_DEBUG’, true);
2. Отключаем поочередно плагины и проверяем работу вордпресс;
3. Сообщаем создателям плагинов об ошибках, которые создают их плагины;
4. Устраняем пробелы перед <?php и после ?> в файлах wp-config.php, functions.php;
5. Проверяем кодировку UTF8 на наличие BOM и перекодировать без BOM  wp-config.php, functions.php;
6. Не используйте для редактирования файлов программу Блокнот.
7. Обращаемся на форумы и лазаем по интернету, ищем ответы;.
8. Отключаем режим просмотра для комфортной работы.

На сегодня всё.

Пока. До встречи в статье «Как найти и удалить битые ссылки?»

Не жадничай на комментарий и расскажи друзьям.

Проверьте ваш файл .htaccess

Файл  .htaccess содержит инструкции для сервера. Иногда он может повредится, что вызывает появление сообщений типа “500 Internal Server Error”.

Если вы предполагаете, что ваш файл .htaccess стал причиной возникновения проблем, получите доступ к сайту по FTP и найдите .htaccess в корне вашей директории WordPress. Иногда этот файл скрыт, и вам придется выбрать “show hidden files” (показать скрытые файлы) в вашем FTP-клиенте, чтоб найти его.

Найдя этот файл, переименуйте его во что-то типа “.htaccess-old”, что остановит его использование и перезагрузит сайт

Если ваш файл .htaccess не проблема, то переименуйте его обратно в .htaccess. Если же наоборот, то сгенерируйте новый файл  .htaccess, перезапустив ваши постоянные ссылки (просто сохраните другую структуру постоянных ссылок, затем верните все обратно и сохранитесь).

Метод 1: Через панель управления CPanel

Если вы используете управляемую хостинговую платформу WordPress или общий хостинг для размещения своего веб-сайта, получить доступ к файлам WordPress можно с помощью CPanel.

Шаг 1: Войдите в CPanel

Вы можете найти CPanel, просто набрав /cpanel в конце URL вашего сайта (например, yourwebsite.com/cpanel). Если это не сработает, войдите в свою панель инструментов веб-хостинга и найдите ссылку для доступа к CPanel.

Затем введите свое имя пользователя и пароль для CPanel. Эти данные для входа предоставляются вам при первой регистрации на веб-хостинге. Вы можете найти их в приветственном письме.

Внутри CPanel вы увидите панель с множеством приложений. Найдите приложение File Manager и откройте его. Это работает и в панели управления DirectAdmin.

Через приложение File Manager вы получаете доступ ко всем файлам на вашем сервере. Чтобы добраться до файлов вашего сайта, найдите папку public.html.

В ней вы увидите каталог WP-Content, в котором находятся все плагины и темы вашего сайта.

Примечание. Если ваш веб-сайт установлен на поддомене или если вы размещаете несколько веб-сайтов на одном и том же сервере, сначала откройте основной каталог для соответствующего веб-сайта, чтобы получить доступ ко всем каталогам определенного сайта.

Настройка ImageMagick через htaccess

Если включать GD Library, то дополнив немного .htaccess, у вас получится контролировать использование библиотекой ImageMagick ресурсов сервера. Находите файл в корневом каталоге и через FTP редактируете его, добавляя строку:

SetEnv MAGICK_THREAD_LIMIT 1

Этот параметр заставляет ее применять лишь один поток для обработки картинок вместо множественных подключений. Это в свою очередь может предотвратить HTTP ошибку в Вордпресс.

Если код выше не помог, попробуйте другой:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

Либо вариант:

# Exclude the file upload and WP CRON scripts from authentication
<FilesMatch "(async-upload\.php|wp-cron\.php|xmlrpc\.php)$">
Satisfy Any
Order allow,deny
Allow from all
Deny from none
</FilesMatch>

Поиск неработающих ссылок в WordPress с помощью инструментов СЕО-аудита

Один из способов найти неработающие ссылки — вручную прочесать ваш сайт WordPress.

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

Предположим, у вас есть блог с большим количеством сообщений. Искать битые ссылки в WordPress вручную было бы неудобно и отнимает очень много времени.

В качестве альтернативы есть несколько веб-инструментов СЕО-аудита, которые можно использовать для автоматического выполнения этой задачи.

Однако имейте в виду, что они предоставят вам только список неработающих ссылок и страниц, которые их используют.

Позже вам все равно нужно будет посещать каждое сообщение, чтобы удалить или исправить ошибочные URL-адреса.

В следующих разделах объясняется, как использовать каждый инструмент.

1. Semrush

Semrush — популярный инструмент СЕО, который позволяет отслеживать различные показатели, от мониторинга бренда до отслеживания позиций.

Это также позволяет улучшить СЕО, проводя исследования ключевых слов и аудит веб-сайтов.

Инструмент аудита сайта включает функцию исправления и поиска неработающих ссылок на вашем сайте WordPress.

Он предлагает ограниченную бесплатную услугу, которая позволяет вам проверить до 100 страниц.

Чтобы использовать его, вам сначала нужно создать учетную запись Semrush.

Затем перейдите на страницу аудита сайта, введите URL-адрес своего сайта и нажмите кнопку «Начать аудит».

Semrush запустит процесс аудита и отобразит обзор отчета вашего сайта.

Нажав на URL-адрес, вы получите более подробную информацию.

Нажмите на опцию «Broken», чтобы найти неработающие ссылки на сайте.

На странице будет отображаться список неработающих ссылок с внешних и внутренних страниц, найденных на вашем сайте WordPress.

Наконец, нажмите кнопку «Export» в правом верхнем углу экрана, чтобы загрузить отчет о сканировании.

2. Ahrefs

Ahrefs — это платформа для СЕО, которая предлагает инструмент для просмотра сайтов, который помогает предотвратить «гниение» ссылок и обнаруживать неработающие ссылки.

Он также предоставляет генератор ключевых слов, проводник контента и трекер ранга, чтобы улучшить ваши общие усилия по поисковой оптимизации.

Чтобы найти неработающие ссылки с Ahrefs, просто зарегистрируйтесь и выберите тарифный план стоимостью от 99 долларов в месяц.

Вы также можете приобрести 7-дневную пробную версию за 7 долларов, прежде чем переходить на план.

После того, как вы вошли в свою учетную запись, перейдите в «Ahrefs Site Explorer» и введите URL-адрес вашего сайта WordPress.

Инструмент запустит процесс сканирования, который может занять несколько минут, и отобразит результаты.

Чтобы увидеть неработающие ссылки, обнаруженные на вашем сайте, нажмите «Pages — Best by links».

Затем отсортируйте результаты, выбрав опцию «404 Not Found».

Затем экспортируйте результаты в файл CSV, чтобы вы могли использовать его позже для исправления неработающих ссылок на своем сайте WordPress.

Чтобы обнаружить неработающие исходящие ссылки, перейдите в «Outgoing links — Broken links».

Вы увидите список неработающих внешних ссылок вместе с каждым текстом привязки и неработающим URL.

Это облегчает вам поиск сообщений в блогах или страниц, содержащих неработающие ссылки, и их последующее исправление.

Щелкните «Export», чтобы загрузить отчет о неработающих ссылках.

3. Google Search Console

Еще один инструмент, который позволяет легко находить неработающие ссылки на вашем сайте WordPress — это консоль поиска Google.

Это бесплатный сервис, который позволяет пользователям отслеживать, настраивать и оптимизировать видимость своих веб-сайтов в результатах поиска.

Прежде чем начать, вам нужно будет добавить свой домен в Google Search Console. Как только вы подтвердите свой URL, вы сможете использовать все его функции.

Войдите в свою учетную запись и выберите сайт, за которым хотите следить. Затем выберите «Покрытие».

Инструмент покажет, сколько ошибок он обнаружил на вашем сайте.

Нажмите «Исключено», чтобы просмотреть список всех обнаруженных проблем.

Нажав на опцию «Не найдено (404)», вы увидите каждую неработающую ссылку, которая вызывает ошибку 404.

Нажимая на каждую ссылку, вы сможете увидеть, на каких страницах она содержится.

Вы также можете нажать кнопку «Загрузить», чтобы сохранить отчет.

Что делать, если невозможно войти в панель управления WordPress

Итак, стратегия следующая:

• поскольку проблема возникла после обновления, нужно найти возможность откатить обновления
• у меня нет доступа в админку WordPress, значит придётся откатывать изменения на уровне файловой системы
• я не помню, какой именно плагин или тема обновились, что в результате сайт перестал работать. Поэтому, чтобы узнать, какие плагины обновились, я посмотрю даты изменения папок и файлов.

Итак, по умолчанию (это может быть изменено настройками веб-сервера и отдельных виртуальных хостов), файлы веб-сайтов в Debian, Linux Mint, Ubuntu и их производных хранятся в директории /var/www/html/. А у Arch Linux файлы сайтов хранятся по пути /srv/http/.

Итак, перехожу в папку с сайтом:

cd /srv/http/site.ru/

Файлы плагинов расположены в папке wp-content/plugins/, запускаю команду ls (показывает содержимое папки) с опциями -l (вывести список файлов с информацией о файлах) и -t (отсортировать файлы в списке по времени изменения):

ls -lt wp-content/plugins/

И вот что я вижу:

Сегодня, 18 февраля, была изменена только одна папка — sitetree. Решение очень простое — удалить плагин sitetree.

Как вернуть WordPress в работу

Для исправления ошибки “на сайте возникли временные проблемы технического характера” нужно вспомнить что вы делали, до того как она появилась и предпринять обратные действия.

При обновлении плагина или тем

Если сбой произошел после обновления или установки отдельного плагина или темы, то заходим на сайт через FTP с помощью FileZilla, удаляем либо переименовываем папку c ним.

Удалить и переименовать FileZilla

Обнуляем сайт клавишами ctrl+f5 и смотрим на работоспособность. Если удалось, то удаляйте такой модуль и ищите альтернативу.

Пакетное обновление

Не советую пользоваться обновлением всех компонентов одновременно, может привести, к падению сервера. Сервер начинает в огромном количестве скачивать файлы, так же посетители на сайте берут ресурсы, если их не хватает, то происходит сбой с перезагрузкой. Вы теряете скорость и посетителей, что делать в такой ситуации, выделю два варианта:

1. Подождать 20–30 минут, хостинг перезагрузит сервер и доделает процедуру до конца
2. Если ожидание не помогло, то это ошибка из предыдущего пункта. Но плагинов много, как определить какой дал сбой, идем в логи хостинга

Разберу на примере Beget, заходим в раздел Журналы.

Журналы

Активируем оба переключателя, если были не активными.

Активация логов

На главной панели (там же где нажимали журналы), выбираем пункт файловый менеджер, находим директорию сайта и находим файл ошибок с окончанием error log. Нажимаем правой кнопкой мыши и выбираем правка.

Просмотр log

Ошибку создал плагин autoptimize, удаляем или переименовываем каталог. Можно включить логирование на уровне WordPress, в wp-config меняем строчку на:

Wp-config располагается в корне сайта, так же через файловый менеджер правим и сохраняем.

Активация log в вп

Теперь при любой ошибке в папке будет создаваться данный файл, открываем и смотрим, что дало сбой.

Обрыв при обновлении или закрытие страницы

При обновлении может пропасть интернет или пользователь обновил или закрыл страницу. В 90% случаев, это не приводит к падению ресурса. Но такой момент бывает, и чтобы справится с ним есть два решения:

• Ожидание в течении 30–40 минут. Разработчики вордпресс советуют ждать это время, WP исправит и доделает процесс на уровне хостинга
• По истечении времени, если сайт не начал работать, делаем бэкап блога. У любого нормального хостера резервная копия делается регулярно. Логи не покажут где ошибка, либо напишут что не знают откуда.

Новая версия PHP

Переход на новую версию PHP планируется, просто так его не стоит производить. Бывает провайдер сам переводит ресурс на новую версию PHP, блог перестает работать и выдает “на сайте возникли временные проблемы технического характера”. В такой ситуации:

Удаление через PHP код темы

Этот способ немного сложней предыдущего, поскольку потребует редактирования исходных файлов темы. Он заключается в том, что нужно убрать из файлов ту функцию, которая отвечает за вывод имени автора, даты публикации и других мета-данных. Она может называться по-разному и находиться в разных местах, все зависит от установленной темы.

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

Если ее удалить или закомментировать, то получиться убрать имя автора со страниц постов. Только имейте ввиду, что не будет и даты публикации, и списка категорий, так как данная строка отвечает за вывод всех мета-данных.

В том случае, если у вас установлена какая-то сторонняя тема, то, скорее всего, у вас эта функция будет выглядеть иначе. Например, это может быть строка the_author() или любая другая, в которой есть слова «entry_meta». Но, чтобы не удалить лишнего и не испортить сайт, лучше перестрахуйтесь и закомментируйте найденную строку, поставив перед ней два слеша «//», а потом проверьте, все ли получилось.

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

• index.php (Главная страница);
• single.php (Страница записи);
• category.php (Категории);
• page.php (Пользовательская страница);
• archive.php (Архив записей).

В дополнение, если вы хотите убрать дату размещения статьи в сторонней теме, то вы можете так же поискать в этих файлах следующие строки: echo get_the_date(), the_date(), the_modified_date() и the_time(). Они все отвечают за вывод даты, только используются по-разному. Если найдете одну из них, то останется только удалить или закомментировать ее.

Что такое неработающие ссылки?

Неработающая ссылка сродни поездке в лифте, который никуда не уходит.

Вы врываетесь, желая добраться до своего этажа, но он отказывается сдвинуться с места.

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

Это происходит, когда браузер не может найти запрошенное содержимое веб-страницы.

Материал в этом случае был либо удален, либо перенесен на новое место.

Неработающие ссылки можно разделить на две категории:

• Внутренние ссылки — это ссылки с одной страницы вашего сайта WordPress на другую страницу вашего сайта. Внутреннее соединение — это, например, ссылка с вашей домашней страницы на страницу ваших услуг.
• Внешние ссылки — это ссылки на другие веб-сайты из вашей учетной записи WordPress. Внешняя ссылка — это, например, ссылка со страницы ваших продуктов на страницу Amazon.

Есть множество других причин неработающих ссылок на страницах WordPress, в том числе:

• URL был написан с ошибкой. Неправильные URL-адреса могут отправить пользователей на неправильную страницу или привести к ошибке 404.
• Распространение системы доменных имен (DNS). Перенос доменного имени на новый хост займет до 48 часов и может привести к ошибкам на вашем сайте.
• Будет некоторое время простоя, но только на короткий период времени. Когда сервер, на котором размещен веб-сайт, выходит из строя, сайт становится недоступным.
• Проблемы с совместимостью. Темы и плагины WordPress, несовместимые с файлами вашего сайта, вызовут проблемы с вашей структурой URL.
• Состав постоянных ссылок изменился. Это постоянные ссылки на сообщения вашего блога на вашем веб-сайте. Неработающие ссылки станут результатом неправильного изменения их структуры.

Поиск и исправление неработающих ссылок на вашем веб-сайте может показаться сложной задачей, но для этого есть три важные причины:

• Неработающие ссылки раздражают ваших потенциальных заказчиков и клиентов: если клиенты ищут подробности или пытаются совершить покупку, но при этом у них прерывается соединение, они вряд ли вернутся на ваш сайт. Они пойдут к конкуренту, где легко смогут сделать покупку.
• Неработающие ссылки влияют на ваш рейтинг в Google СЕО: клиенты могут покинуть ваш сайт, если зайдут в тупик. Это увеличивает показатель отказов, что является одним из факторов, которые Google учитывает при определении вашего рейтинга в поиске. Google сделает вывод, что пользователи покидают ваш сайт, потому что они не смогли найти информацию, которую искали, и в результате ваш сайт будет вытеснен в результатах поиска. Потенциал вашей страницы для индексации также снижается из-за разрыва связей. Страница с неработающей ссылкой не будет проиндексирована ботами Google, что приведет к ухудшению результатов поиска.
• Вы теряете деньги из-за битых ссылок: это суровая правда. Клиенты не будут покупать у вас, если не смогут найти на вашем сайте то, что им нужно. Если Google считает, что ваш веб-сайт бесполезен, он не будет отображаться в топе результатов поиска для потенциальных клиентов. Вот почему вам нужно исправить эти проблемы, прежде чем вы в конечном итоге потеряете из-за них деньги.

Выводы

Теперь мы точно знаем, что битые URL – это отрицательное явление, способное навредить не только странице, но и всему домену в целом. Их не любят поисковики, они раздражают посетителей. Ухудшение пользовательского опыта – одна из главных проблем битых ссылок.

Решить ее можно, как минимум, при помощи четырех вариантов:

• удалить ссылку;
• сделать перенаправление;
• заменить битый линк на рабочий;
• вручную восстановить удаленную страницу.

Таким образом, всегда можно найти наиболее подходящее решение и сделать сайт удобнее для целевых посетителей.

В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров

Источник