Posts tagged with "BlogMore"

Somehow minor version numbers are tracking the day of the month at the moment, and that isn't on purpose, but here we are on March 14th with BlogMore v1.14.0¹.

This release has a couple of changes: one is directly practical and the other a little more experimental/hopeful.

For starters, I've added a minify_html option. Having added minification for CSS and JavaScript files, it made sense to finally do this for all the HTML that's output too. So, if minify_html is set to true in the configuration file, or --minify-html is passed on the command line, any generated HTML file will be squished down as much as possible to reduce its overall byte size.

Every little helps, right?

The second change comes from a request that I don't directly know how to handle, so this is an experiment with allowing for it. The request was for "themes". Now, from the start, I created BlogMore such that the templates can be overridden and that custom stylesheets can be used, but the idea of "themes" suggests something more formal. Allowing for this and planning for this isn't straightforward because, honestly, I'm no web developer and no designer.

So what I have done is try and ensure that the templates and stylesheet are as sensible as possible and then also expand the documentation to try and make it possible for someone to step in and write their own theme.

I've also tried to ensure that there are adequate instructions for agents in the codebase such that no breaking change will be made in the templates and styling, without this being obvious. The plan here is to keep the core of the theme support as stable as possible and to adequately alert people to any breaking change (and, ideally, to never make any breaking change).

On top of all of that, I've got Copilot to also make three example themes. None are that radical, and I might see if I can coax it into making one or two more that are a bit wilder, but they should at least be helpful for someone with skills who feels more adventurous than me (or they might at least work as examples for an agent so that more themes can be AI-generated).

I wasn't intending to make any changes to BlogMore today, but as luck would have it @andyc had a feature request which made sense and seemed easy enough to prompt for, so I did.

So the change is this: if you happen to configure BlogMore such that the post URLs end up being something that ends in index.html, if you turn on clean_urls, all emitted URLs will leave off the index.html. The result of this is that a URL that would look like:

https://blog.example.com/posts/my-first-post/index.html

can then always look like:

https://blog.example.com/posts/my-first-post/

In other words: it gives you a way to have clean URLs.

This is carried through all generated pages and the sitemap too.

