The new Obsigna BLog authored with ContentTools and backed by ContentCGI
In December 2012 I set up my BLog with WordPress, and while it is really true, that you can get your WP system up and running without major headaches, it comes also with a lot of things that most people did not ask for and usually do not need. In addition, several WordPress themes load web-fonts and the jQuery library from Google's CDN services. I don't want to be tracked, and I don't want my visitors to be tracked either. This attitude alone let me maintain a customized CDN-free albeit up to date WordPress for 6 years by the way of the SVN vendor branches method. Finally - the GDPR was lurking already - WordPress 4.9 introduced visual emoticons from yet another CDN. That was the straw to break the camel's back. So, I looked out for another system.
Back to the roots
BLog is the truncation of weBLog, which means it is a kind of a diary published on the web. For publishing a text with some pictures on the web, we don't need WordPress. We would need some writing tools which store our content into the directory where the web server can find it on visitor's requests. Ideally these writing tools would let us author our diary in WYSIWYG style, and it would be really nice if we could edit our text online. Do we need PHP? No. Do we need MySQL? No. Do we need WordPress for this? No, not either.
Visitors of our BLog see static web pages only. The editing facility shall be accessed by a special URI which is access protected by HTTP Digest Authentication.
LoadModule auth_digest_module libexec/apache24/mod_auth_digest.so LoadModule deflate_module libexec/apache24/mod_deflate.so LoadModule ssl_module libexec/apache24/mod_ssl.so LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so LoadModule proxy_module libexec/apache24/mod_proxy.so LoadModule proxy_fcgi_module libexec/apache24/mod_proxy_fcgi.so SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png)$" no-gzip Listen 443 SSLProtocol All -SSLv2 -SSLv3 SSLCipherSuite HIGH:!aNULL:!AES128:!SSLv2:!SSLv3 SSLHonorCipherOrder on SSLPassPhraseDialog builtin SSLSessionCache "shmcb:/var/run/ssl_scache(512000)" SSLSessionCacheTimeout 300 <VirtualHost *:80> ServerName content.example.com:80 RedirectPermanent / https://content.example.com/ </VirtualHost> <VirtualHost *:443> SetEnv CONTENT_TITLE "CONTENT EXAMPLE" ServerName content.example.com:443 ServerAdmin email@example.com DocumentRoot "/usr/local/www/ContentCGI/webdocs" <Directory "/usr/local/www/ContentCGI/webdocs"> Require all granted </Directory> <LocationMatch "^(/_|/.*/_).*$"> ProxyPass "unix:/tmp/ContentCGI.sock|fcgi://content.example.com" SSLOptions +StdEnvVars </LocationMatch> <Location "/edit/"> AuthType Digest AuthDigestProvider file AuthUserFile "etc/apache24/ContentEditors.passwd" AuthName ContentEditors AuthDigestDomain / Require valid-user ProxyPass "unix:/tmp/ContentCGI.sock|fcgi://content.example.com/edit/" SSLOptions +StdEnvVars </Location> SSLEngine on SSLCertificateFile "etc/letsencrypt/live/example.com/fullchain.pem" SSLCertificateKeyFile "etc/letsencrypt/live/example.com/privkey.pem" </VirtualHost>
ContentCGI is a FastCGI daemon which is to be invoked by the Apache web server in case of requests of said special URI's. It responds to edit, save, create, delete, revive and search requests. The search facility is backed by the Zettair search engine.
The ContentTools and ContentCGI are both available on GitHub. ContentCGI runs out of the box on FreeBSD and macOS. It is extensible by the way of plugins. The ContentCGI package comes with the Hello Responder Delegate plugin, named
Those, who need a full featured CMS, would want to stay with WordPress, or Drupal etc. Currently, even a commentary facility is not implemented by ContentCGI (which is problematic anyway with the advent of the GDPR). Who needs a web diary only, may want to explore the new system (s. below).
In order not to disturb users with links to my management utilities, I placed respective menu items into the favorites bar of my web browser.
Let’s say, the base (static) URL of the respective site is https://example.com/, then the URL’s for the editing mode would be:
Enter Editing Mode -
In general, the local links are composed in a way that the editing mode is kept when editors navigate within the site. This means we could enter the editing mode and navigate to the articles which we are going to edit. Saving is done by clicking the check mark in the opaque green circle. Editing can be canceled by clicking the cross in the opaque red circle.
Create a new Article -
The default language is English = ‘en’. Other languages for the article to be created may be defined by the way of the lang query option with said URL. For example German = ‘de’ would be adjusted by
The language option is added to the lang attribute of the page’s HTML tag. This let’s modern browsers do a perfect language based automatic hyphenation and spell checking of the text.
The file names of the articles are composed of the UNIX time stamp of creation and the extension
Delete an Article -
Here the article file having the name
Revival of the the Index and TOC -
Usually auto-indexing would be initiated in the course of one of the above commands. Auto-indexing involves as well removal of stale images. Sometimes we want to manipulate the webdocs directory directly by bypassing ContentCGI. Once the changes are done, the revive action would update the Index and the TOC to reflect the actual state.
Searching is actually a non-editing command, since this can be called by occasional visitors. How this technically works is described my BLog article Using the Zettair Search Engine locally on a Site. Here comes a brief summary:
Searching and refreshing the search index
In case the installation instructions below are followed, everything should be in place for providing the search facility on the site. ContentCGI does not directly update Zettair’s search index. Instead it would place a token into the Zettair’s index directory once something on the site has been changed. The spider script which comes with ContentCGI would be called by a cron job (I do it every minute) and start reindexing only in case it finds the token, otherwise it quits immediately.
While ContentCGI itself works with UTF-8 throughout, Zettair is quite an old system. The main work was done before UTF-8 became popular. So Zettair works well for languages whose characters may be encoded by one of the ISO-8859-x character sets. I write in English, German and Portuguese, so I use the Western European encoding ISO-8859-1 in the spider script, and in the search-delegate plugin of ContentCGI see:
Adaption to another ISO-encoding should be straightforward. In the whole source base of ContentCGI/Zettair search for ISO-8859-1 and replace by one of the other ISO-8859 encodings. Then re-compile everything. I fear, Asian languages do not work well with Zettair.
This tutorial assumes, that you got a clean FreeBSD server connected to the internet up and running, and that it got domain names, let's say
When following the instructions below, you need to replace
Copyright © Dr. Rolf Jansen - 2018-06-20 20:59:36
Discussion on Twitter: 1082820500718583808