docs: adjust documentation to reflect single-binary deployments

docs/content/doc/development/cli.md

@@ -19,7 +19,7 @@ Please refer to its documentation for information about how to use flags etc.
 
 To add a new cli command, add something like the following:
 
-{{< highlight golang >}}
+```go
 func init() {
 	rootCmd.AddCommand(myCmd)
 }
@@ -31,4 +31,4 @@ var myCmd = &cobra.Command{
 		// Call other functions
 	},
 }
-{{</ highlight >}}
+```

docs/content/doc/development/config.md

@@ -32,10 +32,10 @@ Then run `mage generate-docs` to generate the configuration docs from the sample
 To retrieve a configured value call the key with a getter for the type you need.
 For example:
 
-{{< highlight golang >}}
+```go
 if config.CacheEnabled.GetBool() {
 	// Do something with enabled caches
 }
-{{< /highlight >}}
+```
 
 Take a look at the methods declared on the type to see what's available.

docs/content/doc/development/cron.md

@@ -16,13 +16,13 @@ The package exposes a `cron.Schedule` method with two arguments: The first one t
 
 A basic function to register a cron task looks like this:
 
-{{< highlight golang >}}
+```go
 func RegisterSomeCronTask() {
 	err := cron.Schedule("0 * * * *", func() {
 		// Do something every hour
 	}
 }
-{{< /highlight >}}
+```
 
 Call the register method in the `FullInit()` method of the `init` package to actually register it.
 

docs/content/doc/development/db-migrations.md

@@ -27,9 +27,9 @@ and a more in-depth description of what the migration actually does.
 
 To easily get a new id, run the following on any unix system:
 
-{{< highlight bash >}}
+```
 date +%Y%m%d%H%M%S
-{{< /highlight >}}
+```
 
 New migrations should be added via the `init()` function to the `migrations` variable.
 All migrations are sorted before being executed, since `init()` does not guarantee the order.
@@ -44,7 +44,7 @@ It will ask you for a table name and generate an empty migration similar to the
 
 ### Example
 
-{{< highlight golang >}}
+```go
 package migration
 
 import (
@@ -73,6 +73,6 @@ func init() {
 		},
 	})
 }
-{{< /highlight >}}
+```
 
 You should always copy the changed parts of the struct you're changing when adding migrations.

docs/content/doc/development/errors.md

@@ -18,7 +18,7 @@ and a human-readable error message about what went wrong.
 
 An error consists of multiple functions and definitions:
 
-{{< highlight golang >}}
+```go
 // This struct holds any information about this specific error.
 // In this case, it contains the user ID of a nonexistent user.
 // This type should always be a struct, even if it has no values in it.
@@ -69,4 +69,4 @@ func (err ErrUserDoesNotExist) HTTPError() web.HTTPError {
 		Message: "The user does not exist.",
     }
 }
-{{< /highlight >}}
+```

docs/content/doc/development/events-and-listeners.md

@@ -28,11 +28,11 @@ This document explains how events and listeners work in Vikunja, how to use them
 
 Each event has to implement this interface:
 
-{{< highlight golang >}}
+```go
 type Event interface {
     Name() string
 }
-{{< /highlight >}}
+```
 
 An event can contain whatever data you need.
 
@@ -75,7 +75,7 @@ To dispatch an event, simply call the `events.Dispatch` method and pass in the e
 
 The `TaskCreatedEvent` is declared in the `pkg/models/events.go` file as follows:
 
-{{< highlight golang >}}
+```go
 // TaskCreatedEvent represents an event where a task has been created
 type TaskCreatedEvent struct {
     Task *Task
@@ -86,11 +86,11 @@ type TaskCreatedEvent struct {
 func (t *TaskCreatedEvent) Name() string {
     return "task.created"
 }
-{{< /highlight >}}
+```
 
 It is dispatched in the `createTask` function of the `models` package:
 
-{{< highlight golang >}}
+```go
 func createTask(s *xorm.Session, t *Task, a web.Auth, updateAssignees bool) (err error) {
 
     // ...
@@ -102,7 +102,7 @@ func createTask(s *xorm.Session, t *Task, a web.Auth, updateAssignees bool) (err
     
     // ...
 }
-{{< /highlight >}}
+```
 
 As you can see, the current task and doer are injected into it.
 
