Search

I like to use my notes page for lists, especially shopping lists, but the markdown library I'm using (Parsedown) doesn't support checkboxes.

A quick function later and I had support. This takes the raw markdown prior to display and does a simple replace:

function parseMarkdownCheckboxes($text) {
    $text = preg_replace('/[ ]/', '<input type="checkbox" class="checkbox">', $text);
    $text = preg_replace('/[x]/', '<input type="checkbox" checked class="checkbox">', $text);
    return $text;
}

Great. But that only converts the markup for viewing. What if I could check/uncheck boxes and have them automatically update the note in real time?

I broke it down into sections then started asking ChatGPT for some code examples. As usual, it couldn't give me exactly what I wanted but was a great place to start.

Now, when I click a checkbox the following things happen:

• some JavaScript makes an array of all the checkboxes in a note (within the containing div)
• it gets the raw markdown text from a hidden textarea and splits it into an array of lines
• it reduces that further into lines that contain a checkbox
• using the index of the item clicked it update the relevant line from the markdown, joins them back together and replaces the textarea value
• it then makes an AJAX call to another file which updates the note content in the database in the background

To make things even better, a quick bit of CSS fades the checked items:

li:has(input[type="checkbox"]:checked) {
    opacity: 25%;
}

Update After wrangling with ChatGPT some more (and by wrangling I mean pointing out where it got things wrong) I've now also got it moving checked items to the bottom of the list and unchecking an item will move it to the top.

Now that I am no longer using the Garden I wanted to repurpose the 'wiki style' double square bracket markup I was using to link between its pages.

I had previously added markup to turn any text into a search link but haven't really used it. I think part of the problem is that the search takes you away from the post you're reading.

Dave Winer mentioned his tagging feature a couple of days ago and this seemed like a perfect fit. So I blatantly copied it. 😆

Now, if I include text within double square brackets it becomes clickable and opens a dialog listing all posts [[tagged]] with that text.

I already detect if the call to the content filters is coming from the files that build the RSS feeds so can ignore tags there to avoid any issues.

I'm not sure how this will sit alongside the existing 'post labels' but will see how it develops and how I use it. The advantage is that it's more flexible and I don't need to clog up other areas (like 'Start Here') with lots of labels. Tags aren't stored in the database like labels, they are checked when showing the dialog.

Note I have also removed tags on the homepage.

Looking back at posts from a couple of years ago, I was worried about feature creep on the site.

My goal with (b)log-In was to have a simple posting experience and my concern was that all the bells and whistles would detract from that simplicity.

I still want a simple experience (and I still have a simple posting experience) but things have changed in the past two and a half years. Yes, it's been that long!

The site is no longer just a blog, it is now my 'X' – my site for almost everything. Blog, notes, journal, feed reader, it's all in one place, all under my control. That has, obviously, necessitated an amount of expansion.

I'll admit, there are some more frivolous features (like custom markup, the file editor, and Markdown preview for custom pages) but they don't get in the way if I choose not to use them. The base experience is still as simple as it always was: tap a little '+' icon, type, and hit 'Post'. Nothing more complicated than that and no backend to navigate.

I suppose that's the beauty of building your own tools: you can make them work exactly how you want. And what I want (and have) is something that quickly and easily lets me put words on the web.

I've been typing so many backslashes over the past couple of days – escaping characters in seemingly endless regex queries.

It got to the point that I had a brain fart last night expecting italicised text to be slanting to the left.

Hmmm.

What if you could do exactly that?

A quick search found the same question on Stack Overflow with an ingenious solution.

I've modified it slightly so that I can apply it to i tags (with a class) such that they will be slanting to the left on the site but remain normal italicised text when viewed elsewhere (e.g. via the RSS feed).

This is a test of 'left slanting' text.

This is normal italicised text for a comparison.

Pretty cool.

Update I've added the custom markup _$..$_ to indicate left slanting italics.

