Блог Александра Кадырова

12.09.201312.09.2013

9 плохих советов при создании резервных копий

Перечислим несколько плохих советов по резервному копированию сайта на WordPress.

Не делать резервные копии
Не делать полные резервные копии
Используйте только ручное резервное копирование
Нерегулярное резервное копирование
Надейтесь на резервные копии вашего хостинг-провайдера
Сохраняйте ваши резервные копии только на хостинге
Не храните резервные копии в безопасности
Не тестируйте сделанные резервные копии
Не храните долгое время резервные копии

01. Не делать резервные копии

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

Совет: Настройте резервное копирование!

02. Не делать полные резервные копии

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

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

Совет: Настроите полное резервное копирование вашего сайта.

03. Используйте только ручное резервное копирование

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

В чём же проблема?

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

Совет: Позвольте компьютеру делать то, что он делает лучше: автоматизируйте резервное копирование!

04. Нерегулярное резервное копирование

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

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

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

Темы и плагины редко изменяются
Резервные копии загруженных файлов можно разбить на годовые и по-месячные копии, если это необходимо
Либо же можно хранить данные загруженных файлов только за последний месяц
Базу данных необходимо копировать ежедневно, если ваш сайт активно комментируется и регулярно добавляются новые материалы

Совет: Определитесь со временем создания резервных копий вашего сайта и настройте их по расписанию.

05. Надейтесь на резервные копии вашего хостинг-провайдера

Многие хостинг-провайдеры создают автоматически резервные копии сайтов своих заказчиков.

Если это так, вы всё равно должны задать себе несколько вопросов:

Что вы будете делать, если они не смогут предоставить резервную копию сайта?
Если однажды компания обанкротится или закроется в один день?
Если их взломают и уничтожат все данные о резервных копиях?
Если они хранят данные только за последний месяц, а вам необходимы квартальные копии?
Если резервные копии не создаются в полном объёме по разным причинам?
А что конкретно они сохраняют?
Как часто создаются резервные копии?
Как долго хранятся резервные копии вашего сайта?
Могут ли они восстановить какой-то конкретный файл или таблицу из базы данных?
Можете ли вы проверить, что они восстановят ваши данные?

Вы должны контролировать эту ситуацию.

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

Совет: Резервное копирование вашего хостинг-провайдера будет отличным дополнением к вашим собственным копиям. Но не позволяйте им быть единственным способом архивирования файлов.

06. Сохраняйте ваши резервные копии только на хостинге

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

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

Именно по этой причине мы настоятельно рекомендуем иметь несколько мест для хранения резервных копий вашего сайта. Хранение файлов на хостинге может быть хорошей идеей, при наличии второй копии в облачных хранилищах (Dropbox, Amazon S3, Google Drive), либо на внешнем FTP или на вашем компьютере.

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

Если вы параноик, вы можете даже сделать копию вашего сайта на USB-флешку или записать на DVD-диск и убрать в сейф. Поэтому вы должны знать и понимать, сколько стоит ваш бизнес (веб-сайт).

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

07. Не храните резервные копии в безопасности

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

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

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

Гораздо безопаснее будет загружать файлы архивов через Secure FTP на удалённый хостинг или сервер, либо же хранить копии в сервисе Dropbox, Amazon S3, Google Drive.

Совет: Убедитесь, что ваши резервные копии хранятся в надёжном месте.

08. Не тестируйте сделанные резервные копии

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

Тестирование возможности восстановления служит двум целям:

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

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

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

Совет: Убедитесь, что вы сможете восстановить ваш сайт из резервной копии!

09. Не храните долгое время резервные копии

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

Интернет-взломщики, которые производят атаки на ваш сайт с целью финансовой выгоды (воровство трафика, повышая рейтинг своего сайта в поисковой выдаче, размещение объявлений) не хотят, чтобы вы узнали о взломе вашего сайта.

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

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

Я рекомендую вам использовать сочетание нескольких типов резервного копирования:

