note
|

I need to take a break from the merry-go-round of mf2/parser compatibility. I excitedly thought it was fixed. But it wasn’t. I’ve made some further changes, and it might be fixed, but there’s a good chance it’s still broken in some obscure way… IndieWebify.me refuses to recognise my Like and Bookmark posts properly, even though every other parser I throw at example URLs comes back fine? Last I checked, IndieNews still refuses to return anything but “error: no link found.” Update: something I did today must have fixed this… I fixed a typo in an earlier post, and suddenly it was on IndieNews ?‍♂️

It’s getting a bit stressful, to be honest, and that’s means it’s time to move on to another task before it burns me out on the whole project. I’ll come back to it again in a while, hopefully have a break-through and iron out the kinks.

In better news, I do have some custom gallery markup up and running, and the h-card in the sidebar is now a fully-fledged widget. Baby steps…

article

|

(Skip to the end for the TL;DR summary)

After an evening of debugging and rewriting sections of the HTML in “K”, I think I’ve fixed the markup and parsing issues I mentioned yesterday.

It turns out that X-Ray, the parsing engine used by IndieNews, Aperture, and probably others, was only finding the sidebar h-card in my markup. The rest of the content was being ignored. I’m not entirely sure why this is, to be honest, but it gave me a place to start.

Working from the (admittedly shakey) basis that if the parser was only going to find one mf2 entity on the page, then I’d want it to be the main h-feed or h-entry… so I started moving around some blocks of HTML and a few classes, and stripped out a few likely redundant pieces of HTML.

This… worked! The feed would show up in the X-Ray output instead of the h-card, and wasn’t all that different in the Pin13 parser compared to yesterday’s results. But it was far from ideal. The authorship information on every feed entry was screwed up; I’d made a change yesterday so only one full h-card was on the page (the sidebar) and followed the recommendation to markup the h-entry author details with u-author instead. Now came the conundrum: do I add back in a dedicated h-card to every h-entry, and by doing so re-break some of the other parsers looking for a single “representitive” h-card? I tried out adding them back in, just to see what happened. X-Ray was still fixed, but IndieWebify.me complained about it, and the IndieWeb Webring still couldn’t work out who I was.

I could have left it here. X-Ray was the main target, IndieWebify might not have liked it but could at least still see some details, and IndieWeb Webring was a “nice to have” in a way. But truth be told, it would have nagged at me. What if these “minor” issues were the proverbial canary? I want to achieve the widest possible compatibility now, to reduce potential issues at a later date.

It was around about this point that I remembered that an h-feed itself could have its own embedded h-card, which could potentially solve the issue. After moving my ‘h-feed’ class to the body element, instead of the main I’d been using up to then (so now it would use the sidebar h-card to represent the feed), it more or less did solve the issue.

It threw me at first that X-Ray didn’t list a separate h-card item like Pin13 did, but instead used the feed h-card for the authorship of every nested h-entry. Removing the now redundant author h-card from the entries stopped IndieWebify from grousing about these multiples. Oh, and here’s my new profile page on the IndieWeb Webring. Even my test microformat-based feed in Aperture/Monocle started displaying posts almost immediately after applying the change.

So, TL;DR: I moved my main h-card inside the h-feed, instead of it being a distinct entity on the page. By doing so I fixed pretty much all of the microformat parsing issues I was experiencing, which means “K” has taken a big leap forward… and I can stop pulling my hair out ?

Shared to IndieNews (maybe) and IndieWeb.xyz.

article

|

I’ve been chipping away at several things over the last two weeks, mostly focussing on markup, presentation, and theme file organisation. I want to get these finalised before I look at theme customisation options. If you’ve visited the home page, you might have noticed the display of certain post types has been evolving, as I search for a pleasing balance of information, appearance, and not overwhelming a visitor with a wall of text. I don’t think I’m quite there yet, so expect a few more iterations. My current thinking is to treat the home page a bit like an “activity feed,” where action-type posts such as Likes are displayed in summary manner to give more emphasis to the written posts.

Of course, if you’re subscribed to the site RSS or JSON feeds in a reader of some description, you’ve probably not seen any difference!

The most challenging issue I’m facing is the markup of posts and other page elements to be compliant with the specs of h-entry, h-card, and the various post kinds such as: Like, Bookmark, Reply, Repost, and so on.

Everytime I think I have the markup nailed down, something comes along to show me it’s broken in some way. I liked a post on Aaron’s site earlier, and instead of showing as the like I intended it became a regular webmention showing my avatar as a photo, as I’ve clearly messed up the h-card and u-like-of markup in the last round of edits. So sorry to Aaron for mistakenly filling his responses with my face! The Pin13 parser shows the right elements as being present, but IndieWebify.me and Webmention.io both fail to pick them up. I’m guessing it’s an issue with how I’ve nested things, and/or some stray classes from previous experiments that I’ve not tidied up? I’ll try to get some time to look into it more tonight.

