Publ changes since 0.7.31:

• Fix some error handling issues causing an ISE
• Add support for HTTP Accept:, properly allowing multiple templates with the same name and providing reasonable fallback behavior
• Improve the Content-Type handling in general
• Fix some markup-safe handling bugs

Note that in order to upgrade to 0.7.35 you’ll also need to restrict your Python environment to use a Python version < 3.13; more on that in a bit.

Pushl changes since v0.3.5:

• Tidy up some code rot
• Actually send an Accept: header
• Removed lxml + Pingback support, which has never actually been useful

So, let’s talk about these projects and some other related stuff.

Tech debt

Publ has quite a lot of tech debt.

Most of the testing is done in an ad-hoc smoke-testing manner, and this has sometimes made it difficult for me to work on new features. (Of course I also am the only person working on these features, so I only prioritize things that I personally need.)

Pony

One particular issue is that it relies heavily on Pony. Pony is a great ORM for doing quick application prototyping stuff, but unfortunately it’s been a problem for quite some time:

• It makes proper unit testing significantly more difficult (it’s actually the main reason the testing is in such a sorry state right now)
• New Python versions usually end up breaking its clever code generator (which is why Publ 0.7.35 requires you to restrict your Python version)
• It never gained support for schema migrations (which, thankfully, Publ was designed to not need to begin with, but this hampers some of my other plans)
• General community support just never really materialized

To address many of these problems, I’ve been wanting to move to another database abstraction; I will most likely use SQLAlchemy. Whether I use its ORM or not is something I’m still trying to decide.

Whoosh

Similarly, full-text search uses whoosh, which has been more or less abandoned. I have updated to use whoosh-reloaded, a community fork that has fixed most of the more egregious issues, but there are still a lot of issues with it:

• Its locking behavior is difficult to work with (and can cause a lot of operational difficulty)
• Its ingest is slow and not easily threadable
• Updating the index can be difficult and fragile
• It stores the index on the local filesystem which can be a problem for many deployment scenarios
• It puts way too much structured into its structured queries, and is overkill for the kinds of query representation Publ needs

Unfortunately there aren’t as many existing full-text search implementations for Python. My expectation for now is that I’ll roll my own using the algorithms described in Bart de Goede’s article, although this doesn’t feel like a great way to do things either.

Misaka

Finally, the Markdown engine currently used by Publ has been abandoned and is unlikely to continue to working in the long term. It’s always been a bit of an operational problem, as well, because it relies on Hoedown (which has been abandoned for ages and never even got updated with HTML 5 support) and requires being able to either retrieve architecture-specific binaries or being able to build them yourself. The build process has been mostly easy for most users, but it’s still not ideal.

Fortunately, I’ve been playing with other Markdown implementations on other projects, and I’m fairly certain that I’ll be happy with Mistune instead. Switching to that will require reimplementing a bunch of stuff in Publ, but it’s all stuff I’d been wanting to fix anyway.

In particular, I’ve been wanting to figure out a way to templatize footnotes (for example, letting people make use of Tufte sidenotes or putting a <details> reveal inline or after the current paragraph or the like), and there’s a lot that could be better about how image sets are currently handled, and ideally I’d be able to templatize those as well.

Comments

The main ways that I’ve handled comments on Publ-based sites is either:

• webmention.io + webmention.js
• isso

Both of these are Fine™ for simple usage but they run into a bunch of issues on larger sites, and also the UX just isn’t really where I’d like it to be.

I wrote a much more detailed blog post on my main site, but the short version is that I’d like to make a comment system that works more closely with Publ (or any other publishing framework) that stores things locally and supports both local posts and webmention (both sending and receiving), and which would also accept user data from the publishing stack.

I’m thinking it would take the form of a Python library that you can embed into an app (with easy hooks for Flask), but would also offer its own Flask frontend for hosting it as an embeddable app instance that can be used from non-Python things.

ActivityPub

