Forem: Dalia

One Worker to Track Them All: Injecting Analytics Scripts into Multiple Websites with Cloudflare Workers

Dalia — Mon, 15 Jan 2024 01:00:00 +0000

For a while now, I've been creating mini web tools to test out ideas or as tiny helpers for myself. I usually publish them on individual subdomains, which might not be the best idea, but I like the concept of a short, easy-to-remember URL. Recently, I discovered that some of these tools actually have a few users, which made me consider adding analytics to them. After a bit of research, I settled on umami. It's a great little privacy-conscious tool with exactly what I need and nothing more.

The issue with having so many subdomains is that you'd have to add a different tracking script to each one of them, treating them as individual websites. Modifying each project to add the script sounds a bit tedious. If only there was a way to map each subdomain to its script.

The Solution

Except that there is. Cloudflare is pretty great for free SSL certificates and DNS management, but they also offer a free Workers plan. A Cloudflare worker is basically JavaScript code that runs on Cloudflare's edge network and handles HTTP traffic. You can do a lot with workers, including modifying/rewriting HTML responses. You can probably see where this is going: If a worker can modify HTML responses, then it can inject the umami script into every HTML response.

I modified one of the existing workers examples, and it worked on the first attempt. Initially, the first version of the worker had a dictionary mapping each hostname to the relevant Umami ID and injected that accordingly. I've changed that since to use environment variables. This way, adding a new subdomain is as simple as adding the hostname and the Umami ID to the worker's environment variables, which you can do from Cloudflare's dashboard.

The Execution

Getting started with Cloudflare workers is pretty simple. You can follow the get started guide to get a basic worker up and running. The worker I ended up with is pretty simple. When a request comes in, the worker checks if the response is HTML. If it is, it looks up the hostname in the environment variables and uses HTTPRewriter to rewrite the <head> tag and inject the umami script. If the response is not HTML or the hostname is not found in the environment variables, the worker just passes the response through.

export default {
  async fetch(request, env) {
    const BASE_UMAMI_URL = "https://eu.umami.is/script.js";
    const hostname = new URL(request.url).hostname;
    // get the umami id from the environment variables
    const umamiId = env[hostname];

    class ScriptInjector {
      element(element) {
        element.append(`<script async data-website-id="${umamiId}" src="${BASE_UMAMI_URL}"></script>`, {
          html: true, // html: true rewrites the string as HTML, otherwise it's escaped as text
        });
      }
    }

    const response = await fetch(request);

    try {
      const contentType = response.headers.get("content-type");
      const isHtml = contentType && contentType.includes("text/html");

      // if the response is html and we have an umami id for the hostname, transform the <head> tag
      if (umamiId && isHtml) {
        return new HTMLRewriter().on("head", new ScriptInjector()).transform(response);
      } else {
        return response;
      }
    } catch (e) {
      return response;
    }
  }
}