For other – minor – examples, IndieWebring also refuses to pick up my representitive h-card, even though IndieWebify.me tells me I have this setup correctly. Aperture doesn’t seem to pick up anything other than my h-card when I use the microformats feed instead of RSS or JSON.

If the markup isn’t right then IndieWeb features are unlikely to work correctly – so fixing this is key for an “IndieWeb integrated” theme.

As an aside, and while I’m on the subject of frustrations, I’m having a hell of a time with the Webmentions plugin. Most of the time it feels like they just don’t get sent, as I frequently have to manually ping sites (such as with the earlier like post). There’s a chance this is related to the above markup issues; if the receiving site can’t parse the post that mentioned it, it might just throw the mention away? That feels like a bit of a stretch though.

I need to come up with a better way of testing these things, rather than “just give it a try on here and see if it’s worked or not…”

But anyway, “K” is progressing, even if it sometimes feels like one step forward/two steps back. I’d hoped to have a proper “release” ready for some time in February, but at the moment I think March or April are more likely. I’m only getting an hour or two a week to tinker at the moment, and I know I’m going to be busier with other things in February.

Syndicated to Indieweb.xyz and IndieNews (hopefully!)

Updated to add – IndieNews still doesn’t like my site. “Error: no_link_found”, every time.

article

|

I just had a weird issue where Cloudflare was blocking Bridgy from syndicating posts from my site.

Attempting to syndicate from either my WordPress editor, or the Bridgy user page would result in an error like this:

.

Now, I’ve never consciously set anything to say “don’t let Bridgy access my site,” have few settings turned on, and haven’t logged in to Cloudflare in months, so it felt like it must’ve been that some rule update on the Cloudflare side that started flagging the requests as potentially malicious. Unfortunately, Cloudflare’s settings are rather opaque – especially on the free tier. More annoyingly, the “Ray ID” in the error didn’t match anything in the limited logs I do get access to.

But, I’m nothing if not persistent… after a bit of trial and error – switching things off and testing again with Bridgy – and I was able to track down the culprit setting, in the “Scrape Shield” section of the control panel, labelled “Server-side Excludes”:

With this turned off, Bridgy could syndicate my posts again.

I’m starting to wonder if this setting is a contributing factor to the issues I’ve had where Webmentions and associated posts like Replies, Likes, and others seemingly haven’t worked? Perhaps someone with more experience with Cloudflare or the various IndieWeb tools could shed some light?

At the very least, I hope this post saves someone a bit of head-scratching if they suddenly find their Bridgy integration stops working.

Shared to IndieWeb.xyz.

article

|

I mentioned before the festive break that I was thinking about open-sourcing “K”, the custom theme I’ve been developing for this site. Since then, I’ve decided I’m going to do it, but I’m going to work to tidy things up beforehand. Some of this has already happened, some of it is yet to be done. For a bit of fun, I’m going to [try to] blog about it whenever I make some progress ?. All-in-all, I’ve identified three main themes I want to focus on before the intial public commits.

My first job is to make the theme more “generic.” As I mentioned, the theme has been very much a hacking together of what I’ve needed, as I’ve needed it. This means a lot of it isn’t as customisable as people expect a modern WordPress theme to be. For example:

  • The site logo is an embeded SVG, rather than an image that can be swapped out in the WordPress Customiser.
  • The sidebar was, until recently, entirely hardcoded HTML.

I’ve made some progress here – there’s now a “widget area” in the sidebar – but my custom author h-card is still mostly manual (although it does use a WordPress menu for the social profile links). I think I’m going to recreate this as a bundled widget. I could try using the IndieWeb h-card widget, but I liked having the flexibility of my manually crafted card, and the IndieWeb version doesn’t support multiple profiles at the same service.

The second main focus is going to be standards support. I want the markup to be as fully compatible with MF2 and structured data as possible. I’ve spent hours debugging this so far, and I think I have it mostly sorted. IndieWebify.me picks up everything I expect it to, and every parser/validator I’ve thrown at the different pages and types of content have come back correct to my eye. For some reason, IndieNews hasn’t liked any of my submitted posts, but that’s lower priority for now. I haven’t done much with marking up elements like comments, but the main page/blog post/author details seem to be correct.

