Scriptor's core stays small on purpose. Anything that isn't part of the editor, the page model, or the frontend Site contract lives in an extension you can install or skip. This track lists the extensions you can pick from today and shows you how to publish your own.
How each extension page is laid out
Every page in this track follows the same shape so you can scan for the answer you need without reading the whole thing:
- What it does. One or two paragraphs on the problem it solves and the kind of site it belongs in. If this section doesn't match your case, scan the catalog table for a better fit.
- Install. The
composer requireline for a host-side install, plus the Docker build-arg variant for image-baked installs. Both paths are documented in Installed plugins and Installing plugins. - Configure. The config block under
plugins.<key>indata/settings/custom.scriptor-config.php, or the theme settings indata/settings/<theme>-theme-config.php. Defaults shown; the minimum required keys called out. - Use. The smallest snippet that proves the extension is working: a code block, a frontmatter example, or a URL that resolves once it's installed.
- Links. Packagist + GitHub + the current published version + license + the Scriptor versions the extension supports.
Catalog
Plugins (5)
Plugins extend Scriptor's backend: they subscribe to events, add editor modules, register console scripts, or mount routes ahead of the page resolver.
| Plugin | What it does |
|---|---|
| scriptor-markdown-pages | File-system markdown pages with nested track navigation; powers this documentation site |
| scriptor-simple-router | Tiny URL router that runs ahead of the page resolver; mount JSON endpoints, controllers, custom paths |
| scriptor-markdown-feed | Atom 1.0 / RSS 2.0 feeds generated on every request from a markdown content track; no build step, no cache |
| scriptor-markdown-containers | Fenced-container syntax (:::note, :::warning, :::details, custom types) for page content, rendered theme-neutral |
| scriptor-sitemap | Drop-in sitemap.xml from CMS pages plus (if installed) markdown-pages URLs; hooks RouteNotFound, no template edits; powers this site's /sitemap.xml |
| Build your own | composer.json shape, scriptor-plugin type, manifest + entry-class contract, release flow |
Themes (1)
A theme owns the frontend HTML, the asset pipeline, and the
template chunks rendered for each page. Themes are not plugins:
they ship as Scriptor packages of type scriptor-theme and live
under themes/<name>/.
| Theme | What it does |
|---|---|
| basic | The reference theme bundled with Scriptor: minimal CSS, semantic markup, six message tokens, FilePond integration in the editor's content slot |
The Build a Theme tutorial
walks through writing your own (mini-case: bigins/atelier),
and the Example Theme
issue tracks a separate ready-to-fork starter skeleton.
Ordering and PR batching
This track lands in four PRs after the plan PR, grouped so each PR reviews as a coherent unit:
| # | PR | Pages |
|---|---|---|
| 1 | Plugin pages | one page per published plugin (scriptor-markdown-pages, scriptor-simple-router, scriptor-markdown-feed, scriptor-markdown-containers) |
| 2 | Theme + Publishing | basic-theme.md + publishing-your-extension.md (shipped) |
| 3 | News track | news/_index.md + first three news entries + RSS hook (shipped) |
The News track ships under Phase I but lives at /news/ (not
under /extensions/); it's batched here because the same plan
PR seeds the news/_index.md file. The two deliverables are
independent: Plugin pages can land before the News track, and
vice-versa.
What's not in this track
Three categories are deliberately out of scope:
- Plugin or theme authoring concepts. "How plugin discovery works", "how event subscriptions resolve", "how the editor's asset slot picks up your CSS" all live in the Developer Guide concepts and the API Reference. This track lists what exists, not how the surface works.
- Bundled iManager modules. The page model, file storage,
FTS5 search, and migrations all live in
bigins/imanagerand travel with Scriptor itself; they aren't extensions you opt into. The iManager docs cover them. - One-off snippets and recipes. A 30-line
_ext.phphook that emits a sitemap is a cookbook recipe, not an extension. The catalog is for packages with their own composer name, version, and changelog.
If you wrote something that fits the catalog and want it listed, the Publishing your extension page covers the submission flow: tag a release, publish on Packagist (or expose a VCS repo), open a PR against this site adding the catalog page.
Where to go next
If you're looking for a specific capability, scan the catalog table above; each row's link goes straight to the page.
If you want to build an extension, start with the Developer Guide concepts, pick the relevant cookbook recipe for the shape you need, then come back to Publishing your extension when you're ready to ship.
If you're operating a Scriptor site and want to know what's already installed, Installed plugins covers the editor-side view.
This track lands one PR at a time, in the order in the table above. The first chapter PR (Plugin pages) opens immediately after this plan PR merges.