After creating the worker, the environment variables can be set from the dashboard or using Wrangler. Once the worker is deployed, it can be added to a route. I added it to the *.<domain>.com/* route, which means that it will run on all subdomains of <domain>.com. You don't have to stick to one domain only. You can add multiple domains to the same worker and have it inject the script into all of them.

Note: Instead of using environment variables, you should be able to use KV to store the hostname-Umami ID mapping. I haven't tried this yet, but I plan to do so soon.

A Word of Caution

This solution ended up working almost perfectly on projects that use plain HTML/JS. However, two projects had the script vanish mysteriously right after the page loads. These specific projects use VueJS and Svelte, so I'm guessing Vue and Svelte might be the reason behind this disappearing act. Investigating this is a task for future me, so I'll leave it at that for now.

CSS Trivia: Masonry Grid Layout

Dalia — Sun, 14 Jan 2024 06:00:00 +0000

Pinterest's layout has always been the defining feature of the site since its inception. It has been used by many others since then, and I've always been fascinated by it. Recently, I've come to learn that this type of layout is called a Masonry Layout, a name that comes from the craft of stonemasonry. Another thing I've learnt recently is that CSS has an experimental masonry grid layout, with very limited browser support. The specifications are outlined in CSS Grid Layout Module Level 3 Editor's Draft for those who are interested.

(DALL.E's interpretation of a masonry layout)

Creating a Masonry Layout

There are a few different ways to achieve this layout. Horizontal masonry layouts are simpler to create than vertical ones¹. You can simply use inline-block elements, or use a flex container with flex-wrap: wrap if you want more control over the layout.

For a vertical layout, flex doesn't do as well unless you have a fixed height container. An approach I like personally is to use columns². Column layouts are responsive and allow setting the maximum number of columns. The following CSS creates a column layout with a maximum of 4 columns, each column having the ideal width of 180px, and a gap of 10px between columns³.

#column-layout {
  columns: 4 180px;
  column-gap: 10px;
}

The main issue with this approach is that the order of the child elements in the layout is vertical, not horizontal. The example below shows the above CSS in action. Note the order of the elements.

Approaches for a CSS Masonry Layout is a great read on the different ways a masonry layout can be achieved. It covers the cases above and more.

Enter Masonry CSS Grids

So far, CSS grid layout hasn't been flexible enough to create a masonry layout, but this might be about to change. The Editor's Draft introduces a new masonry value to be used for grid-template-columns and grid-template-rows properties. The snippet below creates a responsive vertical masonry grid with columns having an ideal width of 180px, and a gap of 10px between the elements in the grid.

#masonry-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
  grid-template-rows: masonry;
  gap: 10px;
}

The result would look something like this:

(CSS Grid with grid-template-rows: masonry)

If your browser supports masonry grids, you can see it in action here:

Examining the result, you'll notice that the order of the elements is horizontal, but they're not exactly in order. The masonry layout algorithm places elements in the columns with the most remaining space to try to achieve an even look for all columns⁴. If order is important, using masonry-auto-flow: next will place the elements in order, but the final result won't be as even.

(Masonry Grid with masonry-auto-flow: next)

Browser Support and Fallbacks

As of writing this, the masonry value is only supported in Safari Technology Preview⁵ and in Firefox⁶ as an experimental feature. If any of the code samples above didn't look right, it might be because the browser you're using doesn't support it yet. If you really want to use it (I know I do), then make sure to provide a fallback for other browsers.

The default fallback when using masonry in an unsupported browser, is to ignore it and use auto instead. This example shows what the fallback would look like.

If that's not the look you're going for, you can detect support for the masonry value using @supports and provide alternative CSS for unsupported browsers. Here's how to fallback to the column layout we saw earlier.

#masonry-layout {
  columns: 4 180px;
  column-gap: 10px;
}

@supports (grid-template-rows: masonry) {
  #masonry-layout {
    columns: auto;
    column-gap: 0;
    grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
    grid-template-rows: masonry;
    gap: 10px;
  }
}

For a live example, my personal website falls back to a hacky flex layout if the browser doesn't support masonry grids.

(The masonry grid in action)

Google Images layout is an example of a horizontal masonry layout, while Pinterest is an example of a vertical one. ↩
A multi-column CSS layout, flows an element's content into columns. ↩
The column-gap property only applies to the space between columns, not between rows (as the name might suggest). The space between rows can be set using margin on the child elements. ↩
The algorithm is explained in more detail in the editor's draft ↩
Enabled since version 163. See the release notes ↩
Available since version 77 and enabled by default in Nightly. Can be enabled from about:config by setting layout.css.grid-template-masonry-value.enabled to true. See the release notes ↩

Adding "Created At" and "Last Updated" Dates to Jekyll

Dalia — Wed, 10 Jan 2024 00:36:44 +0000

In making the Jekyll theme I am using on my personal blog, I wanted each note to show a Created At and a Last Updated date. Jekyll by default supports dates for post types. The date would be specified in the title of the post, e.g. 2020-08-01-My-Post-Title.md. The date is then parsed by Jekyll and is available in post.date. Since I'm using collections instead of posts, and mainly using Obsidian to create and edit the files, the markdown files as they are being generated at the moment don't have a date in the title. I was already writing a set of plugins to add Obsidian support to Jekyll, so I thought I'd write a plugin that tells Jekyll to use the file's creation date as the post date unless it is specified in the frontmatter.

The First (Failed) Attempt

This was simple enough. All I had to do was to add a :documents :post_init hook¹ to set the created_at and last_updated_at variables to File.ctime(doc.path)² and File.mtime(doc.path)³ respectively if they are not already set in the frontmatter. The resulting code looks something like this:

Jekyll::Hooks.register :documents, :post_init do |doc|
  # set created at date to file creation date if not already set
  doc.data["created_at"] ||= File.ctime(doc.path)

  # set last updated date to file modification date if not already set
  doc.data["last_updated_at"] ||= File.mtime(doc.path)
end

This worked perfectly when I was testing it locally. But once pushed to GitHub, all the notes showed the same date, the date of when they were pushed to GitHub. What was going on?

(Image Source: SIMPLY THE TEST)

What was going on?

To understand the issue, it is important to understand the blog's deployment setup. When a new commit gets pushed to GitHub, a GitHub action is triggered which uses actions/checkout@v4 to checkout the repo, then uses a custom action that is not relevant to this post to build the site and deploy it to GitHub Pages. When actions/checkout@v4 checks out the repo, all the files are being created at the same time, which is the time of the checkout. This is why File.ctime and File.mtime are unsuitable for this case. What we need instead is a way to get the creation date of the file in the repo, not the creation date of the file in the local machine.

The Second (Working) Attempt

My next plan was to use git history to set created_at to the file's first commit date, and the last_updated_at to the file's last commit date. By default, actions/checkout@v4 checks out the repo with the fetch-depth option set to 1, so only the latest commit is fetched. Since I need the full git history to get the first commit date as well as the last, the GitHub actions workflow needed a small tweak:

 - name: Checkout
   uses: actions/checkout@v4
+  with:
+    fetch-depth: 0 # fetch all history for all tags and branches

Now that we have the full git history, we can use git log ⁴ to get the first and last commit dates. Using git log --follow --format=%ad --date=iso-strict -- "#{doc.path}" we get a list of all the commit dates for the file from latest to oldest. We parse the list and assign the first and last lines to last_updated_at and created_at. A rough idea of the final code is:

# WARNING
# The below snippet is just a rough idea of what could work.
# Don't use it as it is. The next section gives some pointers
# on how to improve it.
Jekyll::Hooks.register :documents, :post_init do |doc|
  git_dates_log_command = `git log --follow --format=%ad --date=iso-strict -- "#{doc.path}"`
  git_dates = git_dates_log_command.split("\n")
  doc.data["created_at"] ||= git_dates.first
  doc.data["last_updated_at"] ||= git_dates.last
end

Things to Keep in Mind

1. Check that the dates are valid

The first and last lines of the git log output might not be valid dates. For example, git might output a warning or an error message instead of a date. Blindly assigning the first and last lines to created_at and last_updated_at might result in breaking the build. So it is important to check that the dates are valid and that they are actually on the first and last lines.

2. Allow for overriding the dates in the frontmatter

While this is a neat trick, the priority should always be given to the dates specified in the frontmatter.

3. To --follow or not to --follow

The --follow ⁵ option in git log is used to follow the history of a file across renames. Is a renamed post a new post or an update to an existing post? That's your decision.

4. Avoid using `timeago` for post dates

After hours of trying to figure out why Jekyll was still showing "Today" for a post I modified last week, I remembered that I am using the timeago filter from jekyll-timeago plugin. I was rendering the dates using {{ doc.last_modified_at | timeago }}. As you know, Jekyll is a static site generator, and it renders this as HTML at the time of build, and only then. This means any date rendered with timeago is hardcoded as is in the HTML and won't change until the next build. I switched all the dates to the "%-d %b %y" format for now. Might use moment.js in the future to get the timeago dates back.

Jekyll Hooks are a way to run code at specific points in the Jekyll build process. The :documents :post_init hook runs after the documents have been read and parsed, but before it is rendered. ↩
File.ctime returns the creation time of the file. ↩
File.mtime returns the last modification time of the file. ↩
git log shows the commit logs. ↩
git log --follow follows the history of a file across renames. ↩