a896f3ff81
- setup: introduction, installation rewritten from install to serve, configuration with the keys an application sets - console: introduction, setup and maintenance, scaffolding, writing commands, utilities; every command name is checker-verified - bonfire ExampleCatalog shows arguments, bare and repeatable flags - index links the section introductions; TestDocsRequiredPages lists the seven new pages
40 lines
2.3 KiB
Markdown
40 lines
2.3 KiB
Markdown
---
|
|
title: Introduction
|
|
description: What SummerCMS is, who it is for, how its headless model works and how this documentation is organised.
|
|
section: setup
|
|
order: 10
|
|
---
|
|
# Introduction
|
|
|
|
SummerCMS is a content management framework for Go, inspired by WinterCMS. It keeps what makes WinterCMS productive (plugins that extend each other, backend lists and forms described in YAML, models, migrations and console scaffolding) and compiles an application into a single binary.
|
|
|
|
## Who it is for
|
|
|
|
SummerCMS is for developers who build content-driven applications and APIs the WinterCMS way and want a compiled, typed backend. If you already know WinterCMS, most concepts carry over: a plugin still has an ID, requires other plugins, registers and boots, ships migrations and admin YAML, and adds console commands. Start with [Coming from WinterCMS](coming-from-wintercms.md) for a concept-by-concept map.
|
|
|
|
## The headless model
|
|
|
|
SummerCMS is headless. An application serves:
|
|
|
|
- a JSON API, declared route by route by its plugins;
|
|
- an admin area, a compiled single-page application embedded in the binary, driven by each plugin's `fields.yaml` and `columns.yaml`;
|
|
- console commands for migrations, workers, the scheduler and your own tasks.
|
|
|
|
It does not render public pages. There are no themes, CMS pages, layouts, components or AJAX framework. Build the public site as a separate frontend application that calls the JSON API and, for live updates, subscribes to realtime channels.
|
|
|
|
## One binary
|
|
|
|
Plugins are Go packages compiled into the application at build time. The `summer` tool reads the application's `summer.yaml` manifest, generates the plugin imports and builds one executable. Nothing is loaded or installed at runtime, so what you tested is exactly what you deploy.
|
|
|
|
The data layer supports PostgreSQL only, and SummerCMS targets Go 1.27.
|
|
|
|
## How these docs are organised
|
|
|
|
- **Setup** covers installation, configuration and the move from WinterCMS.
|
|
- **Architecture** explains the single binary, Go modules, the application lifecycle and how a request reaches your code.
|
|
- **Plugins** covers registering a plugin, scheduling, extending other plugins and testing.
|
|
- **Console** lists the `summer` tool's commands and the commands of every application binary, and shows how to write your own.
|
|
- **API reference** has one page per framework module.
|
|
|
|
Continue with [Installation](installation.md).
|