Plugins
Configure plugins in oberon/adapter.ts by passing them to initOberon.
oberon/adapter.ts
import { initOberon } from "@oberoncms/core/adapter"
import { authPlugin } from "@oberoncms/core/auth"
import { plugin as developmentPlugin } from "@oberoncms/plugin-development"
import { plugin as tailwindPlugin } from "@oberoncms/plugin-tailwind"
import { plugin as tursoPlugin } from "@oberoncms/plugin-turso"
import { config } from "./config"
export const { adapter, handler } = initOberon({
config,
plugins: [developmentPlugin, tursoPlugin, tailwindPlugin, authPlugin],
})Order matters
Plugins are initialised in array order. Their adapter methods and handlers
are merged from left to right, so later plugins can override keys provided by
earlier plugins.
Generated apps therefore put:
- development first
- database next
- storage after database
- send after storage
- other runtime plugins after send
- auth last
Custom plugin shape
A custom plugin returns an object with:
name- optional
version - optional
disabled - optional
adapter - optional
handlers
import type { OberonPlugin } from "@oberoncms/core"
export const plugin: OberonPlugin = (adapter) => ({
name: "my-plugin",
adapter: {
...adapter,
},
handlers: {},
})Available hooks
Plugins can contribute two kinds of extension points.
adapter hooks:
- lifecycle:
prebuild - content:
addPage,deletePage,getAllPages,getPageData,updatePageData - media:
addImage,deleteImage,getAllImages - users:
addUser,deleteUser,getAllUsers,changeRole,getCurrentUser - auth/session:
signIn,signOut,hasPermissionand Auth.js adapter methods - site and kv:
getSite,updateSite,getKV,putKV,deleteKV
handlers hooks:
- route handlers keyed by path segment, merged into the CMS handler tree
Use the section pages in this Plugins area for concrete examples of each plugin type.
Last updated on