Hummi CMS • Flat-File / Headless Hybrid • PHP 8+ OOP

Wydajny system CMS
zorientowany na bezpieczeństwo i szybkość.

Hummi CMS to autorski system dla stron firmowych, landing page'y i serwisów usługowych, w których priorytetem jest przewidywalna wydajność, niski narzut technologiczny, pełna kontrola nad danymi i wielowarstwowe zabezpieczenia.

Poniżej znajduje się opis architektury, modelu danych i założeń projektowych systemu.

Model architektoniczny Moduły natywne Otwartość danych i ścieżka wyjścia
0 SQL
Na produkcyjnej ścieżce odczytu
≈ 0.13 s
TTFB (End-to-End)
CLS ≈ 0
Natywny potok mediów z Blur Base64
Kontekst

W większości stron firmowych problemem nie jest brak funkcji, lecz nadmiarowa architektura.

Systemy uniwersalne muszą być wystarczająco elastyczne, aby obsłużyć bardzo różne scenariusze. To oznacza, że nawet prosta strona firmowa dziedziczy narzut technologiczny wynikający z architektury projektowanej pod znacznie szersze zastosowanie.

Dla wdrożeń, których główną funkcją jest szybki odczyt treści i stabilny render, taka złożoność bywa nieuzasadniona. Generuje natomiast:

  • dłuższą ścieżkę wykonania,
  • wyższy koszt utrzymania,
  • większą powierzchnię ataku,
  • ryzyko długu technicznego.

Hummi CMS upraszcza ten model. Zamiast budować stronę na architekturze do wszystkiego, ogranicza system do warstw niezbędnych dla konkretnego typu wdrożeń.

Model architektoniczny
Architektura danych i potok renderu

Uproszczony model danych i skrócona ścieżka odczytu

Hummi odrzuca relacyjną bazę danych dla operacji odczytu na produkcji. Dane strukturalne przechowywane są w plikach JSON, które stanowią główne źródło prawdy systemu.

Podczas zapisu dane z panelu są mapowane do natywnych tablic PHP. Bridge inicjuje odczyt z tych tablic, a sam JSON pełni rolę fallbacku. Tablice są utrzymywane w pamięci operacyjnej serwera za pomocą OPcache.

Rdzeń systemu uruchamia się w stałej, przewidywalnej kolejności: środowisko, ścieżki, autoloader, zabezpieczenia, konfiguracja, język i routing. Taki model upraszcza utrzymanie i ogranicza liczbę punktów awarii.

W praktyce oznacza to krótszą ścieżkę renderu: bez zapytań SQL na froncie, bez kaskady rozszerzeń i bez odczytu z dysku przy każdym requeście. Model jest zoptymalizowany pod scenariusz read-heavy, który dominuje w stronach firmowych.

Flat-File JSON PHP 8+ OOP OPcache Bridge Read-heavy
Potok danych 
ZAPIS (panel administracyjny)
→ Dane zapisywane do plików JSON
→ JSON = główne źródło prawdy
→ Mapowanie do natywnych tablic PHP
→ Tablice trzymane w RAM (OPcache)

ODCZYT (użytkownik na stronie)
→ Request → Router
→ Bridge ładuje tablice z pamięci RAM
→ JSON jako fallback
→ Render HTML
Wydajność

Wydajność nie wynika z warstw optymalizacji dodawanych po fakcie, lecz z krótszej ścieżki wykonania.

W systemach uniwersalnych wydajność poprawia się zwykle po wdrożeniu — pluginem cache'ującym, pluginem do obrazów, dodatkową warstwą CDN. Każde z tych rozwiązań łagodzi skutki złożonej architektury, ale nie eliminuje jej przyczyny.

W Hummi ścieżka renderu jest krótsza na poziomie projektu. Serwer wykonuje mniej operacji, aby dostarczyć tę samą stronę, a czas odpowiedzi wewnętrznego renderu schodzi do mikrosekund nawet na hostingu współdzielonym.

Natywny potok mediów

Obraz jest zasobem produkcyjnym, nie plikiem wrzuconym do biblioteki

