How This Site Works | Back ⬏

Bear with me, this is a lot of text, not a lot of images and it's pretty long.

Today, I'll be talking about how my personal site works. As I mentioned in the project page for it, everything on this site is custom made with no frameworks or libraries*, and I wanted to detail what's going on behind the scenes for those interested.

* Well, almost no libraries...

I'll structure this post the following way, first we'll talk about the why, after we'll detail the what and finally I'll show you the how. Let's see if I can stick with it.

Why?

I believe there are two "why"s to answer here. Why make a personal website, especially in this day and age, would be the first one. The second one is, why make everything from scratch and not use what people before you have made? You know, "rise on the shoulders of giants" and such.

For the first question, I don't like having "profiles" where I'm not in control of anything. Sure, if you take a look at my about page, I list three profiles right there, but I feel like those are the "essentials" so to speak.

Maybe it's nostalgia for the (in my eyes) golden age of the Internet, maybe it's because I want to be able to customize what my "profile" looks like, maybe it's because I don't want my entire life recorded in some data center somewhere, I don't know. Whatever it is, it makes it worth it in my eyes to go through the hassle of setting up a personal website.

Besides, it's more compact. I can share my work, my art, my thoughts, random things I made, all on the same website. I don't need an ArtStation profile to share art and Tumblr to write a blog, it's all under my name right here.

For the second question, to put it simply, I like the challenge. Sure, I could use one of the millions of frameworks, libraries, static site builders or backends for my site. Sure, that would make it infinitely easier for me, especially considering I'm not a "great" programmer by any means. But where's the fun in that?

Besides, I want to improve and understand how things work on a lower level. And I feel like getting your hands dirty is the way to do that. Re-inventing the wheel, if done not in an environment where efficiency is a top level concern, is not only fun but very teaching. At least that's my belief. I would like to write more about my thoughts on this matter but let's not get ahead of ourselves.

Back to the website.

What?

Now that we know why this website exists, and why is it the way it is, let's talk about exactly what is this website and what is it made out of.

To sum it up, this is a static website built using HTML, CSS, JS, Python. To go more into detail, "the website" is made up of three components:

  • The Content Management System.
  • The Static Site Generator.
  • The content.

These all work in tandem to create this beautiful website you're viewing right now. Short section, but not much else to say here really. Let's move on to the most interesting part, the how.

How?

How, as in how does this all work?

Now we'll tackle the how component by component. I'll order them by their use, as in, we'll talk about them one by one in the order of their appearance during the process of creating a new post for this website. We'll start off with the content management system.

The Content Management System

When you log in to the CMS this is what you see.

As you can probably tell by this image, or by just looking at the site itself, the entire website works on a "directory-post" system. In the image above you can see some directories (or categories in the context of the website) and some posts already showing. This page allows you to create new categories or posts, or edit the existing ones.

The accented directory (root, in the image) is where the new category/post will be created. Once you create a new post or start editing an existing one, you'll be met with this screen:

Now, there are some strange things happening in that image, I know. Let's go over them

First of all, you see the path to the top left. That's where this post will reside in the directory structure. It's filled automatically but exposed to the editor just in case you want to move or copy this post.

Then there's the resource browser, this is to upload a file of any kind to the server. They're then put in a temporary directory.

Then there's the title of the post, which is self explanatory.

Under the "body" field you see this exact post being written, here is what the strange stuff begin. You see a header being declared in markdown, and paragraphs written just like in markdown, but then an HTML tag is closed with md, what the hell is that tag anyway?

And then, an image is declared again with HTML instead of markdown. But then in the preview, there's just a dot where the image would be. After the image there's more text inside one of those md tags.

As you might have guessed I use a combination of HTML and Markdown form creating posts. This allows me to do several things:

  • Use custom classes when I need to.
  • Add a script or style tag if I want to, which would only exist within that post without affecting the global style or script.
  • Avoid declaring special markdown blocks for every edge case there is.
  • Add header information such as the post date (which is so far unused on the site but it's there for every post before the site generator kicks in) or icon to use for the directory listings (for example the about page has a special post icon, that's also declared in the head).

To achieve this, I just made a custom HTML tag, which is md. This tells my parser to parse everything inside as Markdown and convert it to HTML. After this, the post is saved as a HTML file. This file has no styling, it isn't structed as the rest of the site or anything, we'll get to that.

Creating the list of categories and posts, creating or editing new posts or previewing the post currently being edited are all handled through requests (XMLHttpRequest from JS or form submissions directly from HTML) on the front-end and python scripts on the back-end. Previewing uses the python markdown library, which's the only external library I have installed for this site (that's why it's almost no libraries).

The CMS is completely separate from the main website, so it saves the generated HTML to the raw content directory. Let's talk about that.

The Content

This section is pretty short.

Now we have an HTML file inside some directories with no styling, no other components (like the post container or the header information etc.) and some loose resources in a temporary directory.

This makes up the "raw content" part of the site. This is stored on a completely separate part of the server than the main website that's being served.

This part also includes templates on how certain types of pages are structured (directory listing pages, posts, 404 pages etc.), the global style and the global script. Whenever there's a change in this directory, the generator runs automatically.

Let's move on to that

The Static Site Generator

This is a custom Python script that does the following:

  • It creates the directory listing pages on the main site.
  • It creates the posts by taking the HTML pages generated using the CMS, extracting the content from it, placing the content inside the appropriate tags on the HTML post template.
  • It determines which of the uploaded resources are used, moves them out of the temporary directory, and creates the appropriate links inside the posts which use them.
  • Places all generated pages in the appropriate directories to create readable and static URLs.
  • Takes this generated project and places it on the appropriate directory on the server in order to start serving the site to the Internet.

As you can see, the script really isn't complicated. Python is good enough for the job because performance isn't really that important in this case. The script only runs once when the directory is updated.

My plan for it is to allow it to generate only the parts that need updating, as currently it generates the entire website from scratch whenever a post is created/edited.

I will also allow it to sort posts in multiple ways in the future, as right now it only sorts them alphabetically.

With all that being said, I'm happy with how everything turned out. The structure is really easy to work with, it isn't complicated but it's very flexible. With the variety of content I'm planning to upload on this site, this kind of flexibility is very important for me.

It also taught me a lot of things, since I had to make everything myself including the server set-up.

It isn't perfect, it isn't very fancy but this is exactly what I wanted it to be and that's what matters.

Ahmet Fırat Usta