Changelog

You can now sign in to Flowershow using just your email address. Enter your email on the login page and we'll send you a magic link — click it and you're in. No password to remember, and no GitHub or Google account required.

Signing in with GitHub or Google still works exactly as before. And if you originally signed up with Google or GitHub, a magic link sent to that same email address signs you into your existing account — it won't create a duplicate.

If you've used Obsidian, you know the graph. A mini graph panel now appears on every page of your Flowershow site: the current note sits at the centre, highlighted in orange, with every connected note radiating outward. Hover a node to dim everything unrelated; click one to navigate to it. Two buttons in the corner let you go further: one opens a full-size local graph in a modal, and another opens the global graph — every note in your site at once.

Why it's here now

The graph needs a fast, queryable map of which page links to which. The backlinks feature shipped that infrastructure — a dedicated Link table that captures every wiki link, note embed, and CommonMark link during the publish pipeline. The graph is the second feature built on top of it.

Configuring it

The graph is off by default. Turn it on site-wide in Settings → Show Knowledge Graph or via config.json:

{
  "showKnowledgeGraph": true
}

Learn more in the Knowledge Graph reference.

Every page on your site now shows a Links to this page panel listing all other pages that link to it — using wiki links or standard Markdown links.

Backlinks are on by default. To turn them off, disable Show Backlinks in your site's Settings or set showBacklinks: false in your config.json.

Learn more in the Backlinks reference.

You can now paste markdown directly in the dashboard and publish it as a page on your site — no CLI, no GitHub connection, no files to upload.

It's useful for quick one-off shares: you did some research with ChatGPT and want to send the findings to a friend, you drafted notes in Obsidian and just need a shareable link without syncing your whole vault, or you wrote a quick how-to and need it somewhere people can actually read it.

Look for the Paste Markdown option on your site's welcome screen. It's marked as Experimental for now — give it a try and let us know what you think.

You can now install a Flowershow skill for your AI coding assistant that gives it everything it needs to configure and manage your sites — regardless of whether you publish via the fl CLI, a GitHub repository, or the Obsidian plugin.

What it does

The skill teaches your AI assistant how to configure your site, add custom styles, and walk you through complex operations that require the dashboard (custom domains, GitHub connections, comments via Giscus, billing). If you publish with the fl CLI, it also knows how to authenticate, publish a folder or a single file, and manage sites from the terminal.

A few things it gets right that a plain LLM wouldn't:

• Never guesses config or CSS options — fetches the authoritative reference docs before suggesting any config.json key or CSS variable name.
• Knows which features are premium — warns you if a configured feature won't work without a paid plan.
• Step-by-step for complex setups — custom domains, Giscus comments, GitHub connections, and password protection all require steps outside the CLI. The skill instructs your assistant to spell these out explicitly, numbered, rather than assuming you know where to click.
• Styles your site — knows how to add a custom.css to override visual styles, and fetches the authoritative CSS variable reference before making any suggestions.

Installing

Install the skill with one command:

npx skills add flowershow/skills --global

This registers the flowershow skill. Your AI assistant will then use it automatically whenever you ask to configure or manage a Flowershow site.

If you don't have Node.js, refer to your agent's documentation for adding custom skills or instructions, then point it to the skill source directly.

The dashboard showed you a "last published" timestamp and, for GitHub-connected sites, a sync status badge. What it couldn't tell you was anything about individual publishes: what files changed, what went wrong on a specific run, or what happened across multiple publishes over time.

Every publish — whether triggered by a GitHub push, the CLI, the Obsidian plugin, or a drag-and-drop upload — now gets a history entry you can inspect from the dashboard.

Publish history

A new History tab in your site settings shows a chronological list of every publish. Each entry displays:

• Status — Success, Error, Pending, or Canceled
• Source — GitHub, CLI, Obsidian, or Dashboard
• Timestamp — when the publish started
• Commit — for GitHub-connected sites, the commit SHA and message that triggered the push
• File summary — counts of added, updated, and deleted files

Expand any entry to see the full per-file breakdown: what changed, and whether each file was processed successfully or failed (with the error message).

Consistent status across all publish paths

The status badge now shows Published and Publishing… for all publishing paths — GitHub, CLI, Obsidian, and Dashboard. Previously, GitHub-connected sites showed "Synced" and "Syncing…" while all other paths showed "Published" and "Publishing…".

For GitHub-connected sites this is also a behaviour change. Previously, the Published status was computed by comparing your site's stored tree SHA against the current GitHub repository tree — a live API call on every dashboard refresh. This caused a visible flicker (Synced → Outdated → Synced) and used GitHub API quota on every open tab.

Published is now derived from the latest publish's file records instead. No live GitHub comparison, no flicker. The trade-off: if you suspect a push didn't trigger a publish, the status badge won't reflect that directly — open the History tab to check whether a publish was created for that commit.

Manual sync removed