Bix wrote about the idea of universally followable /now pages. This notion is a replacement for / addendum to an idea he previously had about a site or service that would show you when people have made updates to their info rather than what those updates actually were.

The key is that it would let the individual explore those updates in their own time. They are given the minimum information required rather than be overloaded.

He says:

"So that's my pitch to the /now page community: develop tools that publish these pages not just to a webpage but to RSS and/or ActivityPub, as well as tools to markup, perhaps using some kind of microformats, the underlying HTML in ways that would allow for a crawler to parse them even absent an RSS or ActivityPub feed."

Microformats2 certainly could work. There are already indieweb tools that parse pages based on markup, like monocle but RSS is far more familiar with much wider adoption. Even if people persist in saying social killed RSS or that it died with Google Reader.

Using rssCloud to push updates (I wish more feeds supported it) would be a nice addition.

This got me thinking about feed readers. They became popular because of their killer feature: convenience. They bring everything together in one place allowing the consumer to easily scan updates from multiple sources without having to navigate halfway across the web.

Feed readers also homogenise content, displaying it according to local preferences. Links will always be the same colour and other elements, like blockquotes, will always look the same. It reduces the cognitive load when consuming posts from multiple and varied sources.

But is this always a good thing?

I've written before about trying to shift away from posts just being "social units" in a timeline – that is one of the big disadvantages with certain social networks: all content is rendered the same. Also mentioned in passing before.

It makes me wonder if we're 'doing it wrong' with feed readers.

The homogenisation of post content means we lose the personality behind the words. As I have previously quoted Robin Sloan: "presentation is a form of content" – abstracting the content from how it was meant to look can do it a disservice.

I have been intrigued by the idea of having "less of an emphasis on the actual consumption itself within the reader – more of a notification system" and Bix's post brings me back to this.

The menu tray for /reader is just a list of blogs with an indication of unread posts. What if this was all it did? Just told you someone had updated their site and it was up to you, the reader, to go off and find out what.

I wondered if this approach might cause me to read less due to the loss of convenience. Conversely, it might make me interact more, leave more comments, as I would already be on the host site.

I posited an alternative view for /reader 7 months ago (wow, was it really that long) but nothing ever came of it. Now, however, I think the time is right to return to it and see what I can come up with.

I've gotten into a groove working with the file posts for hyblog. The RSS feed creation is now done: I get the files collection, grab the most recent ones, then cycle through the specified number of posts to build the feed.

What it does, however, is highlight that I really should come up with a better way of handling the posts in the markdown files. At present it's very basic and means that there is no record of when each post is published, only the date. It's enough to have something for the item pubDate but not as ideal as it should be.

I was thinking about using yaml but it conflicts with markdown so I would have to switch completely. Not happening. Instead, I'm considering having the system add the dates and then use more custom markup to separate it out.

In a way, I have been prepping for my return ever since stepping away. Quite a bit has changed.

To remove the focus from the blog itself I changed the home page to a 'Hello' page, inspired by Alastair Johnston. That has now moved to /hello and been replaced with a new, simple home page. By necessity, the blog moved to /blog – and that is where it's going to stay.

For a few years now, the whole ethos of the blog has been to focus on "today" – that's what you'd see even when there were no posts. I've moved away from that. Now, when not signed in the blog will show the last day with a post. Also, when going back and forth between days, it will only show those days with posts.

The biggest changes have been with feeds, both the creation and consumption of them.

The live feed now supports markdown using the source:markdown item-level element. As I post in markdown it's pretty cool for a feed to support the raw source.

Because I use custom markup in (b)log-In I have to convert that to normal HTML before adding it to the feed but that's fine. It was always intended for HTML to coexist with markdown where required.

Markdown support is also now built in to /reader. If an item within a feed includes the source:markdown element that will be used by default instead of the description or content elements.

Blogging through time

