Необходимостта от пренасочване на уеб сайтовете към HTTPS расте с всяка година. В предишна статия ви показахме как се избира и инсталира SSL сертификат, а в днешната публикация ще ви обясним подробно как да мигрирате WordPress уеб сайта си изцяло към HTTPS. Инструкциите, които ще опишем, ще ви отнемат минимум 1 час при уеб сайт с няколко страници, но е възможно да се наложи да отделите повече време при по-големи сайтове. Процесът на мигриране е съпроводен с необходимостта от технически познания, свързани с редактирането на WordPress файлове.

1.Направете пълен архив преди да започнете

Първата и най-важна стъпка, която често пъти е подценявана, е архивирането. Има много специалисти, които я пренебрегват, защото смятат, че минималните промени не могат да доведат до сериозни последствия и загуби. Това обаче не е така. Направете пълен архив преди да започнете да променяте каквото и да било. Задължително е да има както файловете на WordPress, така и архив на базата данни. Ако разполагате с голям уеб сайт, можете да избегнете създаването на голям архив, като оптимизирате процеса и архивирате само директроиите, в които ще направите промени. Наложително е да има архив на папките wp-content/plugins, wp-content/themes и базата данни със сайта, който ще се мигрира. Препоръчваме  ви да имате архив на следните файлове в основата на WordPress - .htaccess и wp-config.php.

Защо е необходимо това? Обикновено архивите на уеб сайтовете са десетки (или стотици) мегабайти, дори гигабайти, а на вас ви се налага да промените много малка част от цялата информация - може би няколко килобайта. Ако сте начинаещи, ви препоръчваме да направите пълен архив. Ако имате опит обаче, можете да се справите само с архивиране на горните файлове и папки. Досега във всички миграции 90-95% от работата е свързана с базата данни, а едва 5-10% от останалите промени са върху файловете. Ако сте експерт, можете да направите само архив на базата, но съществуват рискове, които трябва да бъдат предвидени при възникване на проблеми. След създаването на архивите, можете да ги преместите на компютъра, от който ще извършите миграцията. В точка 7 ще обърнем повече внимание на това.

2.Проверете кога е най-подходящото време за миграция

Изключително важно е да проверите кое е най-подходящото време за извършване на миграцията, за да избегнете недоволството на потребителите. Това е от особено значение за по-натоварени уеб сайтове, за да успеете да избегнете неприятната обратна връзка от потребителите при неработещ или частично неработещ сайт. Проверете в Google Analytics кога са активни потребителите ви и кога самият уеб сайт има по-малко посещения. Практиката досега показва, че има 4 най-удобни момента:

• събота и/или неделя
• през нощта - от 00:00 до 07:00 часа
• много рано сутрин - от 07:00 до 09:00 часа
• по време на национални или на по-големите религиозни празници

Възможно е да направите и комбинация от горните предложния, защото най-доброто решение е моментът, в който няма трафик. Със сигурност ще има няколко потребители, които ще бъдат недоволни. Трябва да знаете, че е възможно да има и пострадали търсещи машини (Google, Yahoo и т.н.), за които няма как да предвидите кога ще посетят уеб сайта ви.

3.Преглед на външните ресурси

Препоръчваме ви да проверите дали уеб сайта ви използва външни ресурси, като например - рекламни мрежи, скриптове, шрифтове, снимки или вгражда аудио или видео файлове от други сайтове. Проверката става много лесно, като единствено трябва да отворите няколко примерни адреса с https вместо с http. Ако файловете се отварят безпроблемно с новите адреси, продължете със следващите стъпки. Ако обаче файловете не могат да бъдат отворени със сигурната връзка или възникне грешка при установяването на сигурната връзка, тогава ще трябва да се свържете със собствениците на сайтовете и да ги уведомите за проблема. Ако собствениците планират миграция или са в процес на такава, може да се наложи да изчакате приключването им или да ги замените с други. Ако обаче не предвиждат миграция към https, ще се наложи да ги смените с конкурентен продукт или услуга. Не съществува универсално решение за действия в подобна ситуция, но добрата новина е, че през 2017-та повечето сайтове, предоставящи ресурси за вграждане, са или в процес на миграция, или вече са мигрирали.

4.Спрете модулите за ускоряване и системите за доставяне на съдържание

