NetlifyCMS open-source content management

Kas yra NetlifyCMS ir kodėl jis vis dar aktualus

NetlifyCMS – tai open-source turinio valdymo sistema, kuri pasirodė maždaug 2017 metais ir greitai tapo populiari tarp frontendo kūrėjų, kurie ieškojo paprastesnio būdo valdyti statinių svetainių turinį. Skirtingai nei tradicinės CMS sistemos kaip WordPress ar Drupal, NetlifyCMS veikia pagal visiškai kitą principą – jis nesaugo duomenų duomenų bazėje, o dirba tiesiogiai su jūsų Git repozitorija.

Pagrindinis šios sistemos privalumas – ji puikiai dera su JAMstack architektūra. Jei jūsų svetainė sukurta naudojant Gatsby, Next.js, Hugo ar bet kurį kitą statinių svetainių generatorių, NetlifyCMS gali tapti idealiu sprendimu turinio valdymui. Sistema generuoja paprastą administravimo sąsają, kuri leidžia redaktoriams ir turinio kūrėjams valdyti turinį be jokių techninių žinių, nors pati svetainė lieka statinė ir greitai veikianti.

Įdomu tai, kad NetlifyCMS nereikalauja jokio backend’o – visa logika vykdoma naršyklėje. Kai redaktorius prisijungia prie CMS, sistema naudoja Git Gateway arba tiesiogiai GitHub/GitLab API, kad skaitytų ir rašytų failus į repozitoriją. Tai reiškia, kad kiekvienas turinio pakeitimas tampa Git commit’u, o tai suteikia visą versijų kontrolės galią.

Diegimas ir pradinė konfigūracija

Pradėti naudoti NetlifyCMS yra stebėtinai paprasta. Jums reikia tik dviejų failų: admin/index.html ir admin/config.yml. Pirmasis failas – tai paprasta HTML struktūra, kuri įkelia NetlifyCMS JavaScript biblioteką, o antrasis – konfigūracijos failas, kuris apibrėžia, kaip turėtų atrodyti jūsų turinio struktūra.

Štai minimalus index.html pavyzdys:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Content Manager</title>
</head>
<body>
  <script src="https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js"></script>
</body>
</html>

Konfigūracijos failas yra šiek tiek sudėtingesnis. Jame reikia nurodyti backend’ą (paprastai GitHub ar GitLab), media aplanką, kolekcijas ir laukų tipus. Pavyzdžiui, jei kuriate blogą, galite apibrėžti „posts” kolekciją su tokiais laukais kaip pavadinimas, data, autorius, turinys ir pan.

Vienas dalykas, kurį pastebėjau dirbdamas su NetlifyCMS – autentifikacija gali būti šiek tiek kebli pradedantiesiems. Jei naudojate Netlify hostingą, viskas veikia iš karto su Netlify Identity. Bet jei hostinate kitur, reikės sukonfigūruoti OAuth aplikaciją GitHub ar GitLab pusėje. Tai nėra raketos mokslas, bet dokumentacija kartais būna per daug abstrakti.

Turinio modeliavimas ir kolekcijos

NetlifyCMS leidžia kurti dviejų tipų kolekcijas: folder collections ir file collections. Folder collections naudojamos, kai turite daug panašių įrašų – pavyzdžiui, blog’o straipsnių. Kiekvienas įrašas tampa atskiru failu tam tikrame aplanke. File collections tinka, kai turite vienkartinius puslapius, tokius kaip „Apie mus” ar nustatymus.

Štai kaip atrodo tipinė blog’o kolekcijos konfigūracija:

collections:
  - name: "blog"
    label: "Blog"
    folder: "content/blog"
    create: true
    slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
    fields:
      - {label: "Title", name: "title", widget: "string"}
      - {label: "Publish Date", name: "date", widget: "datetime"}
      - {label: "Featured Image", name: "thumbnail", widget: "image"}
      - {label: "Body", name: "body", widget: "markdown"}

