Blog Settings

Overview

Each blog in Postnomic has configurable settings that control its behavior, appearance, and interaction features. Access these settings from the dashboard by selecting your blog and navigating to the Settings page.

Comment Settings

Postnomic includes a built-in comment system with configurable required fields and moderation options. Under Settings → Comments, you can control:

Required Fields

Choose which fields commenters must provide when leaving a comment:

• Name — Require commenters to enter their name. Enable this for accountability.
• Email — Require an email address. Useful for follow-up notifications and spam reduction.
• Phone — Require a phone number. Typically only needed for specific use cases.

You can enable any combination of these fields. When a field is required, the comment form will not submit without it, and the API enforces the requirement server-side.

Comment Moderation

Enable moderation to review comments before they appear publicly:

• Moderation enabled — New comments enter a Pending state and must be approved by a blog editor or admin before they are visible.
• Moderation disabled — Comments are immediately visible after submission.

When moderation is enabled, comments can be in one of three states:

Manage the moderation queue from the Comments page in your blog dashboard.

Blog Layout

Choose how your blog's post listing is displayed to readers:

• Default — A traditional single-column layout where posts appear in a vertical list. Best for blogs focused on long-form written content.
• Masonry — A multi-column grid layout where post cards fill available space dynamically. Ideal for visual blogs with cover images and shorter posts.

The layout setting is returned via the API and automatically applied by the Client SDKs when rendering the blog index page.

API Key Management

Manage the API keys that your applications use to access this blog's content. Navigate to Settings → API Keys to:

• Create new keys — Generate keys with descriptive names for different environments or applications.
• View existing keys — See all active keys with their names and creation dates.
• Revoke keys — Permanently disable a key. This immediately prevents all applications using that key from accessing the blog.

See the API Key Authentication guide for detailed best practices.

Blog Information

Under Settings → General, you can update:

• Name — The display name shown in listings and page titles.
• Description — A summary used in metadata and blog headers.
• Canonical URL — The primary URL where your blog is hosted, used for SEO purposes and canonical link headers.

Renaming a Blog

The blog slug is the blog's address: it is the identifier in public API routes, the BlogSlug in your Client SDK configuration, and the folder your media is stored under. Changing it is therefore a rename, and Postnomic moves everything that depends on it:

1. Every media file is copied from the old slug's folder to the new one, and the copy is verified.
2. The media links stored in this blog's posts and translations are rewritten to the new folder. Post dates are not touched.
3. The slug is switched.

You can rename a blog by editing its slug in the blog dialog (a warning appears as soon as you change it), with the MCP tool rename_blog, or through the API with POST /blogs/{blogId}/rename. Only an Admin of the blog can do it. A slug must consist of lowercase letters and digits separated by single hyphens.

Nothing breaks on the day of the rename. For 90 days afterwards:

• Public API requests for the old slug are answered as the renamed blog, so a site or app still configured with the old BlogSlug keeps working. Each such response carries the header X-Postnomic-Blog-Slug with the current slug — a sign that a configuration is due for an update.
• Every old media link keeps working, because the old files stay where they are.

Use those 90 days to update your BlogSlug setting. A rename is reversible: rename the blog back to its old slug at any time.

If a rename is interrupted — for example by a storage hiccup — the blog is left exactly as it was (the API reports the unfinished rename as pendingSlug). Run the same rename again and it continues where it stopped.

After the 90 days the old slug stops answering. The old media files are kept until an Admin removes them explicitly (DELETE /blogs/{blogId}/former-slugs/{slug}); only then is the old slug free to be used by another blog. That removal is refused while any post still links to a file in the old folder. The retained files do not count toward your storage quota.

The general update of a blog (PUT /blogs/{blogId}) no longer changes the slug; it answers 400 and points to the rename if you try.

Danger Zone

At the bottom of the settings page, you will find destructive actions:

• Delete Blog — Permanently removes the blog and all associated content (posts, comments, media, tags, categories, user assignments). This action cannot be undone. Only Admins can delete a blog.