Ugrás a tartalomhoz

Sütibeállítások

Típusonként válassza ki, mely sütiket engedélyezi. Választását bármikor módosíthatja a Sütibeállítások linken, amely minden oldal alján megtalálható. Adatvédelmi nyilatkozat

Szükséges

Mindig bekapcsolva

A bejelentkezéshez, a kosár megőrzéséhez és a választásai megjegyzéséhez szükségesek. Ezek mindig be vannak kapcsolva.

Milyen sütik?
  • weboke_sessie, weboke_klant, weboke_remember: a munkamenet és a bejelentkezve maradás
  • weboke_basket: a kosár
  • wkBtwIncl: az árak megjelenítése ÁFÁ-val vagy anélkül
  • wok_cookies: a sütiválasztás, 12 hónap

Méri, melyik hirdetés vezet látogatáshoz vagy rendeléshez, hogy ne fizessünk hatástalan hirdetésekért.

Milyen sütik?
  • Google Ads a Google Tag Manageren keresztül (_gcl_au, _gcl_aw), legfeljebb 90 napig
  • OpenAI Ads, hirdetések a ChatGPT-ben
  • wok_aff: melyik partnerünk ajánlására érkezett (partnerprogram), 60 nap

4,6

Ország és nyelv

Minden országnak saját oldala van, az adott ország áraival és ÁFA-jával.

Megtekintés

A motorháztető alatt: webszerver, PHP és adatbázis

Modul 1: Hogyan működik a WordPress · Olvasási idő: 8 perc

Tanulási cél: Ennek a leckének a végén lépésről lépésre el tudja magyarázni, hogyan lesz egy oldalkérésből WordPress esetén HTML oldal, és hol rövidíti le ezt az utat egy gyorsítótár.