В периода на миграция е много важно да се спре всякаква форма връщане на вече готово съдържание от сайта. Това може да бъде модул за кеширане, система за доставяне на съдържание (CDN), модул към сървърите за ускорение или нещо подобно. Тъй като ще се правят драстични промени по сайта, ще трябва за известен период тези системи или модули да се изключат, за да можете да наблюдвате промените. Ако не изключите модулите и системите, е невъзможно да проследите случващите се промени и тогава се появяват дефекти - забелязвате промени, които вече са направени, изведнъж изчезват или се появяват пак, или се появяват по няколко пъти, а това не само затруднява процеса по преместването, но го прави и невъзможен за изпълнение. За да избегнете подобни усложнения, е необходимо да спрете модулите или системите докато не приключи процесът по мигриране.

5.Спрете всички пренасочвания от .htaccess

Абсолютно задължително е временно да спрете всички пренасочвания от .htaccess, ако има такива.

Примерни кодове:

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

или

RewriteEngine On
RewriteCond %{SERVER_PORT} 443
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

или

RewriteEngine On
RewriteCond %{HTTPS} ^on$
RewriteRule ^(.*)$ http://example.com/$1 [NC,L,R]

Това, което ще направите с тези редове, е да пренасочите целия възможен трафик от сигурна към несигурна връзка. Напълно е възможно да имате и обратен сценарий - от несигурна към сигурна. И в този случай е необходимо да спрете кодовете временно, като ги закоментирате с един диез # за първи символ на редовете. След редакцията е необходимо да проверите дали пренасочванията са спрени. Ако не са - продължете да търсите в .htaccess, докато не намерите и не забраните пренасочванията.

6.Миграция на базата данни

Досега описвахме подготвителните стъпки към миграцията. Време е да преминем към същинската част. Възможни са няколко подхода и всичко зависи от вашите знания и умения. Първият начин е да инсталирате модул за самата миграция. Най-доброто решение в момента е Really Simple SSL. Този модул със само една настройка извършва всички налични промени, свързани с миграцията, но без да променя данните. Промените се правят в движение и са напълно обратими, ако изключите модула. Въпреки че модулът изглежда много прост и лесен, в действителност той извършва почти всичко в порцеса към мигрирането. Уви, има и лоша новина. Точно такива модули натоварват процесорното време и понякога уеб сайтовете се сриват с напълно невинни обновления. Ако процесорното време може да бъде преодоляно, това решение е един чудесен вариант за вас. Препоръчваме ви да изпозлвате този модул в случаите, когато сайтът е или много малък, или миграцията трябва да стане мълниеносно бързо. Във всички случаи обаче е необходимо да се коригира базата с последващите модули.

Вторият начин е да се използва специализиран модул за WordPress. Ние ви препоръчваме Better Search Replace или специализиран скрипт, като interconnect/it Search Replace DB PHP Script. Ако при първия модул ви е необходим един клик за инсталирането му под WordPress, то при втория ще се наложи да го свалите в ZIP формат, да го разархивирате, а след това с FTP клиент да го качите на сървъра за следващо изпълнение. И двата варианта имат еднакъв краен резултат -  позволяват много лесно и просто базата данни да бъде претърсена за даден стринг и ако има - да бъде заменен с друг стринг. Например: искаме да заменим навсякъде, където се среща http://сайтами.сом с https://сайтами.сом. Друга полезна функция е, че може да се направи тестово пускане, което само ще покаже какво би се променило без реално да бъдат направени промени. Това е вид функционален тест на промените, който е напълно безопасен.

След замяната на символите можете да използвате уеб сайта през сигурна връзка на адрес https://сайтами.сом/wp-login.php. Ако не се получи или влезете пак на стария адрес http://сайтами.сом/wp-login.php, то трябва да проверите дали в wp-config.php съществуват следните редове:

define('WP_HOME', 'http://сайтами.сом');
define('WP_SITEURL', 'http://сайтами.сом');
define( 'WP_CONTENT_URL', 'http://сайтами.сом/wp-content' );

и да ги замените с https, след което пак да направите опит за вход. Ако възникне друг проблем, тогава е необходимо да проверите за наличието на пренасочвания в .htaccess и да ги спрете временно. Възможно е да стигнете и до ситуация на безкраен цикъл от пренасочвания. Най-простият пример е, когато http://сайтами.сом пренасочва към https://сайтами.сом, който пренасочва към http://сайтами.сом, който пренасочва към https://сайтами.сом и т.н. Ако попаднете в такава ситуация, причината е, че или редакцията на базата данни не е коригирала правилните пренасочвания, или има допълнителен код за пренасочвания в .htaccess. Възможно е и двете да са валидни. Ако стъпката е успешна, вече можете да използвате уеб сайта само през новия адрес https://сайтами.сом, а той самият да бъде почти напълно функционален.