While I have been active on the internet in one form or another since 1993 ¹ I got 'online' properly in 1995 and spent a lot of time in various forums or on ICQ and IRC. In the late 90's I started noticing blogs and became a frequent reader and commenter. By 2003 I decided it was time to have my own blog. As I was working in outsourced support for Microsoft UK at the time it seemed natural that my first blog was a mixture of personal updates and what I was learning about various Microsoft technologies.

Kev Quirk recently gave a design history of his blog prompting others to do the same, so here's mine.

2003 – Now this is how it started

Through my job I had full access to an MSDN account and had been looking at various Microsoft server products. It was, therefore, no real surprise that my first blog was built on SharePoint. That's right, SharePoint! It wasn't designed for it, required a lot of tweaking and custom code but it worked... Mostly. In June 2003 I first registered the domain randomelements.me.uk and launched a blog using SharePoint Portal Server.

The first capture on the Internet Archive is, sadly, from 10th March 2004 but the look hadn't change much since launch.

I had a static IP from my ISP at the time so was self-hosting this and an Exchange Server on a machine in my dining room.

SharePoint wasn't supposed to be a blogging platform and a lot of customisations had to be made to make it viable. RSS feeds were not supported out of the box but a clever chap called Sig Weber created an add-on that generated feeds for SharePoint lists. I also took and rebuilt an open-source ASP forum, integrating it into the site using iframes. The forum doubled as the mechanism for making comments using some SQL tricks.

2006 – One SharePoint to another

In 2006 I switched from SharePoint Portal Server to Windows SharePoint Services v3. Things were more streamlined with WSS and the site looked more like a blog than before. There was now an RSS feed for comments as well as posts, and even a mobile view using WAP.

Changing sidebar widgets aside, that's how things remained for almost the next two years. Over time I became disillusioned with SharePoint. While I had managed to make it a reasonably functioning system I'd reached the limits of what it was capable of. I had mostly switched my blogging focus to social media and was looking for better integration with the social web. My wife had been trying to get me to use WordPress for a while and I finally succumbed.

2008 – Welcome WordPress

While I had been essentially microblogging since 2003, with the occasional longer post, the change saw me try to be a citizen journalist. I fell into the trap of writing mainly essay style posts and wanted a theme that would look more like a news portal, emulating the tech blogs rather than a personal blog. By complete contrast I decided to change to a personal domain and registered colinwalker.me.uk.

Gone was the blue of SharePoint in favour of red and black, multiple columns and 'read more' links. In retrospect it's not something I'm overly proud of but I was trying to be something I wasn't. I took the first of numerous blogging breaks in 2009 and the domain redirected to a wordpress.com version which may be why the Internet Archive again failed to properly capture the site until October 2010.

2011 – Rebrand

Towards the end of 2011 I rebranded the blog to 'Social Thoughts' instead of just my name but, in the short term, not much else changed. Over the next few months I slowly simplified things and the site evolved. I cut out a column and made it lot lighter, more whitespace; the red stayed but was dialled back a bit.

In keeping with the name I had also decided to re-include shorter posts or 'thoughts' as I would call them to match the site name. I had been running a separate 'blogette' on Posterous called 'Colin's Thoughts' which focused on shorter, quicker, less essay style posts and it seemed a good opportunity to combine the two.

I was heavily active on Google+ which prompted a number of design choices like the inclusion of G+ comment sections and direct links to subscribe in Google Currents while it was still a news reader app before becoming the rebranded Google+ for business.

2012 – Stripping it back

By the end of 2012 I had continued cutting back and embraced a more minimal approach. I think I had realised the previous error of my ways.

The site had been cut back to a single column with no sidebar. Links were still red but the site was otherwise monochrome with a lot of whitespace, things felt much more airy. Posts were mainly essays with the 'thoughts' becoming less frequent. I was becoming jaded with constantly striving for perfection on the blog and switched full time to Google+ in November 2013.

2016 – Blogging back better

By the end of 2015 I had stopped writing on Google+ as a number of changes, and a shift in the community, made me realise it couldn't really replace your own site, but I still wasn't quite ready to return to the blog. It took until March 2016 for me to reboot the site. The first capture in April illustrates a shift in design to go with a shift in content. I wanted to write a lot less about social media due to an increasing frustration with life on social networks.

