Под капака: уеб сървър, PHP и база от данни

Модул 1: Как работи WordPress · Време за четене: 8 минути

Учебна цел: След този урок ще можете стъпка по стъпка да обясните как заявка за страница при WordPress се превръща в HTML страница и къде кешът скъсява този път.

Ключови понятия: уеб сървър (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, заявка (query), index.php, йерархия на шаблоните, динамично срещу статично, TTFB

Статична и динамична страница

При статичен уебсайт всяка страница се намира като готов файл на сървъра. Уеб сървърът взема файла и го изпраща. Това е бързо и просто, но всяка промяна означава нов файл.

WordPress е динамичен: страницата съществува едва в момента, в който някой я поиска. Няма файл contact.html. Има парче текст в базата от данни, тема с шаблони и куп PHP код, който съединява двете. Това дава удобство (променяте текста във Вашия браузър), но изисква изчисления при всяко посещение. Ако разберете тези изчисления, по-късно ще разберете и защо един сайт е бавен, защо кеширането има толкова голямо значение и защо ъпгрейд на PHP понякога може да счупи нещо.

Пътят на една заявка за страница

Да кажем, че посетител отваря https://example.com/contact/. Ето какво се случва:

1. DNS: браузърът търси IP адреса на example.com (вижте курса по DNS). Той установява защитена връзка с този адрес.
2. Уеб сървър: на сървъра работи уеб сървър, например LiteSpeed, Apache или nginx. Той получава заявката. Ако съществува реален файл или папка с такова име (изображение, stylesheet), той го изпраща директно. Ако не, важи правилото от .htaccess (при LiteSpeed и Apache) или от конфигурацията на nginx: „предай всичко, което не съществува, на index.php“.
3. PHP: index.php е PHP файл. Уеб сървърът го предава за изпълнение на PHP, програмния език, на който е написан WordPress. PHP зарежда първо wp-config.php (настройките, с данните за базата от данни), после останалата част от WordPress, после всички активни разширения и активната тема.
4. База от данни: WordPress проверява какво съдържание отговаря на /contact/ и задава въпроси към базата от данни (MariaDB или MySQL): коя страница има slug contact, какви са настройките на сайта, кое меню принадлежи към нея? Такъв въпрос се нарича заявка (query). Дори обикновена страница бързо достига до десетки заявки; с разширения те могат да станат стотици.
5. Тема: WordPress избира кой шаблон от темата оформя страницата. Това става според йерархията на шаблоните: за страница със slug contact WordPress първо търси шаблон page-contact, после page-<id> (номерът на страницата), после page, после singular и накрая index. Печели първият съществуващ.
6. HTML обратно: резултатът е HTML страница, която PHP предава на уеб сървъра, а уеб сървърът на браузъра.
7. Браузърът чете HTML и след това зарежда и stylesheet-ите, скриптовете, шрифтовете и изображенията. Те са обикновени файлове, затова идват директно от уеб сървъра (или от кеш).

Между стъпка 2 и стъпка 6 е времето, което е необходимо на сървъра да създаде страницата. Това виждате като TTFB (time to first byte): времето между заявката и първия байт от отговора. При добре настроен сайт то е значително под секунда. В модул 6 ще измерите това сами.

Защо всяко разширение има значение

В стъпка 3 се зареждат всички активни разширения, при всяка заявка. Дори ако това разширение не прави нищо на тази конкретна страница. Разширение за фото галерия например се зарежда и когато някой отвори Вашата контактна страница. Всяко разширение може да изпълни допълнителни заявки, да зареди допълнителен код и да добави допълнителни скриптове към страницата.

Това обяснява две неща, с които ще се сблъсквате по-често в този курс:

• По-малко разширения обикновено означава по-бързо. Не защото броят сам по себе си има значение, а защото всяко разширение може да извършва работа при всяка заявка.
• Едно счупено разширение може да повали целия сайт. Ако в стъпка 3 нещо се обърка (например разширение, което не работи с новата версия на PHP), PHP никога не стига до стъпка 6. Посетителят получава празна бяла страница или съобщение „Възникна критична грешка на този уебсайт“ (урок 5.4).

Откъде идват PHP и базата от данни

PHP и базата от данни работят на сървъра на Вашия хостинг доставчик. Обикновено Вие сами избирате версията на PHP в контролния панел (при DirectAdmin това се нарича Select PHP version, вижте урок 8.4). Базата от данни се създава по време на инсталацията; инсталаторът често прави това вместо Вас (урок 2.2).

Няколко неща, които да запомните:

• Версия на PHP: всяка нова версия на PHP е по-бърза и по-сигурна, но стар код може да се счупи при нея. wordpress.org в момента препоръчва PHP 8.3 или по-нова версия (към ноември 2026).
• База от данни: wordpress.org препоръчва MariaDB 10.11 или по-нова версия, или MySQL 8.0 или по-нова версия. MariaDB е разклонение на MySQL; за WordPress това няма значение.
• Базата от данни обикновено се намира на същия сървър (DB_HOST тогава е localhost). При по-голям хостинг тя може да бъде на отделен сървър.

Кеш: скъсяване на пътя

Ако сто посетители поискат една и съща контактна страница, без кеш WordPress я създава сто пъти наново. Всеки път едни и същи заявки, един и същи шаблон, един и същи HTML. Кешът на страниците запазва HTML след първия път. Следващият посетител получава запазената версия: стъпки от 3 до 6 отпадат.

Без кеш:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
С кеш:     browser > webserver > opgeslagen HTML

Ето защо кеширането дава най-голямата печалба в скоростта (урок 6.2). Това обяснява и често срещано объркване: „промених текста, но виждам старата версия.“ Тогава получавате запазена версия; след изчистване на кеша виждате новата.

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

Хедъри: какво Ви казва сървърът

Всеки отговор от уеб сървър започва с хедъри (headers), преди HTML. Те не се виждат на страницата, но се виждат в инструментите за разработчици на Вашия браузър (F12, раздел Мрежа, кликнете върху първата заявка). Пример:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server показва кой уеб сървър отговаря.
• link с wp-json издава, че това е WordPress.
• x-litespeed-cache: hit означава, че тази страница идва от LiteSpeed кеша. Други кешове използват други имена, например x-cache: HIT или cf-cache-status: HIT при Cloudflare.

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

Обобщение

• WordPress създава всяка страница в момента на заявката: уеб сървър, PHP, разширения, база от данни, тема, HTML.
• При всяка заявка се зареждат всички активни разширения; едно счупено разширение може да спре целия сайт.
• Йерархията на шаблоните определя кой шаблон от темата оформя дадена страница.
• Кешът на страниците пропуска изчисленията, като подава запазен HTML. Влезли потребители и количките за пазаруване не трябва да попадат в този кеш.
• Хедърите на отговора показват кой уеб сървър отговаря и дали страницата е дошла от кеш.

Тест

Задача

Задача A1.2: Прочетете хедърите на Вашия сайт. Отворете Вашия собствен сайт (или wordpress.org) с инструментите за разработчици на Вашия браузър (F12, раздел Мрежа, опреснете страницата, кликнете върху първата заявка). Попълнете кой уеб сървър е посочен в хедъра server (или „няма“, ако липсва) и дали има хедър, който показва, че страницата идва от кеш (кое е името и коя е стойността). Програмата ще поиска същата страница и ще сравни.

Допълнително четене

Тези статии описват стъпките в панелите на WebOké; в други панели те работят по подобен начин.

• Ръководство за DirectAdmin 1.9: Термини обяснени: domain, subdomain, pointer, DNS, mailbox и database
• Ръководство за DirectAdmin 14.1: Избор на версия на PHP (Select PHP version)
• Безплатен DNS курс 1.4: Пътуването на една DNS заявка
• Йерархия на шаблоните (developer.wordpress.org, на английски): https://developer.wordpress.org/themes/basics/template-hierarchy/