Native ActivityPub support has been at the back of my mind for a while. Having its own built-in webmention endpoint would also make for a nice spot to start adding in ActivityPub, since ActivityPub verbs aren’t fundamentally different from Webmention verbs.

The main thing this would bring to the table is being able to set up various outboxes for different views (for example, @blog@example.com for just blog posts or @all@example.com for everything), and then also being able to make use of the user permissions to send private entries as DMs to the authorized subscribers, reducing the need for private entry stubs (which are bad UX all around and which I only adopted as a compromise because magic links have problems and feed readers still don’t support bearer tokens or Ticket Auth).

Documentation

Also, having had to actually consult the docs while building a new Publ-based website, I’ve come to realize just how bad a disaster the manual currently is. It could really do with some reorganization at the very least.

In conclusion

I have a lot of stuff I want to work on and hopefully I get somewhere with some of these things this year. If you’d like to help out, you can make code contributions, or you can make financial contributions via Ko-Fi, Patreon, or GitHub Sponsors. But no pressure.

• Major documentation improvements
• Bug fixes with Fediverse instance caching
• All providers now normalize to the same profile format
• Some basic spam prevention for the email provider
• 100% unit test coverage on the Fediverse provider (which is now using mastodon.py instead of a hand-rolled OAuth client)

And in Publ:

• Fenced code now uses <figure> and <figcaption> instead of ad-hoc <div>s for its layout, and the overall HTML semantic has been greatly improved
• Individual code blocks are now configurable with respect to highlighting and line numbering
• The user object now provides a user profile and separates the identity URL from the familiar name

Currently I am getting quite frustrated with the state of this documentation site. I am working towards making Publ itself more amenable to documentation via pydoc/readthedocs, and transitioning this site only to be for demos and usage examples. I’m not sure how to make the templating guide and markdown extensions fit in with RTD, though.

I’ve long wanted to do some sort of automated documentation generation, though, and as the various mechanisms in Publ get more complicated this starts to feel way more important. This is definitely something I could use some help on, for anyone who’s interested.

It’s also becoming more and more apparent that there needs to be some sort of online post editor, and I really ought to get around to building the simple one I’ve had in mind for a while. This is long-overdue.

Anyway. This update is a lot of fun. See some of the stuff you can do with it!

Publ v0.6.6 changes:

• Fixed a regression that made it impossible to log out
• Fixed a problem where WWW-Authenticate headers weren’t being cached properly
• Improve the changed-file cache-busting methodology
• Add object pooling to Entry, Category, and View (for a potentially big memory and performance improvement)

Authl v0.4.0 changes:

• Finally started to add unit tests
• Removed some legacy WebFinger code that was no longer relevant or ever touched
• Added a mechanism to allow providers to go directly to login, as appropriate
• Added friendly visual icons for providers which support them (a so-called “NASCAR interface”)

Publ 0.6.6

The main reason for this update is just that the embarrassing logout bug was rearing its head and I wanted to fix it on my site without monkeypatching it or temporarily moving to git head or whatever. The WWW-Authenticate fix is nice, though, as it’s related to some work I’m doing on Pushl (namely adding the ability to retrieve bearer tokens from an external helper program).

It’s difficult to estimate what a performance change will be like based on testing on a developer desktop vs. a production VPS. In particular, the various I/O performance characteristics can vary a lot, and Publ is primarily I/O bound. In my desktop-side testing I found that the object pooling increased performance by 15%, which is already pretty great, but that’s also on a machine with a lot of memory, a huge file cache, and no disk virtualization. I’ve only deployed Publ 0.6.6 on my personal website around half an hour ago, but already my site monitoring is showing a rather impressive performance improvement. For example, the Atom feed used to take around 30 seconds to render on a cache miss. Right now it seems to take 2.5 seconds.

So, yeah, it takes only 10% of the time to run now – that’s around a 900% performance improvement in a typical deployment scenario. So, that’s pretty great.