Alapfogalmak: webszerver (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, lekérdezés (query), index.php, sablon hierarchia (template hierarchy), dinamikus vs. statikus, TTFB

Egy statikus és egy dinamikus oldal

Egy statikus weboldalnál minden oldal kész fájlként van tárolva a szerveren. A webszerver megfogja a fájlt és elküldi. Ez gyors és egyszerű, de minden módosítás egy új fájlt jelent.

A WordPress dinamikus: az oldal csak abban a pillanatban jön létre, amikor valaki lekéri. Nincs contact.html nevű fájl. Van egy szövegrész az adatbázisban, egy sablon (sablonminta) a megfelelő sablonfájlokkal, és egy halom PHP-kód, amely ezt a kettőt összeilleszti. Ez kényelmes (a szöveget a böngészőn keresztül is szerkesztheti), de minden látogatáskor számítási munkát igényel. Ha megérti ezt a folyamatot, akkor később azt is megérti majd, miért lassú néha egy weboldal, miért számít ennyit a gyorsítótárazás, és miért törhet el valamit egy PHP-frissítés.

Egy oldalkérés útja

Tegyük fel, hogy egy látogató megnyitja a https://example.com/contact/ címet. Ekkor a következő történik:

  1. DNS: a böngésző kikeresi a example.com IP-címét (lásd a DNS-tanfolyamot). Ezután biztonságos kapcsolatot létesít azzal a címmel.
  2. Webszerver: a szerveren fut egy webszerver, például LiteSpeed, Apache vagy nginx. Ez fogadja a kérést. Ha létezik olyan nevű valódi fájl vagy mappa (egy kép, egy stíluslap), akkor azt közvetlenül elküldi. Ha nem, akkor a .htaccess fájlban (LiteSpeed és Apache esetén) vagy az nginx konfigurációban található szabály érvényesül: „ami nem létezik, azt adja tovább az index.php fájlnak”.
  3. PHP: az index.php egy PHP-fájl. A webszerver a PHP-vel futtatja le, ez az a programozási nyelv, amelyen a WordPress készült. A PHP először betölti a wp-config.php fájlt (a beállításokat, köztük az adatbázis adatait), majd a WordPress további részét, majd az összes aktív bővítményt és az aktív sablont.
  4. Adatbázis: a WordPress megnézi, milyen tartalom tartozik a /contact/ címhez, és kérdéseket intéz az adatbázishoz (MariaDB vagy MySQL): melyik oldalnak van contact nevű slugja, melyek a weboldal beállításai, melyik menü tartozik hozzá? Egy ilyen kérdést lekérdezésnek (query) nevezünk. Egy egyszerű oldal már önmagában több tucat lekérdezésbe kerülhet; bővítményekkel akár több száz is lehet.
  5. Sablon: a WordPress eldönti, hogy a sablon melyik sablonfájlja formázza meg az oldalt. Ez a sablon hierarchia (template hierarchy) szerint történik: egy contact slugú oldalnál a WordPress először egy page-contact nevű sablont keres, majd page-<id>-t (az oldal azonosítószáma), majd page-t, majd singular-t, és végül index-et. Az első, amelyik létezik, nyer.
  6. A HTML visszaküldése: az eredmény egy HTML oldal, amelyet a PHP ad át a webszervernek, a webszerver pedig a böngészőnek.
  7. A böngésző beolvassa a HTML-t, majd ezután lekéri a stíluslapokat, szkripteket, betűtípusokat és képeket is. Ezek viszont valódi fájlok, tehát közvetlenül a webszervertől érkeznek (vagy egy gyorsítótárból).

A 2. és a 6. lépés között telik el az az idő, amire a szervernek szüksége van az oldal elkészítéséhez. Ezt a TTFB (time to first byte) mutatja: a kérés és a válasz első bájtja közötti idő. Egy jól beállított weboldalnál ez jóval egy másodperc alatt van. A 6. modulban saját maga is megméri majd ezt.

Miért számít minden egyes bővítmény

A 3. lépésben minden aktív bővítmény betöltődik, minden egyes kérésnél. Akkor is, ha az adott bővítmény ezen az oldalon semmit sem csinál. Egy fotógaléria bővítmény tehát akkor is betöltődik, ha valaki a kapcsolat oldalt nyitja meg. Minden bővítmény végezhet további lekérdezéseket, tölthet be további kódot és adhat hozzá további szkripteket az oldalhoz.

Ez két dolgot magyaráz meg, amelyekkel ebben a tanfolyamban többször is találkozik:

  • Kevesebb bővítmény általában gyorsabb. Nem azért, mert a darabszám önmagában számítana, hanem mert minden bővítmény minden kérésnél végezhet munkát.
  • Egyetlen hibás bővítmény leállíthatja az egész weboldalt. Ha a 3. lépésben valami elromlik (például egy bővítmény, amely nem működik az új PHP-verzióval), akkor a PHP soha nem jut el a 6. lépésig. A látogató ekkor egy üres oldalt vagy a „Kritikus hiba történt ezen a weboldalon” üzenetet kapja (5.4. lecke).

Honnan jön a PHP és az adatbázis

A PHP és az adatbázis az Ön tárhelyszolgáltatójának szerverén fut. A PHP-verziót Ön általában maga választja ki a vezérlőpanelen (DirectAdmin esetén ezt Select PHP version néven találja meg, lásd a 8.4. leckét). Az adatbázist a telepítéskor hozza létre; a telepítő gyakran ezt elvégzi Ön helyett (2.2. lecke).

Néhány dolog, amit érdemes megjegyezni:

  • PHP-verzió: minden új PHP-verzió gyorsabb és biztonságosabb, de a régi kód megakadhat rajta. A wordpress.org jelenleg a PHP 8.3-as vagy annál újabb verzióját ajánlja (2026. novemberi állapot szerint).
  • Adatbázis: a wordpress.org a MariaDB 10.11-es vagy újabb, illetve a MySQL 8.0-ás vagy újabb verzióját ajánlja. A MariaDB a MySQL egyik elágazása; a WordPress számára nincs köztük különbség.
  • Az adatbázis általában ugyanazon a szerveren található (ilyenkor a DB_HOST értéke localhost). Nagyobb tárhelyeknél külön szerveren is lehet.

Gyorsítótár: az út lerövidítése

Ha száz látogató ugyanazt a kapcsolat oldalt kéri le, a WordPress gyorsítótár nélkül százszor készíti el újra. Minden alkalommal ugyanazok a lekérdezések, ugyanaz a sablonfájl, ugyanaz a HTML. Egy oldal gyorsítótár az első elkészítés után megőrzi a HTML-t. A következő látogató a tárolt változatot kapja: a 3. és a 6. lépés közötti rész ekkor kimarad.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

Ez az oka annak, hogy a gyorsítótárazás adja a legnagyobb sebességjavulást (6.2. lecke). Ez magyaráz egy gyakori félreértést is: „megváltoztattam a szöveget, de még mindig a régi verziót látom.” Ilyenkor egy tárolt változatot kap; a gyorsítótár ürítése után már az új változatot látja.

Nem minden jöhet gyorsítótárból. Egy bejelentkezett rendszergazda, egy bevásárlókosár vagy egy fizetési oldal minden látogató számára más. Egy jó gyorsítótár bővítmény ezeket kihagyja.

Fejlécek: amit a szerver elárul Önnek

Minden webszerver válasz fejlécekkel (headers) kezdődik, még a HTML előtt. Ezeket nem látja az oldalon, de igen a böngésző fejlesztői eszközeiben (F12, Hálózat fül, kattintson az első kérésre). Egy példa:

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
  • a server megmutatja, melyik webszerver válaszol.
  • a link a wp-json résszel elárulja, hogy WordPress-ről van szó.
  • az x-litespeed-cache: hit azt jelenti, hogy ez az oldal a LiteSpeed gyorsítótárból érkezett. Más gyorsítótárak más neveket használnak, például x-cache: HIT vagy cf-cache-status: HIT Cloudflare esetén.

Nem kell ezeket a sorokat fejből tudnia. De aki el tudja olvasni őket, az sok problémát maga is meg tud találni.

Összefoglalás

  • A WordPress minden oldalt a kérés pillanatában készít el: webszerver, PHP, bővítmények, adatbázis, sablon, HTML.
  • Minden kérésnél betöltődik az összes aktív bővítmény; egyetlen hibás bővítmény is leállíthatja az egész weboldalt.
  • A sablon hierarchia határozza meg, melyik sablonfájl formázza meg az oldalt.
  • Egy oldal gyorsítótár kihagyja a számítási munkát azáltal, hogy tárolt HTML-t ad vissza. A bejelentkezett felhasználóknak és a bevásárlókosaraknak nincs helyük ebben a gyorsítótárban.
  • Egy válasz fejlécei elárulják, melyik webszerver válaszolt, és hogy az oldal gyorsítótárból érkezett-e.

Kvíz

1. Ki futtatja a WordPress PHP-kódját?



2. Egy 40 bővítményt használó weboldal lassú, még azokon az oldalakon is, ahol ezek a bővítmények semmi láthatót nem csinálnak. Mi a legjobb magyarázat erre?



3. Honnan érkezik általában egy olyan stíluslap, mint a /wp-content/themes/thema/style.css?



4. A fejlécek között ezt látja: x-litespeed-cache: hit. Mit jelent ez?



5. Melyik sablonfájlt használja a WordPress egy contact slugú oldalhoz, ha a sablon csak page és index fájlokkal rendelkezik?



Feladat

A1.2 feladat: Olvassa el a weboldala fejléceit. Nyissa meg a saját weboldalát (vagy a wordpress.org oldalt) a böngészője fejlesztői eszközeivel (F12, Hálózat fül, frissítse az oldalt, kattintson az első kérésre). Töltse ki, melyik webszerver szerepel a server fejlécben (vagy „nincs”, ha az nem szerepel), és hogy van-e olyan fejléc, amely azt jelzi, hogy az oldal gyorsítótárból érkezett (melyik néven és milyen értékkel). A program lekéri ugyanazt az oldalt, és összehasonlítja az eredményt.

A1.2. feladat: Olvassa el a weboldala fejléceit




Amit beír, és amit találunk, azt nem tároljuk. A böngészője megjegyzi a válaszait és azt, hogy teljesítette e a feladatot. Ha bejelentkezett, a Fiókomban csak azt tároljuk, hogy a feladat (majdnem) helyes volt; ott ezt is törölheti.

További olvasnivaló

Ezek a cikkek a WebOké vezérlőpaneljein keresztül mutatják be a lépéseket; más vezérlőpaneleken hasonlóan működnek.

Egy pillanat…

Domainek beállítása

Állítsa be domainenként a névszervereket, a tárhelyhez való kapcsolást és azt, hogy ki legyen a tulajdonos.

Domainek betöltése…