3 распространенные ошибки WordPress и как их исправить, CMS и движки для сайтов

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

Крушите собственный стол для работы в приступе отчаяния? Обидная ошибка стала причиной тому, что вы разлюбили WordPress ?

WordPress – это отличная платформа для блогов и система управления контентом, но нет ПО без ошибки. В данной заметке рассматриваются искусные решения трех самых популярных ошибок WordPress : « Белый экран смерти », « Внутренняя ошибка сервера » и « Ошибка установки соединения с БД ».

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

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

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

Часто трудностью, стоящей за этой ошибкой, считается достижение лимита доступной памяти. Чтобы сделать больше объем доступной памяти, поищите файл wp-config.php : перейдите к корневому каталогу вашего сайта при помощи FTP -клиента или файлового менеджера на панели управления хостингом. В середине ключевого php тега необходимо будет добавить строку кода, которая повысит максимальный лимит памяти до 64 МБ:

Можно задать и больше, чем 64 МБ, однако это уже зависит от вашего сервера, благодаря этому 64 МБ, в основном, считается неопасным вариантом. Возможно, увеличение памяти не помогло, или вы уже задали лимит выше 64 МБ? Тогда проблема может заключаться в плагинах или вашей теме.

Если у вас обеспечивается доступ к панели администрирования, проблемы с плагинами легко решаются. Просто перейдите в раздел « Плагины » ( Plugins ) и отключите заключительный установленый плагин. Если это не помогло, можно выключить все плагины вашего сайта, для этого выдилите их, поставив галочку в самом верху, и подберёте команду « Выключить » ( Deactivate ).

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

Зайдите в каталог wp-content/plugins , в котором содержатся все установленные плагины. Просто переименуйте директорию plugins , к примеру, добавив слово в конец подобным образом, что plugins станет plugins-test .

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

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

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

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

Все еще бьетесь об стол в отчаянии? Есть иной вариант, который поможет — включение режима отладки.

Если решения, вышеприведенные, не помогли вам избавится от проблемы, тогда необходимо копать глубже. Процесс, описанный ниже, поможет вам выявить проблематику. Впрочем корректировка обнаруженных ошибок может «настойчиво попросить» от вас более специфичных знаний и способностей.

В первую очередь, откройте файл wp-config.php . И поищите в нем следующую строку:

Разместите ‘//’ в начале строки, так чтобы вышло:

Теперь эта строка закомментирована. Второй шаг: вставьте нижеприведенный код сразу же после этой строки:

Вот здесь вам будут нужны маленькие знания программирования. Действия, которые мы предприняли, позволят направить ошибки в файл с названием error.log ( который находится в папке wp-content ). Если вы не можете его отыскать, может, у Вас нет прав для его создания. Просто создайте новый файл error.log и задайте для него права доступа 666 .

Откройте файл error.log в текстовом процессоре и необходимо проверить на ошибки PHP . Если это то, что вы не знаете или в чем не уверены, то рациональнее обратиться к кому-нибудь за помощью.

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

Благодаря этому берем горячий напиток с большим содержанием кофеина, делаем глубокий вдох, и готовимся к предстоящему решению проблем. Есть ли хорошая новость? Да — некоторые подходы сходственны методам, описанным в прошлом разделе.

Обратитесь к секциям « Плагины » и « Темы » из прошлого раздела. Метод решения проблемы полностью подобен.

И опять, это решается также, как описано в прошлом разделе.

Дело не в ваших плагинах и не в теме? Тогда настало время проверить, не повреждён ли файл .htaccess . В первую очередь переименуйте данный файл — опять просто прибавьте в конец « temp » или что-то похожее. Не замечаете этот файл?

Тогда поймете, что вы включили опцию « отображать невидимые файлы ». Как собственно это сделать, зависит от вашего FTP -клиента, однако это очень легко. К примеру, в Filezilla , просто подберёте сверху « Сервер » ( Server ) и потом — « Демонстрировать невидимые файлы » ( Show hidden files ).

Теперь второй шаг — в первую очередь вернитесь назад в панель администрирования WordPress . Пройдите в « Настройки — Частые ссылки » ( Settings – Permalinks ) и потом сбросьте ваши частые ссылки. Нынче вы сгенерировали новую версию рабочего файла, благодаря этому вы можете проверить, была ли решена проблема.

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

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

Если вы видите такое же сообщение об ошибке на серверной стороне ( wp-admin ) « Ошибка во время установки соединения с БД » (« Error establishing a database connection »), тогда пропустите второй шаг.

Но если видите другое сообщение об ошибке, где рассказывается что-то вроде «….. The database may need to be repaired …» (« Возможно, требуется регенерация базы данных »), тогда вы обязаны добавить следующий код в ваш файл wp-config.php :

После перейдите на вот эту страницу http://www.адрес_вашего_сайта/wp-admin/maint/repair.php .

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

Вы меняли ваш пароль администратора, или пароль к базе данных? Если да, вам также необходимо добавить корректировки и в файл wp-config.php . Благодаря этому зайдите в ваш файл wp-config.php , и поймете, что эта информация верна:

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

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

Есть методы, разрешающие проверить, отвечает ли сервер MySQL на запросы, но ваш провайдер также может рассказать Вам это. Во всяком случае, поддерживать связь с вашим провайдером — это всегда хорошая идея, так отчего же не позвонить им?

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

Эта статья собой представляет перевод публикации « 3 common WordPress errors, plus how you can fix them » , подготовленной дружной командой проекта Интернет-технологии.ру