Right now the largest remaining performance bottleneck seems to be in PonyORM, which is unfortunate. I haven’t yet figured out if it’s with PonyORM itself, or with its interface to sqlite. From what I can tell, the way that trace profiling works in Python means that things with a lot of function calls become quite a lot slower than long-running things within a single function, so things that do a lot of abstraction and dependency injection (like, say, PonyORM) get unfairly impacted in trace profiling. A sample-based profiling approach would be much more fair and realistic, but I haven’t found any sample-based Python profilers (and I don’t know enough about Python’s internals to know if that’s even a possibility).

My short-term goals for Publ are otherwise unchanged since the last release announcement.

Authl 0.4.0

I hadn’t worked on Authl in quite some time, but I felt like it needed some attention.

These Authl changes are basically for some UX improvements that had been bugging me for a while; there was an awful lot of text to read and that was possibly scary to newcomers. Now there’s still just as much text to read but there’s friendly icons for a bunch of the supported services, and silo services such as Twitter can now go straight to the login flow without implying that the username is necessary.

Here’s a before and after on the default Flask template:

The next thing I want to work on for Authl is finally adding actual support for user profiles. This would also probably go along with things like adding more providers, particularly Facebook, Tumblr, and maybe even OpenID 1.x (i.e. Dreamwidth). Better profile support means having a friendlier greeting than just the canonical identity URL, among other things that people might want in their own federated login use cases.

Some other thoughts of things that would be neat

Now that Publ supports entry attachments, it might be reasonable to add native server-side webmentions; rather than fetching the mentions from webmention.io on every page view, have a webhook on update that triggers a script that fetches and formats the mentions as an attachment that can then be rendered and cached, as well as getting all of the benefits of SEO that it would bring. For some sites, having the comments be indexed by the search engines makes a huge difference to page ranking, since the conversation about an article can add in some useful keywords that weren’t in the actual article. (Not to mention it improves the page’s “freshness” as far as the search engine is concerned.)

Another thought I’ve had about attachments is they could be used to implement a server-side comment system, although that would require a lot more work than webmention rendering (UI, moderation/spam-filtering, migrating stuff again) and after all the work I put into my Isso setup I’m not quite ready to think about how to actually do that. I’d probably want to do it in the form of having a mechanism to pre-render the Isso comment thread and form into an HTML attachment rather than having every part of it handled via Publ entry attachments.

• Upgrading Publ will now invalidate the cache
• Fixes the missing database session around the authentication log viewer
• Fixes the way that the indexer works when an entry changes ID
• Fixes a bug where draft entries' temporary IDs were overriding the permanent/assigned IDs of visible entries
• Added some useful commandline tools

The next things I want to work on:

• Micropub endpoint (done as a separate component that you can optionally add)
• Adding more unit tests
• Maybe an actual (very basic) CMS UI? I dunno

Main things with Publ since the last release:

• Internal cleanups to how caching happens
• Stop spuriously-caching a bunch of stuff; in particular login/logout endpoint URLs no longer get cached
• Various cleanups
• Improve the way that built-in templates are managed
• Initial cruddy implementation of an admin authentication dashboard (although this isn’t quite ready for prime time)

The only Authl change is that email identities are now given as a full mailto: URL; going forward all identity strings will be full URLs. This simplifies the UX for admin dashboards, in particular, and removes some ambiguity.

This initial release of the admin dashboard is incredibly slow, both because there’s a bunch of stuff that isn’t being cached that could be, and because it just shows the entire log. Which turns out to be massive in a lot of cases. Or at least it is on my site.

To that end, since releasing this (and discovering how horribly it runs on my own site), I’ve made the queries a lot faster, enabled pagination on the auth log, and also changed the auth log to not record actions on non-logged-in users, because that turns out to not actually be useful. The point of the auth log is really to see which known users are actively trying to access entries and whether they were successful or not – meaning, do permissions need to be adjusted. The only time it’s useful to know about anonymous logins is on entries whose auth header is set to !* and that seems of limited use.

In the future I may go even further and limit it to only tracking the most recent access for a given user on an entry. The purpose of this is for verifying access control, not for performing analytics or being creepy/narcissistic.

