Website Overhaul: Moving to dllup

After years of sporadic hand wringing, and messing around with various web stacks, I have finally settled on a platform for my website. Since this is mostly a blog and I don’t need any dynamic content, I settled on building with a modified version of dllup, a lightweight markup language developed by one of my friends. The dllup environment is similar to markdown but pages are built with python instead of perl. It also implements svgtex to compile latex formulas to svg images, which is great, because it means desired content display is not relient on users having, for example, MathJax supported/enabled. Once generated, websites are very light and have minimal overhead. Though my implementation differs from the source (in that I modified some of the generating scripts and overall site filesystem), it is essentially to spec. Dllup is discussed in more detail below.

1 Previous Efforts

Originally, back when I was a lowly first year, I started working on this site. Like a newborn playing with letter blocks, I thought I would get somewhere by coding 100% of the HTML by hand, and doing other intelligent things, like storing everything in the same root directory. This grew… unmanageable and, eventually, I got bored of it and quit.

My next attempt at having a working website was slightly more intelligent, though perhaps too ambitious. After reading about things like PHP and Django, I got the idea to create a python backend for generating page content based on user inputs and form/content fields passed to it via PHP. This involved minimal php code, basically just an accounting of all arguments in-play, and then a system call to the python script on applicable user-induced events.

Data flow in the 2nd iteration of this site
FIGURE 1 User input was parsed by the background php script and sent to a python script running on the server backend if any modifications to the webpage layout or content was required. The webpage was refreshed if the python script was called.

Unfortunately, the execution speed of python scripts on my hosting provider’s shared servers is unbearably slow. It often took several seconds just to load the homepage. Another attempt at a website: crash and burn. I actually regret having to abandon this approach, I think it could have been a lot of fun if the server just had enough resources. There is almost no limit to what kind of functions I could have had on my website due to the massive amount of python libraries available. Additionally, all scripting is hidden from the end-user by default. So, unlike JavaScript, which requires complicated schemes to hide script content from source viewers, the only thing visible from the front end is the PHP script which calls the python script. The python script can be placed outside of the /public_html directory (as long as your server can see and execute it) and your proprietary methods of compressing and decompressing cat pictures are hidden from public view.

I briefly tried WordPress. It has some decent features and you can, with some effort, set up a synchronization routine with the Google Drive API. I shortly grew bored of WordPress, mostly due to it’s overwhelming bloat, and restrictive content management.

2 dllup

Shortly before I graduated, I learned that one of my friends had created a lightweight markup language and I started thinking about this website again. The idea of using a parser to generate pages is appealing because I can focus on writing content rather than the layout. I went this route before, with the python backend, but this is slightly different. Rather than relying on python to dynamically generate content, the scripts are only ran once, at deployment time, to generate the HTML files and file structure. I can use his already developed content structures (he has two, one for static blog pages, seen here, and one for gallery-esque content display, which I do not use), and add my own layouts later.

With my friend’s permission, I pulled his site with all of the build scripts from his public bitbucket repo and went to town on it, removing unncessary configuration files and creating new build and deployment scripts to suit my needs. I left the dllup.py parser mostly intact, with some changes made to solve implementation-specific bugs. I also, with his permission, hijacked his footers/headers and scss files, though I intend to modify these later (or write new ones). I wanted to get some content up before I drowned in back-end development boredom again. It’s likely that future iterations of this site will be similar, but with different style themes and slightly different page layouts (I intend to leave the body layout to dllup).

I had to think a bit about how I wanted to do deployment. Obviously I created a git repo for the top level development files, but I was unsure how I wanted to move the resulting site content around. I modified the build scripts to dump only necessary website content into a deployment directory which contained its own git repo. Becuase this is just generated content, I don’t care about being too strict about standard commit and repository mantras. When I dump content into this directory I simply run

git add --all *
git commit -m "whatever"
git push website master

The first line is important as it both adds any new files and runs git rm -rf on any files which have disappeared (if I deleted a picture, or something, etc). This saves me unncessary hassle when deploying content to the hosting server.

The documentation and installation instructions for the dllup environment can be found here. In order to build properly, it uses several (reasonable) third-party dependencies, including PhantomJS, svgtex and the Pygments module for parsing/formatting code snippets. Note that the installation instructions for PhantomJS on their website do not mention that you can simply install from canonical repos:

sudo apt-get install phantomjs

I originally compiled PhantomJS from source and set up the library links only to find out that I couldn’t call it from shell because it conflicts with the package in the repo (they have the same name, I’m sure there’s a way around this but I’d rather just use the repo version). Additionally, if you have both python2.7 and python3.X on your system, make sure to call the build script with python3.X only ($ python3 build.py), or change the first line of all python scripts from #!/usr/bin/python to #!/usr/bin/python3 (the latter is cleaner).

To promote my friend’s efforts, I’ve left the links to the dllup source in all of the footers.

3 Closing Thoughts

Python is very malleable and once you have a working piece of software it’s easy to wrap a GUI around it, or implement it as a submodule in another piece of software. The dllup parser is pretty self-contained (once you set up phantomjs/svgtex) and can be added to any desired scripts. However, something that is lacking is support for initial deployment.

This website required some changes to the build scripts to generate a different directory structure as well as different types of pages. Some of my pages have embedded content, like my CAPTCHA-enabled contact form, which was created by a third party. It would be interesting to create initialization software so that, on install, a user could specify the directory structure and the styles, navigation, and layout of each subpage. This would then generate a new build script that iterates through the user-specified directory structure and generates all of the pages. I leave this to my future self, or to another interested party.