I made a deliberate decision to become even more minimal and move to grey scale, the red had finally gone along with the 'read more' links, full posts on the home page was the way to go instead of having to click through.

There was, again, a period of gradual evolution. A few months later saw the change to the blue/grey colour for links - completely monochrome wasn't working but I didn't want too much colour. The default link colour in (most) web browsers is blue so I wanted to reflect that but remain more muted.

Strangely, a couple of months later I had reverted to the grey and reintroduced the 'read more' links along with social buttons. What was I thinking? I was more active on Medium and had outsourced comments there, disabling native WordPress comments to avoid having to deal with spam. It seemed like a good idea at the time...

2017 – Big changes

In January 2017 I stumbled across the kickstarter for micro.blog. Having stopped using Twitter in December 2016 this piqued my interest and in February I started prepping the blog to better integrate with the service and provide a better venue for hosting my own microblog posts. This also had a big impact on the way I posted – I returned to how things were from 2003 - 2008 with predominantly short, micro posts and the occasional longer effort.

Around this time I also switched to the colinwalker.blog domain

The first half of 2017 was a period of massive change. I originally felt that the microblog should be separated from longer posts but relented when it seemed counter-intuitive to do so. Threads and themes would go between long and short posts so it became hard for people to follow along if only following one RSS feed.

Micro posts integrated with longer items as seen here.

Some of the more familiar design elements from later iterations of the site started to creep in such as the the little icon to show if there were comments on posts. Visually, it was another case of gradual evolution; technologically it was taking huge leaps as I began integrating IndieWeb elements and plugins into my theme and WordPress.

In June 2017, inspired by Dave Winer's Scripting News, I made what was probably the most fundamental change to the site which has defined how it looks and works ever since. I changed the homepage of the blog to a "Today" page with posts in chronological order. You would start the day at the top and read down in time order – top to bottom just like reading a book. If there were no posts for that day it would say so and list the 5 most recent posts. There are no working captures on the Internet Archive for this period but the below shows how it looked on mobile:

I was initially worried about the change as people are so used to reverse-chron but it stuck and I have kept with it ever since. The rest of the year saw me refining the design, permanently reintroducing the blue/grey for links. I had toyed with trying different colours to make them stand out more (especially when using my phone in greyscale) but decided the blue was best.

2018 – Rebrand and revert

By April 2018 I reverted to calling the blog by my name rather than the 'Social Thoughts' moniker which no longer fit my approach. The option of a dark mode had appeared by way of clicking a dot at the top right of the page.

By July 2018, after going on holiday and being largely disconnected, I decided that I needed to step away from online life for a while – cue another blogging break. On my return in 2019 I started further simplifying, reducing, decluttering. Here's a capture from May 2020 (again, captures are very spotty.)

Over time the 'Today' page had moved to a "blank slate" metaphor; I stopped linking to previous posts so if there were none that day there would literally be nothing to see, each day a blank slate, a fresh start. The blog had hit peak minimal. Each day became a single post that I would continue to edit throughout the day and divide into sections. To start a new section I would type two ampersands which would get converted to a linkable hash at display time. I created a custom RSS feed that would take each section and present it as a separate item but recommended people used the Daily Feed to catch up with everything in one go, top down like on blog.

November 2020 also saw the birth of The Garden, my own digital garden/wiki style repository where I could store things that weren't posts. Each item was a WordPress page within a hierarchical structure (parents, children, grandchildren) and I could use typical wiki markup (double square brackets) to link between pages.

2021 - (b)log-In

Although I saw it as my ideal setup, the new mechanism lasted for just over a month. I was becoming increasingly frustrated with WordPress feeling it too heavy for what I was doing so looked at building a new version of the Today page that was straight up PHP, no WordPress. It pulled the posts from the same database but was considerably more lightweight. I realised I wanted to turn it into a fully self-contained system so built one – it was launched on the 6th Jan 2021.