Anyway! Milestone v0.5.0 is almost met! I just have a few tasks remaining, after which I can start on the next milestone which is mostly about testing and quality; Publ is very much lacking in the automation department, particularly for testing and for building the documentation.

I’d also like to finally make this site into a useful demo of Publ’s capabilities. Demonstrating its image handling, template flexibility, and authentication support is really important to me, since those are the reasons I decided to build Publ, after all.

Changes since 0.3.23:

• Fixed a bug with absolute paths in asset links
• Added a default error handler if there’s no global error template configured
• Finally added the ability to configure the Markdown processor, both at the global and per-template level

So that closes out the last three issues before I was ready to consider this usable by a wider audience. Neat.

There’s a lot of stuff I want to do for 1.0 of course, but also more importantly I need to vastly improve the documentation on this site, as well as collect things to make it easier for people to get started with Publ. I would absolutely invite people to make suggestions; have you looked into Publ, and been confused about what exactly to do? Please let me know!

The best ways to do so are to either hop onto my Discord channel or to open issues against the documentation site.

Also, Publ itself is built to be a tool, and not a complete standalone thing. I will absolutely talk your ear off about how I think a more user-friendly publishing frontend could be built, as well as easier ways of actually installing/deploying this places.

One of the things I am considering doing is running some minimal Publ-oriented hosting for folks, where I’d set up a private git repository and a minimal site and make it hopefully easier for people to actually do their thing, and maybe charge a marginal amount for it (say, $X/month for X GB of storage, and include SSL and basic site assistance and whatever). If you’d be interested in that sort of thing, again, please let me know!

Here’s a list of what’s been added or changed since 0.3.18:

• The test site is now part of the Publ repository itself (as mentioned previously)
• Added crop and fullsize_crop to image renditions (although I’ve already decided the format should be different after using this for a day)
• Made Path-Alias less annoying
• Fixed an issue with unpaged archive links getting filtered
• Prune missing files from the index

Credits

I want to thank Karina Antonio for implementing image cropping.

On image cropping

Originally I would have implemented cropping the way Karina did, but I got it stuck in my head that it would be much more efficient to compute the source rectangle and only do a single crop operation when it came to building the rendition. My four reasons for this were:

• Performance (only crop once if possible)
• Something to do with better image quality (i.e. an intuitive thing that was stuck in my brain but had nothing to do with reality)
• Wanting to match the cropping rectangle’s aspect to the output aspect
• Wanting the rendition filename to only reflect the input box

Performance is a non-issue; even if it did make a measurable difference, renditions are cached as long as they’re being used, and thus don’t actually need to be recomputed every time.

Image quality was just something stuck in my head from when I was working on the Amazon image rendering service, because of some less-than-optimal things it did internally. It’s not an issue for how Pillow works though.

Aspect matching is still a thing I kind of wanted to do, but then that leads to a few things like, what gravity should be used when “uncropping” the rectangle, and what about honoring the intent of the crop for excluding stuff outside of the box, and so on? Anyway those are a lot of questions that had fiddly answers and the reality is that it’s easier to just leave it up to the user to match the aspect as appropriate, and use resize="fill" vs. resize="fit" as appropriate.

And the rendition filename? Who heckin' cares, the point to rendition filenames is that they’re unique, idempotent, and debuggable, not pretty. The basic tenet of humane URLs doesn’t apply to them.

Anyway, as mentioned above the cut I do want to make a change to how cropping works in that right now it uses Pillow’s rectangle specification of (left,top,right,bottom) but after using it for a day I’m finding that really annoying and basically all imaging software uses (x,y,width,height) with respect to the top-left corner, and it makes no sense to have right < left or bottom < top anyway. So, on the off chance you’re using Publ for your site and trimming thumbnails of your images, I’d recommend holding off until the next version.

Update: And then about an hour later I realized that there was actually a really easy way to make scale-cropping work correctly here and I’m feeling silly for not noticing it before. So this actually satisfies all of my original reasons except for the cropping rectangle aspect! Also while testing this I found a case where the (x,y,w,h) tuple syntax confuses the Markdown parser, so it now also accepts an 'x,y,w,h' string as well.