Съществува още един начин за мигриране на базата данни с помоща на wp-cli (WordPress Command Line Interface). Wp-cli е изключително мощен инструменt за управление на WordPress под команден ред и за него има специална команда search-replace. Ако хостингът поддържа wp-cli, както Dev хостинг, то тогава единственото, което трябва да направите, е да изпишете следния ред в конзолата:

wp search-replace 'http://сайтами.сом’ 'https://сайтами.сом’

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

Важно: В никакъв случай не използвайте инструмент за редакция на базата данни, като phpMyAdmin или директно MySQL. WordPress използва подход за записване на данните в базата, известен като сериализация. Ето и как изглежда нещо записано по този начин:

O:1:"a":1:{s:5:"value";s:3:"100";}

Какъв е проблемът? Ако забележите “value” или “100”, ще видите, че преди тях е указана тяхната големина. В единия случай е 5 символа, в другия случай е 3 символа. Редакцията на базата данни с MySQL или phpMyAdmin ще предизвика промяна в съдържанието на стринга и неговата големина. Само прибавянето на буквата S след http добавя един символ. Но тези инструменти (MySQL/phpMyAdmin) не коригират големината, която се указва преди тях. Няма как от 5 да стане 6 или от 3 да стане 4 с тяхна помощ. Това води до срив на целия сайт с огромни размери -  част от уеб сайта ще работи, друга част - не. Ако се стигне до тук - ще трябва да възстановите от архива, който създадохме в точка 1 и да започнете работа отново. Ако използвате горните инструменти, които изрично показахме, няма да се появи подобен проблем, защото те са създадени специално за работа със сериализирани данни. Накратко - не използвайте инструменти за работа с MySQL или phpMyAdmin за промяна на сериализирани данни, използвайте само специализирани такива.

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

7.Мигриране на скриптове, стилове, шрифтове и вградените рамки към сигурна връзка

Ако уеб страницата ви вече работи под сигурна връзка, то браузърът ще спре всички опити на страницата ви да зареди нещо от несигурна. Това може да бъде файл, който съдържа скрипт, стил, шрифт или друг файл, като рамка (iframe). За тази цел ще трябва да проверите какво пречи на страницата да се зареди, и защо се показва така нареченото “смесено съдържание”. Най-лесно се вижда, когато се използват инструментите за разработчици на съответния браузър, който използвате. Ето и няколко примера:

В горните снимки e указано ясно какво се опитва да се зареди, както и че е забранено. В този случай се налага да се използват архивите от точка 1. Ровенето обаче във всички файлове, като времеемка операция, е препоръчително да бъде спестено чрез използването на правилния инструмент, който позволява търсене на стринг в множество файлове. За потребителите на Windows това може да е Notepad++; macOS потребителите могат да ползват EasyFind, TextWrangler (безплатни) или Coda (платена); Linux потребителите - Bluefish или grep/egrep. Съществуват още много инструменти за целта, но основната задача е да намерите стринга и да го замените от http с https. Файловете, които се налага да бъдат проверени са: или файловете на темата (или темите), или файловете на модулите на WordPress. В другите файлове (wp-admin, wp-includes, wp-content/uploads) търсенето не е необходимо.

След това трябва единствено да качите променените файлове на сървъра чрез инструмент за обмен на файлове (FTP) и да тествате отново, докато грешките не бъдат отстранени. Има частни случаи, когато даденият стринг не може да бъде открит. Има го в кода на сайта, но го няма във файловете. Тогава се налага да  потърсите по част от стринга - домейн, част от пътя или името на файла. Има и частни случаи, когато действително го няма във файловете и тогава пред вас съществувт два варианта. Първият и по-лесен е да се опитаме да го открием с инструментите за търсене в базата данни, както описахме в точка 6. Ако го открием, ще го заменим от http на https, а след промяната е необходимо да тествате отново, ако не можете да го откриете там, е възможно отново да се намира в кода или базата данни, но да е кодирано. В този случай определено трябва да се обърнете към специалист. Препоръчваме ви да се свържете с разработчиците на темата или модула и да ги предупредите за премеждията, през които сте преминали. По този начин те ще могат да направят корекция и при следващите обновления, промените да останат. Ако не успеете да се свържете с разработчика или ако той игнорира вашият апел, тогава е необходимо единствено да спрете да обновявате темата или модула, защото процесът на обновяване ще доведе до връщане на старите и несигурни връзки. Добър вараинт е да потърсите тема или модул, които да заменят проблемния такъв.