I emulated the theme and layout from my custom templates in the WordPress version of the blog; I liked the look that had evolved and wanted to retain it.

Each instance of the blog has had an ongoing process of evolution. From 2008 to 2016 it was the same WordPress theme just constantly reduced and butchered. 2016 to 2021 was my custom version of Automattic's old Minnow theme reduced to one column and tweaked. (b)log-In continues to benefit/suffer from this process - constant tweaks, borrowing bits from other people and integrating them in a way that feels natural to the site, it's all a remix.

Ups and downs

It's been fun taking a walk down memory lane but a little cringeworthy at times thinking back to some of the decisions I made or, rather, why I made them. Thanks to Kev for the prompt.

There have been a lot of ups and downs over the years with a number of breaks from blogging, both completely and by switching to write elsewhere (Google+ and Medium) but I have always come home. I sometimes regret writing away from the blog but remember that I needed to shake things up. If I hadn't, the possibility is that I might have stopped blogging completely and not returned from one of my breaks.

Things will, no doubt, continue to morph and develop over time (the recent additions of the 'Start Here' page and feed reader are testament to that) and it will be a fun experiment to see how they have changed in another 19 years, presuming blogging is still a thing.

---

1. first sharing music samples on a Usenet board over a 2800 baud modem – speedy! ↩

My indie, integrated feed reader

For a few years now, it has been a goal (or more of a dream) to build my own feed reader which integrates directly with the blog making it easy to perform indieweb actions such as likes and replies. I started building a WordPress plugin back in 2018 but quickly abandoned it as I didn't have the coding skills necessary at the time.

Today I am officially unveiling /reader, my new indie, integrated feed reader.

Before getting to the details I wanted to say that this has been made possible thanks to this RSS & Atom parser by David Grudl, it took a lot of the grunt work out of the equation meaning I could focus on the important bits.

Down to business

Reader adopts the visual style from the blog and my notes page displaying items as 'cards' in a river of news – oldest first. It can show all items, per feed or the last 24 hours.

New feeds can be added individually or imported from an (uploaded) OPML file. When added, the posts for that feed will be automatically pulled in. A cron job polls for new items every 30 minutes checking the last time the feed was updated to see if it needs to grab new items. That date is then written to the database for the next time it checks.

I'm currently storing a rolling three months of items but may reduce this to keep the table size down. When polling for posts it compares the timestamp (e.g. pubDate or updated) against 'now minus three months' and ignores anything older. New items are pulled into the database and those older than three months are deleted.

I can trigger a manual update at any time via a 'refresh' icon which triggers an async action to poll feeds in the background. The feed list (which slides out from the left) shows which feeds have unread items.

Indie and Integrated

So, why go to all the trouble of building my own feed reader? The main reason is integration with the blog. It's also another aspect of my online life that I can bring into my own control.

In addition to 'mark as read' each 'card' has actions which allow me to post directly to the blog and send webmentions. I can like, reply to or bookmark a post and the relevant Webmention will be sent.

Tapping each of these actions brings up a form populated with the post URL and the 'content filter' to add the required markup. I can then add some comments or my reply and post that straight to the blog.

I can 'mark all as read' which does as it suggests unless viewing a single feed when only items for that feed are marked.

Public/Private

The /reader page is publicly available but all admin and post actions are gated behind login checks. Anyone is welcome to come and have a look at what feeds are listed – the posts visible will reflect my read/unread status.

I am considering adding the ability for anyone to download an OPML export of the feeds list should they want. I might also add an option to 'suggest a feed' where visitors can let me know of a site they think I should be subscribed to.

v1.0

This is a version 1.0 feature that likely has bugs and needs tidying up or refining so it will likely change as I use it more and come up against issues or frustrations. I've already thought of one thing I want to add while typing this.

It doesn't support JSON feed but someone submitted a PR to include this in the library so I may look at implementing that in future.

