This website has been unavailable for the last few months. Prior to that it was also pretty quiet.
The reasons for this are a little convoluted, but in essence COVID meant I had less time for personal projects, and the https certificate for the site ran out. Moreover the machine the site was hosted on was in a state where it couldn't be upgraded. In the background I was getting frustrated with the way the site worked technically - it was wordpress running on apache, using mariadb database (a fork from mysql). This was/is all very conventional for a blog. But
In the meantime I've seen the rise of static sites and static site generators, often for programming based sites. Whilst looking into this I ran across Caddy, in a discussion on static site generators. In that context it seemed like it might make for a good server for static pages. I wanted to write the content in markdown. Doing so would mean I could just use a simple text editor. Having the content in text format also means I can store everything easily in a version control system.
It turned out though that caddy had a variety of extra nice features
I was thinking I would have to develop a template & markdown systems and then just use a static web page server. With caddy I wouldn't need to do this - as long as I was happy with it's support of the features.
The site you are reading now is a recreation of the original
toy theory website running on caddy. The features lost
Some might improve as I get more used to the new system. As part of my initial plan I did not make it a requirement to be able to comment, and so that may never happen.
The first step in making this transformation was to export my wordpress site as XML. I then used a tool that would extract the contents as markdown. This did a pretty good job - but I still had to go through most pages fixing small issues. I then took the markdown based caddy documentation site as a starting point, and then tried to build out something that looked close to the original. This was actually fairly time consuming as I was really rusty CSS.
For a first post on the new system, I thought I'd give initial thoughts on caddy server, when redeveloping the site.
format single_field common_logwhich gets what I want but that option is 'depreciated'.
It was more effort than I originally thought. There are lots of time consuming details in putting together a website.
On the 'templating' side I guess I would have preferred if a standard scripting language was used as it's basis - such as LUA. That has it's own issues - perhaps the idea was to have something purposefully limited.
Overall I'm pleased with the outcome and the experience. By using Caddy I had most of what I needed out of the box.
It's not entirely clear how I can make a single
Caddyfile work for both production and testing. I like that I can run the server on windows, but that only works if I run as localhost. I don't want to have to edit the Caddyfile, or have a production/test files as they can get out of sync.
For now I'm using the
--config option, and using a testing
Caddyfile. To start the test server I can then use
caddy run --config Caddyfile.test
By making the name start with
Caddyfile, means I don't need to specify the 'adapter'.
I'm not entirely satisfied with this result, so I will have to look into a little more in the future.
A more irritating problem is how to trigger an update. I have my website stored in a subversion repository. When I push changes to the repository I want an easy way to make the server do a 'svn update'. If I had used
git then there is actually an example that makes this all work as Caddy has built in git support.
I could use a cron job, that would automatically update on a regular basis. One thing I don't like about this, is that I would also need a mechanism to disable updates - because I might be doing fixes and changes on the web server, I don't want updates to happen whilst I'm doing this. I could perhaps have a file that would enable/disable the script execution. This remains a viable option.
On a webserver like apache I could just use CGI. I could then just hit a 'special' webpage, doing so would run a script that would do
svn update and perhaps other 'build' operations. Caddy doesn't support CGI by default - which I think is an odd choice. It does support fast-cgi, but that's way more complex than needed for this simple use case. So I tried to get CGI to work with the CGI plugin.
At first it was confusing because on the Caddy website there is no documentation for this module. On the download page it has a link to the github repository for that module. This does have documentation, and some examples. It looked like a straightforward answer.
So I downloaded a binary with the CGI module, and tested first on Windows. I couldn't get the script to trigger - it would always just end up with 404 'file not found'.
I wondered if this was due to Windows not being so well supported, so I tried again on Linux, but had the same behaviour - I couldn't get the script to trigger. I didn't see any errors in the log.
I might try this again in the future, as this mechanism still seems preferable. In the end I just settled on a shell script that was easy to trigger manually.