Hummi nie pozwala na wgranie surowego zdjęcia bezpośrednio na stronę. Silnik automatycznie wykonuje resizing, kompresję i konwersję do WebP. Generuje miniatury oraz placeholder Blur Base64 osadzany w strukturze HTML.

Przeglądarka od pierwszej milisekundy zna proporcje obrazu i rezerwuje pod niego przestrzeń w layoucie. To eliminuje przesunięcia układu i redukuje wskaźnik CLS do wartości bliskich zeru — bez zewnętrznych skryptów ani pluginów optymalizacyjnych.

Resize Kompresja WebP Miniatury Blur Base64 CLS ≈ 0 Core Web Vitals
Potok mediów 
UPLOAD (panel administracyjny)
→ Walidacja formatu i rozmiaru
→ Resize do zdefiniowanych breakpointów
→ Kompresja i konwersja do WebP
→ Generowanie miniatur
→ Generowanie kodu Blur Base64

RENDER (strona publiczna)
→ Placeholder Blur Base64 w HTML
→ Znane proporcje od pierwszego bajtu
→ Brak przesunięć layoutu
→ CLS ≈ 0
Bezpieczeństwo

Bezpieczeństwo wynika z ograniczenia powierzchni ataku, nie z liczby zainstalowanych zabezpieczeń.

Największe ryzyko w popularnych systemach CMS nie wynika z ich rdzenia, lecz z otwartego ekosystemu wtyczek, motywów i rozszerzeń stron trzecich. Hummi drastycznie ogranicza tę powierzchnię ataku na poziomie fundamentów architektury.

Audyty OWASP ZAP

Publiczna warstwa systemu przechodzi regularne testy penetracyjne. Audyty OWASP ZAP Full Scan oraz AJAX Spiders potwierdzają zerową liczbę podatności o statusie krytycznym i średnim.

Eliminacja wektorów SQLi

Produkcyjny odczyt treści opiera się na formacie JSON i tablicach w pamięci RAM. Całkowity brak zapytań do relacyjnej bazy danych na froncie fizycznie uniemożliwia ataki typu SQL Injection.

Zamknięty łańcuch zależności

Brak zewnętrznego marketplace'u wtyczek i motywów. Cała logika biznesowa jest natywną częścią silnika, co drastycznie redukuje powierzchnię ataku i eliminuje ryzyko luk w kodzie stron trzecich.

Rate Limiting i anty-flooding

Publiczne punkty wejścia są chronione mechanizmami ograniczającymi częstotliwość żądań w modelu sliding window. Chroni to aplikację przed floodingiem i niekontrolowanym obciążeniem zasobów.

Stateless API i walidacja żądań

Publiczne żądania obsługiwane są w modelu bezstanowym. Przechodzą wielowarstwową walidację: kontrolę metody, weryfikację pochodzenia, walidację struktury danych JSON oraz niewidoczne filtry honeypot neutralizujące boty.

Bezpieczna inicjalizacja rdzenia

Środowisko, sesja i nagłówki bezpieczeństwa — w tym rygorystyczna polityka Content-Security-Policy (CSP) — są inicjalizowane centralnie na poziomie rdzenia systemu, zanim jakakolwiek logika aplikacyjna zostanie uruchomiona.

Panel administracyjny
Warstwa edycji treści

Panel zarządza danymi, a nie układem strony

Hummi celowo rezygnuje z edytorów wizualnych typu drag-and-drop. Panel udostępnia dedykowane pola i kolekcje, w których klient wprowadza surowe dane — teksty, zdjęcia, pozycje menu. Silnik renderuje je w niezmiennym, przetestowanym layoucie.

Efekt: strona wygląda tak samo dobrze po roku użytkowania, jak w dniu wdrożenia. Design jest częścią kodu, nie częścią panelu.

Dedykowane pola Kolekcje Brak drag-and-drop Stabilność layoutu Odporność na błędy obsługi
Co klient może edytować
  • teksty, nagłówki, opisy
  • zdjęcia i grafiki
  • pozycje menu i dane kontaktowe
  • elementy kolekcji (wpisy, pozycje oferty)
  • dane SEO i Open Graph per podstrona
