Directory contents:

Dergen Fire

The "Dragon Fire" project is the codename for this very website you are watching right now (that, hopefully, being https://lucidragons.de). Chosen along how dragons usually roar with a powerful flame to communicate and, perhaps, to show off.

It's main purpose, thusly, is documentation of our work and communication about it, to let us better share what we create and work on with others.

You will find its general style to be reminiscent of that of a code editor's file tab, and most of the writing ordered as a directory. This is intentional for two reasons - firstly, to give the reader a comfortable feeling for the slightly longer-form text. The site is written by nerds, for nerds, and many of us know the environments of the likes of VSCode well. Secondly, to give a structure to the content. Unlike a social media site, our website does not have one central, linear feed - instead it has folders and projects and blog collections and galleries, all their own avenues of exploration and writing. You can follow each one at your own pace.

In fact, the entire contents of this website consist of Markdown files in a git repository, which you may download from ... We need to set the link up here, remind us later :P

This website is a casual side-project along the other items being worked on, and will receive a more gradual and gentle level of affection because of this.

Changelog

• 2024/10/07: Initial writing

Technical specifications

Client side tech

Unlike most other websites, this one ... Is very boring on the client side. No React, no Vue... In fact, it will work entirely without JS at all! Most importantly, no client side tracking. That should never, and probably never will be, a technology we need nor desire.

There are a few client-side tech tricks, though. Firstly, the Banner at the top of this webpage is gently animated with a small, custom JS script - not even JQuery, just a few vanilla setTimeout()s to move the banner and occasionally trigger a CSS animation to swap out the image.

Secondly, HTMX is the big one. It is a very small (~40kB zipped) JS file, not even installed via NPM, it's just dropped in, and thusly creates little overhead. Its main purpose is to smooth out website transitions thanks to the wonderful HTMX Boost. Boosting here refers to HTMX grabbing any normal <a href="..."> click, requesting the page in the background and then smoothly replacing the website content in-place, rather than refreshing the whole site. This allows e.g. the Banner at the top of the site to remain in place, and makes everything feel smoother. As a sane fallback, if JS is disabled, all links simply act like normal links and the Website can be used like normal! Just a bit less smoothly.

HTMX also sprinkles in a few other modern touches to the site. Look at the top navigation bar (hidden behind the burger menu button), and things such as the folder navigation are loaded behind the scenes using HTMX on:reveal triggers. It's all very neat and clean~

And ... That is all for the client side. No behind-the-scenes live zipped optimized on-deman document-reflow-reducing reduxing reactor vueframe. Just HTML - mostly.

Server-Side tech

The server side code is a little more interesting, at least.

The current rough structure is that of a fairly average PHP setup - nginx pretending to be Apache2 running PHP, with a MySQL database to serve some rough info.

What might be a little surprising to hear, though, is that this whole site does not use a specific framework. No WordPress or Laravel or such. The biggest component in use is probably Twig, thanks to its amazing template engine - it probably is one of the best we know, really. This is closely followed by some libraries for RSS/Atom Feed generation, YAML and Frontmatter parsing, and Markdown rendering. But no framework.

All CSS and HTML was essentially custom-written for this site, and I think if you were to inspect it, you would see as much - it's quite a lean DOM!

For most cases of viewing a website, the data-flow is as follows:

• The Webserver filters out image/file requests (these are served directly, without interaction of PHP).

• The root PHP is called by the server.

• It looks at the address in question. Most of the time, this will be a regular page to load, but this might also be a call to /api/ or such - we'll ignore that for now.

• It then looks up the post in question in the Database, and grabs its details.

  • Posts are essentially just neatly indexed Markdown/Frontmatter files. Frontmatter here refers to a small section of YAML at the start of the Markdown page, which is used to add extra information such as metadata (page title, banner images), brief description, etc.

• The given post is then chewed through a Markdown renderer with a few small, custom additions - these additions let us insert fancy snippets into the middle of the page, such as inline searches/feeds/carousels etc.

  • Some inserts can, themselves, call up other posts to generate previews.

• The rendererd HTML is then inserted into a small Twig Template set, mostly to add some flair and the rest of the page.

• Finally, a few small metrics are tracked, such as how long the PHP rendering took, how many page views a page got, etc. - nothing traceable, no IPs, specifics, even the view count timestamp is bucketed into five minute segments.

• And then, you get it!