Ko CMS postane večji od problema

Večina vsebinskih projektov se ne ustavi zato, ker ljudje ne znajo pisati vsebine. Ustavi se prej: pri domeni, CMS izbiri, temi, pluginu za obrazce, pluginu za SEO, cookie consentu, newsletterju, slikah, notranjih povezavah, pravnih straneh, analitiki in oglasih.

Na papirju je CMS rešitev. V praksi je CMS pogosto začetek novega operativnega problema. To ni članek proti CMS-om. WordPress, Webflow, headless CMS-i in podobni sistemi imajo svoje mesto. Problem nastane, ko relativno enostaven publishing workflow začne zahtevati enako količino pozornosti kot resen produktni sistem.

Litepress je nastal iz te bolečine: kako zgraditi publishing sistem, ki ni samo še ena plast CMS kompleksnosti, ampak manjša, bolj eksplicitna in bolj tehnično predvidljiva infrastruktura za vsebinske strani.

Markdown sam po sebi ni čarovnija. Dobro zna opisati tekst: naslov, odstavek, seznam, link. To je dovolj, dokler je stran res samo dokument. Realne strani pa hitro potrebujejo več: newsletter obrazec, galerijo, primerjalno tabelo, callout, oglasni blok, placeholder za sliko, prihodnjo notranjo povezavo ali komponento, ki ima privacy posledice.

V trenutku, ko avtor napiše blok kot :::newsletter-form, to ni več samo tekst. To je semantični ukaz. Sistem mora razumeti, kaj blok pomeni, kateri model pričakuje, kako se renderira v produkciji, kako izgleda v editor previewu, kateri JavaScript potrebuje, katere stile uporablja in ali potrebuje integracijo s tretjim sistemom.

Zato v Litepressu Markdown ni obravnavan kot končni HTML string, ampak kot strukturiran vhod v sistem, ki razume razširitve, integracije, design in publishing pravila. Markdown postane majhen DSL za publishing runtime. Ja, malo nerdovsko. Ampak vsaj ne rabimo sedmih pluginov, da izrišemo en obrazec.

Pri takih sistemih je zelo mamljivo reči: naredimo plugin sistem. To skoraj vedno zveni dobro v prvem diagramu. Potem pride realnost: verzije, varnost, nepredvidljiv JavaScript, CSS konflikti, server-side rendering robni primeri, polomljeni upgrade-i in plugin, ki ga nihče več ne vzdržuje.

Litepress zato trenutno ne cilja na javni plugin marketplace. Ima pa temelje za razširljivost. To je pomembna razlika. Arhitektura je zasnovana okoli kontroliranih extension pointov, ne okoli poljubnega izvajanja tuje kode.

Sistem ima registre, contracte in ločene runtime odgovornosti, execution pa ostane pod nadzorom core sistema. To omogoča, da je platforma razširljiva, ne da takoj postane plugin arheologija. WordPress PTSD naj ostane tam, kjer je: v naših spominih in občasno v nočnih morah.

Vsaka resna Markdown razširitev ima dve strani. Backend del skrbi za stvari, ki jih mora sistem vedeti pri renderiranju, validaciji in objavi: model, parsing, SSR obnašanje, JavaScript, CSS, integracije in consent zahteve.

Frontend del skrbi za avtorsko izkušnjo: toolbar gumb, popup za urejanje, preview rendering, custom stile za editor, pomoč za uporabnika in pomoč za LLM. To pomeni, da en logični extension živi v dveh izvedbenih okoljih.

Ne zato, ker bi bilo lepo imeti več datotek. Ampak zato, ker editor in renderer nimata iste odgovornosti. Editor mora pomagati človeku in AI agentu ustvariti pravilen blok. Backend mora zagotoviti, da je ta blok validen, renderabilen, varen in pravilno povezan z integracijami.

To je bolj podobno compiler/runtime arhitekturi kot klasičnemu CMS pluginu. Malo manj seksi v marketingu, precej bolj zdravo v produkciji.

Litepress ločuje registre za Markdown extensione in integracije. Markdown extension pove, kaj pomeni določen blok. Integracijski register pove, kateri konkretni provider je aktiven za določen site ali projekt.

To loči semantiko od providerja. Design ne sme vedeti, ali je zadaj Mailchimp, Brevo, ConvertKit ali lasten API. Design mora vedeti samo, da renderira newsletter obrazec v svojem vizualnem jeziku. Extension ne sme biti zlepljen z enim zunanjim ponudnikom, integracija pa ne sme neposredno diktirati designa.

