- src= fences name a file, a Go declaration or Example body, or a docs:start region - confinement: relative clean paths inside the root, no dotfiles or .env, no nested go.mod modules, Examples need // Output:, test regions must run - a drifted or missing snippet is a problem, so docs:build writes nothing - docs:sync rewrites drifted fence bodies in place - fences render in figure.code with a source caption; .md fences keep only the language - bonfire ExampleCall is the first verified example, shown in setup/installation
2.4 KiB
title, description, section, order
| title | description | section | order |
|---|---|---|---|
| Installation | Install the Go toolchain, PostgreSQL and the summer CLI you need to build a SummerCMS application. | setup | 20 |
Installation
SummerCMS is a Go module. An application requires it, lists its plugins in a summer.yaml manifest and builds everything into one binary with the summer CLI.
Requirements
- Go 1.27.
- PostgreSQL 16 for any application that uses the data layer. The database's default locale must be the ICU
pl-PLlocale, which lagoon checks when it connects. - Docker, only for the integration tests that start PostgreSQL or Mailpit containers.
You do not need Node.js to build an application or these docs. It is needed only when you work on the admin SPA itself.
Install the summer CLI
Clone the framework repository, then install the summer tool from its root:
go install ./cmd/summer
summer --help
The tool builds and watches applications, scaffolds plugins, models, migrations and admin controllers, and builds this documentation. Check that the framework compiles and its unit tests pass:
go vet ./...
go test -short ./...
go test -short skips the tests that need Docker. Run go test ./... without -short when Docker is available.
Check your install
Console commands in SummerCMS are plain bonfire.Command values: a name in namespace:verb form, its arguments and flags, and a run function that reads input and writes output. The summer tool and every application binary are built from such values, and bonfire.Call runs one in-process, which is how tests call commands. This example comes from the framework's own tests, so it compiles and runs whenever you run go test ./...:
commands := []bonfire.Command{{
Name: "acme:greet",
Description: "Greet someone by name",
Args: []bonfire.Arg{{Name: "name", Required: true}},
Run: func(ctx context.Context, in bonfire.Input, out bonfire.Output) error {
name, _ := in.Argument("name")
out.Printf("Hello, %s\n", name)
return nil
},
}}
if err := bonfire.Call(context.Background(), commands, "acme:greet", []string{"blog"}, os.Stdout); err != nil {
fmt.Println(err)
}
// Output: Hello, blog
If the tests above pass, this example ran and printed Hello, blog. See the bonfire reference for flags, prompts and styled output.