Ежедневные копии, хранящиеся 2 недели
Еженедельные копии, хранящиеся 3 месяца
Ежемесячные копии, хранящиеся 2 года

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

Конечно же, вы можете настроить срок и периодичность резервного копирования в соответствие с вашими потребностями.

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

Совет: Убедитесь, что ваша стратегия резервного копирования позволяет вернуться к копиям большой давности.

Заключение

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

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

12.09.201323.02.2016

Форма обратной связи на WordPress

Для создания формы обратной связи существует множество плагинов (настройка плагина Contact Form 7). Мы же рассмотрим самый простой в настройке — плагин Contact Form.

Contact Form позволяет создавать и настраивать форму обратной связи, но при этом он достаточно легкий и не грузит сайт. В данном уроке рассмотрим, как использовать плагин Contact Form для создания формы обратной связи.

Будем создавать форму вот такого вида:

Установка плагина

В Панели управления в разделе «Плагины» выбираем пункт «Добавить новый».
Вбиваем в поисковую форму «Contact Form» и нажимаем кнопку «Поиск плагинов».
В списке находим нужный нам плагин и жмем ссылку «Установить».
Нам нужен плагин Contact Form, а не Contact Form 7, это два различных плагина.
После установки активируем плагин.

Создание формы (настройка плагина)

После установки и активации плагина в меню появится раздел «BWS Plugins».

Выбираем его, а в нем подраздел «Контактная Форма».
Откроется страница с настройками плагина, их не очень много, тем не менее, рассмотрим только самые необходимые.
В первую очередь, указываем электронный адрес, на который будут приходить письма. И сразу ставим галочку напротив пункта «Дополнительные настройки».
«Использовать этот email:» — здесь указываем адрес электронной почты, на который будут приходить оставленные посетителями сообщения.
«Отобразить блок Прикрепить файл» – отмечаем пункт, если в форме обратной связи необходима возможность к сообщению прикреплять файлы.
«Изменить текст для поля ОТ в письме» — здесь можно указать определенный текст, который будет отображаться в поле «От» письма вместе с e-mail адресом. Удобно сюда вставить название сайта.

Например, для сайта site.ru мы вводим – «Сообщения с site.ru».
Это позволит нам сразу определять, откуда пришло письмо.
«Выберите email для поля ‘FROM’ письма» — выбираем из двух вариантов.
В первом случае в поле адрес будет отображаться e-mail человека, который отправил сообщение с сайта. Во втором – указанный нами e-mail.
«Отобразить поле для телефона» — добавления к имеющимся полям дополнительного поля, в котором указывается телефон.
«Обязательные поля» — отмечаем, какие поля являются обязательным для заполнения (если посетитель их не заполнит, форма откажет ему в отправке сообщения).
«Отображение дополнительной информации в письме» — стоит отметить данный пункт, если есть необходимость просматривать дополнительную информацию об отправке сообщений через обратную связь (когда они были отправлены, с какого ip-адреса и т.д.).
«Языковые настройки для названия полей в форме» — выбор языка, на котором будет форма обратной связи.
«Изменить названия полей контактной формы и сообщений об ошибках» — отметив данный пункт, можно изменить надписи полей по своему усмотрению.
«Действие после отправки письма» — вы можете выбрать один из двух вариантов.
В первом случае посетитель увидит указанный вами текст и останется на странице обратной связи, а во втором – будет перенаправлен на указанную страницу.
Сохраняем настройки, нажав внизу страницы кнопку «Сохранить изменения».

Вставка созданной формы

Чтобы вставить созданную форму обратной связи на страницу или в запись достаточно в визуальном редакторе переключиться на вкладку «HTML».
И в нужном месте вставить код contact_form.

Код должен быть заключён в квадратные скобки!
Вот так будет выглядеть наша форма на странице.

Остались вопросы? Задайте их в комментариях! :-)

Если вы хотите поблагодарить меня за материал — можете сделать это здесь :-)

03.09.201319.11.2013

