Top-level Files of trunk

Files in the top-level directory from the latest check-in of branch trunk


For very various reasons, blogcpp won't be continued - by me. If anyone of you is interested in continuing this promising project, please open a GitHub issue or contact me on Twitter. :-)


A static blog generator, written in C++17.

First things first: How can I get it?

  1. You can use the Fossil client: fossil clone
  2. You can use a Git client of your choice to download from the GitHub mirror: git clone


Because there are not enough static site generators yet.

No, seriously, why?

Current version

The latest released version is version 9.


Used libraries

blogcpp uses the following third-party libraries:

Some code was added from other people's suggestions:


How can I use blogcpp?

The easier way:

Set up your blog.cfg file first, follow the documentation in the blog.cfg-example file in this repository. Then type blogcpp --new-article to start a new article or blogcpp --new-page to start a new page. When you're done, run blogcpp and everything will be there soon.

The nerd way:

Set up your blog.cfg file first, follow the documentation in the blog.cfg-example file in this repository. Then start to add Markdown-formatted posts (in /posts) and/or pages (in /pages) formatted like this:

Author: Your name here.
Date: 2016-01-01 12:00:00
Title: This is the title.
Tags: tag 1;tag 2;tag 3
Categories: some;random;categories


(Everything that follows will be a part of the contents.)

When you're done, run blogcpp and everything will be there soon.

Which meta data types are allowed?

You mean, except the Title/Tags/Date part? Well:

OK, but how can I compile blogcpp first?

Starting from version 3, CMake files are provided, tested on GNU/Linux and FreeBSD systems. (On other systems you might have to adjust the paths.) You'll need a C++17 compiler, blogcpp makes heavy use of the <filesystem> header and other oddities. You will need Conan installed to fetch some dependencies.

% mkdir build
% cd build
% cmake .. ; cmake --build .

blogcpp has been proven to compile on:

Optional preprocessor definitions while linking:

Which directories need to be there?

Here's a site's minimal directory structure:


Of course, the capital letters mean that the values are indeed variables. By default, TPLNAME is default, INDIR is site and OUTDIR is outdir. Please use the configuration file when building your site in order to change these values.

Note that the binary blogcpp file needs to be in the root directory to work!

The name is stupid!

Well, I am a developer, not an economist. I do software, not shiny product names. However, blogcpp is path-agnostic (as long as it finds its usual path structure). You think blogcpp is a stupid name? mv blogcpp klaus and blog with klaus!

Also, please consider to ask a real question next time.

How does syntax highlighting work?

Four spaces at the beginning of a line mark the beginning of a code block. blogcpp tries to determine the language of the code automatically. If you want to set the language explicitly, you can use the Pelican syntax for code blocks; example:

print("This is Python code.")

Which parameters are supported?

You can call blogcpp with the following parameters:

If compiled with WITH_PLUGINS. three more parameters are supported:

Which emojis are supported?

Given that you have actually enabled Emoji support in your blog.cfg file and not disabled it for the page or article you want to process, the following smiley codes will automatically be replaced:

Code Emoji


;-) 😉

:-D 😀


:'( 😭

:-| 😐

>:) 😈

>:-) 😈

>:( 😠

>:-( 😠

:-* 😘

:-O 😮

:-o 😮

:-S 😕

:-s 😕

:-# 😶

0:-) 😇

:o) 🤡

<_< 😒

^^ 😊

^_^ 😊


m( 🤦

Which comment systems does blogcpp support?

While blogcpp does not have its own commenting system, you can easily integrate existing external commenting systems via your blog.cfg (please refer to the blog.cfg-example file in this repository). Currently supported are:

How can I write a blogcpp plug-in? Is it hard?

Good news: blogcpp plug-ins are actually JavaScript scripts, meaning that it is rather easy to write one. Everyone can write JavaScript today, right?

The plug-in mechanisms are still in an early phase, they will probably be more extended in later releases. As of now, blogcpp only supports three kinds of plug-ins:

The standard naming scheme is something.plugin.js, blogcpp will gladly ignore any files which do not have a name like this. You are also able to have a multi-part plug-in which affects multiple parts of the blog: Plug-ins with an identical file name are considered to belong together, blogcpp will handle them as one big plug-in which affects various parts of the software, e.g. <plugindir>/contents/moo.plugin.js for moo'ing in the contents part, <plugindir>/header/moo.plugin.js for moo'ing in the site header.

In order for this to work, you'll need to have blogcpp compiled with WITH_PLUGINS and the configuration variable plugins set to on. If you did so, blogcpp will read all files in the particular folder under your plug-in directory. If they are - more or less - valid JavaScript (ECMAScript 5.1 is mostly supported), blogcpp will try to find the process() method in them, fill it with the appropriate text and replace it by the results of the process() method before continuing as usual.

Plug-ins can also access certain parts of blogcpp itself from the BlogEngine object. By the time of writing, those are the following one:

Please refer to the hello-world.plugin.js example plug-in in this repository for more or less information.

Can I use raw HTML in my Markdown-enabled article or page?

Yes, you can! Everything between <rawhtml> and </rawhtml> will be ignored by blogcpp's Markdown parser.

Which files does a template need to work?

blogcpp needs index.txt, post.txt, page.txt and archives.txt in order to be able to process your site correctly. All other template files are optional. CSS and image files can be put into a subfolder named static, blogcpp will automatically copy this folder to your output directory then.

Starting with version 9, blogcpp's templates are mostly compatible with the Jinja2 syntax, so porting your existing Python themes should be rather easy.