I’ve been working a bit more on mdtosendy, my Ruby script for converting Markdown to email-ready HTML, and recently added a multi-template system that makes it much more flexible for managing different email designs.

To read more about the inspiration and initial development of mdtosendy, see the blog post I wrote a couple of days ago.

The Problem

Originally, mdtosendy used a single set of template files in ~/.config/mdtosendy/. If you wanted different styling or configuration options for different types of emails, you’d have to manually swap files or maintain multiple config directories. Not ideal.

The Solution: Template Directories

Now you can create multiple templates, each in its own directory under ~/.config/mdtosendy/templates/. Each template can have its own HTML template, CSS file, and configuration.

Creating a Template

Creating a new template is simple:

mdtosendy.rb --create-template mytemplate

This creates ~/.config/mdtosendy/templates/mytemplate/ with:

  • email-template.html - copied from the default template
  • styles.css - copied from the default styles
  • config.yml - blank, so it uses the base config

Then use it with:

mdtosendy.rb --template mytemplate email.md

Child Templates

Even better, you can create child templates that inherit from a parent. This is perfect when you have a base design but want variations:

mdtosendy.rb --create-template darktheme --parent mytemplate

This creates a child template that:

  • Inherits all config from the parent
  • Inherits HTML and CSS files if they don’t exist in the child
  • Lets you override just what you need

The child’s config.yml looks like:

parent: mytemplate

# Parent template config (commented out):
# ... all the parent's config as comments for reference

You can override specific settings in the child’s config, and if you don’t provide HTML or CSS files, it automatically uses the parent’s.

Configuration Hierarchy

The configuration system works in layers:

  1. Base config (~/.config/mdtosendy/config.yml) - Your Sendy API settings, default list IDs, etc.
  2. Template config (~/.config/mdtosendy/templates/NAME/config.yml) - Template-specific overrides
  3. Child template config - Overrides parent template config

Each layer can override the previous, so you can have base settings for Sendy, template-specific list IDs, and child-specific styling tweaks.

Development Mode

I also added a --dev flag that generates an email-dev.html file for easier template development:

mdtosendy.rb --dev --template mytemplate

This creates ~/.config/mdtosendy/email-dev.html with:

  • Linked CSS (not inlined) so you can edit styles and refresh
  • Sample content showing all the elements
  • A template info table showing which template and CSS file you’re using
  • Proper wrapper and content-wrapper classes so the styling matches the final email

It’s much easier to iterate on designs when you can edit CSS and see changes immediately in the browser.

Button Variants

While building this, I also added support for button variants. You can now use:

  • [Primary](url){:.button} - The default button
  • [Secondary](url){:.button .secondary} - Alternative styling
  • [Tertiary](url){:.button .tertiary} - Another alternative

Or use the aliases:

  • .btn for .button
  • .btn.alt for .button.secondary
  • .btn.alt2 for .button.tertiary

The script automatically detects which variant to use and applies the correct CSS styles when converting to email HTML.

Backwards Compatibility

If you’re upgrading from an older version, the script automatically migrates your existing template files to templates/default/ on the first run, so nothing breaks.

The multi-template system makes mdtosendy much more flexible for managing different email designs, whether you need completely different templates or just variations on a theme. Check out the GitHub repo for the latest script and details.