NetlifyCMS palaiko įvairius widget’us: string, text, markdown, boolean, datetime, image, file, select, list, object, relation ir kitus. Relation widget’as yra ypač naudingas, kai norite susieti skirtingus turinio tipus – pavyzdžiui, priskirti straipsniui autorių iš autorių sąrašo.

Viena iš stipriausių NetlifyCMS pusių – tai galimybė kurti sudėtingas turinio struktūras naudojant nested objects ir list widget’us. Galite sukurti, pavyzdžiui, produktų katalogą su variantais, kiekvienas variantas gali turėti savo kainą, nuotraukas ir aprašymą. Visa tai valdoma per intuityvią sąsają, kuri automatiškai generuojama iš jūsų konfigūracijos.

Darbas su media failais ir vaizdais

Media valdymas NetlifyCMS yra gana paprastas, bet turi savo niuansų. Pagal nutylėjimą, visi įkelti failai saugomi jūsų Git repozitorijoje nurodytame aplanke. Tai puiku mažoms svetainėms, bet gali tapti problema, jei turite daug didelių vaizdų – Git nėra optimizuotas dideliems binary failams.

Laimei, NetlifyCMS palaiko išorinius media saugyklas. Galite integruoti Cloudinary, AWS S3 ar bet kurį kitą cloud storage sprendimą. Cloudinary integracija yra ypač patogu, nes ji suteikia automatinį vaizdų optimizavimą ir transformacijas. Konfigūracija atrodo maždaug taip:

media_library:
  name: cloudinary
  config:
    cloud_name: your_cloud_name
    api_key: your_api_key

Praktikoje pastebėjau, kad daugelis projektų pradeda su Git-based media saugykla, o vėliau, kai projektas auga, pereina prie Cloudinary ar panašių sprendimų. Migracija nėra labai sudėtinga, bet reikia atnaujinti visus nuorodų kelius turinyje.

Dar vienas patarimas – jei naudojate Git media saugyklą, įsitikinkite, kad turite Git LFS (Large File Storage) įjungtą, jei planuojate saugoti video ar didelius PDF failus. Be to, verta sukonfigūruoti automatinį vaizdų optimizavimą build proceso metu naudojant tokius įrankius kaip sharp ar imagemin.

Editorial workflow ir turinio valdymas komandoje

Viena iš mano mėgstamiausių NetlifyCMS funkcijų – editorial workflow. Tai leidžia sukurti turinio publikavimo procesą su trimis būsenomis: draft, in review ir ready. Tai ypač naudinga, kai dirbi su komanda, kur turinį kuria vieni žmonės, o tvirtina kiti.

Kai editorial workflow įjungtas, kiekvienas turinio pakeitimas sukuria atskirą Git branch’ą. Kai turinys patvirtinamas, branch’as sujungiamas į pagrindinį. Tai reiškia, kad galite naudoti visas Git galimybes – pull requests, code review, konfliktų sprendimą ir pan.

Konfigūruoti editorial workflow labai paprasta:

publish_mode: editorial_workflow

Tačiau yra vienas dalykas, kurį reikia žinoti – editorial workflow reikalauja, kad jūsų backend’as palaikytų branch’us. GitHub ir GitLab palaiko, bet jei naudojate kažką egzotiškesnio, gali būti problemų.

Dirbant su komanda, taip pat verta sukonfigūruoti tinkamai prieigos teises. NetlifyCMS pats neturi vartotojų valdymo sistemos – jis remiasi jūsų Git platformos autentifikacija. Tai reiškia, kad turite valdyti prieigą GitHub/GitLab lygmenyje. Galite sukurti skirtingas komandas su skirtingomis teisėmis – vieni gali tik kurti turinį, kiti gali ir publikuoti.

Customizacija ir išplečiamumas

