Kas yra CMS? Turinio valdymo sistemos paprastai paaiškintos

CMS, arba turinio valdymo sistema, – tai programa, leidžianti žmonėms kurti, redaguoti ir publikuoti svetainės turinį – straipsnius, puslapius, paveikslėlius, produktų aprašymus – per patogų redaktorių, o ne keičiant kodą. Ji saugo turinį, seka juodraščius ir versijas bei į svetainę įdeda publikuotą versiją. Žinomiausias pavyzdys – WordPress, bet yra ir daug kitų.

Kodėl tai svarbu kuriant su DI

Kai svetainę kuria DI, žodžiai ir paveikslėliai dažniausiai įrašomi tiesiai į kodą. Tai tinka, kol vienintelis redaguojate jūs ir patenkinti, kad keitimus prašote DI. Problema prasideda, kai kitam žmogui – rinkodaros specialistui, parduotuvės darbuotojui, savanoriui – reikia kas savaitę ištaisyti klaidą, pridėti tinklaraščio įrašą ar pakeisti darbo laiką, nesiliečiant prie kodo.

Todėl vienas naudingiausių klausimų, kurį verta užduoti anksti, yra: kas keis turinį ir kaip dažnai? Atsakymas lemia, ar jums reikia CMS, paprastos administravimo srities, įdėtos į programą, ar nieko. Jei tai padarote klaidingai, vėliau teks CMS prijungti arba sukurti tokį, kurio niekada nenaudosite.

Kasdienis palyginimas

Pagalvokite apie restorano meniu lentą.

Vienoje restoranų meniu nudažytas tiesiai ant sienos. Atrodo puikiai, bet pakeisti kainą reikia pasikviesti dailininką. Tai turinys, įrašytas į kodą.

Kitoje meniu parašytas kreidele ant lentos su fiksuotu rėmu ir antraštėmis: Užkandžiai, Pagrindiniai patiekalai, Desertai. Bet kuris darbuotojas gali nuvalyti eilutę ir užrašyti naują patiekalą, o lenta vis tiek atrodys nuosekliai, nes rėmas ir antraštės nesikeičia. Tai ir yra CMS. Rėmas – tai dizainas (šablonas), kreidės eilutės – turinys, o taisyklė „kainas keičia tik vadovas“ – CMS leidimai.

Tradicinė ir „headless“ CMS

Yra dvi pagrindinės rūšys.

Tradicinė (susieta) CMS. Viena sistema saugo turinį ir atvaizduoja svetainę. Pasirenkate temą, rašote redaktoriuje, paspaudžiate publikuoti – ir puslapis atsiranda. WordPress, Drupal ir Joomla veikia taip, taip pat įmontuoti redaktoriai tokiose svetainių kūrimo priemonėse kaip Squarespace ir Wix.

„Headless“ CMS. CMS tik saugo ir redaguoja turinį. Jai nepriklauso svetainės „galva“. Jūsų svetainė ar programa prašo turinio per API ir rodo jį savo dizainu. Žinomi pavyzdžiai – Contentful, Sanity ir Strapi, o WordPress taip pat gali veikti šiuo režimu.

Jei jūsų svetainė sukurta DI kūrimo įrankiu kaip individualus kodas, „headless“ CMS (ar mažos įmontuotos administravimo sritis) natūraliai tinka, nes DI jau sukūrė frontend'ą.

Darbo pavyzdys: kepyklos naujienos ir meniu

Tarkime, kepyklos savininkė Maja turi DI sukurtą svetainę su pradžios puslapiu, meniu ir naujienų skiltimi. Jos darbuotojai nori paskelbti „Moliūgų bandelė grįžo!“, nelaukdami Majos kiekvieną kartą.

CMS šiai svetainei turinį saugotų struktūruotais tipais, panašiai kaip lentelės duomenų bazėje:

Turinio tipas: įrašas

Turinio tipas: meniu elementas

Darbuotojai prisijungia prie redaktoriaus, užpildo formą naujam įrašui, įkelia nuotrauką ir spaudžia publikuoti. Svetainės naujienų puslapis CMS prašo visų įrašų su būsena = publikuota, naujausi pirmi, ir rodo juos svetainės dizainu. Niekas nesiliečia prie kodo, o išdėstymas išlieka nuoseklus, nes darbuotojai pildo tik laukus.

Pažiūrėkite, ką daro laukai. Kadangi kaina yra atskiras laukas, o ne sakinys pastraipoje, svetainė gali visur rodyti kainas tuo pačiu formatu. Kadangi yra būsenos laukas, darbuotojai gali išsaugoti juodraščius, kurie svetainėje nepasirodys.

Pagrindinės sąvokos

Dažniausios klaidos ir klaidingi įsitikinimai

• „CMS yra tas pats, kas svetainių kūrėjas.“ Svetainių kūrėjai dažnai turi įmontuotą CMS, bet CMS skirta būtent turinio valdymui. „Headless“ CMS visai neturi svetainės dizaino.
• „Kiekvienai svetainei jos reikia.“ Penkių puslapių svetainei, kuri keičiasi du kartus per metus, nereikia. DI paprašyti „atnaujinti darbo laiką“ gali būti paprasčiau nei prižiūrėti CMS.
• Viso turinio talpinimas į vieną didelį tekstų lauką. Jei kainos, datos ir adresai paslėpti pastraipose, negalite jų rikiuoti, filtruoti ar keisti formato. Naudokite atskirus laukus.
• Pamirštami leidimai. Nuspręskite, kas gali publikuoti, o ne tik kas gali rašyti. Naujas darbuotojas tikriausiai neturėtų galėti ištrinti pradžios puslapio.
• Paveikslėlių ignoravimas. Be dydžio apribojimų žmonės įkelia didelių nuotraukų, ir svetainė lėtėja. Paprašykite automatinio pamažinimo.
• Prielaida, kad turinys lengvai persikelia. Persikėlimas iš vienos CMS į kitą paprastai reiškia turinio eksportavimą ir perkėlimą. Žr. kaip perkelti WordPress svetainę.

Ko prašyti savo DI kūrimo įrankio

• „Kurios šios svetainės turinio dalys įrašytos į kodą, o kurios ateina iš duomenų bazės?“
• „Saugok tinklaraščio įrašus duomenų bazėje su pavadinimu, slug, tekstu, viršelio nuotrauka, būsena ir publikavimo data.“
• „Sukurk paprastą administravimo puslapį, kuriame prisijungę darbuotojai gali kurti, redaguoti ir publikuoti įrašus. Ištrinti gali tik administratoriai.“
• „Juodraščius rodyk tik prisijungusiems darbuotojams; viešoje svetainėje rodyk tik publikuotus įrašus.“
• „Keisk įkeltų paveikslėlių dydį ir saugok juos failų saugykloje, o ne duomenų bazėje.“
• „Arba prijunk šią svetainę prie [headless CMS] per jos API ir API raktą laikyk serveryje.“

Nuoseklesnei pagalbai žr. kaip pridėti tinklaraštį prie svetainės ir kaip sukurti tinklaraštį su DI. Jei svarstote apie WordPress atsisakymą, WordPress alternatyvos palygina galimybes.

CMS ir Mythex

Mythex yra DI kūrimo įrankis, o ne CMS: iš karto nėra atskiro redaktoriaus prisijungimo turinio komandai, o turinį paprastai keičiate pokalbyje prašydami. Jei kiti žmonės turi redaguoti turinį, paprašykite agento sukurti nedidelę administravimo sritį, paremtą projekto Postgres duomenų baze, o įkeliamus failus laikyti failų saugykloje. Mythex pats galutinių vartotojų prisijungimo nesuteikia, todėl agentas prijungia prisijungimo teikėją, kurį pasirenkate. Arba galite paprašyti prijungti svetainę prie jau naudojamos headless CMS per jos API.

Klausimai