CozyNet Blog

How I like to make my websites

I know that a lot of people like using static site generators which can make things a whole lot simpler than having to keep up with individual web documents, but I never got onboard with this method of making and maintaining websites, finding it either too restrictive or locking you into a specific application or scripting syntax and template system. Instead, I went with what appeared to me at the time as a logical progression of web technology that grew from out of the days of CGI (Common Gateway Interface) applications and SSI’s (Server Side Includes) known today as server-side dynamic page generation, which is basically the opposite of a static site generator.

The OG, now replaced by PHP.

I’ve never been fond of client-side based presentations either, especially for simple web pages, since this method historically relied on plugins and browser-based features like Macromedia Flash, Shockwave, AJAX, Silverlite, Java, or JavaScript because of licensing, technical complexity, browser lock-in, or proprietary nature. Today’s frameworks, albeit mostly all JavaScript, have been the bread and butter of modern web development and much like those old clunky plugins, they too will go the way of the dodo. I value stability and “evergreen knowledge.” I could go on and on about why I dislike them, but I’ll spare you the rant and just move on.

For server-side dynamic page generation, there’s no concept of a build or compilation of the site in the SSG sense. It is possible to make PHP into an SSG with WGET or cURL, which I’m actually interested in building out for a future project, but conventionally all site content and any changes made to it are live. You could shoehorn in git for publishing similar to how some of you pair it with an SSG, but it would offer no advantage and would only get in the way. Rsync is your friend. ;-) Ideally you’d probably be looking for a Content Management System (CMS) like WordPress for something like that with some sort of git integration for collaborative projects.

I find all this too complicated for maintaining a simple Personal Home Page (i.e. PHP) or blog and have opted to go my own route here. I’d reconsider my choices if I were building a complex web service, but for smaller easy going sites, it’s too overkill.

Making a simple dynamic web page doesn’t have to be difficult, which I find a whole lot more maintainable than dealing with SSG’s. “How so?” you may be asking. Well let me show you how!

HTML templating paired with a server side scripting interpreter

There are many different scripting languages and interpreters that you can use, but I’ve found PHP to be the best fit for this.

There are a few ways to approach it, but I’ve always liked the SSI-like method of includes within my HTML documents for loading in external PHP scripts that exist outside the webroot of the site. Instead of every web document ending in “.php,” it’s just “.html” and the dynamic content on that page such as navigation buttons and input forms are all loaded in upon request by the server interpreting the PHP include statements before presenting the finished document to the client. This isn’t too dissimilar to what client-side frameworks are doing, but it’s far more cleaner and doesn’t rely on specific client device browser capabilities, CDNs, keeps QA testing very minimal and the site browser agnostic.

Because of this method in loading dynamic content by external scripts, if or when I need to make site-wide changes, I can go directly to the source PHP script file to apply my changes there. The changes are applied immediately with no need to rebuild the site.

The template is the HTML document which has everything pre-arranged. The only static content that I keep within the document would be, in the case of CozyNet, the written blog itself. The sky’s the limit as to how far you want to take it from here, but generally I keep actual blog content on the HTML document itself rather than loading it in from a database. So content-wise, my sites are quite static in this regard while my attention is toward replicable things that I do know will have a more dynamic nature such as pagination buttons, menus, nav bars, and just about any intractable element of a web page.

An advantage to keeping the content of my posts within the HTML document itself rather than loading it in from a database is that I can use a site indexer such as Xapian Omega to index my site to create a user search form. Site indexing systems that trawl a database are not easy to setup, hard to even find, and poorly documented. It’s also a lot easier and straightforward to make corrections with a text editor should need be, otherwise if everything is stored on database tables then you’ll need to look into either some sort of CMS (Content Management System) or building your own in order to manage it, which is too complicated!

My workflow

I should give a run-down of my workflow to hopefully better explain how things work.

Let’s say that I want to make a new blog post. Well, all of my work is done directly on the server rather than offline or in a git repository. I copy a blog template document into the blog directory to begin working with and open it with VIM. I could do this offline on my laptop to upload later with rsync, and have in the past, but it’s quicker to just do it live.

I have VIM setup with a plugin called Marvim, which extends the macro system into a storable / re-callable keybindable system which is perfect for making VIM into a speedy HTML editor. I used to use an editor called Composer which was part of the Mozilla Application Suite long after it was discontinued and picked up by the SeaMonkey project, but after learning how to use VIM and pairing that with the Marvim plugin, I found that it was much quicker to just make web pages this way. Sometimes people resort to some markdown language that gets converted to HTML on build since HTML has a tendency to become unwieldy and cumbersome to type, but because my documents are quite minimal from the get-go thanks to the “PHP includes” and the fact that I can call up and bind macro functions to keys, I can quickly insert a video element, a code box, or image div containers without typing them out and making potential mistakes.