Czego klient nie może zepsuć
  • responsywność
  • układ sekcji i hierarchia wizualna
  • typografia
  • zachowanie na urządzeniach mobilnych
  • struktura kodu HTML
Moduły natywne
Architektura modularna

Skalowanie funkcjonalności bez marketplace'u wtyczek

Zamiast instalować zewnętrzne rozszerzenia od losowych autorów, Hummi udostępnia natywne moduły wbudowane w silnik. Każdy jest opcjonalny i aktywowany w konfiguracji. Żaden nie pochodzi z zewnętrznego źródła.

Analityka

Natywna klasa analityczna zgodna z GDPR przez design: adresy IP są pseudoanonimizowane hashem SHA-256 z solą dzienną i nie mogą zostać odtworzone. Tracking działa bez plików cookie i bez ciężkich skryptów zewnętrznych. Dane utrzymywane są w 14-dniowym oknie kroczącym z deduplikacją wizyt per sesję i per IP.

Formularze

Przesył AJAX, walidacja backendowa, honeypot i rate limiter. Publiczna warstwa formularzy działa bezstanowo, bez przeładowania strony i bez zewnętrznych bibliotek.

Multilang

Dedykowane URL-e (/en/, /de/), hreflang, osobne mapy canonical, SEO per język. Wbudowane w architekturę routingu.

Multipage

Konfigurowalny dispatcher tras. Przejście z one-page do serwisu wielostronicowego bez przepisywania silnika. Landing page'e, podstrony statyczne, kolekcje dynamiczne z wzorcem /sekcja/{slug}.

Image Pipeline

Resize, kompresja, WebP, miniatury, Blur Base64. Każdy obraz jest przetworzonym zasobem produkcyjnym przygotowanym pod Core Web Vitals.

Panel administracyjny

Dedykowane pola i kolekcje zamiast edytora wizualnego. Klient edytuje dane. Design pozostaje stabilny.

Backup i wersjonowanie

Automatyczne kopie zapasowe przy każdym zapisie. Przywracanie poprzedniej wersji treści. Dane w JSON umożliwiają wersjonowanie.

SEO techniczne

Sitemap XML, schema.org, canonical, Open Graph, hreflang, semantyczny HTML5, priorytetyzacja tras. Natywna część silnika.

Security Layer

Restrykcyjny router, filtrowanie skanów, sanityzacja wejścia, zabezpieczone sesje administratora, tokeny CSRF dla operacji panelowych oraz rotacja logów. Bezpieczeństwo strukturalne zamiast warstwy dokładanej po fakcie.

Każdy moduł jest opcjonalny i aktywowany w konfiguracji. Żaden nie wymaga zewnętrznych zależności.

Otwartość danych i ścieżka wyjścia

Autorski system nie musi oznaczać uzależnienia od jednego wykonawcy.

Najczęstszy zarzut wobec autorskich CMS-ów to ryzyko vendor lock-in. W wielu przypadkach jest uzasadniony: dane w zamkniętym formacie, nieczytelny kod, brak ścieżki migracji. Hummi został zaprojektowany tak, aby te problemy nie wystąpiły.

Model danych i przenoszalność

Dane klienta są otwarte, a wyjście z systemu jest zdefiniowaną operacją techniczną

Treści i konfiguracja są przechowywane w plikach JSON — otwartym standardzie IT czytelnym dla każdego języka programowania.

Silnik jest napisany w PHP 8+ z wykorzystaniem namespaced klas i autoloadingu zgodnego z praktyką PSR-4. Kod jest podzielony na moduły i metody, co ułatwia jego przejęcie, rozwój i audyt przez innego programistę.

W przypadku rezygnacji z Hummi klient ma dwie ścieżki wyjścia:

Wykup pełnej licencji — klient nabywa prawa do silnika i kontynuuje rozwój samodzielnie lub z innym programistą.

Eksport do szablonu statycznego — projekt zostaje wyeksportowany do czystego HTML/CSS/JS wraz z danymi JSON. Strona działa niezależnie od silnika Hummi.

