The headline change in 1.1.0 is that notACMS now ships two themes out of the box, and you pick one on your very first build:

./notACMS deploy --demo    # default — the amber-phosphor design you see here
./notACMS deploy --bare    # a minimal wireframe: system fonts, light mode, ~200 lines of CSS

ddev build supports the same flags. Whichever you choose, every feature works: multi-language content, blog, RSS, sitemap, search, contact form, images with responsive variants, reading time, reading progress. The difference is only in how it looks — and, critically, in how much you inherit before you start customising.

Bare core#

The core at templates/, assets/, translations/ is now a wireframe. It's intentionally minimal so that overriding a single block doesn't drag in a visual language you have to fight. If you're building a bespoke design, start from bare and you'll own the full look from day one.

Demo theme#

The demo lives at docs/demo/ and is copied into local/ when you choose --demo. It's the full amber-phosphor design you're reading now — dark mode, search overlay, docs sidebar, theme toggle, the lot. Start here if you want a polished design today and plan to tweak, not rebuild.

The local/ override system#

Both themes consume the same mechanism: every file in local/ takes precedence over the matching core path.

Core is never edited. git pull stays clean. Customisations live in your site's repo, not in a fork of this one.

Upgrading from 1.0.0#

If you were running 1.0.0 and want your site to look exactly as it did, the compatibility package is a one-liner:

cp -r docs/customization/old-template/. local/
ddev build

That drops the complete pre-1.1.0 theme — templates, SCSS, fonts, images, translations — into local/. Your site renders exactly as before. Then you can remove files from local/ selectively as you adopt new design elements.

The breaking changes you'll actually hit if you customised the old core:

• SCSS entrypoint renamed: local/assets/styles/local.scss → local/assets/styles/app_local.scss. Rename the file and update the import in local/assets/app.js.
• Core colour SCSS variables replaced with CSS custom properties: $color-body → var(--text), $color-link → var(--accent), and so on. Full mapping in UPGRADE-1.1.md.
• Translation keys removed from core (still present in the demo theme): header.tagline, nav.projects, nav.search, blog.published_on, blog.comments_disabled. If your templates call '...'|trans on those, update them.
• docs/examples/ directory removed: the useful bits moved to docs/customization/old-template/; the scratch override examples were superseded by the bare/demo model.

See UPGRADE-1.1.md for the full list with before/after snippets.

Also new in 1.1.0#

• Reading time and reading progress on posts, docs, and releases.
• Language switcher as a Twig extension (lang_switch_urls) with proper fallback chains for archives, paginated lists, and home pages.
• Post excerpts strip heading anchors — no more stray # characters in listing cards.
• Test suite scaffolding at tests/Unit/, tests/Integration/, tests/Fixtures/ with initial coverage and a test command runnable from the host.
• AI-agent skills under .claude/skills/ for working with the repo: adding locales, doc alignment checks, site sweeps, translations, and upgrade-guide generation.

Full changelog#

Every change with its category: CHANGELOG.md.

After several months of internal use on personal projects, I'm tagging the first stable release. The core feature set is solid enough to build real sites with.

Content pipeline#

The content pipeline is the heart of notACMS. It reads your local/content/ directory, parses frontmatter, and generates a complete static site in one command.

• Markdown content with YAML frontmatter
• CommonMark rendering with heading permalinks
• Excerpt generation from prose content
• Reading time calculation

Multilingual routing#

Locales are defined in _site.yaml. Each locale gets its own URL space, with optional path overrides in _routes.yaml. hreflang tags are generated automatically.

site:
  locales:
    en:
      label: "English"
      date_format: "M d, Y"
    pl:
      label: "Polski"
      date_format: "d.m.Y"

Pagefind search#

Full-text search is built into the static output via Pagefind. The build command generates the search index automatically. No external API, no server-side search — just a static index that works offline.

Image processing#

Images co-located with content are processed during build. notACMS generates WebP variants at multiple widths, automatically updates src attributes with responsive srcset, and handles the path mapping between content and output directories.

DDEV local development#

The development environment is fully containerized with DDEV. ddev start gives you PHP 8.5, Nginx, and all build tools. ddev build produces the static output. ddev code-check runs PHPStan and PHP CS Fixer.

Breaking changes#

This is the first stable release. If you've been using a pre-1.0 version, review the _site.yaml schema — the social key changed from a list to a map.

Upgrade#

git pull
ddev composer install
ddev build

What's next#

v1.1.0 will focus on the design system and documentation. This site — built with notACMS — will become the official documentation and design reference.

Longer backstory on my personal blog: I left WordPress.

The problem I kept running into#

Every PHP project I worked on eventually needed a website. Documentation, a landing page, a blog — the usual. And every time I reached for a tool, I ended up in the same place: a tool that wanted me to think like it, not like a PHP developer.

Hugo is fast but its template language is alien. Jekyll requires Ruby. WordPress is the wrong shape for static content. Next.js is powerful but it turns a Markdown publishing problem into a JavaScript bundler problem.

I kept thinking: I already know Symfony. I already know Twig. I already have Composer. Why do I need to learn a new ecosystem just to publish text?

The zero-database decision#

The first thing I decided: no database. Not "database optional" — no database at all. Content lives in files. The build process reads files. The output is files.

This forces a certain discipline. Content structure has to be explicit and predictable. There's no database query to reach for when you want to find related posts or generate a sitemap. Everything has to be derivable from the file tree.

That constraint turned out to be the right one. It makes the system easy to reason about, easy to back up, and trivially easy for AI tools to work with.

AI-friendly by design#

I started thinking about this seriously when I began using LLMs in my daily work. Asking an AI to help generate content, translate pages, or validate YAML schemas is straightforward when the format is plain text.

With a database-backed CMS, you'd need to explain the schema, write SQL, manage migrations. With notACMS, you hand the AI a directory of Markdown files and it can read, generate, and edit content directly — because the format is just text.

This isn't a feature I added after the fact. It's the reason the system is designed the way it is.

The Symfony foundation#

I built notACMS on top of Symfony 7 for the same reason I use Symfony for everything else: it's explicit, typed, and well-documented. The DI container, console commands, Twig — all of this is standard Symfony. There's nothing novel about the infrastructure.

The content model is the interesting part. The routing system reads _routes.yaml and generates Symfony routes from your content tree. The build command renders each route and writes static HTML. The service layer is thin and replaceable.

What's next#

This first release is a working foundation. The things I want to build:

• Pagefind search integration (coming in v1.0.0)
• Better image pipeline with WebP generation
• More complete multilingual support
• A proper Design Reference page (that's what this site is becoming)

The repository is public. If you want to follow along or contribute, the link is in the footer.