Local file links

So, as I mentioned previously, right now a lot of my work on Publ is with the purpose of updating the website of the research lab I currently work at. There’s a lot of content on the site and most of it isn’t particularly well-structured. Much of the site involves collecting publications that lab members have been involved in, and also providing the supplemental materials thereof or even the full papers in some cases.

This means there’s a lot of assets to manage, and they aren’t all systematically-named. Or tracked. Or easy to track down.

One of the things I’ve wanted to do for a while is to support posting images which aren’t necessarily images that PIL can handle (such as SVGs or the like), and with a lot of the refactoring I’d done over link handling I realized that there isn’t really anything fundamentally different about SVGs than, say, all sorts of file types – PDFs, Javascript, source code, and so on. So, I extended the model’s Image type a bit to allow for “images” that aren’t actually images. (Really I should rename the class to Asset, which maybe I’ll do later on.)

So, after a bunch more refactoring of how links and images are handled, link resolution is much simpler and also supports any file that’s not covered by the index. But it does it in a safe way! Rather than index every possible file, it only indexes files which are pointed to by an entry, and if that file isn’t an image, it gets assigned a fictional filename which is (essentially) unguessable but humane, and then there’s an asset-retrieval endpoint which retrieves the file.

The end result of this is that only links to files which have been linked to on the site are available via the _file endpoint – it shouldn’t be possible for people to guess at file paths and get at internal data!

Anyway, now static assets which belong to an entry can just live along with that entry!

(Assets which belong to a template should still live in the static/ directory, though. That’s what it’s for, after all.)

entry.date_year et al

This is also a thing I added for the lab’s site; I needed a convenient way to group publications by year, and realized that there are other use cases which call for this as well, such as structured archive pages on a blog or the like. I wasn’t terribly happy with adding purpose-specific properties for this but I couldn’t find a way to make Jinja group by the result of a callable, so this was a convenient compromise.

view.pages

This was an artifact of the first way I tried implementing year grouping – I thought, hey, maybe I’ll just paginate by year and then iterate over the pages. This turned out to be very slow, however.

It might be a useful thing for someone, though, so I left it in. I don’t recommend using it.

Future priorities!

A thing which keeps on coming up is the ability to add tags to entries, and specifically a way of filtering by tag. I put in what I hope is a short-term hack on the applicable templates on the lab site which looks something like:

{% for entry in view.entries %}
{% if my_tag in(entry.get_all('Tag')) %}
{{entry.body}}
{% endif %}
{% endfor %}

but I’d really like to be able to do something like:

{% for entry in view(tag=my_tag).entries %}
{{entry.body}}
{% endfor %}

i.e. make the database do the work. This also enables a bunch of other useful stuff like being able to finally implement tag navigation for blogs and feeds and whatever.

I don’t think it would be that hard to implement, but I just haven’t gotten around to it, despite having a bunch of tags on my own blog entries already. It’s not, like, urgently needed, but now I have an impetus to actually do it.