Питай програмист #5

https (или т.н. SSL криптиране) се базира на два компонента – един сървърен и един, свързан със самата функционалност на сайта.

Сървърният компонент се управлява основно от хостинга. Повечето хостинг компании поддържат Let’s Encrypt – non-profit организация, която издава безплатни сертификати. Инструментите работят лесно и каузата е чудесна, поради което се поддържа широко.

Не всички доставчици имат директна поддръжка обаче, а спецификите при VPS/заделени сървъри варира. SuperHosting например използват някакъв AutoSSL съвместно със Sectigo.

Когато се активира сървърният компонент, WordPress все още няма да зарежда сертификата. За разлика от доста други системи, WordPress записва вътрешно всички пътища като абсолютни такива (целият URL), вместо “релативни” (само пътят след основния домейн, примерно “/blog/title-post”).

Някои хостинг компании решават и този проблем с опция в админа (активиране на SSL по подразбиране и презаписване на пътищата). Плъгини като Really Simple SSL и евентуално
SSL Insecure Content Fixer могат да служат за алтернатива.

На ниво база от данни, въпросните плъгини презаписват записания стар път на блога към https вариант, заедно със съответните препратки в менюта, в съдържанието на страници и в мета данни от плъгини като Advanced Custom Fields.

Ние, програмистите, правим това на ниво база – т.е. презаписваме настройките в Settings -> General, пускаме няколко заявки, които обновяват абсолютно всички адреси в базата, и решаваме проблема. Минусът на варианта с плъгините е теоретично забавяне, защото всяка заявка трябва да променя пътищата в движение, вместо да се реши проблемът еднократно.

Допълнителни услуги като Cloudflare също имат различни настройки за SSL сертификати (4 или 5 вида), някои настроени за улеснение, други – за сигурност.

При всички случаи е добре да се процедира внимателно, защото може да се “заключите” извън самия сайт (случвало се е и на мен), ако например смените адресите, а сертификатът още не е активиран или валиден. Затова се процедира първо хостинг настройки, след това плъгини, при проблем – деактивиране от cPanel, phpMyAdmin и евентуално съпорт (за стандартни потребители).

Като финал, активно тестване винаги е полезно. Има и някои други детайли, които могат да ви изненадат. Преди няколко години счупихме за ден един от най-големите маркетинг подкасти в света при такава миграция, защото всички епизоди се регенерираха наново (наред със статистиките), тъй като пътищата бяха нови. Информация за Facebook likes и т.н. може да се загуби също (нови адреси). Коментарите от някои външни платформи също. Трябва да се внимава кога наистина е важен оригиналният адрес и какво друго може да се афектира.