The manual Sync button and the Auto-sync toggle have been removed. GitHub-connected sites always sync automatically on every push — this was already the case for over 98% of sites, and the toggle added complexity without meaningful benefit.

Flowershow has always had a rich set of configuration options, but most of them required editing a config.json file — something that's not obvious if you've never heard of it, and a barrier for anyone who isn't comfortable with JSON. Even for technical users, discovering what was actually configurable meant digging through the docs.

That changes today. Every major config option is now available in the dashboard, and the single settings page has been split into focused sections so features are easy to find without ever opening a file.

What you can now configure from the dashboard

Appearance

• Theme — choose from Default, Letterpress, Superstack, Less Flowery, or Leaf (was config.json only)
• Color mode — set the default to light, dark, or auto (was config.json only)
• Show/hide the dark mode toggle (was config.json only)

Navigation

• Logo — upload an image directly (was config.json only)
• Nav title (was config.json only)
• Nav links — full dropdown support via a JSON editor (was config.json only)
• Social links (was config.json only)
• Footer navigation (was config.json only)

Content

• Show sidebar (was config.json only)
• Sidebar sort order and path restrictions (was config.json only)
• Show table of contents (was config.json only)
• Content include / exclude / hide paths (was config.json only)
• Redirects (was config.json only)

Analytics

• Google Analytics ID (was config.json only)
• Umami website ID and script URL (was config.json only)

Features

• Show edit-this-page link (was config.json only)

Other improvements

Image upload for favicon and social image — instead of pasting a URL, you can now upload images directly. Files are processed and stored automatically.

Settings are split into sections — General, Appearance, Navigation, Content, Features, Analytics, GitHub, Access & Domains, and Billing replace the single long form.

What's still config.json only

A handful of options aren't in the dashboard yet:

• showHero, hero, cta — homepage hero section and call-to-action. We're still evaluating whether to keep these in their current form before surfacing them as dashboard settings.
• Advanced Giscus config — repoId and categoryId are manageable from the dashboard, but other Giscus options (mapping, theme, lang, inputPosition, reactionsEnabled, etc.) are still config.json only.
• Emoji favicon — the dashboard favicon upload only accepts image files. To use an emoji as your favicon, set it via config.json: { "favicon": "🌸" }.

config.json format changes

Two fields have been updated. Old forms still work for now but are deprecated:

Logo — the canonical location is now root-level logo instead of nested nav.logo:

// before (still works, deprecated)
{ "nav": { "logo": "/logo.png" } }

// now
{ "logo": "/logo.png" }

Umami — the plain string shorthand is deprecated in favour of the object form:

// before (still works, deprecated)
{ "umami": "your-website-id" }

// now
{ "umami": { "websiteId": "your-website-id" } }

Self-hosted Umami users can now also set the script URL from the dashboard (no longer requires config.json).

How config.json still works

Dashboard settings and config.json coexist. If you have a config.json in your connected repository, its values are merged on top of the dashboard config at render time — config.json always wins. This means existing file-based config continues to work without any changes. The dashboard only shows and controls DB state; it won't surface values that come from your file.

fl now does the right thing whether or not a site already exists. Run the same command every time:

fl ./my-notes

First run creates the site. Every run after that syncs changes — uploading only new or modified files and removing deleted ones.

What changed

No more separate sync step

Previously you needed two different commands:

# Before
fl ./my-notes           # first publish
fl sync ./my-notes      # every update after

Now it's just one:

fl ./my-notes           # always

fl sync still works but is deprecated.

New --yes flag for scripts and CI

When creating a new site, fl now shows a confirmation prompt with the proposed name and URL. To skip it in automated contexts:

fl --yes ./my-notes

Passing --name also skips the prompt.

Folder mode remembers the site name

After the first publish of a folder, fl writes a .flowershow file to that folder storing the site name. Subsequent runs pick it up automatically — no need to pass --name again.

Previously, if your content root had no README.md or index.md, visiting your site's root URL returned a 404. This was a common pain point for Obsidian users, whose vaults rarely contain either — your home note might be called anything from Home.md to Welcome.md to My Notes.md.

Flowershow now resolves the home page (/) via a fixed priority order, so your site always has something to show at the root.

Resolution order

1. index.md(x) or README.md(x) at your content root
2. index.html — for when you want a fully custom homepage with your own HTML, outside the Flowershow layout
3. First .md or .mdx file (sorted by path) — best-effort fallback so Obsidian vaults and other collections without an index file always show something
4. First .html file (sorted by path) — fallback for content roots with only HTML files
5. 404

index.* takes precedence over README.* if both exist.

If you want full control over which note is your home page, just rename it (or add a copy) as index.md.

See Home page docs for the full details and recommendations.

You can now control search engine crawling by publishing a robots.txt file from your vault. If one is found in your content root, it takes precedence over the default auto-generated one.

This is useful for blocking specific crawlers (e.g. AI bots) or restricting certain paths from being indexed.

See Custom robots.txt docs for details.