Ta ločitev je dolgočasna, ampak ravno zato pomembna. Dolgoročno prepreči, da bi vsak nov provider, vsak nov design in vsak nov content block ustvaril eksplozijo posebnih primerov.

Litepress podpira več designov. Vsak design ima lahko svoj rendering layer, svoje komponente in svoj Tailwind build. CSS se compila ločeno po designu. To ni samo organizacijska odločitev, ampak meja med vsebino in vizualnim runtimeom.

Stran je lahko napisana v strukturiranem Markdownu, sistem pa jo lahko izriše v izbranem designu z upoštevanjem uporabniških modifikacij, extensionov, preview stilov in integracij. Vsebina ni vezana na en vizualni runtime.

Če se content, design, integration, editor in SSR pomešajo, sistem nekaj časa deluje hitreje. Potem pa vsaka sprememba postane dražja. To je zelo pogosta past: najprej si hiter, potem pa imaš arhitekturno mineštro s Tailwind posipom.

Dober primer je newsletter obrazec. Na ravni avtorja je to enostavno: dodaj newsletter form. Ampak sistem mora iz tega razbrati več stvari. Če aktivna newsletter integracija uporablja zunanji JavaScript in marketinške piškotke, potem obrazec ni samo UI komponenta. Je capability, ki ima privacy posledice.

Litepress lahko iz extensionov in integracij razbere, kaj stran potrebuje, še preden uporabnik klikne na objavo. Če stran uporablja element, ki zahteva marketinško soglasje, mora frontend to znati prikazati v izbranem designu: kot consent page, cookie banner, placeholder ali blokirano komponento do potrditve.

To je drugače od klasičnega pristopa, kjer se najprej injecta skripta, potem pa nek globalni cookie plugin poskuša ujeti posledice. V Litepressu consent ni naknadna dekoracija. Je del modela strani.

Ena zanimivejših posledic take arhitekture je, da extension ni samo render funkcija. Extension zna opisati samega sebe. Frontend extension lahko generira pomoč za človeka: kaj ta blok počne, katere opcije ima in kako ga pravilno uporabiti.

Isti opis je uporaben tudi za LLM. AI agentu ni treba ugibati, kako izgleda veljaven blok. Sistem mu lahko pove, kateri extensioni obstajajo, kakšne podatke pričakujejo, kakšen Markdown naj generira, katere omejitve veljajo in kaj je dober primer uporabe.

To je razlika med 'dodali smo AI' in 'sistem je zgrajen tako, da ga AI lahko razume'. Litepress prek MCP-ja agentu izpostavi aktualna Markdown navodila glede na omogočene extensione in integracije, zato agent dela z dejanskimi pravili sistema, ne s krhkim string hackingom.

Litepress ni poskus narediti najbolj fleksibilnega CMS-a na svetu. To bi bila napačna metrika. Neskončna fleksibilnost je pogosto samo drug izraz za neskončno površino napak.

Litepress raje optimizira za strukturiran Markdown, hitro objavljanje, jasne publishing state-e, predvidljive extensione, ločene designe, integracije z eksplicitnimi contracti, AI/MCP-friendly workflowe in manj operativne teže.

To pomeni tudi tradeoffe. Prvi extension je dražji kot 'samo dodaj HTML snippet'. Register zahteva disciplino. Frontend in backend del extensiona morata ostati usklajena. CSS mora biti scoped in predvidljiv. Modeli morajo biti eksplicitni.

Ampak to je namerna kompleksnost. Bolje je imeti kompleksnost v contractu kot v nevidnih runtime stranskih učinkih.

Veliko publishing projektov ne potrebuje celotnega CMS ekosistema. Potrebujejo jasno vsebinsko strukturo, predvidljivo objavo, nekaj dobro definiranih extensionov, stabilen design, podporo za slike, linke, pravne strani, analitiko in oglase ter workflow, ki ga lahko razume človek in AI agent.

Litepress je moj poskus zgraditi sistem za ta razred problema. Ne kot CMS killer. Bolj kot publishing infrastruktura za primere, kjer je klasičen CMS večji od problema, ki ga rešuje.

Najboljši znak dobre arhitekture ni, da zmore vse. Najboljši znak je, da zna jasno povedati, česa ne poskuša rešiti.