Phase 2 can one successfully build a blog?

So we are now onto building phase 2. In Phase 1 the development goal was to create a tool that could take a bunch of MD files and turn it into something that could be hosted. In Phase 2 the goal is to turn that output into something that could be used as a functional blog. This phase is mostly going to be functionality updates to the developer experience/ features in the blog output

(However, saying that, those are pretty much the only two things I can work on, but eh.)

What are the planned features?

  • Dev Server
  • Post Command
  • Validate Command
  • Init Command
  • Robots.txt
  • RSS Feed
  • Better Content Model
  • Tag Pages
  • Archive Page
  • Sitemap
  • Layout Updates
    • site header
    • navigation
    • footer
    • tag links
    • archive link
    • feed link
    • better typography
    • responsive layout
    • basic SEO
  • Better Errors
  • Internal Link Checking?

Dev Server

The Idea with this feature is to create a command that can serve a built version of your site locally.

It should be able to:

  • Show the content of the build root in the localhost
  • Show draft posts with a clarification they are drafts
  • Render the site as a static web host would
  • Watch for changes to the files and rebuild the served output.

Proposed Command

cable dev --root "<path to root>"

Post Command

This should allow a user to create a new post at the root directory

It should be able to:

  • Create a new stub post as draft
  • The post should have all the required frontmatter fields

Proposed Command

cable new post "Post Title" --root "<path to root>"

Validate Command

This should allow a user to validate their post configuraton before building it. It should also give the user usable output and errors.

Proposed Command

cable validate --root "<path to root>"

Init Command

This command should allow the user to scaffold the blog from scratch.

It should be able to:

  • Load a blog.toml
  • Accept a user title
  • Accept a user defined content space
  • It should also correctly wire the routes
  • It should generate the content directory and a sample post

Proposed Command

cable init --title "Title" --content "content/posts"

Robots.txt

This is a feature that would generate a robots.txt file in the root of the project dist. It should have a standard configuration and for now, allow the user to overwrite it with their own robots.txt. If the future this should be config driven.

I think a good build structure would be:

  • check to see if a user has a robots.txt in their root directory.
  • If they dont:
    • Build a robots.txt
    • save it to the dist
  • If they do:
    • Validate the robots.txt
    • if its valid copy it to the dist

Future considerations:

  • What crawlers the user wants to allow
  • Do they want AI to scrape their content
  • Honeypot?

Better Content Model

So this is basically, how can we make the post frontmatter better? At the moment its fairly limited in terms of metadata. This would allow for better SEO, RSS feed, and Aarchive page formatting. Some good things to add would be:

  • An expert (Either user defined on the post or derived)
  • A description, This is longer than the excerpt
  • An updated field. Might be hard to define this in the front matter, but we could do it in the post struct at build
  • Reading time - This would be an estimate based on word count.
  • Word Count

RSS Feed

This would allow the user to turn on or off an RSS feed and add that button into the output for a user to add. Each time a new post is published it gets added into the RSS feed for a reader. However, it would be needed to be made clear to the user that this would require some config outside of CABLE.

This should take the list of posts and then convert it into a feed.xml file and save it at the root level of the dist

Tag Pages

This would generate tag index pages where all posts for a tag are listed. Every tag is clickable. This should be auto generated with no extra user burden.

The main idea here is that tags should stop being just metadata that sits in the frontmatter and start being useful navigation. If I tag a post with cable, then the output should include a page for that tag with all the published posts that use it. This means a reader can move around the blog by topic, instead of only by date or by whatever happens to be on the index page.

It should be able to:

  • Generate one page per tag
  • Link tags from post pages
  • Link tags from the index where it makes sense
  • Ignore tags from draft posts in published builds
  • Sort the posts on each tag page by date

I do not think the user should have to define these routes by hand. If the posts have tags, Cable should be able to work out the tag pages itself.

Archive Pages

This would allow the user to see all the posts by year. For example, all posts generated in 2025.

Archive pages are fairly boring. But cable should probably generate it if blogs get too large to navigate from the homepage.

The first version can probably be fairly simple:

  • Group published posts by year
  • Sort years newest first
  • Sort posts within each year newest first
  • Add a link to the archive from the main layout

In the future this could maybe become monthly archive pages as well. A yearly archive is probably enough until there are enough posts for that to become annoying.

Sitemap

This would auto generate a sitemap at build and save it to the root of the output.

The sitemap should include the pages that Cable knows it has generated. That means the homepage, post pages, tag pages, archive pages, and any other generated public pages that exist by this point. Drafts should not be included, because the sitemap is for the published site.

This probably needs a site URL in the config. Without that, Cable can create paths, but it cannot really create useful absolute URLs. So this may be tied to a small config update as well.

It should be able to:

  • Generate sitemap.xml
  • Include only published output
  • Use the configured site URL
  • Be written to the root of the dist directory

Layout Updates

This would be generalized layout updates to make the final blog more readable to a user.

At the moment the output is good enough to prove that the compiler works, but "good enough to prove the compiler works" and "something I want people to read" are not really quite the same thing. The generated pages need a bit more structure around them.

The main layout work I want to do here is:

  • Add a proper site header
  • Add simple navigation
  • Add a footer
  • Make tags visible and clickable
  • Add obvious archive and feed links
  • Improve post typography
  • Make the layout behave properly on mobile
  • Add basic metadata for SEO and sharing