Актуальность перевода сайта на защищенный протокол HTTPS возрастает с каждым днем. Браузеры уже вовсю грозятся в будущем помечать сайты работающие на HTTP как незащищенные и уже ограничивают их функциональность просто отключая возможность использования, например, веб-камеры и микрофона, а Google не так давно заявил о приоритете HTTPS-сайтов в выдаче. Эти сигналы позволяют предположить в ближайшем будущем массовую миграцию сайтов на работу по защищенному протоколу и если вы еще не сталкивались с переездом на него, то самое время рассмотреть такую возможность и хотя бы ознакомиться с алгоритмом такого переезда.
В данной заметке я опишу свой опыт и затрону решение некоторых неочевидных проблем. Как я понял, необходимость некоторого обобщения полученного опыта имеется, так как на самом деле, предложенная в интернет информация не всегда оказывалась актуальной и приходилось собирать ее из разных источников, а техподдержка хостинга в ответ на вопросы просто самоустранялась, отсылая на форум поддержки CMS.
Так как вопросом переезда на HTTPS я озадачился впервые, то прежде всего набросал небольшой план действий, который выглядел просто и вполне логично:
- приобретение и установка SSL-сертификата через панель управления хостинга
- переключение сайта на HTTPS-протокол, согласно рекомендаций для WordPress
- организация 301 редиректа страниц сайта с протокола HTTP на HTTPS через файл htaccess
- перевод внутренних ссылок сайта из абсолютных в относительные
- оформление переезда на новый протокол для поисковых сервисов через файл robots и панель управления самого сервиса
В таком порядке мы и будем продвигаться.
Приобретение и установка SSL-сертификата
Сам сайт размещается на хостинге Timeweb, предлагаю рассматривать это не как рекламу, а как данность, поэтому речь будет идти о панели управления этого хостинга. Именно через эту панель управления и осуществлялся процесс приобретения и установки SSL-сертификата. Каких то проблем при этом не возникло. Стоит только указать, что сам алгоритм нигде не прописан и первоначально вызвал у меня некоторые вопросы относительно своих действий на определенном этапе, поэтому опишу чуть подробнее, чем возможно, это будет некоторым интересно.
Перед оплатой заказа SSL-сертификата я создал почту admin@codeseller.ru, на которую позже будут приходить письма необходимые для подтверждения заказа на SSL-сертификат.
Сразу после произведенной оплаты SSL-сертификата, никаких дальнейших инструкций я не получил, поэтому решил написать в поддержку для их получения. Ребята с техподдержки что то похимичили, зачем то зачислили мне средства опять на счет, затем заново списали их в оплату SSL-сертификата, а заказ оформленный мной ранее удалили и через некоторое время на созданную почту пришло письмо со ссылкой подтверждения, по которой я перешел и подтвердил свой заказ на создание SSL-сертификата. Хм, сделал вывод, что я что то сделал неверно при первоначально оформленном заказе.
Итак, через некоторое время техподдержка сообщила, что все в порядке - сертификат успешно установлен.
Переключение WordPress-сайта в режим HTTPS
Сразу сообщу, что это наверное самый сложный этап из всего плана действий, поэтому рассмотрю его наиболее подробно.
Идем в панель управления хостинга и переключаем работу сайта в режим HTTPS, далее идем в общие настройки сайта и изменяем "Адрес WordPress (URL)" и "Адрес сайта (URL)" с учетом протокола HTTPS. После сохранения настроек сайт уходит в цикличную переадресацию или, как еще говорят, в луп.
Согласно полученной из различных источников информации в файле wp-config.php требуется также размещать код:
define('FORCE_SSL_ADMIN', true); if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='on';
Но у меня его размещение погоды не сделало, ничего не изменилось - сайт в жопе лупе.
На этом этапе поддержка хостинга послала меня куда подальше, а именно на форум поддержки WordPress, поэтому пришлось полагаться только на себя.
Опять полез в интернет, в том числе англоязычный, но предлагаемые решения не работали.
Пришлось включить мозги и начать анализировать ситуацию. Решил посмотреть, а что собственно возвращает фундаментальная для WP функция is_ssl() на данном этапе, в возвращала она false, т.е. говорила нам, что никакого HTTPS на сайте сейчас нет. Именно поэтому и возникла цикличная переадресация, WP не фиксировал, что HTTPS режим работает и перенаправлял на HTTP, а сервер гнул свою линию и с HTTP перенаправлял обратно на HTTPS.
Функция is_ssl() понимает, что сайт работает в режиме HTTPS, только если в глобальном массиве $_SERVER передается ключ "HTTPS" со значением "on". Стал смотреть, что передает действующий сервер в массиве $_SERVER, оказалось, что ключ HTTPS не передается, приехали.
В качестве выхода из сложившейся ситуации следует убедить функцию is_ssl() в том, что HTTPS у нас включен, поэтому необходимо в массив $_SERVER принудительно добавить данные о действующем режиме HTTPS.
Но нам надо как то отличать загружается наш сайт по HTTP или по HTTPS, стал выяснять как это сделать. Как оказалось в массиве $_SERVER этим отличием является ключ "HTTP_X_HTTPS", который передается сервером, и как я понял, характерен только для данного хостинга, если его значение 1, значит сайт загружается по протоколу HTTPS, если этого ключа нет, значит протокол HTTP.
Изменяю приведенный выше код в файле wp-config.php под существующие реалии:
define('FORCE_SSL_ADMIN', true); if (isset($_SERVER['HTTP_X_HTTPS'])&&$_SERVER['HTTP_X_HTTPS']==1) $_SERVER['HTTPS']='on';
Сайт заработал!
Ок, основная проблема решена, можно переходить к следующему этапу.
301 редирект через .htaccess
На данном этапе, наш сайт доступен как по HTTP, так и по HTTPS и основной задачей становиться организация редиректа со всех страниц с протоколом HTTP на те же самые страницы, но уже с протоколом HTTPS.
В интернете для решения этой задачи широко применяется код, размещаемый в файле .htaccess:
RewriteEngine On RewriteCond %{HTTPS} !'on' RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]100
Конечно же, этот код не работал у меня как нужно и отправлял сайт обратно в бесконечный луп. Если был сервер отправлял данные о включенном режиме HTTPS как $_SERVER['HTTPS']='on', то все заработало бы, но тут Timeweb детка, поэтому, зная нюансы описанные выше, приходится изворачиваться и менять общепринятый код редиректа таким образом:
RewriteEngine On RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]100
Вот так редирект замечательно заработал.
Вспомнив техподдержку хостинга еще раз, переходим к следующему этапу.
Переделываем внутренние ссылки из абсолютных в относительные
На этом этапе надо понимать, что сайт уже работает в режиме HTTPS, редирект настроен, но могут быть мелкие проблемы на каких то отдельных страницах сайта, где пути до отдельных скриптов, изображений или внутренних страниц сайта прописаны абсолютными ссылками с указанием старого протокола HTTPS. На таких страницах зеленый замок в адресной строке браузера не будет отображаться, а это будет означать, что безопасность на таких страницах является неполной. Для решения этой проблемы и необходимо перевести все внутренние ссылки в статьях и страницах сайта с абсолютных на относительные, например:
- http://codeseller.ru/polzovateli/ - абсолютная ссылка
- /polzovateli/ - относительная ссылка
В первую очередь, меня беспокоили пути до изображений в статьях сайта и отдельных страницах. Вручную мы ничего менять не будем, а лучше отправим SQL-запрос к базе данных для массового перевода ссылок в статьях и страницах сайта. Через phpmyadmin делаем запрос:
UPDATE `wp_posts` SET `post_content` = REPLACE (`post_content`, 'http://codeseller.ru/', '/')
После этого, все изображения и внутренние ссылки в статьях и страницах приобретут относительный путь, что нам и требовалось.
Далее, аналогичным образом решаем проблему с абсолютными путями до аватарок пользователей сохраненных через плагин WP-Recall и Ulogin. Для этого делаем два запроса:
UPDATE `wp_usermeta` SET `meta_value` = REPLACE (`meta_value`, 'http://codeseller.ru/', '/') WHERE `meta_key` = 'rcl_avatar' UPDATE `wp_usermeta` SET `meta_value` = REPLACE (`meta_value`, 'http://codeseller.ru/', '/') WHERE `meta_key` = 'ulogin_photo'
После этого, мне осталось лишь по мелочи поправить ссылки в футере, меню сайта и тп, чтобы можно было уже с уверенностью сказать, что о общем задача была решена.
Остался последний штрих.
Сообщаем поисковикам о переезде сайта на HTTPS
Для поисковиков сайт на HTTP и сайт с тем же самым доменом, но на HTTPS - два разных сайта, поэтому фактически мы не сообщаем о смене протокола, а сообщаем о совершенно новом сайте.
Для этого производим несколько несложных действий:
- прописываем в файле robots.txt новый host с протоколом HTTPS в качестве главного зеркала, например "Host: https://codeseller.ru"
- переходим в панель управления Яндекс.Вебмастера и вебмастера Google и указываем свое доменное имя на новом протоколе в качестве главного зеркала.
Вместе с настроенным выше 301 редиректом и этими настройками через некоторое время в результатах поиска все страницы с вашего сайта будут вести на страницы с протоколом HTTPS вместо HTTP. Правда, как предупреждают сами поисковики, сайт вполне может на некоторое время потерять свои позиции в поиске и поисковый трафик просядет, но затем позиции будут восстановлены.
UPD: Решение проблемы с работой крона
Чуть позже, после переезда на HTTPS, обнаружил проблему в работе wp-cron на сайте. Пока проблема в работе крона от WordPress работающего в обычном режиме не решена, решил использовать альтернативный вариант, прописав в файле wp-config.php:
define( 'ALTERNATE_WP_CRON', true );
События крона стали выполняться, но были замечены некоторые проблемы с работой определенных событий. В результате анализа выявил некорректную работу(?) стандартной wp-функции get_posts(), которая вызывалась внутри этих событий. В качестве решения пришлось написать прямой запрос к БД на получение необходимых данных из таблицы wp_posts. После этого проблему в работе крона на сайте можно было считать решенной.
Хотя, возможно чуть позже, удастся выявить причину неработоспособности крона в обычном режиме. Если кому то будет интересно, то удалось выявить проблему в работе функции wp_remote_post(), которая используется в обычном режиме. Работа функции заканчивается ошибкой и возвращает сообщение о слишком большой кол-ве переадресаций, причину этого выявить пока не удалось.
Мы подошли к концу статьи, надеюсь кто то найдет ее полезной. Во всяком случае, я бы хотел наткнуться на нее во время своих поисков. Если у кого то будут замечания по содержанию или вопросы жду в комментариях.
Удачи с переездом на HTTPS.
Поздравляю с переездом. Вообщем интересно. Меня только, что заинтересовало? А перевод внутренних ссылок сайта из абсолютных в относительные обязательно нужен? Я этого у себя не делал, когда свой сайте переводил на https.
Это не критичный для переезда момент, но браузер в консоли панели управления будет ругаться на такие ссылки в контенте и не будет показывать зеленый замок в адресной строке, что будет означать, что на данной странице безопасность обеспечивается не полностью.
Да я в курсе этого я просто переписал во всех ссылках http на https
В дополнение, в переезде есть много нюансов... Как твердит google да и другие поисковые системы, мол мы будем поднимать сайты c https выше в поиске... Делаем всё по рекомендациям многоуважаемого googla. Настраиваем редиректы, радуемся проделанной работе. И наблюдаем как твой сайт проседает в поиске и теряет поискового трафика 30%. Вот такая палка с двух концов. Хочешь как лучше, а получается как всегда. Будем надеется, что это явление временное. ИМХО.
Андрей у Вас как с трафиком обстоят дела после переезда?
собственно, это уже второй переезд в этом году. Первый - смена доменного имени, в результате поисковый траффик просел на 50%, но затем несколько восстановился. После смены протокола такого резкого снижения не наблюдаю, но все равно, сейчас из поиска приходят на 30% меньше чем до первого переезда. Времени после смены протокола прошло не так много, поэтому надеюсь на восстановление всех показателей чуть позже.
Значит будем надеяться вместе, что трафик восстановится. 😉
Тут я посмотрел статистику за май во все года в мае трафик проседает. На улице тепло, хорошо, все из берлог вылезают ... Дачный сезон однако.
Когда переезжал на https заметил такой баг не знаю правда с чем он связан, когда домен использует www c https вход в личный кабинет через фронтенд wp-recall не работает корректно. Вход осуществляется, но после перехода на любую другую станицу сайта происходит "разлогивание". При попытке зайти через штатную форму wordpress данного бага нет. Сразу говорю, что это не кэширование (Использовал "голый" wordpress). Если домен по умолчанию без www, то фронтенд wp-recall работает. Данную тему я поднимал на форуме (Хотел ссылку прикрепить, не могу найти), но что-то ответа там не получил. Если будет интересно я дам доступ к сайту https c www.
Ответы на ваши созданные темы на форуме доступны вам в FEED сайта "Ответы на форуме"
Спасибо за наводку.
ссылка https://codeseller.ru/forum/ustanovka-i-nastroyka/sale-download-problema-pri-skachivanii/#p14135 там правда по ходу тема не много другая... Если, что могу потом отдельную тему создать.
Хорошая тема была поднята. Сам пытался годом ранее то же самое сделать, в итоге куча проблем была, ужс. В итоге вернул как былО.
Добрый день решил удалить свой недостаток решением проблемы переезда на HTTPS, так как некоторые страницы не были полностью переведены.
На данный момент сайт вообще выдал 500.
после действий что здесь написаны.
Если не трудно можете поделиться своим .htaccess
В конфиге я прописал 2 ваших кода про крон, и редект в админке чтобы не было желтого замка,
первый запрос в базу прошел, а вот второй выдал ошибку
Не после действий, что здесь написаны, а после действий, что вы произвели. Результат всегда будет зависеть от прямоты рук.
Все что необходимо знать о переезде описано в статье, мой htaccess вам ни к чему.
Ну благо есть бекапы 🙂
Тоже возникал такой вопрос для timeweb. Правда сделал до того, как увидел эту статью. Автору спасибо за подсказку с .htaccess, но "[R=301,L]100" - это не верно, нужно без "100", тогда работает.
Я сделал путем изменения /wp-includes/functions.php, в функции "function is_ssl()" сразу после объявления добавил текст:
if($_SERVER['HTTP_X_HTTPS']==1){
return true;
}
Тоже имеет место быть, но здесь не знаю, что будет после обновления. Оставил свой код, посмотрим.
И что самое интересное техподдержка хостинга присылает для переадресации именно такой код:
Хотя в итоге я для редиректа ничего в htaccess не прописывал, а указал его в настройках сайта панели управления хостинга.
Доброго времени суток. Так и не получилось перевести свой блог на https. Перепробовали много вариантов. В БД все ссылки заменены на https. Но при использовании выше описанных вариантов максимально чего добились это ошибки 500. В чем проблема ни как не поймем. Супорт хостинга молчит. Может сможете помочь?
Для хостинга sprinhost в файл wp-config.php необходимо прописывать
а в файле .htaccess прописываем:
Очень полезная статья!!! Почему она не в топе странно, я второй раз ее вообще в истории искал((
Подскажите, Андрей, пожалуйста. Благодаря Вам перешел – все работает кроме админки. Благодаря Вашему коду цикличность убрал, но теперь там сообщение "Извините, вам не разрешено просматривать эту страницу."
Подскажите, где его можно хоть копать? Уже день потратил. Оно появляется именно после изменения пути в настройках ВП или БД (wp-options). Все форумы перегуглил, буржуйсткие сайты... Проблема распространена и есть люди порешали, но никто нпотом не говорит как это сделал((
К сожалению или к счастью с такой проблемой я не сталкивался.
С доступом в админку возникла проблема после всех произведенных действий, но достаточно было почистить кеш и куки в браузере и доступ был восстановлен.
Я после перехода на https в wp-options изменений не каких не вносил, все прекрасно работает, может и вам не стоит не чего прописывать. Вот моя статья с видео по переезду на https, возможно поможет: web-revenue.ru/perevod-wordpress-sayta-s-http-na-https-lets-encrypt-za-7-minut
Если в указанных таблицах БД прописаны ссылки с явным указанием старого протокола, то изменения надо вносить.
В БД я все ссылки старые заменил (во всех таблицах), я не трогал файлы wp-config.php и прочие.
вам просто повезло находится на хостинге, где проблемы переезда хостинг берет на себя и решает без вашего участия. К сожалению, на других хостингах дела обстоят далеко не так, и за 7 минут без правки файлов указанных в статье никуда "переехать" не получится.
Есть смысл всем почитать вот эту новость https://wordpress.org/news/2016/12/moving-toward-ssl/
В кратце: Не будет сертификата на домене, в течении 2017г, начала и самого года, у вас не будет работать некоторые важные функции в WP. В итоге сертификат должен быть у всех, а хостинги не дающие оного, идут в "бан" системы.
SSL становится стандартом, пора к этому привыкать.
Это да, я имел ввиду почитать сомневающимся или откладывающим этот момент, время не осталось.
У меня хостинг бегет, там одним кликом мыши выдают ssl сертификаты на домены (бесплатно). После переезда на https, я вообще практически не делал не каких манипуляций: поменял в настройках адрес сайта, заменил в базе старые адреса с http на https, в робот.тхт изменил путь к sitemap и поправил htaccess, он у меня стал таким:
[crayon-5848250be242e277423399/]
Все)
wp-config.php и в прочие файлы изменений не вносил. Единственное были проблемы со смешанным содержимым (картинки с левых сайтов (рекламные), пару скриптов от плагинов, которые подключались через http, поправил и все отлично работает, везде зеленый замочек) Крон тоже пашет исправно! Ну и в панелях веб мастеров (яндекс, гугл) указал что сайт на https. На все про все у меня ушло 7 минут! На счет трафика пока не понятно, в принципе он пляшуший, на 2 день после перехода он вырос, а не упал, а если сейчас смотреть то просел на 17%, ну это опять же все пляшущее, завтра может опять взлететь. Зато сайт как мне кажется чуть шустрее стал, ведь теперь он на новой версией протокола HTTP/2, которая позволяет выполнять множество запросов в рамках одного соединения, благодаря чему значительно повышается производительность)
htaccess
Видимо, нам остается только вам позавидовать) На следующий год буду рассматривать возможность получения SSL уже бесплатно. В любом случае, спасибо за ваш опыт, будем иметь ввиду 8)
Если тиц был у сайта, то отклеится, но потом вернется, если с сайтом все будет ок за это время 🙂
Ну да ТИЦ обнулился после перехода) Надеюсь не надолго)
Реально - самая полная (со всеми нюансами) статья по переезду WordPress на HTTPS из всех что в выдаче прочитал. Там друг у друга тырят одно и тоже пишут но никаких подробностей (как SQL запросы) нет. Один сайт переехал дальше будет проще.
СПАСИБО БОЛЬШОЕ за материал!
Столкнулся с такой проблемой. При переключении в админке на https адекватно все отображается только на главной странице сайта. На остальных страницах не ссылки на файлы стилей, на файлы скриптов, отображаются все равно по протоколу http и соответственно не работают. Ссылки на скрипты для плагинов и стили которые добавляются через wp_head ведут себя так же. Может подскажете где может быть проблемма
Доброго дня, скажу коротко, админка работает, все хорошо, но после перехода на https, я заметил, что в некоторых темах и плагинах пропали пункты, а если я стараюсь перейти по ссылкам, которые раньше относились к этим пунктам, то возникает сообщение "Извините, вам не разрешено просматривать эту страницу отдельные страницы."
Для примера возьмем тему Newspaper, которую мне нужно активировать (занулидь), но не могу дорваться до заветного адреса wp-admin/admin.php?page=td_cake_panel, выскакивает это сообщение, что я писал выше. Кто знает, как решается эта проблема с скрытием некоторых пунктов и запретом на просмотр?
мне хотелось бы чтобы подобное сообщение показывалось всем, кто пытается "занулидь" темы или плагины.
Я давно пользуюсь этим генератором. Генератор SQL-запросов, необходимых при смене домена сайта на WordPress https://misha.blog/sql-domain-replace Может кому тоже пригодится : )
Спасибо за публикацию, хорошая статья - полезный материал для многих!
У меня вопрос: на страницах пользователей, у которых загружена обложка ЛК, зеленый замок в адресной строке браузера почему-то не отображается. Возможна-ли проблема с абсолютными путями до этих изображений (если да, то какой нужен SQL-запрос к базе данных для массового перевода этих ссылок)?
в статье уже предложены варианты sql-запросов для изменения протокола ссылок, для таблицы wp_usermeta в том числе.
Если для аватаров это:
то для обложек ЛК так?
Или я не так понял...
да, должно сработать
Да, теперь всё норм. Спасибо Вам!
Роман, не забудьте после всех операций, но до добавления в панели поисковиков нового сайта, проверить в валидаторе правильность установки сертификата. Что бы все пункты в нем были "ок"
Здравствуйте! Проблему с cron ом не решили? Перешёл на HTTPS и такая же проблема. Не публикуются запланированные статьи.
Здравствуйте! Что то у меня не получается никак перевсти относительные ссылки в абсолютные на файлы js и css. Дело в том что в коде страницы ссылки на эти файлы начинаются с http и из за этого по безопасному протоколу стили и скрипты не подгружаются - сайт просто отображается криво, очень криво...
Вот как на скрине http://joxi.ru/GrqK10PSQObMD2
Может знаете как решить проблему?
В настройках сайта поменяли протокол на https?
Кеш удалили из всяких плагинов и браузера?
Да, это всё сделано...
Я так понимаю мне нужно ссылки вида http://site.ru/wp-includes/js/mediaelement/wp-mediaelement.min.css заменить на ссылки вида //site.ru/wp-includes/js/mediaelement/wp-mediaelement.min.css или https://site.ru/wp-includes/js/mediaelement/wp-mediaelement.min.css через запросы в БД, но не могу нигде найти как это сделать. Может знаете?
Я видел ваш коммент на почте, тут он скорее всего из за ссылок не отобразится. Откуда у вас в базе ссылки на стили? Они возможно у вас в шаблоне прописаны, вот там и поменяйте, возможно в функциях шаблона.
В функциях всё что есть касательно этого вот:
//default fonts
$default_font_string = 'Poppins:' . $font_weight_str.'|Open Sans:'.$font_weight_str;
$protocol = is_ssl() ? 'https:' : 'http:';
общение будет длинное - поэтому переходим на форум поддержки https://codeseller.ru/forum/ и публикуем в разделе вордпресс новую тему. Можете воспользоваться поиском по форуму - "смешанный контент" - это мноооого раз обсуждалось и решалось
Спасибо, поищу на форуме. Только вот открыл первые три темы по этому запросу и там тоже самое - то есть все пишут воспользуйтесь поиском по форуму, неоднократно обсуждалось))
значит на самом деле много раз обсуждалось - если приходится учить пользоваться базой знаний 😉