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
41 lines
3.9 KiB
Markdown
41 lines
3.9 KiB
Markdown
---
|
|
title: Frontend and AJAX (not provided)
|
|
description: SummerCMS is headless, so CMS pages, themes, components, the AJAX framework and Snowboard are not provided; build the frontend as a separate application.
|
|
section: services
|
|
order: 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](routing.md) shows how routes, auth groups and JSON responses are declared, and [Queries and pagination](../database/queries-and-pagination.md) 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.CookieRefreshHandler` and `bouncer.CookieLogoutHandler` as its refresh and logout endpoints. See [Authentication](authentication.md) and [Cookie transport](authentication.md#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](realtime.md).
|
|
- **Cross-origin calls:** when the frontend runs on another origin, allow it in `http.cors`, as [Routing](routing.md#cors) describes. A credentialed single-page app that needs its own policy on some routes names a profile with the `cors:<profile>` middleware; see [CORS profiles](routing.md#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:open` or `turnstile:closed` middleware checks it. See [Turnstile](authentication.md#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](caching.md#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](routing.md#api-documentation-page).
|
|
- **Push notifications:** see [Web Push](push.md).
|
|
|
|
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](../backend/admin-spa.md).
|
|
|
|
The full map of what carries over from WinterCMS, and what does not, is on [Coming from WinterCMS](../setup/coming-from-wintercms.md).
|