title: How to sneak in a static CMS
---
pub_date: 2019-09-24
---
author: Nico Schottelius
---
twitter_handle: NicoSchottelius
---
abstract:
Let's see how easy it is [to sneak in a static
CMS](https://ungleich.ch/en-us/cms/blog/2019/09/24/sneaking-in-a-static-cms/)
into an existing
dynamic CMS.
---
body:

## Introduction

To put you in the right mood for reading this article, I ask you
take some assumptions for reading this article:

Assume you are the CEO of a small IPv6, Linux and FOSS company. Assume
that some years ago you made the decision to use
[Django CMS Blog](https://github.com/nephila/djangocms-blog) for the
blog to support non-technical staff to post blog articles.

Also, for the sake of completeness, assume that you are still running
your own [private blog](https://www.nico.schottelius.org) with
[ikiwiki](http://ikiwiki.info).

## Motivation

I believe that before changing anything
([especially in IT](https://en.wikipedia.org/wiki/Not_invented_here)),
you should have a good reason for changing. So what could be
the reason for sneaking in a static CMS? The answer is relatively
easy:

* Reducing latency
* Reducing latency
* Reducing the inhibition threshold for writing blog articles

Let's have a look at each of the points in detail,
[before letting us convince
ourselves...](https://en.wikipedia.org/wiki/Not_invented_here).

### Reducing latency

One of the biggest problems for me is to wait for an web application
to *save* something. With Django CMS Blog, you have the standard
**write - save - publish flow**. So when I want to see the result, I
have to wait seconds. Depending on my distance to our blog this might
take 1 second (Europe) or about 5 seconds (South Korea). While this
does not sound like much, it **feels** very long.

While google apps (which we don't use for our blog)
like google drive (which has other issues as well)
take a different approach in *autosaving*, this also blocks if you
have a weak network link.

While it is just a few seconds, it is a huge difference between just
being able to write in [emacs](https://www.gnu.org/software/emacs/)
(yes I was converted from vim) versus writing in a browser, waiting
for the website to return.

### Reducing latency

While editing with "high" latency is a problem of the writer, latency
while loading the result is a metric that directly affects the readers
*feeling* about a website. If it takes too long to a website, you,
dear reader, are about to leave this website very fast. Even if I
write the greatest and best content, you won't like it.

So by switching to a static CMS, the dynamic processing time is
removed and pages can load as fast as the round trip time (RTT)
between the web server and you.


### Reducing the inhibition threshold for writing blog articles

Let's come to the third and maybe most important point: reducing the
inhibition threshold for writing blog articles. Let's put some
background into this: we are a small, Swiss based hosting company
loving open source. However, the emphasises is on **small**.

So we cannot (nor do we want to ) afford huge marketing / adwork / paid
advertisements. But our strategy is to **do good and talk about it**.

However if the barrier for writing and publishing is high, we won't
write much about the things we do. And I think with a static CMS,
geeks (like me) are having a much easier time to actually write a blog
entry.

## How to do it

Now let's have a look on how to sneak in a static CMS into an existing
company website. [ungleich.ch](https://ungleich.ch) is powered
by our [Django CMS](https://www.django-cms.org)
based CMS (full [source code is
online](https://code.ungleich.ch/ungleich-public/dynamicweb/)).

The Django instance is running behind nginx, which allows us to proxy
different parts of the website to different backends and to serve
static assets directly from the filesystem.

On the other hand we have a static web server named
*staticweb.ungleich.ch* that hosts various static pages.

The existing URLs of ungleich.ch should all stay as they are without
any conflict. For this reason the new static cms is placed at
**/u/**. The static pages are generated on a client machine and are
uploaded using the following Makefile snippet:

```
BUILDDIR=../ungleich-staticcms-build
DESTINATION=ungleichstatic@staticweb.ungleich.ch:/home/services/www/ungleichstatic/staticcms.ungleich.ch/www/

all: publish

publish: build permissions
	rsync -av $(BUILDDIR)/ $(DESTINATION)

permissions: build
	find $(BUILDDIR) -type f -exec chmod 0644 {} \;
	find $(BUILDDIR) -type d -exec chmod 0755 {} \;

build:
	lektor build -O $(BUILDDIR)
```

The last step to sneak in the CMS was to modify the nginx
configuration of ungleich.ch with the following snippet:

```
    location /u/ {
        proxy_pass https://staticcms.ungleich.ch;
    }
```

## What's next?

As you can see in this post, the design does not fully (*cough*) fit
the regular design of ungleich.ch. However Lektor uses jinja2, which
is very similar to what we already use in the
[existing dynamicweb
project](https://code.ungleich.ch/ungleich-public/dynamicweb/).

If you want to join the discussion about this, I invite you to our
open chat on [chat.ungleich.ch](https://chat.ungleich.ch).

And next in this blog: how to use it ;-)