Перевод WordPress на https

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

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

Итак, мне понадобиться сделать следующие шаги:

Создать резевную копию
Получить ssl-сертификат
Установить ssl-сертификат
Поменять ссылки в контенте с http на https
Убедиться, что нет ситуации «Loading mixed»
Редирект на https
Меняем robots.txt
Переезд в поисковиках

Резервная копия

Первым делом подстелю соломки — обзаведусь резервной копией. Можно воспользоваться специальным плагином, например, UpdraftPlus WordPress Backup Plugin, но я срежу угол. На хостинге я переезд сделаю, как только хостер сделает ночную резервную копию сайта. А на локале — делаю снимок виртуальной машины, завершив предварительно её работу. Один клик — и я вернусь в исходное положение, если что-то пойдет не так.

Получение ssl-сертификата

Генерирую ssl-сертификат Let’s Encrypt согласно своей же инструкции.

Установка ssl-сертификата

У меня хостинг в Ru-Center, поэтому пользуюсь той же инструкцией, ссылка на которую дана выше.

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

Лирическое отступление: установка ssl-сертификата на Nginx

На своём компьютере для dev-экспериментов в виртуальной машине (Ubuntu Server) я попытался воспроизвести максимально похожую конфигурацию Apache и Ngnix хостера. Расхождения есть, и главное из них — у меня нет панели управления, поэтому ssl-сертификат надо ставить руками.

Для Apache я ничего не меняю, так как в тандеме с Nginx с внешним миром общается именно последний, и настройку ssl надо делать в нём (Nginx обрабатывает всю статику, всё остальное проксируется в Apache).