Wyjście z systemu jest procesem technicznym, a nie problemem negocjacyjnym.

JSON — otwarty standard PHP 8+ OOP PSR-4 Autoloading Wykup licencji Eksport HTML/CSS/JS Brak vendor lock-in
Dane projektu
  • format: JSON (otwarty standard)
  • lokalizacja: serwer klienta
  • dostęp: pełny, bez ograniczeń
  • import/eksport: natywny
Kod silnika
  • język: PHP 8+ z OOP
  • architektura: namespaces, klasy, metody
  • autoloading: zgodny z PSR-4
  • zależności zewnętrzne: brak
  • przejęcie przez innego dewelopera: tak
Ścieżki wyjścia
  • wykup pełnej licencji z prawami
  • eksport do statycznego HTML/CSS/JS + JSON
  • migracja danych JSON do dowolnego stacku
Powiązane analizy
vs WordPress
Porównanie architektury i utrzymania
Bezpieczeństwo
Security by Design i OWASP ZAP
Vendor Lock-in
Otwartość danych i ścieżka wyjścia
Flat-File CMS
Model danych, JSON i odczyt bez SQL
Analityka
GDPR by Design i tracking bez cookies
Core Web Vitals
CLS, TTFB i architektura wydajności
Panel
Dane zamiast layoutu
Multipage
Routing i kolekcje dynamiczne
Multilang
Routing, JSON per język i hreflang
vs WIX
Kontrola nad danymi i kodem
vs Kreatory
Platforma SaaS kontra własny system
Formularze
AJAX, honeypot i stateless API
Stack technologiczny
PHP 8+
OOP / PSR-4 Autoloading
JSON (Flat-File)
OPcache
Vanilla JavaScript
HTML5 semantyczny
CSS3 / Custom Properties
WebP / Blur Base64
AJAX / Fetch API
Stateless API / Honeypot / Rate Limit
Schema.org / Open Graph
Hreflang / Sitemap XML
FAQ
Pytania techniczne

W stronach firmowych dominują operacje odczytu. Nie ma tu relacji transakcyjnych uzasadniających SQL. Flat-File z OPcache optymalizuje ten scenariusz: szybki odczyt z RAM, prosty model danych, niski koszt utrzymania.

Ryzykiem nie jest autorskość, lecz zamknięty model danych i brak ścieżki migracji. Hummi ogranicza te ryzyka: dane w JSON, kod w PHP OOP, wykup licencji lub eksport do statycznego szablonu.

Tak. Dane w JSON, silnik w PHP 8+ z podziałem na klasy i metody. Projekt może zostać przejęty, zmodyfikowany lub zmigrowany do innego stacku.

Natywny image pipeline: resize, kompresja, WebP, miniatury, Blur Base64 w HTML. Przeglądarka zna proporcje od pierwszego bajtu. CLS ≈ 0. TTFB minimalny dzięki odczytowi z RAM.

Celowa decyzja projektowa. Klient edytuje dane, nie układ. Strona zachowuje spójność wizualną niezależnie od sposobu obsługi. Standard systemów premium typu Statamic, Craft CMS, ProcessWire.

Strony firmowe, serwisy usługowe, gastronomia, marki lokalne i premium. Od prostych one-page po serwisy wielostronicowe z blogiem, landing page'ami i wielojęzycznością.

Wyjście z Hummi jest zdefiniowaną operacją techniczną. Wykup licencji z prawami albo eksport do HTML/CSS/JS + JSON. Dane pozostają własnością klienta.

Kontakt
Wdrożenie Hummi CMS

Wybór technologii powinien wynikać z wymagań projektu

Opowiem, jak architektura Hummi rozwiązuje Twój konkretny scenariusz.
Przygotuję spersonalizowane demo dopasowane do skali Twojego biznesu.

Szybki kontakt

Wypełnij formularz

Wysyłając formularz, zgadzasz się na kontakt w sprawie zapytania.
Szczegóły znajdziesz w Polityce prywatności.