Вывод META-данных для категорий

Долгое время я пользовался записью «МЕТА данные для категорий и тегов» Александра Тодосийчука, но каждый раз искать несоответствия в коде примера стало надоедать.

Поэтому решил сделать обновляемый пост на своём блоге, чтобы каждый раз при обновлении плагина All in One SEO Pack (дальше по тексту — AIOSP) иметь под рукой актуальную информацию о необходимых изменениях.

Данная статья более не актуальна, т.к. перешёл на новый SEO плагин: WordPress SEO by Yoast. Скорее всего материалы инструкции не будут работать с новыми версиями AIOSP.

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

Плагин CategoryTinymce

Для удобства написания текстов в разделе «Рубрики» и «Метки» существует плагин CategoryTinymce. Он добавляет возможность писать текст с помощью удобного редактора TinyMCE:

Это всё хорошо, но не стоит забывать и о мета-тегах, а именно выводе корректных title и description для этих страниц.

Плагин Category SEO Meta Tags

Для решения этой задачи существует плагин Category SEO Meta Tags. Устанавливаем и активируем его как обычно, ничего нового вы тут не узнаете.

После этого можем зайти в раздел «Записи» — «Рубрики» вашего блога, выбрать нужную рубрику и увидим следующее:

Таким образом, с помощью этого плагина мы добавляем в WordPress возможность заполнять нужные нам значения meta-тегов.

Но есть одно «но» — нужно внести несколько правок в файл плагина AIOSP, чтобы исключить дублирования лишних тегов и активировать работу плагина Category SEO Meta Tags.

На момент написания этой заметки версия AIOSP на моём блоге 2.0.3.1 и все изменения касаются именно её. Если вы читаете эту заметку и версия вашего плагина отличается — напишите в комментариях, обновлю пост в соответствие с новой версией.

Добавляем фильтр для плагина Category SEO Meta Tags

Подключаемся к хостингу через FTP или SSH, заходим в директорию плагина AIOSP: /wp-content/plugins/all-in-one-seo-pack/ и открываем на редактирование файл aioseop_class.php.

Находим строку 1752 и вставляем сразу после неё код:
[php]$title = apply_filters(‘aioseop_category_title’, $title);[/php]

В итоге получится следующий код:
[php]$title = $this->apply_page_title_format( $title );
$title = $this->paged_title( $title );
$title = apply_filters(‘aioseop_category_title’, $title);
$title = apply_filters( ‘aioseop_title_page’, $title );
[/php]

Теперь перемещаемся к строке 1775 и добавляем после неё код:
[php]$title = apply_filters(‘aioseop_title’, $title);[/php]

Получается следующий код:
[php]$title = $this->paged_title( $title );
$title = apply_filters(‘aioseop_title’, $title);
return apply_filters( ‘aioseop_title_single’, $title );[/php]

Я искал эти строки по фразе «paged_title», именно после неё необходимо добавлять наши фильтры.

Убираем дублирование meta-тега description

После выполнения предыдущего пункта, скорее всего у вас на странице будет два meta-тега description, первый от него плагина, второй от AIOSP, выглядеть это будет примерно так:

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

Для этого находим строку 1156:
[php]$meta_string .= sprintf( "<meta name=\"description\" content=\"%s\" />\n", $description );[/php] Её быстро найти можно с помощью фразы «meta name».

И обрамляем её условием if:
[php]if (!is_category()) {
$meta_string .= sprintf( "<meta name=\"description\" content=\"%s\" />\n", $description );
}[/php]

Всё, теперь должно работать как нам надо.

03.09.201330.08.2013

Как запретить публикацию записи без миниатюры

В своей RSS-подписке зарубежных блогов о WordPress обнаружил крайне интересный плагин — Require Featured Image. Из названия становится понятным, что он делает — запрещает публикацию записи без установки миниатюры.

В этом случае на странице добавления записи будет висеть вот такое вот красное сообщение и кнопка «Опубликовать» станет недоступной:

Многие темы на WordPress сделаны таким образом, что выводят миниатюры на главной или в режиме блога, например, вот так это выглядит на моём блоге:

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

Поэтому, если ваша тема подразумевает использование и отображение миниатюр, настоятельно рекомендую установить данный плагин. Называется он Require Featured Image.

20.08.201326.08.2013

Запрещаем редактирование файлов через Консоль WordPress

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

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

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

Речь идёт об этой возможности WordPress:

После запрета редактирования файлов через Редактор WordPress, файлы можно будет изменить лишь через FTP, либо же SFTP/SSH вашего хостинга. Помните об этом.

Для активации этой возможности добавьте следующий код в файл wp-config.php:
[php]define(‘DISALLOW_FILE_EDIT’, true);[/php]

Не забывайте делать резервные копии файлов перед изменениями!

20.08.2013

Как ограничить количество попыток входа

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

Сегодня рассмотрим один простой, но очень эффективный плагин, который позволяет ограничивать число попыток входа в ваш WordPress. Название этого плагина — Limit Login Attempts.

Устанавливается он как и все плагины в WordPress — через раздел «Плагины» — «Добавить новый», вводите имя плагина и после этого активируете его.

Принцип действия плагина очень простой — в настройках устанавливаете допустимое количество раз, сколько можно ввести неправильный пароль и время блокировки. Как только человек введёт неправильно логин и пароль указанное количество раз, доступ для его IP адреса будет заблокирован на указанное вами время. Всё просто и понятно.

Заходим в «Настройки» — «Limit Login Attempts»
Вводим желаемые параметры для блокировки
Лично я предпочитаю использовать следующие параметры:

После этого нажимаете на кнопку «Изменить настройки» и можете радоваться.

Теперь при вводе неправильного логина или пароля будет выводиться следующее сообщение:

Вы приблизились ещё на один шаг к максимальной защите своего сайта на WordPress!

14.08.201325.05.2017

Исправляем ошибку установки соединения с базой данных

Ссылка на оригинальную статью

Эта статья является переводом оригинальной статьи How to Fix the Error Establishing a Database Connection in WordPress из блога WPBeginner.

Если вы занимаетесь разработкой своего сайта сначала на локальном компьютере, то при переносе на хостинг практически всегда столкнётесь с ошибкой установки соединения с базой данных, в английской версии WordPress она звучит так: Error establishing a database connection.

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

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

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

Проявляется ли проблема в wp-admin

Первым делом стоит убедиться, что данное сообщение об ошибке выводится и на сайте, и в административной панели. Для этого попробуйте зайти в админку сайта (wp-admin).

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

Если же вы получили сообщение «Одна или несколько таблиц базы данных недоступны», тогда нужно будет выполнить автоматическое исправление таблиц механизмами WordPress.

Для этого нужно выполнить следующие шаги:

Открыть файл wp-config.php и добавить в него следующую строку:
[php]define(‘WP_ALLOW_REPAIR’, true);[/php]
После этого зайти по адресу http://ваш-сайт.ru/wp-admin/maint/repair.php
Нажать кнопку «Починить базу данных» и дождаться завершения операции.
Это может занять некоторое время, в зависимости от размера данных в таблицах базы вашего сайта.

Запомните, что доступ к этой странице может получить любой пользователь вашего сайта, обратившись к ней по прямому адресу. Поэтому после исправления ошибки обязательно удалите строку WP_ALLOW_REPAIR из файла wp-config.php!

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

В ином случае рекомендую продолжить чтение заметки.

Проверка файла wp-config.php

Файл wp-config.php один из самых важных файлов в WordPress — именно в нём прописаны все параметры для нормальной работы вашего сайта. Все настройки для подключения к базе данных тоже находятся именно в этом файле.

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

За настройки подключения к базе данных MySQL отвечают следующие константы:
[php]define(‘DB_NAME’, ‘название базы данных’);
define(‘DB_USER’, ‘пользователь базы данных’);
define(‘DB_PASSWORD’, ‘пароль пользователя’);
define(‘DB_HOST’, ‘localhost’);[/php]