And that’s basically it.

There is a service script that I’ll run shortly after which updates the search index database, the pagination database, and creates the comment section database table for that particular post so people can comment. In all, this takes 5 seconds.

I still haven’t yet automated the RSS feed, which I have to manually remove any divs, style ID’s and other elements not fit for feed readers as I copy it over from the source document. Ideally this would be automatic, but I haven’t had the time to flesh something out.

Here's the blog template I use. The orange highlighted text are the things I change in it while the rest is left alone.

<?php session_start(); ?>
<!DOCTYPE html>
<html lang="en">
<?php include("/var/www/php/head_new.php");?>
<body class="body">
  <center>
  <br>
  <div id="top" class="content_adapt" style="height: 100%;" border="0" cellspacing="0" align="left">
    <div class="content_adapt main">
      <article style="padding: 10px;">
        <center class="no-print">
          <?php include("/var/www/php/navbar_init_new.html");?>
        </center>
        <div class="blog_box">
          <h2 class="blog_title">Title</h2>
          <br>
          <center>
            <a href="/blogs/images/insert_image_here"><img class="center img_style" src="/blogs/images/insert_image_here" align="center" width="60%" height="60%"/></a>
          </center>
          begin blog here
          <p>Thanks for reading my blog!</p>
          <br>
          <div class="pagination">
            <center>
              <?php
                $src_name=basename(__FILE__);
                include("/var/www/php/navblog_init_new.html");
              ?>
            </center>
          </div>
          <br>
        </div>
        <input class="no-print" id="comment_toggle" type="checkbox"/>
        <label class="comment_toggle" for="comment_toggle">[Toggle comments]</label>
        <div class="comment_state">
          <h2 class="no-print">Comments:</h2>
          <div id="comments" class="forum no-print">
            <?php
              $src_name=basename(__FILE__, '.php');
              include("/var/www/tinybbs2/comment_init.php");
            ?>
          </div>
          <script type="text/javascript" src="/scripts/comments.js"></script>
        </div>
        <br>
        <a class="no-print" href="#top">[Back to top]</a>
      </article>
    </div>
  </div>
  <br>
  </center>
</body>
</html>

Pros and Cons

I think I’ve pretty much already covered the pros of this method which boils down to dynamic web pages made easy, but I should cover the downsides of it too.

Due to the nature of running scripts on the backend to present a complete document to the requesting client, you have to be careful in how you write out your scripts or else you could cause a lot of wasted processing on your server which can quickly lead to a denial of service if one too many people hit refresh with cache bypassing in their browser. There are backend caching mechanisms for PHP such as opcache (default) and memecached, which can help if your site is particularly heavy and the Apache web server does have timeout options to slow people down from doing that to some extent. Caching and load balancing is a whole other level that’s not very applicable to small scale sites and blogs though, so you can skirt by without it.

Client-side focused sites meanwhile couldn’t care less how much battery life and memory they waste since it’s not their device.

Another downside to this method I suppose is the learning curve. This is all backend web development work with an emphasis on operations. You’re dealing with servers, networking, firewalls, certificates, permissions, backups, upgrades, etc. If you don’t know what any of this is and are only familiar with content management front-end systems like WordPress and web hosting providers that do much of the work for you, then this is going to be a very steep learning curve.

One last downside here is the upfront amount of time it might take to setup your site. It took me quite a while to make CozyNet because I was learning new things as I went and wanted to build out my own tooling. It takes hindsight and some experience to plan out and organize every component of the server. Once it’s established, you don’t have to mess with it again nor worry about some unwanted change to your tooling, removed features, paywalls, or UI overhauls if you make it yourself. I’ve seen the world of CMS platforms and web hosting providers and it’s just a racket.

Wrap up

I can understand some people wanting a GUI editor that just seamlessly translates to HTML without having to think about it, or going so far as to writing everything in markdown, but a keyboard and console based approach isn’t just absolutely possible, it’s faster! If you’re already familiar with VIM, then it wouldn’t be too difficult to learn this method paired with the Marvim plugin. Keep in mind that HTML was supposed to be a rather easily readable language, so keep it simple.

I should comment on the fact that my old blog posts aren’t consistent with the site theme, which there’s a reason for. I like seeing what the site use to look like, so I purposefully left them alone. I could easily change them to look consistent with the rest of the blog, so don’t think it’s outside my ability or that I’m being lazy!

Anyhow that about wraps it up. Let me know what you think or what method you prefer for making web sites, there are a lot out there!

Thanks for reading my blog!