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

Weblog
1

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
2

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
3

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?)

4

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

5

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

6

Can you share the file entry metadata?

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

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
9

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.

10

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