Имейте в виду, что в константе DB_HOST не всегда будет значение localhost, это может быть и IP адрес сервера, либо же какой-то другой адрес, если вы используете хостинг от МастерХост, например. В любом случае, эту информацию вам нужно уточнить у вашего хостинг-провайдера, либо в личном кабинете вашего хостинга.

Но для большинства хостингов значение DB_HOST будет всё-таки localhost и чаще всего изменять его не придётся.

Стоит упомянуть, что в некоторых случаях вам нужно будет указать нестандартный порт для подключения к MySQL, это делается следующей командой в файле wp-config.php:
[php]define(‘DB_HOST’, ‘127.0.0.1:3351’);[/php] , где 3351 — порт, на котором «прослушивается» MySQL-сервер. Уточните это значение у вашего системного администратора.

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

Проверка работоспособности MySQL сервера

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

Если у вас виртуальный сервер (VPS) и вы используете cPanel или ISPManager, то ссылка на phpMyAdmin будет на главной странице панели управления сервером.

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

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

Создаёте на компьютере файл, назовём его test.php и добавляем в него следующий код:
[php]<?php
$resource = mysql_connect(‘localhost’, ‘пользователь’, ‘пароль’);
if (!$resource) {
die(‘Ошибка при подключении: ‘ . mysql_error());
}
echo ‘Подключено успешно!’;
mysql_close($resource);[/php] Вместо «пользователь» и «пароль» укажите свои данные для подключения к базе данных. Если у вас VPS — можете использовать учётную запись root.
Загружайте этот файл на FTP вашего хостинга
Открывайте в браузере адрес http://ваш-сайт.ru/test.php
Если на экране отразилось «Ошибка при подключении», то рядом с ней будет выведено сообщение (чаще на английском), по которой в Google или Яндекс можно найти какие-то комментарии
Если же отобразилось «Подключено успешно», тогда внесите используемые ваши логин и пароль для подключения к базе данных в файл wp-config.php, как в позапрошлом шаге

Если при открытии этого скрипта вы получили сообщение: #1045 – Access denied for user ‘foo’@’%’ (using password: YES), это значит вы используете неправильный логин или пароль. Проверьте ещё раз и попробуйте снова.

В случае, если не удалось подключиться к базе данных ни через phpMyAdmin, ни через файл test.php — рекомендую обратиться в службу поддержки вашего хостинг-провайдера и разобраться в чём дело по телефону. У нормального провайдера круглосуточно работает служба поддержки.

Решения, которые помогли другим

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

Обновление настройки в wp_options

Некоторым пользователям помогало выполнение следующего запроса к базе данных через phpMyAdmin:
[sql]UPDATE wp_options SET option_value=’адрес_вашего_сайта’ WHERE option_name=’siteurl’;[/sql]

Вместо «адрес_вашего_сайта» укажите адрес сайта, чтобы запрос выглядел так:
[sql]UPDATE wp_options SET option_value=’http://ваш-сайт.ru’ WHERE option_name=’siteurl’;[/sql]

Имейте в виду, что таблица wp_options может называться иначе, если вы изменяли префикс таблиц WordPress. В этом случае, вместо wp_ укажите свой префикс.

Подключение под root к базе данных

Если у вас VPS и удалось подключиться с помощью файла test.php к базе данных под пользователем root — тогда попробуйте использовать эти данные для подключения к базе данных вашего сайта через wp-config.php.

Если всё пройдёт нормально и сайт заработает, тогда рекомендую зайти в phpMyAdmin, создать нового пользователя и указать логин и пароль нового пользователя в wp-config.php.

Никогда не работайте под учётной записью суперпользователя на вашем боевом сервере.

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

Если вы знаете ещё какие-то пути решения это проблемы — напишите о них в комментариях и я обновлю заметку.

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