It's not something I'd personally use for this blog (because it's been around long enough and has a specific URL layout that I want to keep working) but I can see it being useful for any future project, and of course I can see it being useful for anyone else wanting to use BlogMore.

Another wee change is to make sure that the rebuild-on-change feature of the local test server always loads any new values set in the configuration file. While it was reacting to some properties changing, it wasn't reacting to all; so I asked Copilot to check all the values and make sure all are handled.

Another day, another tweak to BlogMore. This bump adds a couple of features relating to headings. The main change being that I've added support for custom IDs for links. To borrow from the docs:

If you need a specific id — for example because the auto-generated one is too long, or because you want a stable id that won't change if you reword the heading — you can set it explicitly by appending {#your-id} to the end of the heading line:

### My Great Heading {#custom-id}

This produces:

<h3 id="custom-id">My Great Heading</h3>

The custom id overrides the auto-generated one. Headings without a {#…} suffix keep their auto-generated IDs as usual.

Headings, of course, have a default "slugged" ID if a custom one isn't provided.

The other main change is that it's now easier for a reader to discover a link to a heading should they want to link someone to a specific part of a post or page. Again, to borrow from the docs:

To make it easy for readers to share a link to a specific section, BlogMore renders a small ¶ symbol at the end of every heading. The symbol is invisible by default and appears when the reader moves the mouse over the heading. Clicking the symbol navigates the browser to that heading's URL fragment, where the address can be copied from the browser's location bar.

The anchor appears and disappears with a smooth fade and does not affect the layout of the page in any way.

Another small change I added was to the "Generated by BlogMore" text that appears at the bottom of every generated page. I always think it's nice if some tool lets you turn that sort of thing off, and I'd not paid attention to that yet. So as of v1.12.0 you can add this to the configuration file:

with_advert: false

and you then don't have to have that at the bottom of each page.

Credit BlogMore if you want, but you don't have to.

I was going to call this one "Yet more BlogMore" but I think, even after two posts with that naming scheme, the "...more BlogMore" thing has had its day. But here I am: another day, another wee change to the blogging engine I'm building as an experiment with developing using AI.

Just a couple of simple changes in this release. The first comes from the fact that I was updating my blog to include more of the "socials" icons (the ones you'll see towards the bottom of the sidebar if you're on a wide enough display, or in the collapsible header if not) and when I deployed some were missing. Which, after a moment of puzzling, made sense.

See: I made a change a while back such that I stopped using the full FontAwesome stylesheet, and instead only used a specially-built subset. This is handy in that it really reduces how much data goes into a page. But the downside, of course, is the browser will cache this file; so if you then add more "brands" to the list their icons will be missing until the cached version of the old generation of the CSS file goes stale.

So in this release I've added a generation-based cache buster; it's just the simple ?v=thing approach but it should work fine for what I need here.

The other change is I've added the generated FontAwesome CSS file to the list of files that get optionally minified at generation time. While it's not a massive change in terms of the total amount of data that gets pulled down, every little helps.

I feel like, at this point, I've managed to add everything I could possibly want from this little static site generator; yet somehow each day I have a new idea and off I go again.

It'll be finished soon. I'm sure.

While the additions have, for sure, slowed down, I'm still tinkering away with BlogMore. Recent changes stem from the fact that someone else has been mad enough to want to experiment with rebuilding their blog with it too, which, if I'm honest, is massively helpful with the ongoing GitHub Copilot experiment. Somehow it feels a little different, ganging up with the agent to implement changes for someone else's benefit.

Recent changes include:

• Tweaking the size and layout of the "social" icons that appear in the sidebar (this one was for my benefit)
• Making it possible to customise the title for the socials section in the sidebar (also for my benefit)
• Providing control over the path used for posts -- this one was a request that made a ton of sense, it's at this point it stops being a tool for me and starts being a more general tool

Next up is the first breaking change where I'm going to remove a feature. This came from my very initial experiment last month, where I was concentrating purely on building a tool for my blog and my blog alone. I'd made it such that the /attachments directory in the content directory had special status, and it would be copied over to the output directory in full. Oddly, however, this never made it into the documentation.

Meanwhile, the /extras directory also had special status with its content, full hierarchy included, being copied over but moved up one level in the output. So, for example, extras/humans.txt became /humans.txt in the resulting site, etc.

Presumably, at this point, you can see where this is going. Why the heck did I have a special attachments folder being copied over, when a folder of any name could live below extras and also get copied over?

So, now, my blog, which uses /attachments for all inline images and covers, has been updated so that the attachments live under extras and it all works as it did before; no special messing with a special folder name.

Given all this, the next release of BlogMore will remove treating /attachments as a special case, making it less hard-coded for my habits and more of a general tool that could be useful for others.

Mildly related to this: I did a lunchtime talk at work today, having turned Five days with Copilot into a 20-25 minute presentation. It was fun to do. I've not written or given a talk or presentation in a long time -- probably the last time was when I helped run Newton's Astronomical Society in the early 2000s -- so the preparation for this was a little daunting to start with.

While doing this, not wanting to break a long streak of never having used PowerPoint, I discovered and gave sli.dev a go. Writing a single Markdown file to power the talk was exactly my kind of approach. I don't have any experience with any other such tools, but if you're ever looking for something like this I recommend giving it a try.

I'm also open to suggestions of other options, given I might end up doing this some more.

Following on from the rescue of my photoblog, followed by the rescue of the original incarnation, I've been thinking that I should get into the habit of posting the odd image here and there again, when the desire takes me.

The problem is the workflow. The point and purpose of the last two incarnations was that I just had to take image, manipulate image, post image and then lots of other things would happen. As I've mentioned in the posts linked to here, and others here on this blog, it's much harder these days to achieve that seamless and frictionless workflow we used to enjoy during the rise and the peak of "Web 2.0".

So yesterday I decided on an approach that, while it's neither seamless nor frictionless (yet), it feels like it will work. So here's the plan:

• Take photo
• Manipulate photo¹
• In Apple Photos add a description to the image
• Export JPEG file to a Photoblog Inbox folder in iCloud Drive
• Later, when I'm at my desk, import the image into the photoblog
• Publish the updated blog

So, yeah, more manual steps are required, at least for the moment. I suspect though that if this works well I might be able to increase the automation involved and do it in such a way that I'm in control of the steps and services (or at least I'll be able to do it in a way that I can swap out a step should whatever service being be lost).

As an aside, for anyone who might have been following along with my experiments with GitHub Copilot: the import tool I link to above was written from a prompt. This, for me, feels like the ideal use for such a tool. Writing that script was going to be a chore, I wanted to get on with the bigger picture thing, so asking Copilot to write it while I attended to other things felt sensible and useful.

I'll likely tidy up the code soon, but for now what was produced works and it let me try all of this out in the time I had available on an otherwise busy Sunday afternoon.

I've just released v1.7.0 of BlogMore, my ongoing experiment with GitHub Copilot. Since the last release I wrote about I've made a couple of cosmetic changes, and also addressed a couple of bugs.

The first cosmetic change relates to how the blog appears on mobile devices¹. In such a circumstance, before the change, the sidebar content would, by design, relocate to the top of the page. This made sense, it meant that the information was still available, but it also had the unfortunate effect of pushing the actual post content way down the screen, sometimes off the bottom of the screen.

Not great.

So I decided to try and improve the mobile layout. As I have done so many times now, I started out with an issue that served as a prompt and assigned it to Copilot; despite the fairly vague request and the fact that I gave it an image to consider, and essentially gave it a hand-waved ASCII diagram of what I wanted, it mostly managed to one-shot the problem.

Now, when I visit the site on my phone, I see a lot less "admin" stuff at the start.

As a reader I can still toggle the "sidebar" information into view and out of the way again, but the important thing is I can get into the post itself right away.

Another change that's mostly cosmetic, although has a purpose too, is an index in the archive page. I've created this to only be available on wider displays; a tool to make use of any "dead" space on the right hand side of the page. This gives a table of contents of years and months so the reader can skip around the archives faster.

There have been some under-the-hood changes too. One was an effort to reduce the repeated boilerplate that I noticed was creeping into the templates. While I'm mainly building this tool for myself and the "out of the box" design is how I want my blog to look, I do want the templates to be usable and as efficient and as easy to modify as possible.

As mentioned earlier, there's also been a couple of bug fixes; one example being tackling some misbehaviour on GNU/Linux when it comes to site generation. That issue was an interesting one in that I wasn't able to reproduce the problem, so I decided to let Copilot have at it and make its best deduction. From what I can tell it came through (I still need confirmation that it has solved the problem; but it does seem to have identified an actual edge-case that was worth taking care of).

At this point I'd also like to give a shout out to @andyc. He's been a great source of testing and feedback as I've been toying with this experiment. While I set out to build a useful tool for me and me alone, he's raised a few good issues that should push it in the direction of being of more general use.

I highly recommend having a read of his post reviewing a good number of static site generators. As I keep tinkering with BlogMore I'll be keeping this post in mind.

While I've written a lot of documentation in my life, it's not something I enjoy. I want documentation to read well, I want documentation to be useful, I want documentation to be accurate. I also want there to be documentation at all and sometimes the other parts mean it doesn't get done for FOSS projects¹.

When I started the experiment that is BlogMore, I very quickly hashed out some ideas on how it might generate some documentation, and the result was okay. In fact, if anything, it was a bit too much and there was a lot of repeated information.

So, this morning, before I sat down for the day's work, I quickly wrote an issue that would act as a prompt to Copilot to rewrite the documentation. This time I tried to be very clear about what I wanted where, but also left it to work out all the details.

The result genuinely impressed me. While I'll admit I haven't read it all in detail (and because of this have left the same warning right at the start), on the surface it looks a lot clearer and feels like a better journey to learning how to use BlogMore.

blogmore.davep.dev hosts the result of this.

I have a plan to work through the documentation and be sure it's all correct and all makes sense, but if it's as correct and as useful as I think, I might have to consider the idea of taking this approach more often. Writing down the plan for the documentation and then letting it appear in the background while I get on with my actual day makes a lot of sense.

I fear I might be warming to these tools, a little bit. :-/

Since switching over on the 19th of last month I've been making lots of changes to BlogMore. While there's been a good few bug fixes and QoL changes, I've also been adding new features that I've found myself wanting.

Here's a list of some of the significant additions I've added in the last couple of weeks (and, yes, as per the experiment, all of these have been developed by me prompting GitHub Copilot):

• All parts of a date in a post's timestamp can be clicked to get to an archive of that point in time.
• Added fully-client-side full text search (I'm finding this especially useful).
• Added sitemap generation.
• Added a general fallback description for any page that doesn't have one.
• Added fallback keywords for any page that doesn't have any.
• Added author metadata to the header of all pages.
• Hugely optimised the use of FontAwesome.
• Made best possible use of all the usual og: type metadata in the head of all pages.
• Added optional CSS minification, improving page load times.
• Added optional JavaScript minification, improving page load times.
• Where appropriate, all pages now have rel="prev" and rel="next" tags in the <head>.
• Added a rel="canonical" tag to the <head> of all pages.
• Improved the style and workings of the pagination of all archive type pages.
• Improved the cosmetics of the category and tag clouds.
• Improved how the first paragraph is discovered for a page or post, when using it as the default description in the <head> of a page.
• Cleaned up the generated HTML so it's more compact.
• Added support for custom 404 pages.

As I say, they're just the improvements I've made that have come to mind as I've used BlogMore. I've also done a lot of bug fixing too. You can read the full changelog over on the BlogMore website¹.

I feel that the pace of updates and additions has started to slow; I think I've now got more or less everything I wanted from this. I'm pretty sure I can do everything I ever bothered to do with Jekyll and Pelican, and I am enjoying "owning" the code such that, if I have an idea for something I want, it's easy enough to make it happen.

I'm also pretty happy with how well the results perform. Despite the fact I'm not a web developer, and despite this blog being served by GitHub Pages (which, let's be honest, isn't the most speedy host), the measurements for a single page in the blog look fairly good:

That's measuring loading in a desktop context. Even measured as mobile (which I've tried to make work well too) it's not too shabby:

I think I can rightfully be satisfied with those values, given this isn't normally my primary focus when it comes to software development.

Anyway, if you like messing with static site generators, and one that is blog-centric sounds useful, and if you're not put off by the fact that this is a deliberate "use GitHub Copilot" experiment, feel free to take a look.

At the end of yesterday's post I said I might see if I can rescue the original photoblog from its backup on WordPress. This was the first photoblog I played with, posting to the long-dead Posterous between 2009 and 2013.

So, yesterday evening, I did an extract of the full feed from WordPress, and also asked for a full backup of all the media. I then fired up Emacs and rattled out some Python code that would marry up the two sets of data and add to the photoblog repository. It took a little bit of working out; it seems that every post had two entries in the feed: a parent and a child entry. I've no clue why that's the case; I didn't really care to get too deeply into it.

Soon enough seen-by.davep.dev was updated with an extra 1,833 posts! So now the categories on that blog site are broken down into Seen By Me 1 (the original) and Seen By Me 2 (the second incarnation).

Sadly, for the first blog, tagging wasn't really much of a thing so the tag cloud hasn't grown too much.

But, finally, I've got both the photoblogs back up and hosted somewhere I can point to, and I'm fully in control of their content. While it is hosted on GitHub Pages I've done this in a way that it would be pretty easy to move elsewhere; this is down to the fact that it's a simple static site built with BlogMore.