@@ -122,13 +122,13 @@ A single event can have multiple listeners who are independent of each other.
 
 All listeners must implement this interface:
 
-{{< highlight golang >}}
+```go
 // Listener represents something that listens to events
 type Listener interface {
     Handle(msg *message.Message) error
     Name() string
 }
-{{< /highlight >}}
+```
 
 The `Handle` method is executed when the event this listener listens on is dispatched. 
 * As the single parameter, it gets the payload of the event, which is the event struct when it was dispatched decoded as json object and passed as a slice of bytes.
@@ -165,7 +165,7 @@ See the example below.
 
 ### Example
 
-{{< highlight golang >}}
+```go
 // RegisterListeners registers all event listeners
 func RegisterListeners() {
     events.RegisterListener((&ListCreatedEvent{}).Name(), &IncreaseListCounter{})
@@ -183,22 +183,22 @@ func (s *IncreaseTaskCounter) Name() string {
 func (s *IncreaseTaskCounter) Handle(payload message.Payload) (err error) {
     return keyvalue.IncrBy(metrics.TaskCountKey, 1)
 }
-{{< /highlight >}}
+```
 
 ## Testing
 
 When testing, you should call the `events.Fake()` method in the `TestMain` function of the package you want to test.
 This prevents any events from being fired and lets you assert an event has been dispatched like so:
 
-{{< highlight golang >}}
+```go
 events.AssertDispatched(t, &TaskCreatedEvent{})
-{{< /highlight >}}
+```
 
 ### Testing a listener
 
 You can call an event listener manually with the `events.TestListener` method like so:
 
-{{< highlight golang >}}
+```go
 ev := &TaskCommentCreatedEvent{
 	Task:    &task,
 	Doer:    u,
@@ -206,6 +206,6 @@ ev := &TaskCommentCreatedEvent{
 }
 
 events.TestListener(t, ev, &SendTaskCommentNotification{})
-{{< /highlight >}}
+```
 
 This will call the listener's `Handle` method and assert it did not return an error when calling.

docs/content/doc/development/feature.md

@@ -25,9 +25,9 @@ It returns the `limit` (max-length) and `offset` parameters needed for SQL-Queri
 
 You can feed this function directly into xorm's `Limit`-Function like so:
 
-{{< highlight golang >}}
+```go
 projects := []*Project{}
 err := x.Limit(getLimitFromPageIndex(pageIndex, itemsPerPage)).Find(&projects)
-{{< /highlight >}}
+```
 
 // TODO: Add a full example from start to finish, like a tutorial on how to create a new endpoint?

docs/content/doc/development/mage.md

@@ -53,23 +53,23 @@ These tasks are automatically run in our CI every time someone pushes to main or
 
 ### Build Vikunja
 
-{{< highlight bash >}}
+```
 mage build:build
-{{< /highlight >}}
+```
 
 or
 
-{{< highlight bash >}}
+```
 mage build
-{{< /highlight >}}
+```
 
 Builds a `vikunja`-binary in the root directory of the repo for the platform it is run on.
 
 ### clean
 
-{{< highlight bash >}}
+```
 mage build:clean
-{{< /highlight >}}
+```
 
 Cleans all build and executable files
 
@@ -94,9 +94,9 @@ Various code-checks are available:
 
 ### Build Releases
 
-{{< highlight bash >}}
+```
 mage release
-{{< /highlight >}}
+```
 
 Builds binaries for all platforms and zips them with a copy of the `templates/` folder.
 All built zip files are stored into `dist/zips/`. Binaries are stored in `dist/binaries/`,
@@ -118,17 +118,17 @@ binary to be able to use it.
 
 ### Build os packages
 
-{{< highlight bash >}}
+```
 mage release:packages
-{{< /highlight >}}
+```
 
 Will build `.deb`, `.rpm` and `.apk` packages to `dist/os-packages`.
 
 ### Make a debian repo
 
-{{< highlight bash >}}
+```
 mage release:reprepro
-{{< /highlight >}}
+```
 
 Takes an already built debian package and creates a debian repo structure around it.
 
