Managing This Blog — 2
Part 1: Managing This Blog — 1
For many months I used wordpress.com to host this blog. I never liked wordpress.com. I can use but am not fond of WordPress either. For a long time I struggled to find an appropriate solution.
I have some HTML experience and can create basic web pages and CSS. Conversely, I do not overestimate those nominal skills.
A challenge is providing myself some automation and convenience. Likely a basic CSS and template could suffice. Some shell scripting and cron jobs could sync a local copy online. To support scheduled posts likely some meta data would be passable along with a cron job. Tagging support is not a requirement but would be nice. Likewise with some kind of built-in search engine. An RSS feed subscription service would be nice.
I do not know how to support comments without a database or control spam. I have no interest in battling spam.
Mostly I want a simple static web site.
That means forget the big names: WordPress, Drupal, Joomla, etc.
A low-end content management system (CMS) would resolve some automation and convenience desires. A challenge with a CMS is most run on PHP. While PHP has a built-in mini server, using PHP implies using a local web server for testing and validating. Another challenge is a requirement by many CMSs to use JavaScript, cookies, and Google APIs. While some low-end CMSs support flat files, most require a database backend.
A static web site usually means a static site generator. A challenge with static site generators is most do not come in convenient distro packages. Most require manual installations. Another challenge is the esoteric support only for various markdown languages. All of the static site generators I researched have a high geek factor.
While I run a basic web server on my LAN server, static pages should need nothing more than a web browser for local viewing and testing.
I prefer the following features:
- Static site.
- Not dealing with a manual installation.
- Designed to be used by anybody and not just geeks.
- Flat files with no database backend.
- No dependencies on third parties, such as Disqus.
- No Google dependencies (fonts, icons, JavaScript APIs, etc.).
- Not dealing with Markdown, reStructuredText, AsciiDoc or other markup fad languages.
- No JavaScript.
- After almost 200 posts I notice I use only a href, code, pre, ul, ol, strong, em tags.
- I prefer using a text editor until ready to post.
- An ability to schedule posts.
- Maintained locally and ssh/rsync to a hosting site.
- Dynamic page creation or linking not needed.
- Use cron and a script to update the blog only when there are local changes or a scheduled post is due.
- Email contact with no spam headaches.
- Do not need “real-time” stats such as trending articles, most read, etc.
Nice but not critical:
- Tagging.
- Site search (requires dynamic scripting).
- Code syntax highlighting.
- RSS feed.
- Visitor comments but not third-party and no spam.
I want to store blog entries files in date-structured directories:
- 2015/09
- 2015/10
- 2015/11
- 2015/12
- 2016/01
- 2016/02
- 2016/03
- 2016/04
- 2016/05
- 2016/06
- 2016/07
- 2016/08
All files use a four digit sequential number prefix: 0001, 0002, 0003, etc. This is an easy visual way to know the number of articles written and to cross-check that I did not miss a post.
A visual text editor is not needed or wanted. I prefer to create the files in a stand alone text editor such as geany or bluefish and add basic HTML tags. I am not fond of web based visual editors because they require the bane of the web, JavaScript. Many visual editors are dependent upon Google services, a deceptive way of tracking people.
While many flat file site generators exist, I always got disappointed every time I ran across the words “markdown” or “bbcode.” A preference for these features meant a system designed by geeks for geeks. To be charitable, these tools seem to be written by developers, targeting other developers, of whom many happen to also write blogs.
While I have been around computers for a few decades, I just want to write.
Some wiki software are adaptable to blogging — to a degree, and wikis come with their own oddball markup language. Wikis are high maintenance.
Just old fashioned simple HTML, thank you.
I read many reviews and was discouraged. Many of the reviews are nothing more than copy-and-paste efforts from parent web sites. Most reviewers never perform any meaningful testing or asked questions. Just the usual click-bait information. The only way I would learn anything is consuming gobs of my time installing and testing.
I looked at many blog related apps.
- getsimple
- flatpress
- pivotx
- pelican
- nikola
- jekyll
- grav
- blogofile
- cmsimple
- htmly
- pyblosxom
- nibbleblog
- pluck
- phile
- pico
- dokuwiki with blog plugin
- typesetter
Some nominal testing further discouraged me. For example, the following require JavaScript, cookies, Google or other quirky dependencies:
- nibbleblog
- getsimple
- flatpress
- pivotx
- nikola
CMSimple uses a single HTML page, which my mind does not wrap around. I have posted almost 200 articles and expect to continue writing. A single page?
I tried to browse the grav web site. That was a challenge without enabling JavaScript. Even the forum required JavaScript. I then concluded that if the developers create a JavaScript excrement site then the software probably is much the same. Too high of a geek factor. Anything that depends heavily on JavaScript likely is dependent on Google APIs.
Then there is something like Dokuwiki. While flat file by design, wikis are just plain weird and generally, user-hostile.
More to follow.
Posted: Category: Usability Tagged: General, Migrate
Next: Managing This Blog — 3
Previous: Managing This Blog — 1