- docs/backend: admin controllers, forms, lists and filters, relation manager, users and permissions, settings, partials and widgets, admin SPA - docs/services: storage, outbound HTTP, realtime, Web Push, search, parity testing and the Frontend and AJAX (not provided) page - Examples for cabana (with testdata/docs YAML), fetchguard, lighthouse and its centrifugo driver, flare, beachcomber and typesense, tide; lighthouse and beachcomber TestDocs* regions run on their Postgres harnesses - concept map rows link their guide pages and the not-provided rows the Frontend and AJAX page; index lists Backend, Database and Services - TestDocsRequiredPages asserts the D-08 section order
2.8 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. See Authentication.
- 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. - 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.