The road to v0.4.0

A lot has changed in Publ since v0.3.0, and I feel like a v0.4.0 release is overdue. If I were doing proper semantic versioning we’d be on, like, v2.29.0 by now, but I feel like Publ is more of a stream-of-updates thing than a scheduled-release thing. So the versioning scheme is pretty ad-hoc and more represents where I feel like Publ is in terms of being a Real Professional Publishing System vs. being a toy I made for myself.

So, I have two planned version milestones, v0.4 and v1.0. v0.4 is roughly where I feel like it should be stable enough for use by people who are into having a stable system to work with and don’t want to deal with fiddly stuff that’s an artifact of things being developed ad-hoc, and v1.0 is more like, hey, let’s get all of the Big Features done and also get it incredibly polished for large-scale adoption.

So, v0.4 is almost ready for release, I think, but v1.0 is going to be much further out, since it also involves much larger feature work (such as authenticated/private content), and likely I’ll end up establishing a closer milestone for major feature work like that but for now I’m just using 1.0 as a bucket for “everything that makes this a compelling blogging platform” (i.e. stuff to get people out of silos like LiveJournal or Facebook).

• Add date grouping properties to entry
• Add a pages property to view
• Provide the current category object to the error handler
• Support linking to non-image/non-entry local files
• Added, then removed, some performance micro-optimizations that only caused problems

More details about the major changes below!

Update: I released a hotfix as 0.3.18.1 because there was a last-minute bug that snuck in while I was trying to silence a new pylint error. Oops.

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.

• A more complete fix for how to handle image sets and inline images with respect to paragraphs
• Better cleanup for spurious empty paragraphs
• Improved internal entry link handling

Detailed descriptions of the changes are below.

Improved entry link handling

Entry links used to just be pretty simplistic; for example,

previously an entry link like

[foo](123)

would just generate

<a href="123">foo</a>

which would require at least a redirect to the entry from the path resolver, and also required external feed readers to be savvy enough to rewrite URLs (which is technically a violation of the Atom spec although most feed readers do the rewriting even though they’re not supposed to). Now it will generate a link like:

<a href="/example/123-some-foo">foo</a>

or, in an absolute context (e.g. a feed),

<a href="http://example.com/example/123-some-foo">foo</a>

But the primary improvement here is that it will also resolve links to entries by filename; for example, all of the below should work:

[some other entry](other-entry.md)
[in a parent directory](../other-entry.md)
[relative to content root](/blog/other-entry.md)

You can see some tests of this (UPDATE: tests have been removed from this repo). This link was, of course, generated with [some tests of this](/_tests/relative entry links.md) (but using the entry ID should still work as well).

This of course means that any Publ site will automatically get much better links for existing entries too, with no work needed on the publisher’s end.

Thoughs about future functionality

One of the things I’ve been wanting to add since the very beginning is private content; I’ve rambled quite a lot about how I might support that in Atom over on my personal blog. But I haven’t really talked about how this will go into Publ itself.

The changes to URL resolution got me thinking a lot about the whole “public links to private entries” issue and thinking about how I want to deal with data hiding/sanitization in Publ itself, and I came to realize that a lot of the groundwork for the fiddly bits is already there in Publ. For example, the changes to caching already make it so that I don’t have to worry about serving up private content due to a spurious cache hit (or serving up a public view to an authenticated viewer, for that matter), as the authenticated user will be part of the cache memoization already.

And I think that the data privacy model can be that the Entry object itself knows about auth – for example, it will know who the logged-in user is and whether they have access to the entry – and will only provide the data that should be visible. Which means that out of the box, private entries will at worst show up as placeholders with no data (or displaying shim content, anyway), and even things like link generation will be subject to these rules; the link resolver will be able to just see whether the viewer is authorized to see the title, and if not, it will just produce an old-style /id link, so no information about it leaks through that either.