Here's a short video of /reader in action.

Today is the first anniversary of (b)log-In going live and it's been quite a ride. I can't quite believe that it has been a whole year since it launched.

The roots of (b)log-In go back to while I was still on WordPress trying to make the experience simpler and easier. My goal at the time was to avoid having to go to wp-admin.

I had created a separate page with a posting form so all I had to do was navigate to '/new' type a post and hit submit – much easier than diving into the back end. After about a year of using this I decided it wasn't enough so, in August 2020 and inspired by the P2 WordPress theme, added the form to the main page template. When logged in I could just go to the blog and add new content straight away.

October 2020 saw me add inline editing of posts: each post had an icon beside it that I could tap to switch to edit mode, a form appearing in situ with the post contents – make the required changes and hit submit. No need for wp-admin to fix typos etc.

Over the next couple of months, I fleshed out what I called my 'custom layer' on top of WordPress adding content filters (which allowed me to use custom markup) and media uploads, all straight from the front end. It made WordPress so much easier to use.

Then on Christmas Eve 2020 everything changed: I first created a version of the blog homepage that didn't use WordPress. It was a PHP page that used a MySQL query to pull posts from the database. It was originally just an experiment but the seed was sown. I had originally envisaged it as a standalone page that let you read the blog without the bloat of WordPress. A few days later, the potential for it to become its own thing became apparent and I devised a separate authentication system (which I later rebuilt from the ground up.)

I wrote at the time "I'd like to make it a fully self-contained system" but wasn't sure what trade-offs and compromises I would have to accept to make it happen.

On New Year's Eve 2020 I decided to stop development saying that I needed to focus on work and training so that I could get a new job. Creating a custom CMS seemed like a luxury I couldn't afford at the time but the idea wouldn't go away, it was always there in the back of my mind.

I went to bed on the 2nd Jan 2021 but couldn't sleep, my mind went to the blog and I had a number of ideas about how I could make the new system a reality. The next day I started coding in earnest adding inline posting and the framework for creating RSS feeds. I wrote that I was almost there on what could be considered a minimum viable product.

4th Jan 2021 saw the addition of inline editing, media uploads and full RSS feed creation triggered by posting. I could have potentially made it live at that point as I had everything I needed to create and edit posts. I was considering a commenting feature but decided that wasn't a priority. However, in typical fashion, decided to build a simple one the very next day which sent me an email when a comment was received. Inline post deletion was also added at this point along with the content filters from WordPress.

Then, on 6th Jan 2021, after only 5 days of actual development, I switched to what would become known as (b)log-In full time. A lot of the groundwork was done while still on WordPress and it was more a case of translating features rather than creating them from scratch. That saved a lot of time and effort.

5 days to get up and running then the rest of the year to polish.

The next few days saw a couple of new features, including draft posts, but then, on 14th Jan, I discovered that my code wasn't secure – a post had been overwritten with spam during the night. I wrestled with this for about the next week with little success. Posts were getting replaced and I was playing catch-up. I thought it might have been a MySQL injection but the RSS feed was getting updated with the spam posts meaning that it had to be coming from the posting process. I rewrote all of my prepared query statements and wrapped as much as I could in authentication checks.

I was thinking that I would have to scrap everything as my coding skills were not up to it but eventually got on top of the problem.

At the same time I started working on a webmention endpoint. I originally thought I was going to have to sacrifice webmentions entirely but both sending and receiving turned out to be much easier to implement than expected.

Since then, many more things have been added and I've actually gone beyond feature parity with the WordPress blog. I also thought that I would have to run both systems in parallel as I didn't feel capable of migrating everything. I needn't have worried as I eventually got the Journal, muse-letter and Garden all moved to the new system. The last holdout was the blog archive which I thought would still require WordPress as I wasn't willing/able to build an import function. Instead, I created an archive page that pulled posts, and their comments, from the old WordPress tables. With this complete I was able to completely remove WordPress from the server in September 2021.

