Simple, honest tools for the small web.

This is where I share short updates and notes as I build Pure Commons. Every post is syndicated to Mastodon, and there's an RSS feed if that's more your thing.

Really big update that I've been working on for a while in #PureBlog - this is all about theming and customisation.

You can now create/manage your own themes, as well as upload a custom logo to the sidebar. I'm particularly proud of how the themes worked out.

Read the docs - https://docs.pureblog.org/themes/

So the AI generated issue logging has found its way to #PureBlog. I had 2 overnight, both security vulnerbilities, both required authentication.

One was a nothing burger, but the other had the potential for an authenticated remote code execution, so fairly serious.

Anyway, both are patched in v3.7.3 so if you're running Pure Blog, I'd recommend patching ASAP.

Wooo that was a wild few hours!

  • v3.0.0 of #PureBlog released on #Codeberg ✅
  • v2.5.2 released on #GitHub for admin notice. ✅
  • Pure Blog repo archived on GitHub. ✅

Pure Blog is now fully on Codeberg! 🎉

Next up, #PureComments. But that's for another day.

Problem with doing a pre-release is that people may not see the update at all (as the PB updater only looks for published released), so I may just be moving the problem when I subsequently release again.

For the past 6 weeks or so, I've been doing a major re-factor of Pure Blog to clean some stuff up. I'm ready to release it, but it will be a breaking update, as it includes changes to the update process.

So people won't be able to update from within #PureBlog, but I'm not sure how to manage this? Should I just communicate this everywhere and hope people see it? Or should I mark the next release as pre-release in GitHub so the in-app updater doesn't work?

I'm open to any other ideas to..