Ez a blog egy markdown-fájlokat tartalmazó mappa

A blog mögött nincs CMS, és adatbázis sincs. Minden bejegyzés egy markdown fájl, amelyet ugyanabba a repositoryba commitolunk, mint a LiteTMS kódját, így egy bejegyzés közzététele pontosan úgy működik, mint egy funkció kiadása: egy commit és egy deploy.

Ezt máshogy szerettük volna csinálni, mint a legtöbb vállalati blognál, és ez a bejegyzés bemutatja a teljes mechanizmust, beleértve éppen annak az oldalnak a forrását is, amelyet most olvas.

A felépítés, amit mindenki más használ

Egy tipikus vállalati blog teljes értékű tartalomkezelő rendszeren fut. Adatbázis, adminfelület, felhasználói fiókok, bővítmények és egy sablon, ami ellenáll, ha hozzá mer nyúlni az ember. Mindez a gépezet azért létezik, hogy a szerkesztői csapat anélkül publikálhasson, hogy a kód közelébe kellene mennie.

Nálunk nincs külön szerkesztői csapat, és amúgy is egész nap a kódtárban dolgozunk. Így kihagytuk ezt a gépezetet. Minden extra rendszer újabb feladatot jelent: frissíteni, menteni és védeni kell. Egy szöveges fájlokból álló mappa viszont nem ilyen.

Hogyan néz ki egy bejegyzés fájlja

Íme egy rövidített másolat magának ennek a bejegyzésnek a fejlécéről, majd a törzsszöveg felépítése:

---
title: This blog is a folder of markdown files
slug: why-this-blog-has-no-cms
locale: en
description: There is no CMS behind the LiteTMS blog. Every post is...
date: 2026-07-15
category: technology
tags: markdown, blog, aieo, engineering
draft: false
---

The first paragraph answers the title on its own, because that is
the part search snippets and AI assistants quote.

## A section heading

Plain markdown body. Nothing exotic.

## FAQ

### Does this sample show the FAQ convention?

Yes. Each ### line is a literal question, answered right below it.

A felső blokk kulcs-érték párok egyszerű listája. Alatta hagyományos markdown található, amelyet egy szabványos markdown-könyvtár jelenít meg. Nyelvenként egy fájl készül: ez a bejegyzés létezik .en.md és azonos nevű .pl.md fájlként is, és a lengyel változat közvetlenül megírt szöveg, nem gépi fordítás.

A minta végén található ## FAQ szakasz egy valós konvenció, nem díszítés. Mindegyik kérdés olyan, amilyet egy felhasználó beírna a keresőbe, és a build folyamat ezekből a párokból strukturált adatokat hoz létre, amelyeket a keresők bővített találatként jeleníthetnek meg. Az oldal alján található egy élő példa.

Szerkesztő helyett validátor

Mielőtt bármi élesedne, egy build parancsfájl végigolvassa az összes bejegyzésfájlt, és ellenőrzi a sémának való megfelelést. A leírás hosszának 80 és 170 karakter közé kell esnie. A kategóriának az öt megengedett érték egyikének kell lennie. A dátumnak valódi naptári dátumnak kell lennie, a slugnak pedig egyeznie kell a fájlnévvel.

A parancsfájl ezután létrehoz egyetlen indexfájlt az összes bejegyzés metaadataival, és a webhely kizárólag ezt a fájlt olvassa be. Egy listázó oldal kiszolgálása pontosan ugyanannyi erőforrást igényel ötszáz bejegyzésnél, mint ötnél.

Ugyanez a parancsfájl fut le a CI-ben minden egyes push alkalmával. Ha egy bejegyzés érvénytelen, vagy valaki elfelejtette újragenerálni az indexet, a build elbukik, és semmi sem élesedik. Hibás tartalom nem juthat el az éles környezetbe, mert az éles rendszer semmit sem fogad be, amit a validátor nem engedett át.

Miért éppen a markdown, őszintén szólva

A markdown nem látványos, hanem tisztán gyakorlatias okokból győzött. Egy markdown fájl bármilyen szövegszerkesztőben olvasható, külön eszközökkel vagy azok nélkül is. Soronként összehasonlítható, így egy bejegyzés véleményezése pontosan úgy zajlik, mint a kódé: pontosan látható, melyik mondat változott. Ráadásul ez a lehető legolcsóbban feldolgozható formátum az AI-asszisztensek számára, ami hónapról hónapra egyre fontosabbá válik.

Ez utóbbi szempont miatt érhető el itt minden bejegyzés háromféleképpen. Az oldal, amit most olvas, a HTML-verzió. Ha a böngésző címsorában a cím végére írja a .md kiterjesztést, a nyers forrásfájlt kapja meg, bájtról bájtra úgy, ahogy be lett commitolva, tiszta markdown formátumban. Emellett minden nyelv saját RSS-hírcsatornával rendelkezik az olvasók és a tartalomgyűjtők számára.

A közzétett bejegyzésekről egy gépileg olvasható katalógus is található a /blog/index.md címen, és az oldal llms.txt fájlja közvetlenül erre irányítja az AI webes robotjait. Ebből soha nem lesz duplikált tartalom, mert a nyers fájlok noindex fejlécet és a HTML-oldalra visszamutató kanonikus linket tartalmaznak.

Mit nyer Ön ezzel olvasóként

Itt semmi sem közvetlen termékfunkció. Ez egy döntés a saját tartalomközzétételünk módjáról, és illeszkedik az első bejegyzésben tett ígéretünkhöz: nincsenek kitalált számok, a szöveg pedig a forrásnál ellenőrizhető. Maga a TMS is ugyanerre a letisztult, átlátható működésre épül. Ha szeretne körülnézni, a regisztráció ingyenes.

Gyakori kérdések

Elolvashatom a LiteTMS blogbejegyzéseit nyers markdown formátumban?

Igen. Írja a .md kiterjesztést bármelyik bejegyzés címének végére, és a webhely átirányítja a nyers forrásfájlra, tiszta markdown formátumban. A közzétett bejegyzések teljes katalógusa a /blog/index.md címen érhető el.

Miért nem használ CMS-t a LiteTMS blogja?

Mert a CMS egy második rendszer lenne, amelyet frissíteni és védeni kell, miközben a blog szerzői eleve a termék kódtárában dolgoznak. A CI-validátorral támogatott markdown fájlok ugyanezt a feladatot jóval kevesebb karbantartással ellátják.

Rosszabbá teszi a bejegyzéseket az emberek számára, hogy AI-asszisztenseknek is íródnak?

Nem. Az a felépítés, amit az asszisztensek előnyben részesítenek, vagyis a lényegre törő nyitó bekezdés, a leíró címsorok és a konkrét kérdések a rövid válaszokkal, pontosan az a szerkezet, amely az emberek számára is könnyen áttekinthetővé teszi a cikket. A nyers markdown egy külön formátum, így az Ön által olvasott cikk megmarad normális, jól olvasható cikknek.