I have no immediate plans or a roadmap for 2022, I will continue to revise and improve the code where I find issues but, as far as new features are concerned, I only add new things when inspiration strikes. There is nothing I can currently think of that is needed.

The first year of (b)log-In breaks down as follows:

• 967 posts
• 701 comments (239 local, the rest are webmentions mostly replies from micro.blog)
• 4740 entries in the redirect table to ensure old links work

The last year has been amazing and the decision to drop WordPress and switch to my own system has been one of the best decisions I've made in years.

Thanks for being on the journey with me.

I was thinking about using webp images to reduce page size and the amount of data transmitted when viewing the blog so started looking at conversion apps for my phone. While webp support exists in most modern browsers now it may still be the case that people are using one that still doesn't support them, especially older versions, so I couldn't just upload webp files.

The obvious answer was to automatically convert images when uploaded using the PHP function imagewebp. Only one problem: how to handle the image fallback as I use Markdown to write posts?

The solution was a custom content filter using the markup similar to how an image is defined in Markdown and inline with the existing filters. I also added the ability to include optional attributes of class and alt text. ¹ An image would, therefore, be added to a post as follows:

The path_to_img is the original uploaded file. If that is a png or jpg it gets converted to webp and a <picture> tag built with the relevant images and attributes added.

The above image was uploaded as a png but the webp version will be displayed for those browsers that support it.

I've had to change the search markup to double $ to avoid messing up code blocks with PHP variables.

Search markup is now in place – I decided on surrounding the search term in single '$' signs. Search links are indicated by a double underline.¹

There is a bit of logic in place to prevent incorrect replacements when there are extra $ signs in a post.

Happy Friday.

Hashtags on the blog automatically get rendered as search links for that tag but I'm also thinking of adding additional markup to search for whatever text is within it. That would enable me to do searches without having to worry if a hashtag had been included. I just need to decide on the actual markup to use.

The full post titles feature should now be sorted on the demo site, including RSS feeds. I'm still debating whether I'm going to port it back to my live blog. Maybe I will want to draw specific attention to individual posts by way of a title, especially if I do implement the indentation idea I was having – there could be independent threads within a day.

Just my brain going round and round, working overtime on features I may never actually use.

A number of features here are achieved by using custom markup within the body of a post (inspired by wiki style markup) so I need to document all of this properly. I think section indentation would probably be easiest to achieve using something similar at the start of the text. I've got some ideas as to how I would do this but need to conduct some testing before making any announcements.

I can't ever see myself returning to a "normal" blog (reverse-chron with post titles) but seeing as how (b)log-In can now be set to the more traditional reverse-chronological post order I was considering adding the option to enable titles in the admin page. Even then they would not be mandatory and the output (and microformats markup) would be adjusted based on whether a post had one or not.

Now that I have the demo site up and running I can do dev work over there and port changes back rather than risk breaking the main blog.

I'm also considering making the Daily RSS feed optional as it requires a cron job configured to rebuild the feed file each night which some might not want to set up – assuming anyone would actually use this engine that is. 😊

I'm having issues with the microformats markup on comments not being recognised correctly where replies will contain the content of the post rather than their own. I don't know why and currently don't know how to fix it so will step back for a while and look at it with fresh eyes in a couple of days.

I was looking to the old WordPress plugin for comment webmentions for guidance but can't really see anything there to help.

The microformats markup on comments seems to be okay as I was able to spoof a webmention using Postman with a comment as the source. Now I need to work on the actual code to create and display replies.

I'm going to be working on a test copy of the blog page rather than break the live one – I think that's the sensible option.

John Gruber on Markdown:

"the whole point of it is to provide a syntax where the most common HTML tags for prose can be replaced by simple punctuation characters that are meant to be visible to the writer ... I have no idea why there are now apps that use Markdown as their back end storage format but only show styled text without the Markdown source code visible."