NetlifyCMS nėra tik out-of-the-box sprendimas – jis gali būti gana lankstus, jei žinote, kaip jį customizuoti. Galite kurti custom widget’us, custom preview templates, ir net custom backend’us.

Custom widget’ai leidžia sukurti specialius įvesties laukus, kurių nėra standartinėje NetlifyCMS bibliotekoje. Pavyzdžiui, galite sukurti color picker widget’ą, map location picker’į ar bet ką kita, ko reikia jūsų projektui. Widget’as yra tiesiog React komponentas, kuris atitinka tam tikrą API.

Preview templates yra ypač naudingi turinio kūrėjams. Vietoj to, kad matytų tik žalius laukus, jie gali matyti, kaip jų turinys atrodys tikroje svetainėje. NetlifyCMS leidžia registruoti custom preview komponentus kiekvienai kolekcijai:

CMS.registerPreviewTemplate("blog", BlogPostPreview);

Kur BlogPostPreview yra React komponentas, kuris gauna turinio duomenis kaip props ir renderina preview. Tai gali būti tas pats komponentas, kurį naudojate tikroje svetainėje, arba supaprastinta versija.

Jei NetlifyCMS standartiniai backend’ai (GitHub, GitLab, Bitbucket) jums netinka, galite sukurti savo backend’ą. Tai reikalauja daugiau darbo, bet suteikia visišką kontrolę. Pavyzdžiui, galite integruoti NetlifyCMS su savo custom API, kuri saugo turinį kur nors kitur, bet vis tiek naudoja NetlifyCMS UI.

Performance ir optimizacija

Vienas iš dažniausių klausimų apie NetlifyCMS – kaip jis veikia su dideliais projektais? Atsakymas: priklauso. Jei turite šimtus ar tūkstančius įrašų, gali pradėti pastebėti lėtėjimą, ypač kai NetlifyCMS bando įkelti visą kolekciją admin sąsajoje.

Yra keletas būdų optimizuoti performance. Pirma, galite naudoti summary lauką kolekcijos konfigūracijoje, kad NetlifyCMS rodytų tik tam tikrus laukus sąraše, o ne visą turinį:

collections:
  - name: "blog"
    label: "Blog"
    folder: "content/blog"
    summary: "{{title}} - {{date}}"

Antra, jei naudojate GitHub backend’ą, įsitikinkite, kad turite tinkamą API rate limiting strategiją. GitHub API turi limitus, ir jei juos viršijate, CMS gali tapti lėtas ar net neveikti. Netlify Identity su Git Gateway padeda išspręsti šią problemą, nes jie naudoja proxy, kuris geriau valdo rate limits.

Trečia, verta apsvarstyti lazy loading strategijas. Jei turite daug kolekcijų, galite sukonfigūruoti, kad ne visos būtų įkeliamos iš karto. Tai ypač aktualu, jei turite media-heavy turinį.

Dar vienas performance aspektas – build laikas. Kiekvienas turinio pakeitimas triggerina naują build’ą, o jei jūsų svetainė didelė, tai gali užtrukti. Verta investuoti į incremental builds, kuriuos palaiko daugelis modernių static site generatorių. Taip pat galite naudoti Netlify ar panašias platformas, kurios turi optimizuotus build procesus.

Alternatyvos ir kada NetlifyCMS gali būti ne geriausias pasirinkimas

Nors NetlifyCMS yra puikus įrankis, jis nėra vienintelis žaidėjas Git-based CMS rinkoje. Yra keletas alternatyvų, kurias verta apsvarstyti priklausomai nuo jūsų poreikių.

Decap CMS – tai iš esmės NetlifyCMS fork’as, kuris atsirado po to, kai Netlify sumažino investicijas į NetlifyCMS plėtrą. Decap bendruomenė aktyviai palaiko ir tobulina sistemą, prideda naujas funkcijas ir taiso bugs. Jei pradedate naują projektą, verta apsvarstyti Decap vietoj originalaus NetlifyCMS.