@@ -138,25 +138,25 @@ Used to be run inside a [docker container](https://git.kolaente.de/konrad/reprep
 
 ### unit
 
-{{< highlight bash >}}
+```
 mage test:unit
-{{< /highlight >}}
+```
 
 Runs all tests except integration tests.
 
 ### coverage
 
-{{< highlight bash >}}
+```
 mage test:coverage
-{{< /highlight >}}
+```
 
 Runs all tests except integration tests and generates a `coverage.html` file to inspect the code coverage.
 
 ### integration
 
-{{< highlight bash >}}
+```
 mage test:integration
-{{< /highlight >}}
+```
 
 Runs all integration tests.
 
@@ -164,9 +164,9 @@ Runs all integration tests.
 
 ### Create a new migration 
 
-{{< highlight bash >}}
+```
 mage dev:create-migration
-{{< /highlight >}}
+```
 
 Creates a new migration with the current date.
 Will ask for the name of the struct you want to create a migration for.
@@ -177,16 +177,16 @@ See also [migration docs]({{< ref "mage.md" >}}).
 
 ### Format the code
 
-{{< highlight bash >}}
+```
 mage fmt
-{{< /highlight >}}
+```
 
 Formats all source code using `go fmt`.
 
 ### Generate swagger definitions from code comments
 
-{{< highlight bash >}}
+```
 mage do-the-swag
-{{< /highlight >}}
+```
 
 Generates swagger definitions from the comment annotations in the code.

docs/content/doc/development/metrics.md

@@ -23,7 +23,7 @@ First, define a `const` with the metric key in redis. This is done in `pkg/metri
 
 To expose a new metric, you need to register it in the `init` function inside of the `metrics` package like so:
 
-{{< highlight golang >}}
+```go
 // Register total user count metric
 promauto.NewGaugeFunc(prometheus.GaugeOpts{
     Name: "vikunja_team_count", // The key of the metric. Must be unique.
@@ -32,7 +32,7 @@ promauto.NewGaugeFunc(prometheus.GaugeOpts{
     count, _ := GetCount(TeamCountKey) // TeamCountKey is the const we defined earlier.
     return float64(count)
 })
-{{< /highlight >}}
+```
 
 Then you'll need to set the metrics initial value on every startup of Vikunja.
 This is done in `pkg/routes/routes.go` to avoid cyclic imports.

docs/content/doc/development/notifications.md

@@ -18,13 +18,13 @@ Vikunja provides a simple abstraction to send notifications per mail and in the
 
 Each notification has to implement this interface:
 
-{{< highlight golang >}}
+```go
 type Notification interface {
     ToMail() *Mail
     ToDB() interface{}
     Name() string
 }
-{{< /highlight >}}
+```
 
 Both functions return the formatted messages for mail and database.
 
@@ -35,7 +35,7 @@ For example, if your notification should not be recorded in the database but onl
 
 A list of chainable functions is available to compose a mail:
 
-{{< highlight golang >}}
+```go
 mail := NewMail(). 
     // The optional sender of the mail message.
     From("test@example.com").
@@ -54,7 +54,7 @@ mail := NewMail().
     Action("The Action", "https://example.com").
 	// Another line of text.
     Line("This should be an outro line").
-{{< /highlight >}}
+```
 
 If not provided, the `from` field of the mail contains the value configured in [`mailer.fromemail`](https://vikunja.io/docs/config-options/#fromemail).
 
@@ -74,14 +74,14 @@ It takes the name of the notification and the package where the notification wil
 Notifiables can receive a notification.
 A notifiable is defined with this interface:
 
-{{< highlight golang >}}
+```go
 type Notifiable interface {
     // Should return the email address this notifiable has.
     RouteForMail() string
     // Should return the id of the notifiable entity
     RouteForDB() int64
 }
-{{< /highlight >}}
+```
 
 The `User` type from the `user` package implements this interface.
 
@@ -92,7 +92,7 @@ It takes a notifiable and a notification as input.
 
 For example, the email confirm notification when a new user registers is sent like this:
 
-{{< highlight golang >}}
+```go
 n := &EmailConfirmNotification{
     User:  update.User,
     IsNew: false,
@@ -100,7 +100,7 @@ n := &EmailConfirmNotification{
 
 err = notifications.Notify(update.User, n)
 return
-{{< /highlight >}}
+```
 
 ## Testing
 
@@ -110,9 +110,9 @@ If it was called, no mails are being sent and you can instead assert they have b
 When testing, you should call the `notifications.Fake()` method in the `TestMain` function of the package you want to test.
 This prevents any notifications from being sent and lets you assert a notifications has been sent like this:
 
-{{< highlight golang >}}
+```go
 notifications.AssertSent(t, &ReminderDueNotification{})
-{{< /highlight >}}
+```
 
 ## Example
 

docs/content/doc/development/releasing.md

@@ -16,13 +16,7 @@ Not all steps are necessary for every release.
 	* New Features: If there are new features worth mentioning the feature page should be updated.
 	* New Screenshots: If an overhaul of an existing feature happened so that it now looks different from the existing screenshot, a new one is required.
 * Generate changelogs (with git-cliff)
-	* Frontend
-	* API
-	* Desktop
 * Tag a new version: Include the changelog for that version as the tag message
-	* Frontend
-	* API
-	* Desktop
 	* Once built: Prune the cloudflare cache so that the new versions show up at [dl.vikunja.io](https://dl.vikunja.io/)
     * Update the [Flathub desktop package](https://github.com/flathub/io.vikunja.Vikunja)
 * Release Highlights Blogpost

docs/content/doc/development/swagger-docs.md

@@ -21,7 +21,7 @@ These comments will show up in the documentation, it'll make it easier for devel
 
 As an example, this is the definition of a project with all comments:
 
-{{< highlight golang >}}
+```go
 type Project struct {
 	// The unique, numeric id of this project.
 	ID int64 `xorm:"bigint autoincr not null unique pk" json:"id" param:"project"`
@@ -69,7 +69,7 @@ type Project struct {
 	web.CRUDable `xorm:"-" json:"-"`
 	web.Rights   `xorm:"-" json:"-"`
 }
-{{< /highlight >}}
+```
 
 ## Documenting api Endpoints
 
@@ -78,7 +78,7 @@ When generating the api docs with mage, the swagger cli will pick these up and p
 
 A comment looks like this:
 
-{{< highlight golang >}}
+```go
 // @Summary Login
 // @Description Logs a user in. Returns a JWT-Token to authenticate further requests.
 // @tags user
@@ -93,4 +93,4 @@ A comment looks like this:
 func Login(c echo.Context) error {
 	// Handler logic
 }
-{{< /highlight >}}
+```

docs/content/doc/development/test.md

@@ -27,9 +27,9 @@ The easies way to do that is to set the environment variable `VIKUNJA_SERVICE_RO
 
 To run unit tests with [mage]({{< ref "mage.md">}}), execute
 
-{{< highlight bash >}}
+```
 mage test:unit
-{{< /highlight >}}
+```
 
 In Vikunja, everything that is not an integration test counts as unit test - even if it accesses the db.
 This definition is a bit blurry, but we haven't found a better one yet.
@@ -71,18 +71,18 @@ You should put new fixtures in this folder.
 When initializing db fixtures, you are responsible for defining which tables your package needs in your test init function.
 Usually, this is done as follows (this code snippet is taken from the `user` package):
 
-{{< highlight go >}}
+```go
 err = db.InitTestFixtures("users")
 if err != nil {
 	log.Fatal(err)
 }
-{{< /highlight >}}
+```
 
 In your actual tests, you then load the fixtures into the in-memory db like so:
 
-{{< highlight go >}}
+```go
 db.LoadAndAssertFixtures(t)
-{{< /highlight >}}
+```
 
 This will load all fixtures you defined in your test init method.
 You should always use this method to load fixtures, the only exception is when your package tests require extra test 
@@ -97,13 +97,13 @@ Check out the docs [in the frontend repo](https://kolaente.dev/vikunja/vikunja/s
 
 To run the frontend unit tests, run
 
-{{< highlight bash >}}
+```
 pnpm run test:unit
-{{< /highlight >}}
+```
 
 The frontend also has a watcher available that re-runs all unit tests every time you change something.
 To use it, simply run
 
-{{< highlight bash >}}
+```
 pnpm run test:unit-watch
-{{< /highlight >}}
+```