f3e8a984b0
- new setup/upgrading.md: version rule, the two 0.2 boot refusals with their fixes, behaviour changes, and what 0.2 adds since 0.1 - architecture module table lists all 28 modules - WinterCMS map: cache and reorder are provided; rows for field types, sanitizing, singletons, API tokens, CORS, Turnstile, menu item types - configuration keys for CORS profiles, api_docs, auth.cookie, turnstile - index, setup intro and frontend page link the new topics
3.9 KiB
title, description, section, order
| title | description | section | order |
|---|---|---|---|
| Frontend and AJAX (not provided) | SummerCMS is headless, so CMS pages, themes, components, the AJAX framework and Snowboard are not provided; build the frontend as a separate application. | services | 160 |
Frontend and AJAX (not provided)
WinterCMS renders its frontend on the server: CMS pages and layouts in a theme, partials, components that plugins attach to pages, and the AJAX framework with Snowboard for handlers such as onSave that update parts of a page without a reload. SummerCMS provides none of these. It is headless: it serves a JSON API, realtime channels and the admin SPA, and the frontend is a separate application that talks to it.
What is not provided
| WinterCMS | In SummerCMS |
|---|---|
CMS pages, layouts and partials in themes/ |
Not provided. The frontend application renders every page. |
| Themes and the theme customisation form | Not provided. |
Components and componentDetails, defineProperties, onRun |
Not provided. Expose the data a component loaded as a JSON route. |
The AJAX framework (data-request, $this->page, AJAX handlers) |
Not provided. Call JSON routes with the frontend's own HTTP client. |
| Snowboard and its plugins | Not provided. |
| Twig and the Twig filters and functions | Not provided. |
| Sessions and flash messages | Not provided. The API is stateless and authenticates each request with a token. |
A WinterCMS plugin that shipped components and AJAX handlers is ported as routes: each component's data loading and each handler becomes a JSON endpoint declared through pact.HasRoutes.
Building the frontend
Build the frontend with any framework that can call a JSON API, as its own project with its own build and deployment:
- Data: call the plugins' JSON routes. Routing shows how routes, auth groups and JSON responses are declared, and Queries and pagination the list envelope.
- Signing in: the user plugin issues JWTs; send them as a bearer token or in the cookie the guard reads. A browser frontend can keep the token in an httpOnly cookie that the API sets, with
bouncer.CookieRefreshHandlerandbouncer.CookieLogoutHandleras its refresh and logout endpoints. See Authentication and Cookie transport. - Live updates: instead of polling an AJAX handler, subscribe to realtime channels. The frontend connects to Centrifugo with a token from the token route and receives model broadcasts and explicit events. See Realtime.
- Cross-origin calls: when the frontend runs on another origin, allow it in
http.cors, as Routing describes. A credentialed single-page app that needs its own policy on some routes names a profile with thecors:<profile>middleware; see CORS profiles. - Bot protection: guard public forms such as sign-up or guest entry with Cloudflare Turnstile: the frontend widget's token goes with the request, and the
turnstile:openorturnstile:closedmiddleware checks it. See Turnstile. - Page cache: a server-rendered frontend that caches its pages can have them purged after every admin save, so an edit shows on the next page view. See Site cache purge.
- API documentation: publish a browsable Swagger UI page of the public API for frontend developers with
http.api_docs.enabled. See API documentation page. - Push notifications: see Web Push.
The admin is the one frontend SummerCMS ships. It is a single-page app built the same way, against the admin API; see Admin SPA.
The full map of what carries over from WinterCMS, and what does not, is on Coming from WinterCMS.