Forestry.io (dabar Tina CMS) – tai komercinė alternatyva, kuri siūlo panašią funkcionalumą, bet su geresniu UI/UX ir papildomomis funkcijomis. Tina CMS turi labai įdomų požiūrį – ji leidžia redaguoti turinį tiesiogiai production svetainėje, o ne atskiroje admin sąsajoje.

Sanity – nors tai ne Git-based CMS, jis yra populiarus pasirinkimas JAMstack projektuose. Sanity siūlo daug galingesnį turinio modeliavimą ir real-time collaboration funkcijas, bet reikalauja mokėti už hosting’ą.

NetlifyCMS gali būti ne geriausias pasirinkimas, jei:
– Jums reikia real-time collaboration (keli žmonės redaguoja tą patį turinį vienu metu)
– Turite labai sudėtingą turinio struktūrą su daug ryšių tarp skirtingų tipų
– Reikia pažangių media valdymo funkcijų
– Planuojate labai didelį projektą su tūkstančiais įrašų

Tačiau jei kuriate mažą ar vidutinio dydžio svetainę, vertinate paprastumą ir norite išlaikyti visą turinį Git repozitorijoje, NetlifyCMS (ar Decap CMS) gali būti idealus pasirinkimas.

Ką daryti toliau ir kaip išspausti maksimumą

Jei nusprendėte naudoti NetlifyCMS savo projekte, štai keletas praktinių patarimų, kaip pradėti ir kaip išvengti įprastų klaidų.

Pradėkite nuo paprasto. Nesistenkite iš karto sukurti sudėtingos turinio struktūros su visais įmanomais laukais. Pradėkite nuo bazinių dalykų – pavadinimo, turinio, datos. Vėliau galėsite pridėti daugiau laukų pagal poreikį. Konfigūracijos failas yra tik YAML, todėl jį lengva keisti.

Sukurkite gerą dokumentaciją savo komandai. Net jei NetlifyCMS sąsaja yra intuityvi, turinio kūrėjai gali turėti klausimų apie tai, kaip naudoti tam tikrus widget’us ar kaip veikia editorial workflow. Paprastas README failas su screenshots gali sutaupyti daug laiko.

Naudokite version control savo naudai. Kadangi viskas yra Git, galite lengvai grįžti prie ankstesnių versijų, jei kas nors sugenda. Taip pat galite naudoti Git hooks automatizuoti tam tikrus procesus – pavyzdžiui, automatiškai optimizuoti vaizdus prieš commit’inant.

Testinkite savo konfigūraciją su tikrais duomenimis. Kartais tai, kas atrodo gerai teorijoje, praktikoje gali būti nepatogu naudoti. Paprašykite turinio kūrėjų išbandyti sistemą ir duoti feedback’ą. Galbūt paaiškės, kad tam tikri laukai turėtų būti kitokio tipo, arba kad reikia papildomų validacijų.

Investuokite į preview templates. Tai gali atrodyti kaip papildomas darbas, bet tai labai pagerina turinio kūrėjų patirtį. Kai jie gali matyti, kaip turinys atrodys tikroje svetainėje, jie daro mažiau klaidų ir yra labiau patenkinti sistema.

Sekite NetlifyCMS (ar Decap CMS) bendruomenę. GitHub issues, Discord kanalas – ten galite rasti atsakymus į daugelį klausimų ir sužinoti apie best practices. Bendruomenė yra gana aktyvi ir nori padėti.

Galiausiai, nepamirškite, kad NetlifyCMS yra tik įrankis. Jis turėtų padėti jums pasiekti tikslą – sukurti ir valdyti turinį efektyviai. Jei pastebite, kad sistema trukdo, o ne padeda, galbūt laikas persvarstyti savo požiūrį ar net pasirinkti kitą įrankį. Nėra vieno teisingo sprendimo visiems projektams, ir tai yra normalu.

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *