Mi az a CMS? Tartalomkezelő rendszerek magyarázata

A CMS, vagyis tartalomkezelő rendszer olyan szoftver, amellyel az emberek létrehozhatják, szerkeszthetik és közzétehetik a webhely tartalmát — cikkeket, oldalakat, képeket, termékleírásokat —, egy barátságos szerkesztőn keresztül, kód módosítása nélkül. Tárolja a tartalmat, nyomon követi a vázlatokat és a verziókat, és a közzétett változatot felteszi az oldalra. A WordPress a legismertebb példa, de sok más is létezik.

Miért fontos ez, ha MI-val építesz

Amikor egy MI építi a weboldaladat, a szövegek és a képek általában közvetlenül a kódba íródnak. Ez rendben van, amíg csak te szerkeszted, és elégedett vagy azzal, hogy a változtatásokat a MI-tól kéred. Gondot okoz, ha valaki más — egy marketinges, egy üzletben dolgozó, egy önkéntes — minden héten javítani szeretne egy elírást, blogbejegyzést akarna felvenni, vagy nyitvatartást módosítana anélkül, hogy a kódhoz nyúlna.

Ezért az egyik leghasznosabb kérdés, amit korán érdemes feltenni: ki fogja módosítani a tartalmat, és milyen gyakran? A válasz dönti el, hogy kell-e CMS, egyszerű, az alkalmazásba épített adminfelület, vagy egyáltalán semmi. Ha rosszul döntesz, vagy később kell ráragasztani egy CMS-t, vagy olyat építesz, amit soha nem használsz.

Mindennapi hasonlat

Gondolj egy étterem étlapjára.

Az egyik étteremben az étlap közvetlenül a falra van festve. Szép, de egy ár megváltoztatásához hívni kell a festőt. Ez olyan, mint amikor a tartalom bele van írva a kódba.

A másikban az étlap egy táblán van, fix kerettel és címekkel: Előételek, Főételek, Desszertek. Bármelyik munkatárs letörölhet egy sort, és felírhatja az új ételt, a tábla pedig továbbra is egységesen néz ki, mert a keret és a címek nem változnak. Ez a CMS. A keret a dizájn (a sablon), a krétás sorok a tartalom, a szabály, hogy „csak a vezető módosít árakat”, pedig a CMS jogosultsága.

Hagyományos és headless CMS

Két nagy típus van.

Hagyományos (összekapcsolt) CMS. Egy rendszer tárolja a tartalmat és megjeleníti a weboldalt. Kiválasztasz egy témát, írsz a szerkesztőben, megnyomod a közzétételt, és megjelenik az oldal. A WordPress, a Drupal és a Joomla így működik, ahogy a beépített szerkesztők is olyan oldalépítőkben, mint a Squarespace vagy a Wix.

Headless CMS. A CMS csak tárolja és szerkeszti a tartalmat. Nincs saját „feje”, vagyis nincs webhelye. A webhelyed vagy az alkalmazásod API-n keresztül kéri le a tartalmat, és a saját dizájnjában jeleníti meg. A Contentful, a Sanity és a Strapi ismert példák, a WordPress pedig így is futtatható.

Ha a webhelyedet MI-építővel egyedi kódként készítették, a headless CMS (vagy egy kis beépített adminrész) természetes választás, mert a MI már elkészítette a frontendet.

Kidolgozott példa: egy pékség hírei és étlapja

Tegyük fel, hogy Maya, a pékség tulajdonosa MI-vel épített weboldalt kapott főoldallal, étlappal és hírek résszel. A munkatársai szeretnék közzétenni, hogy „Tökös kenyér újra kapható!”, anélkül hogy minden alkalommal Mayát kérdeznék.

Egy CMS ehhez az oldalhoz strukturált típusokban tárolná a tartalmat, hasonlóan a adatbázis tábláihoz:

Tartalomtípus: Bejegyzés

Tartalomtípus: Étlap-tétel

A munkatársak bejelentkeznek a szerkesztőbe, kitöltenek egy űrlapot az új bejegyzéshez, feltöltenek egy fotót, és megnyomják a közzétételt. A webhely hírek oldala lekéri a CMS-től az összes status = published bejegyzést, a legújabbal kezdve, és a webhely dizájnjában jeleníti meg. Senki sem nyúl a kódhoz, az elrendezés pedig egységes marad, mert a munkatársak csak mezőket töltenek ki.

Figyeld meg, mire jók a mezők. Mivel a price saját mező, és nem egy mondat egy bekezdésben, a webhely mindenhol ugyanabban a formátumban tud árakat mutatni. A status mező miatt a munkatársak vázlatokat menthetnek anélkül, hogy azok megjelennének a webhelyen.

Fontos kifejezések

Gyakori hibák és tévhitek

• „A CMS ugyanaz, mint egy weboldalépítő.” A weboldalépítőkbe gyakran beletartozik egy CMS, de a CMS kifejezetten a tartalom kezeléséről szól. A headless CMS-nek egyáltalán nincs webhelydizájnja.
• „Minden webhelynek kell egy.” Egy ötoldalas oldal, amely évente kétszer változik, nem igényli. Ha a MI-t kéred, hogy „frissítse a nyitvatartást”, az egyszerűbb lehet, mint egy CMS karbantartása.
• Minden egy nagy szövegdobozba zsúfolása. Ha az árak, dátumok és címek mondatokba ágyazva vannak, nem lehet rendezni, szűrni vagy újraformázni őket. Használj külön mezőket.
• A jogosultságok elfelejtése. Azt is döntsd el, ki publikálhat, nem csak azt, ki írhat. Egy új munkatárs valószínűleg nem törölhetné a főoldalt.
• A képek figyelmen kívül hagyása. Méretkorlát nélkül az emberek hatalmas fotókat töltenek fel, és az oldal lelassul. Kérj automatikus átméretezést.
• Azt feltételezni, hogy a tartalom könnyen átmozgatható. Egyik CMS-ből a másikba költözni általában a tartalom exportálását és átképezését jelenti. Lásd hogyan költöztess WordPress-oldalt.

Mit kérj az MI-építődtől

• „Melyik része a webhely tartalmának van kódba írva, és melyik jön adatbázisból?”
• „Tárold a blogbejegyzéseket adatbázisban, cím, slug, törzs, borítókép, státusz és közzétételi dátum mezőkkel.”
• „Építs egy egyszerű adminoldalt, ahol a bejelentkezett munkatársak létrehozhatnak, szerkeszthetnek és közzétehetnek bejegyzéseket. Törölni csak az adminok tudjanak.”
• „A vázlatokat csak a bejelentkezett munkatársak lássák; a nyilvános oldalon csak a közzétett bejegyzések jelenjenek meg.”
• „Méretezd át a feltöltött képeket, és fájltárolóban tárold őket, ne az adatbázisban.”
• „Vagy kösd össze ezt a webhelyet [egy headless CMS-sel] annak API-ján keresztül, az API-kulcsot pedig tartsd a szerveren.”

Lépésről lépésre segítségért lásd hogyan adj blogot a weboldaladhoz és hogyan építs blogot MI-val. Ha a WordPress elhagyását mérlegeled, a WordPress-alternatívák összehasonlítja a lehetőségeket.

CMS és a Mythex

A Mythex MI-alkalmazásépítő, nem CMS: alapesetben nincs külön szerkesztői bejelentkezés egy tartalmi csapatnak, a tartalmat pedig általában a csetben kéred. Ha más embereknek is szerkeszteniük kell a tartalmat, kérd meg az ügynököt, hogy építsen egy kis adminterületet, amely a projekt Postgres adatbázisát használja, a feltöltések pedig fájltárolóban maradnak. A Mythex nem tartalmaz végfelhasználói bejelentkezést, ezért az ügynök az általad választott bejelentkezési szolgáltatót köti be. Vagy kérheted, hogy a webhelyet egy már használt headless CMS-hez kösse annak API-ján keresztül.

Kérdések