I understand why apps such as Ulysses and Bear "only show styled text" but as I now only write in plain textareas I see all my markup. I've previously enjoyed apps that want to allow their users to write in Markdown but retain a clean layout but, if using apps, ultimatey prefer the hybrid scenario where you have both – show the markup and the immediate visual clue of syntax highlighting.

If there's one thing that has surprised me about getting webmentions working on the new blog it's that creating an endpoint is actually a lot easier that I initially thought. I think I had scared myself into not believing that I could make my own endpoint under the misguided impression that it was going to be beyond my limited coding knowledge.

Fuelled by yesterday's bout of positivity I thought I'd have another look but taking a different tack. Rather than thinking about it as a whole I decided to take a more granular approach and break it down.

Chris Aldrich had previously advised looking at the old versions of the WordPress webmention plugin as they were far simpler than at present. I also decided to start from first principles and check out the W3C Recommendation to check the actual specification.

I was previously conflating the mention itself with everything that goes with it (the microformats markup etc.) but looking at the spec a webmention is simply "a POST request containing the source and target parameters" - that's all. Consequently, an endpoint needs to receive that request, verify those parameters and respond to the sender accordingly. It's much easier to get your head around when you look at it like that.

So, a check on the source URL (and error response if it doesn't exist) would be something like:

if ( !isset( $_POST['source'] ) ) {
    http_response_code(400);
    exit ('source is missing');
}

The spec also says that the receiver must check the URLs are of supported schemes (normally http or https) - so simply check if parse_url($_POST['source'])['scheme'] equals http or https. While this is listed as a 'must' an endpoint will still function without it and other checks will likely return errors in any event were this going to fail.

The receiver "must perform an HTTP GET request on source ... to confirm that it actually mentions the target" so do this using cURL to get and test against the source content, returning an error if not.

Next up, the spec says the "source document must have an exact match of the target URL" so I perform a quick lookup in the database to confirm that the target URL resolves to a post ID.

If these checks are all passed then the endpoint sends a HTTP 202 response confirming the request has been accepted. And that's it from the actual webmention side of things.

That may look a bit long winded so here's the short version:

• Are there source and target links?
• Are they valid?
• Does the source contain the target link?
• Does the target link point to a valid item?

What happens after that, as the saying goes, is up to you and how you want to process the webmentions.

For a webmention to be really useful you want to be able to check what type of mention it is, who it's from, and what they say. I'm using mf2-php to parse the contents of the source page:

$jsonmf = new Mf2Parser($contents, $sourceURL, true);  
$mf = $jsonmf->parse();

This is so handy as it translates the source page HTML into a standardised JSON array making it easier to pick out the elements like name and webmention type, for example:

$Name = $mf['items']['0']['properties']['author']['0']['properties']['name'][0];

As my 'posts' (or sections) for any given day all exist on the same page I have to go a level deeper if I mention one of my own posts:

$Name = $mf['items']['0']['children']["$s"]['properties']['author']['0']['properties']['name'][0];

(Where 'children' is the collection of 'sections' and $s selects the correct section number.)

Once the required information is collected I add a new comment to the database (using the ID found earlier as the parent post) and send myself an email notification using PHPmailer in the same way as I do for comments.

At present, I'm only checking for Likes and Replies - anything else will just show as a standard mention but I may expand this over time.

Looks like the last of the glitches with webmentions are sorted. The main one was that Likes were only being seen as normal mentions but this now seems to be fixed. I don't know how but maybe there was some kind of issue with markup that I have inadvertently corrected.

Thanks to a conversation on micro.blog I have changed the way I enter the <details> tag.

There is custom markup for adding spoiler text on Stack Exchange, all you need to do is precede the text with the two characters > ! (but together) so I thought this would be a good place to start for details markup.

I've settled on this:

The filter looks for the text between the delimiters and surrounds it in the required <details><summary> tags instead. I was previously entering the text on two lines with two sets of delimiters so this is more streamlined.

I've since found out that Reddit also uses similar syntax for hidden text so I'm in good company.