About

Table of Contents

About WiWoMu

I wanted to make a website focused on the multimedia aspect of projects I work on.

(Wi)ng (Wo)ng (Mu)ltimedia!

The "WiWoMu" term comes from the first two letters of my first and last name and for "multimedia"!

Welcome to a site dedicated to various multimedia concepts, write ups, tutorials, source code, and some works in progress!

About Platform & Content Management

I'm really enjoy programming in Python. I had been publishing on the Wordpress, which is super user friendly, but also fairly "heavy" when it comes to publishing something simple.

I also wanted to improve the page load times. Wordpress and PHP are not known for the speed of their execution. Many forms of caching are employed to make a Wordpress site "fast": php op caches, pre-rendered content caches, S3 media CDN(s), etc.

While I can certainly manage the whole LAMP stack that powers Wordpress, I really don't enjoy having to.

Basically, I wanted peace of mind, so I went looking at SSG(s), or Static Site Generators. And since I enjoy programming with Python, I opted to go with Pelican.

Why Pelican? Why not one of the many many many other SSG(s)?

I actually did try out other SSG stacks:

Hugo (GO)

I have to say, Hugo is pretty awesome. Written in the GO programming language gives it the performance of writing the code in C/C++ but with a language that is more geared towards creating async servers. This language is great, but the complexity and overhead, for me, would make maintenance of the codebase a bit of a pain.

I ran through a few different configurations, and each time required some finagling of the dev environment. When plugins/extensions were installed, there were compatibility issues that cropped up. Due to my own lack of familiarity with GO, this just made the platform very frustrating to setup and use. Hugo is just shy of a full CMS in and of itself, with some modules available to make it a front end to a headless Wordpress CMS.

The good news is, since all/most of the content is written in one form of markdown or another... migrating to Hugo later won't be a chore.

Gatsby (Javascript/Node)

Gatsby, like Hugo, is very featureful. Based on Javascript/Node, it is likewise performant, though Hugo/GO has it beat. The Node/Javascript ecosystem is very server-side friendly and is well suited to handling live traffic on its own. Like GO, however, it represented additional complexity and a departure from most of my main projects. Similar to Hugo, I just did not need nor want that much power. If I wanted a powerful platform with added complexity, I would just stick with Wordpress.

Jekyll (Ruby)

Not as featureful as Hugo or Gatsby, but considered to be fairly easy to get going. The fact that it is built on Ruby helps in that regard. I liked that it had a simpler setup, but I did not care to maintain any Ruby code-base. And since it's featureset was similar to Pelican and Hyde, which are written in Python... it was a pass.

Hyde (Python)

This was a good project that was the Python version of Jekyll. However, checking their main site, github repo, etc... the project hasn't been updated since 2015. So in my mind, it's an abandoned project. :(

Pelican (Python)

This is the SSG I ultimately chose. In the grand scheme of things, going through the process of choosing which platform to use... came down to the question of whether I had enough confidence in my mastery of the underlying coding language to properly make use of it. This aspect is especially important when you consider that unlike Wordpress, there is NO GUI. Changes are made by hand editing files... or generating them, if one setup some kind of template system.

Pelican is well supported. Has a good library of features. And is written in a language I'm comfortable hacking and maintaining long term. The only real gotcha with Pelican was that there are very very few pre-made themes that are designed to work out of the box with Pelican. Even less if you consider use cases involving photo or product galleries.

However, I'm confident that I can convert a different theme for use on the site... or just customize an existing one.

Hosting? How are you hosting this site?

I'm currently hosting this site on CloudFlare. The code and content is stored in a private Github repository. I basically do a pull, edit, and push back to the system. Github let's Cloudflare know there is new stuff and Cloudflare pulls from the repo, does what it does, and pushes out to their CDN hosting.

Cloudflare Pages

This is essentially Cloudflare's version of Github Pages. It combines a few services of Cloudflare at a very reasonable price while allowing me to keep the underlying content in a private repository..

Cloudflare Workers

Cloudflare has a github hook that allows them to pull whenever a commit/push is completed or when a merge happens. Cloudflare spins up the instances to execute the code to generate the static content. Once generated, the content is pushed out to the Cloudflare CDN.

Cloudflare CDN

All of the static content is hosted on Cloudflare's network of CDN(s). This is normally hosted on a Cloudflare specific sub-domain. However, there is the option to have a custom domain essentially serve as the customer facing CDN and treat the Cloudflare private network CDN as an Origin Server.

Cloudflare Custom Domains

If you have Cloudflare managing your DNS, you can use them to serve your domain content through them and through one of their internal systems.

Deployment

  1. Git pull or clone the repo.
  2. Make local changes and test with make devserver
  3. Once the content is validated locally, it can be validated remotely by committing the changes and pushing them to github.
  4. Github will notify Cloudflare and Cloudflare will checkout the code, generate the content, and push the content out to their CDN.
  5. The live-in-a-minute content will be visible via Cloudflare's dev URL.
  6. To make the site go live, one would just need to perform a pull request and marge the changes into main. Just make sure to update the environment being generated.

Note: Cloudflare, as of 10/2022, only supports Python up to 3.7.8

This means folks on 3.9 or higher may encounter problems with packages being unavailable or dependency conflicts being unresolvable.

This actually happened to me and I had to build a local 3.7.8 environment to proof any changes to ensure they would run on CloudFlare's workers.

The alternative, especially on M1/M2 Apple Silicon macs is to just generate the static content locally and upload that content to github and have Cloudflare push that content. Depending on the size of the produced content and the amount of static content, this option is only feasible for relatively small sites.