Text files for inclusion in <head> (.css, .js, et cetera)

Per an IRC convo the other day about CSS, the idea was raised of just having a way to write a separate CSS file (or other potential files you need to include in your weblog <head>) rather than having to edit the CSS separately in every template you have.

1 Like

Just got this working, far better than my half-hearted late-night attempt the other day.

First up, you’ll see a new section in the weblog UI for Files. To create a file, just make a new entry with (at minimum) these two bits of metadata/frontmatter:

Type: file
Content-Type: text/css

As usual, all of this is case-insensitive. The key components here are:

  1. Type: file tells the weblog engine that this is a file, and will prevent it from appearing in all of the places where you don’t want to see it (posts, search results, etc.).
  2. Content-type is the MIME type of the file. Asking you to indicate this is a little nerdy, but it makes things a lot more open and useful vs. offering a limited array of types of content. You can find pretty much any MIME type by searching the internet for “[thing] mime type”, e.g. “css mime type” will quickly tell you that the MIME type is text/css.

You’ll probably also want to include a Title and Location (the first giving the file a nice label in the file list, and the second making it easy to know where it is so that you can link to it).

So, a complete example for a stylesheet might look like this:

Type: file
Content-Type: text/css
Title: Stylesheet
Location: /style.css

* {
  color: #000;

I also had to add some new logic to handle file entries that don’t have locations — there’s a new Files path configuration item with a default that looks like this: Files path: /files/. This means that if you don’t specify a location to override it, the file will be accessible at a location that consists of files path + the entry’s slug (which will be fashioned from the title, if one is specified; otherwise it’ll be made from the content itself following the usual entry/slug logic). Hopefully that makes sense.

Let me know how it works for you and if you have any questions!

1 Like

I’ve successfully created a CSS file in the web UI but it’s location just gives me a 404. (I am trying to remember if we did something else once that initially failed for custom domains and/or canonical URLs?)

(Also, weirdly, although it didn’t publish as a post to my weblog it did show up in my RSS feed.)

Oops, forgot about feeds. Should be filtered out of those now!

Can you share the file entry metadata?

Title: CSS
Type: file
Content-Type: text/css
Location: /styles.css

Thanks! Turns out that I forgot to check for the presence of a Location metadata item and to not default to the files-path if one is present. Just fixed that, and your CSS now loads as intended!

1 Like

OOC, you files you don’t specify a location on, is the slug a combo of title and content-type? Was wondering how the extension gets figured on those.

It doesn’t factor in the content-type, as it doesn’t even really need to be concerned with file extensions in general. The content-type header (that sends the MIME type) tells the browser what kind of data it’s receiving, so you don’t even need to specify a file extension in your own Location at all if you’d rather not. You could literally do Location: css and bix.blog/css would output your CSS file, which every browser would correctly interpret as a CSS file by virtue of the text/css content-type.

Incidentally this is the same thing that I’m doing for omg.lol profile pics. https://profiles.cache.lol/adam/picture has no extension but the browser receives a content-type of image/png, so it knows that it’s dealing with a PNG.

1 Like