Важно: Възможно е да изключите механизма на защита за зареждане на обекти от несигурни връзки в някои браузъри. Вижте как:

Някои браузъри обаче, като Safari, нямат тази възможност. Ако разработвате сайт и външните ресурси още не са мигрирали към сигурни връзки, ще можете да ги заредите въпреки всичко. Тази възможност се използва предимно от разработчици на сайтове и по никакъв начин не е препоръчително използването ѝ от крайни потребители. Ако сайтът ви използва смесено съдържание, е препоръчително да мигрирате към доставяне от изцяло сигурни връзки.

8.Оправяне на снимките към сигурни връзки

В предната точка показахме как да отстраним различни пречки в миграцията. Ако всичко е наред, настъпва моментът, в който трябва да се оправят и снимките към външни ресурси, а това е много по-лесно, защото снимките, въпреки че се намират към незащитени външни ресурси, все пак се зареждат. В инструментите за разработчици обаче се показват грешки. Необходимо е да откриете тези външни ресурси и да ги пренасочите към сигурна връзка. Откриването е много лесно с инструмента за търсене в базите от данни. По-големият проблем е самото пренасочване.

Както виждате, тук браузърите показват изрично, че има смесено съдържание и не цялата страница се зарежда от сигурни връзки. При Safari дори не се показва катинарът, въпреки че страницата се зарежда от сигурна връзка. За останалите браузъри се показва нещо подобно, което предупреждава потребителия, че има нещо нередно в тази страница. Сега ще коригираме и този проблем.
Вариантите са два. Ако външният ресурс поддържа криптирана връзка, ще можете лесно да промените неговия адрес и да тествате отново. В идеалния случай грешките ще бъдат премахнати и ще намаляват с всяка следваща страница, която бива тествана и със заменени връзки. Но проблемът е далеч по-голям ако външният сайт не поддържа сигурни връзки. Най-лесно е да оставим нещата така, но е възможно потребителите да бъдат уплашени. Различните браузъри имат настройки, които в такива случаи биха възпрепятствали зареждането на ресурсите от несигурна връзка или на самия уеб сайт. Друго лесно решение на този казус е да  свалите снимките локално на компютъра и да ги качите в WordPress, след това да замените външните ресурси с локалните. Трябва да обърнете внимание на снимките с авторски права, за да избегнете проблеми от законова гледна точка.

Най-добре е да се свържете с авторите на другия сайт и да ги информирате, че е по-добре да използват сигурни връзки. Алтернативното решение е да намерите друг сайт, от който да заредите горните картинки, но през сигурна връзка. Както и в предната точка, няма универсална рецепта какво, как и кога да се прави. В най-крайните варианти може дори да се наложи да пренапишете или преработите статиите, така че да ги няма снимките и да не бъдат свързани с текста.

9.Мигриране на AJAX

Това е най-трудната задача от цялата операция по мигриране, дори е невъзможна на този етап без програмиране.  По спецификация е забранено подаването на информация с помощта на HTML форми от сигурна връзка към несигурна. Това изключва моментално всякакви форми за гласуване, контактни форми, форми за вход, форми за попълване на финансова информация, като кредитни карти или нещо друго. Ако формата и скриптовете се намират на същия сървър, то тогава ще трябва да се пренасочи връзката към сигурна такава. Проблемът е, ако се използва външен ресурс от друг сървър, който не поддържа сигурна връзка. Тогава трябва да намерите заместител на тази система.

10.Проверка на всички страници за проблеми

Ако всички стъпки по-горе са направени на няколко страници, вече е необходимо да бъдат направени на всички страници. Това означава, че трябва да проверите всяка една страница за проблеми и своевременно да ги отстраните. Ако сайтът е под 100 страници, това е сравнително проста операция, която ще отнеме около час или два - необходимо е да проверите страниците една по една и да ги коригирате. Проверката на ръка за уеб сайтове с по-голям обем (1000 странции, 10 000 или много повече) ще отнеме много време. За тази цел има създадени специализирани инструменти за обхождане на уеб сайтове, но тези инструменти са платени. Може би най-бързото, а и безплатно, решение е да проверите в базата данни и във файловете дали някъде не е останало нещо, което да се зарежда от HTTP вместо от HTTPS. Ако има такива връзки ги коригирайте и тествайте страниците отново. Ако всичко е наред, можете да обявите, че процесът по мигриране е завършен и уеб сайтът работи изцяло под сигурна връзка.