There will of course be a couple of APIs to add in order to improve the view for unauthorized content, though; I’ll probably add a property to Entry to indicate whether the entry is unauthorized (so the template can show a “please log in” thing or whatever), and then view.entries, entry.next, and entry.previous will gain an unauthorized parameter to decide whether unauthorized content should be shown in the first place. So in fact the placeholder entries wouldn’t even appear by default. Also it should get some way of determining if any auth is needed at all, so that e.g. Disqus threads can be configured appropriately (like having two separate communities, one for public posts that allows discovery and one for private posts which doesn’t).

View will also probably get a needs_auth property, which will return True if the user isn’t identified and there’s private content that would appear in the view. That way, if someone isn’t identified, a category template can show whatever is appropriate to request auth from the client (e.g. an HTML fragment directing the viewer to the login page, or an Atom fragment with <link rel="auth"> or whatever).

Authentication itself, by the way, will absolutely be handled via IndieAuth and AutoAuth.

From a publisher’s perspective I see it working like this:

First, there will be a metadata file in some as-yet-undetermined format (probably YAML or JSON) that has mappings like e.g.:

http://beesbuzz.biz/: # that's me!
    _admin
    friends
    private
http://example.com/larry: # Larry from high school
    enemies
http://example.com/alice: # Alistair
    private
    enemies  # I'm not talking to them right now...
http://example.com/nancy:
    private

Next, private entries will get a header that indicates which identities or groups have (or don’t have) access; for an over-complicated example:

Private: private !enemies http://example.com/fred !http://example.com/nancy

which means that people in the “private” group can see it, unless they’re in the “enemies” group, and also let Fred (who isn’t in a group) to this entry, but don’t allow Nancy to see it even though she’s in the private group. (I would also probably have a special token * which matches anyone who has a known identity, whether they’re in a group or not, mostly for the purpose of showing a login/logout widget on the sidebar or whatever.)

Finally, if someone accesses the site and authenticates, this information will in some way be floated to the publisher, so they know whether to add the person to the friends list or whatever. (Perhaps there can be a daily digest of newly-visible folks, as well as a panel that is restricted to specific identities (like in the special _admin group) that shows all of the information about recent access. Most likely the user table will simply have a last_seen column.)

Open questions:

• Would it be useful to assign access groups on a per-category basis, or does that just needlessly overcomplicate things?
• What about access at the category level itself? (also probably overcomplicated)

• Are there any IndieAuth endpoints out there which let people log in directly with particular OAuth identities?

  Like, it’s really annoying to require people to authenticate with a profile page that has a bidirectional rel="me" relationship to one of the common OAuth providers (GitHub, Twitter, etc.), but none of the endpoints I’ve seen let you just provide that provider as your profile link in the first place. And this presents a big barrier to entry, IMO.

  It’d also be great if these endpoints were to widen their net; so far I only see support for GitHub and Twitter, but there’s a ton of folks using Mastodon now, for example.

• How the heck am I going to test IndieAuth login while I’m working on it? I guess I could spin up another Publ instance on my server, ugh…

Anyway, I am pretty excited about how having proper private blogging feels like it’s actually within my grasp!

• Improved the Path-Alias redirection logic; now it will do a 301 Permanently Moved for inbound Path-Aliased requests, and if a Path-Alias points to an entry with a Redirect-To it will redirect directly to that URL instead (and it will be a 302, same as the old Redirect-To behavior)
• Pagination can now be weekly; you can use entry.archive(paging='week'), and a ?date= view parameter ending in _w will provide a weekly view instead.
• Better default formatting for view.range, and an addition of a week format parameter there

What’s left to do before I’m happy releasing this as beta?

Release blockers

• Cache should be disabled while index is taking place
• Async image renditions don’t respect absolute parameter

Nice-to-haves

• Enhanced path-alias
• Add image cropping function

Already done

A change I made right after cutting v0.1.19 was to restore the index scan at startup, but only when running in production (since the deferred scan was to fix a bug that only manifests in debug mode).