Finally, the third focus is on the code quality and maintenance. This loops back to the customisability/flexibility theme as well. By its cobbled-together nature, “K” has been a bit… loose in the quality of the PHP code, and the frontend files were/are a nightmare to maintain. Up to now I’ve used a hacked to pieces copy of Bootstrap with a bunch of customisations on top to provide the layout framework (literally just the rules I needed, obtained through UnCSS), and a similarly cutdown set of FontAwesome icons. That’s fine for my use case – even if it has been a faff to add to the site – but it won’t work for other people.

I’ve started adding a build system for these frontend files, but it does mean I’m probably going to have to include the entirety of the minimised version of Bootstrap, and the full FontAwesome SVG sprites. Unless someone has a good suggestion? Unstyle has a CLI tool, but integrating that is probably a step beyind what’s needed for the moment. I haven’t added FontAwesome to the live site yet, but this page should be using the new style.css that’s been compiled from SCSS.

On the PHP side I’ve started making sure it conforms to at least the WordPress Coding Standards. There’s still a few files to update, but functions.php and most of the template files are done. After that I want to make sure everything is as modular as possible. I’ll need to add files to handle the various post-types, error pages, and other screens a more rounded theme would handle. I’ll also be bundling a selection of Post-Kinds templates, once I figure out how I want to display them on this site.

There are other things that will need done no doubt, but these are where I want to focus my efforts for now.

Not all of them need to be fully completed before “K” gets open-sourced, but I would feel a lot more comfortable if at least the first steps were taken along these paths. It is a little dependent on having enough free-time, but I’ve set a goal of uploading to GitHub by the end of the month.

If you have any suggestions, or other feedback, please do let me know — either as a comment below, or on your own site.

article

|

As I’ve been experimenting more with IndieWeb ideas on this site, I’ve been kicking around the idea of open sourcing the custom theme I use to power this site (currently called “K”). Part of this is from a desire to start sharing useful code again. I haven’t really put anything out there in years now. Once upon a time, long before the rise of Github, any code I wrote for myself would at least have ended up as a downloadable .zip file.

The other reason I’ve been giving myself, is to add to the pool of MF2-compatible themes available, in an effort to give people more options for deploying Indieweb sites. Right now, the Indeweb wiki only lists a handful of themes as compatible out of the box, so the more that can be added, the better it will be for growing the community.

The thing is, the theme is very much not ready for other people to lay eyes on, in its current state:

  • I (currently) do a bunch of non-standard things under the hood.
  • I’m also not doing a bunch of theme “best practices”. Simply because I’ve not needed to.
  • I’ve not really cared much about testing in browsers beyond the ones I use day to day.
  • A lot of the code has been cobbled together as and when I’ve needed it, so there are loads of “standard” features straight-up not implemented.
  • There’s a tonne of things hard-coded specifically for me. Those would have to be stripped out or altered to be configurable. That’s more code I’d have to write.
  • I’ve hacked up a bunch of dependencies, in the name of optimisation for my own needs. A public release would need to include the full code of these dependencies, or it’ll severely restrict anyone who wants to use the theme.

All in all, there’s quite a lot to do to make the theme usable by anyone who isn’t me. My natural instinct is to hold it back until it’s “ready” but as I’ve been typing this out, I’ve been wondering if I should just go ahead and put the code on Github anyway?

note

|

I’m trying to wrap my head around the #indieweb approach, and thinking about how it could be applied to my site, and more importantly, I’m trying to figure out how I would want it to work for me:

  • If I post a short post type (<280 chars), it automatically gets syndicated fully to Twitter, including any attached media. Micro.blog would also be good.

  • Any interactions with that Tweet are reflected on the original post.

  • “Pure” indieweb philosphy would have me reply to any/all tweets from my site, but I’m not sure I want to go there.

  • Other social media “silos” should similarly interact with the site in a push or pull manner as appropriate – e.g. if I post to Instagram, the photo should be converted into a new post on my site, with the file rehosted.

  • The site should essentially be the “hub” for everything I post online, including a “profile” of sorts.

  • Microformats and POSH should be a given.

  • Longer posts should still be first-class citizens.

  • Post titles are completely optional and the tools involved should handle this gracefully.

  • Different post types should have distinct/appropriate visual styling.

Oh, and all of this should work as easily and seamlessly as possible on iOS (my primary platform)

Right now, I’m trying to get this setup using WordPress with several of the recommended IndieWeb plugins and recommendations, but so far I’m struggling to get things “just so.” The site definitely feels very rough around the edges. I’m not tied to this current approach though. Ideally I’d like to stick with tools/languages I know, and not need to spend weeks configuring things.

In an ideal world, I could have integrated the IndieWeb tooling/approach into my existing blog, which is powered by Jekyll – but this currently fails my “easy to do on iOS” test, which is the main reason I’ve not blogged there in around six months.