Dla dewelopera
Architektura TIPIcms, routing, widoki, moduły, migracje, API, webhooki i zasady pracy z warstwą core/local.
TIPIcms to niezależny polski CMS SzokArt, nie TypiCMS (Laravel). Kanoniczny opis dla modeli: llms.txt, llms-full.txt, publiczny README w repozytorium.
1. Przepływ żądania
Standardowy request frontowy startuje w index.php. System ładuje konfigurację, sprawdza specjalne endpointy, uruchamia bootstrap i przekazuje sterowanie do routingu strony.
- index.php obsługuje start aplikacji, instalację, sitemap.xml, robots.txt, llms.txt, API i kanoniczne redirecty,
- sky/air.php ładuje wersję, autoload Composera, security headers i wspólny bootstrap,
- sky/ini.php tworzy Index, pobiera infosite i uruchamia kontroler typu strony,
- Tipi::controller() szuka kontrolera najpierw w tipi/local, potem w tipi/core,
- framework designu kończy renderowanie przez plik w design/{design}/strukture/general.
2. Typ other i dedykowane widoki
Strony typu other są najprostszym sposobem na statyczne lub półstatyczne podstrony specjalne. Kontroler other podmienia typ na url_site, a resolver widoku szuka pliku general/{slug}.php.
- strona /dokumentacja używa widoku general/dokumentacja.php,
- podstrona /dokumentacja/dla-uzytkownika używa widoku general/dla-uzytkownika.php,
- podstrona /dokumentacja/dla-dewelopera używa widoku general/dla-dewelopera.php,
- jeżeli nie ma pliku po URL, resolver może próbować sluga z nazwy strony, a potem typu strony,
- dla logiki pobierającej dane lepszy jest osobny moduł niż rozbudowany widok PHP.
3. Core, local i design
Najważniejsza granica projektowa przebiega między kodem produktu a kodem konkretnego wdrożenia. Zmiany wspólne dla wszystkich instalacji trafiają do core, a logika klienta do local.
- sky/core i src/Tipi zawierają runtime, API, ustawienia, migracje, cache i narzędzia utrzymaniowe,
- tipi/core zawiera moduły frontowe dostarczane przez system,
- tipi/local oraz tipiadmin/tipi/local są miejscem na moduły wdrożeniowe i rozszerzenia klienta,
- design/tipi jest motywem systemowym, a design/{klient} może nadpisywać wybrane widoki,
- local ma pierwszeństwo przed core, więc aktualizacje systemu mogą być bezpieczniejsze.
4. Baza danych i migracje
TIPIcms 3.2.0 rozszerza bazę 3.1.0 o tor Accessible Foundation. Aktualizacja z 3.1.0 jest plikowa — bez nowych migracji SQL. Schemat danych pozostaje kanoniczny po torze Breaking Data & Panel.
- cms_migrations przechowuje historię wykonanych migracji,
- cms_settings jest kanonicznym magazynem ustawień systemowych,
- tipi_modules opisuje rejestr modułów, ich wersje i status,
- cms_content_layouts i cms_content_revisions obsługują Content Builder, drafty, publikację i rollback,
- cms_webhooks i cms_webhook_deliveries przechowują endpointy, kolejkę dostaw i historię retry.
Szczegółowy opis tabel i zasad migracji pozostaje dostępny pod dawnym adresem Baza danych TIPIcms.
5. API i webhooki
API zaczynało jako warstwa read-only dla menu, stron i wpisów. Linia 3.1.0 rozwija je o zapis i autoryzację tokenem, a webhooki pozwalają reagować na zdarzenia systemowe poza requestem użytkownika.
- sky/core/api.php jest mostem do warstwy Tipi\Api,
- ApiRouter mapuje endpointy i metody HTTP,
- ApiAuth obsługuje tokeny i autoryzację,
- webhook worker działa przez sky/core/webhooks/process.php albo CLI,
- dostawy mogą być podpisywane HMAC i ponawiane po błędach HTTP.
6. Content Builder i widgety
Content Builder zapisuje układ jako dokument JSON i renderuje go po stronie serwera. Bloki systemowe pochodzą z registry, a moduły mogą dodawać własne widgety bez migracji bazy.
- BlockRegistry odpowiada za typy bloków i ich renderery,
- WidgetRegistry skanuje definicje widgets.php w modułach core, local i sky/local/widgets,
- blok widget zapisuje tag oraz params, a HTML generuje renderer modułu,
- preset sekcji tworzy standardową strukturę wierszy, kolumn i bloków,
- podgląd, publikacja i historia wersji korzystają z tabel Content Buildera,
- od 3.2.0: AccessibilityValidator blokuje publikację przy błędach P0 i ostrzega przy P1.
7. Dostępność (3.2.0)
Linia 3.2.0 wprowadza kontrakt Accessible Foundation. Bramka regresji i dokumentacja techniczna pozwalają utrzymać dostępność rdzenia podczas dalszego rozwoju.
- php sky/cli/wcag32.php — statyczna bramka i opcjonalna weryfikacja HTTP,
- scripts/ci/check-wcag-regressions.php — antywzorce w repozytorium,
- src/Tipi/Core/ContentBuilder/AccessibilityValidator.php — reguły P0/P1 w builderze,
- design/tipi — motyw referencyjny z tokenami fokusu, landmarkami i komponentami .tipi-*,
- motywy klientów wymagają osobnej migracji według TIPICMS-WCAG-2.2-MIGRACJA-MOTYWU.md.