11.Създаване на нов архив

Първият архив от точка 1 е необходим за случаите, в които се обърка нещо в процеса на мигриране, или ако се наложи да бъде спрян аварийно самият процес. Той е вашата гаранция, че във всеки един момент можете да върнете уеб сайта към началното му състояние без никакви корекции, ако възникне технически проблем. Целта на този нов архив е по-различна - да си създадете архив на целия мигриран и работещ под сигурна връзка сайт. По този начин ще имате архив, от който ще можете много бързо да възстановите уеб сайта към следмиграционното му състояние, ако в бъдеще се случи нещо с WordPress, хостинга или се обърка нещо при обновление на модул или тема. Препоръчваме ви архивите от точка 1 и точка 11 да ги свалите на локалния ви компютър и да ги запишете на външен носител - диск, флашка или някоя облачна услуга. Необходимо е да направите архив и на базата данни.

12.Пренасочете сайта с .htaccess към сигурна връзка

Първи код:

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Втори код:

RewriteEngine on
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) https://www.example.com%{REQUEST_URI} [R=301,L]

Изключително важно е да проверите какво се е наложило да бъде спряно в точка 5 и да го коригирате съобразно новия сайт със сигурна връзка.

ВАЖНО: Тези кодове пренасочват всичко от несигурна към сигурна връзка, като уеб сайтът започва със WWW. Ако преди миграцията, вашият уеб сайт е работил със и без WWW, това означава, че единият вариант е бил избран за основен, а другият е пренасочван към WWW. Със сигурната връзка уеб сайтът може да бъде зареждан по 4 начина: несигурна връзка - с и без WWW, сигурна връзка с и без WWW. И от всички варианти е възможно да изберете един за основен (напр. сигурна връзка с WWW), а всички останали варианти да ги пренасочите към него. За тази стъпка очаквайте допълнителна публикация.

13.Активирайте модулите за ускоряване и системите за доставяне на съдържание

Стъпката е изключително лесна - с една настройка се активират обратно всички модули. Ако използвате CMS система обаче ще трябва да прочетете в документацията как да активирате системата да доставя съдържание през сигурна връзка. Възможно е да се наложи да се сменят настройките на системата или дори да качите сертификата, с който се защитава уеб сайта в самата система. Няма универсално решение, затова прегледайте документацията и ако възникнат проблеми, се свържете с поддръжката на системата.

В първата част на темата за мигриране на уеб сайт към сигурна връзка имахме уеб сайт, който работи с несигурна връзка, но поддържа и сигурна връзка и инсталирахме сертификата за нея. След изпълнението на днешните 13 стъпки ще имате уеб сайт, използващ само сигурна връзка. Целият процес на миграцията се съдържа в тези 13 точки. Времетраенето на операцията зависи основно от това колко промени е необходимо да бъдат направени по базата данни и файловете, както и от броя на страниците. Уеб сайт, който съдържа до 100 страници се мигрира за около час-два. Ако потребителят няма опит с подобни миграции, първата миграция може да отнеме и няколко часа. Ако нямате опит, а  се налага да мигрирате по-голям уеб сайт, ви препроъчваме да се обърнете към опитни специалисти.

Процесът по мигриране може да се проточи във времето в зависимост от външните ресурси, които използвате - техният брой и дали позволяват или не работа под сигурна връзка. Напълно реален случай е цялата миграция да се върне към архива от точка 1, само защото сайтът използва рекламна мрежа, която още не поддържа сигурна връзка или използва аудио/видео информация от външен уеб сайт, който също не поддържа сигурни връзки. Не подценявайте първите няколко точки от този списък, защото те са необходима подготовка към самата миграция и ако ги изпълните правилно, ще ви спестят по-нататъшните усилия.

В предишната статия, част от поредицата за мигриране към HTTPS, ви показахме как се избира и инсталира SSL сертификат. В трета част вижте всеки един важен момент и стъпките, които е необходимо да бъдат направени точно след миграцията.