Поэтому открываю файл /etc/nginx/sites-available/my-site.conf и добавляю в него строчки для ssl (слушать нужный порт 443 и где лежат сертификаты:

server {
    listen 192.168.56.101:80;
    listen 192.168.56.101:443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/my-site.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/my-site.ru/privkey.pem;

    server_name my-site.ru www.my-site.ru;
    ...
}

Файлы действующего сертификата certbot «кладёт» в папку /etc/letsencrypt/live/my-site.ru/ (в реальности, он новые сертификаты складывает в /etc/letsencrypt/archive/my-site.ru/, а в live делает ссылки на новые экземпляры).

В общем файле настроек Nginx (/etc/nginx/nginx.conf) я тоже чуть поправлю — добавлю список шифров — ssl_ciphers:

    ...
    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;
    ...

Тестирую файлы конфигураций:

> sudo nginx -t

Всё хорошо, поэтому перегружаю Nginx:

> sudo systemctl restart nginx

Проверяю доступность сайта по https-протоколу — всё работает.

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

Поднятие https транспорта на сайте — это меньше половины дела. В постах и на других страницах есть перекрестные ссылки, картинки, чьи пути содержат http://. В реальности мест, где они встречаются в базе WP много. Можно попытаться сделать это вручную, но всё осложняется тем, что эти строчки могут храниться в сериализованном виде. Поэтому я воспользуюсь специальным плагином Better Search Replace. С помощью него сначала прогоню замену http://www.my-site.ru на https://my-site.ru на холостом ходу (так я заодно с http избавлюсь и от www).

Запуск Better Search Replace

Запускаю и получаю ошибку: «Ошибка обработки вашего запроса. Уменьшите значение «Максимальный размер страницы» или обратитесь в поддержку».

An error occurred processing your request. Try decreasing the «Max Page Size», or contact support.

Решить проблему можно разными способами:

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

Первый и третий пункты мне кажутся самыми симпатичными. Я заметил, что на холостом ходу сбой происходит на табличке wp_posts, поэтому для неё я снижу размер страницы до 15’000, а остальные буду обрабатывать на стандартных 20’000. По факту на рабочем сайте для wp_posts пришлось снижаться до уровня 12’000.

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

Понятно, у меня в .htaccess прописан редирект с my-site.ru на www.my-site.ru. Закомментариваю эти строчки, порегружаю странцу и попадаю на форму авторизации. Тоже обяснимо — cookies авторизации относятся к сайту на http, а для https они не действуют. Короче, надо залогиниться.

Логинимся и возвращаемся в плагин. В его настройках уменьшаем размер страницы до 15’000, сохраняем изменения, и проделываем операцию по замене для wp_posts.

Чтобы убедиться, что замена с уменьшенным размером страницы не потеряла что-то по пути, захожу в phpMyAdmin и выполняю запрос:

SELECT * FROM `wp_posts` WHERE post_content LIKE "%http://www.my-site.ru%"

Движок пишет, что ничего не нашёл. А вот такая проверка находит у меня три записи:

SELECT * FROM `wp_posts` WHERE post_content LIKE "%http://my-site.ru%"

То есть надо повторить замену и для варианта — http://my-site.ru на https://my-site.ru. После обработки повторная проверка показывает, что записей с http://my-site.ru и http://www.my-site.ru в их содержимом нет, остались только https://my-site.ru.

Для успокоения души я решил ещё поискать строчку www.my-site.ru

SELECT * FROM `wp_posts` WHERE post_content LIKE "%www.my-site.ru%"

И нашёл 6 штук!!!

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

Проверка Loading mixed

Захожу на публичный раздел сайта по протоколу https — хочу увидеть есть в браузере рядом с адресом замочек. На главной он обычный, то на конкретной статье он оказался с восклицательным знаком, кликнув на который я увидел.

Перемешивание контента по защищённому и не защищённому транспорту

Предупреждение о смешанном контенте можно также увидеть в инструментах разработчика (F12) в закладке Network. Текстовый поиск по html-коду страницы также может подсказать, где подмешивается небезопасный (http) контент.

Источников же такого подмешивания может быть множество:

плагины (о кривых руках разработчиков мы не говорим, в настройках могут быть указаны пути с http, которые следует поправить);
виджеты (особенно, если вы вставляете в них html-код, содержащий статичные ссылки с протоколом http);
файл functions.php темы (вообще он не должен быть источником таких проблем, если пути прописываются через глобальные переменные или функции WP).

В моём случае оказалось, что Yoast SEO вставляет ссылку на логотип с http. Зашёл в настройки Yoast SEO -> Общие -> Первая настройка -> Представление сайта и там перевыбрал картинку логотипа.

В одном из плагинов, общающихся с VK API, был прописан callback-маршрут с http. Поправил.

Также в плагине транслирующем статьи в Яндекс-Новости и Mail-Новости поправил адрес rss-ленты, обновив в личных кабинетах источник ленты.

Редирект на https

Прописал принудительную переадресацию www -> без www и http -> https в .htaccess, как было описано здесь.

Поправки в robots.txt

Поменял

Host: www.my-site.ru
Sitemap: http://www.my-site.ru/sitemap_index.xml

на

Host: https://my-site.ru
Sitemap: https://my-site.ru/sitemap_index.xml

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

Переезд в поисковиках

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

Переезд в Yandex

В Яндекс.Вебмастере: Индексирование -> Переезд сайта я отметил https и снял галочку с www. Сохранил. Система сообщила: «В ближайшее время в результатах поиска вместо домена www.my-site.ru появится https://my-site.ru.»

Здесь же Индексирование -> Файлы Sitemap добавил новую карту сайта с https.

В Яндекс.Метрике я, кстати, также поменял адрес сайта в настройках счётчика.

P.S. В интернете советуют сначала в Яндекс.Вебмастере добавить дубль — сайт с https://my-site.ru и только через некоторое время, когда весь трафик пойдет по https, делать переезд. Но интерфейс поменялся, и я решил сделать как сделал. День первый — полёт нормальный, т.е. трафик не упал, ИКС пока не поменялся

Переезд в Google

В Google Search Console -> Индексирование -> Файлы Sitemap можно добавить ссылку на новую карту сайта с https.

~~~

Вот и всё!