For some bizarre reason, syndication targets have suddenly stopped working on my site in the last few hours…? The WordPress editor doesn’t list any available, Micropub clients don’t see any, and the default targets given by the Syndication Links plugin have disappeared from the settings UI. The custom targets I set up still show in settings, but don’t appear anywhere else.
How odd. One to dig into tomorrow 🤔
I managed to work a little on Saorsa this evening, for the first time in a while. Mostly working on the markup of the comments, and adding little accessibility and microformat improvements where I can. I’m really trying not to put arbitrary timelines on things, but I’d like to have the skeleton HTML mostly locked down in time for IndieWeb Summit 2019. Whether that’s achievable will be determined by how much more I can get done over the weekend.
“Continuing to extend the pathway from easily following websites to having them in your social reader.”
Thanks for consolidating this in one place, Chris. I caught snippets of the series and conversation between you and Ton in my Reader, but didn’t go back to search out everything. Now I have a concise place to go to when I have some time to read everything 😃
For my own part, my Links page is powered by the old WordPress Links Manager. I had no idea that had an OPML import function – that would have saved me hours of manual entry! I also didn’t know it could generate an OPML file for import elsewhere. “Today I Learned.”
In the last couple of weeks I’ve thought about creating a special page on my site to aggregate all of my Bookmark-type posts into one place. Similarly, I could create a custom “Kind” for Following, and aggregate those in a single place. Neither option would have their own automatic OPML file, but using a Kind does allow for a specific Feed for each type. It would allow for the full range of post meta to be added to each type too. The Post Kinds plug-in generates archives for each Kind, but I’m thinking a custom page would allow me to play with the presentation a bit more.
It’s something for me to experiment with at the least!
I’ve started using my new(ish) test site to build my new IndieWeb WordPress theme. It’s very early in the process, and I’m getting the markup in place first, before I go anywhere near a stylesheet – so it all looks very 1996 right now.
The lessons learned on “K” will be put into use with this theme, along with several ideas I’ve picked up along the way. I’ve already reused some of the more useful bits of K to give me a head-start, so I know that stuff like the feed and post microformats should be pretty robust (if not yet 100% complete). The main improvement I want to make over K is in flexibility – i.e. it’s not just usable by me, or locks me/the user into a particular setup.
If there is anything you would like to see in an IndieWeb WordPress theme, or any other suggestions, please file an issue in the repository. I can’t promise I’ll implement it, but at this stage, the chances are high 😉
I’ve taken the decision to switch my site away from the custom theme called “K” I was building, and for now I’m using the excellent Autonomie by Matthias Pfefferle instead1. Development of K had already slowed to a standstill, and realistically, I’m not going to go back to it anytime soon. It feels a little like a failure, a little like giving up, but I think it’s ultimately the right thing to do.
I made a lot of mistakes while building K, which overcomplicated things, made development more difficult, and ultimately led me into a dead-end. I thought “for simplicity” that I would use the Bootstrap frontend framework, as it would give me a robust foundation to build on. It did, but I had to bend and twist WordPress in increasingly hacky ways to get the output to “play nice.” A large chunk of the K codebase was being taken up by code solely tasked with massaging the output of WordPress to add the right Bootstrap classes or container markup. It felt increasingly fragile and hacky, and it was a bad sign. K would work for my setup, but I couldn’t ensure it would work for everyone.
Bootstrap added other complications: to properly manage my CSS “overrides” I had to create a build system that would compile a whole lot of SASS files together. When I started K, the CSS was stripped down to the bare minimum needed, and came to a few KB. After a while I ended up including the whole Bootstrap framework, just to make the build process easier.
There were no “options” to speak of, so it couldn’t be tailored to suit someone else using the WordPress customiser. I didn’t even want to think about Gutenberg support.
Microformats always felt like whack-a-mole. I’d get them working, then make adjustments somewhere else, and promptly see things break again. I put this on my need to make so many adjustments to the WordPress output – inadvertant issues kept creeping in.
Then there were the visual design choices. K grew out of the simple design I employed when I was writing 1-2 short posts a month, in the traditional format. In that scenario it worked fine. Once I started to use the various post kinds, things became more problematic. Now I was posting several posts per day, most of which weren’t in a traditional blog format. The home page became cluttered; it started to remind me of a badly thought-out notification area, rather than a well designed blog. The archive page was a disaster and I had no good ideas on how to fix it. There were a thousand other little niggles.
None of this is meant as a knock against Bootstrap, or WordPress, or build systems, or any other tool or technology I used to get to this point. K failed because of my decisions, rather than deficiencies in the tools. There were things I liked about K… it used zero JavaScript, and I did my best to stop unnecessary plugin resources from loading. Markup was as minimal as I could make it (within the constraints of what I could remove from WordPress output, microformats, and what Bootstrap needed). It worked well across browsers and devices (thanks Bootstrap!), and the accent colours were fun. I learned a lot about the excellent Post Kinds plugin during the development process. I’m filing it away as a failed experiment, which I’ll learn from and apply the lessons to the IndieWeb WordPress theme I’m still intending to create. One that will hopefully work for more people than just me ?
I put the source code to K on GitHub right back near the start of the project. If you want to take a look, steal any code, rework it into something usable – feel more than welcome to!
1 As a result, a couple of things that were setup specifically for K are broken. I’ll look into fixing those over the next few days. ⤴️
“"Autonomie" is a highly semantic, responsive, accessible and search engine optimized WordPress Theme. It provides HTML5 templates refined with microformats, microformats v2 and microdata …”
A really nice, IndieWeb-compatible, WordPress theme by Matthias. If I wasn’t developing K (albeit, that’s slowed down recently due to outside factors), or if I was still looking for an “out of the box” experience, I’d probably be using this.
The more I use it to write IndieWeb Textpattern articles, the more I’m reminded how much of a joy the Textpattern editing interface is. Comparing writing in TXP vs WordPress, on mobile, is like night and day.
“This is an update to my 2018 article on how I set up my WordPress site.”
I added myself and this site the the IndieWeb wiki WordPress Examples page earlier. It felt a little narcissistic, if I’m honest!
I’ve not added K to the WordPress Themes page for now, as I don’t think it’s ready yet, but I’ll add it in due time (or let others judge it worthy of inclusion).
I implemented proper pagination between archive pages last night, which should help making getting around the site slightly easier. I still need to implement pagination for pages/posts that are split into distinct pages. I’m not going to implement comment pagination, because I don’t like it.
Alongside this, I’ve added some templates for archive pages and search results. There’s nothing much to these, but it does give me flexibility to give these their own special formatting if I want to.
I need to come up with a better archive page than the current “Sitemap”. The current “design” was inspired by the archive page on Daring Fireball. It works fine if you’re only posting a couple of items a week, but in January I posted 112 items1. I’ll probably keep the sitemap for discoverability purposes, but a more friendly archive page has been added to the todo list.
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…
(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.
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.
I had the need to change the status on several hundred wordpress posts by a particular author, from “publish” to “pending” (more on this in a future post). This would have taken me hours to do through the frontend, so I figured I’d make my first serious use of WP-CLI, and script the job.
You can list posts using WP-CLI, and specify which columns to display, and even pass in basic filters, like so wp post list --<column>=value --fields=ID,post_title,post_status,post_author. You can also update posts. By combining these with some shell scripting, big jobs can be done fairly easily.
Easily. Oh, the hubris. The problem I ran into was:
I didn’t catch on to this distinction at first, and the number of rows I was returning was large enough it couldn’t display all of them in the terminal. Yes, I should have used less to check. I should have done a lot of things, like take a backup first (wp db export ~/export.sql), but that wouldn’t be as good a cautionary tale.
Long story short, I ran wp post list --post_author=3 --fields=ID,post_title,post_status,post_author, saw only the results I expected because some rows were cut-off. When I fed this into a loop which would update the post_status, I ended up setting every post as pending.
wp post list --post_author=3 --format=ids \
| xargs -d ' ' -I % wp post update % --post_status=pendingThe correct command should have been
wp post list --author=3 --format=ids \
| xargs -d ' ' -I % wp post update % --post_status=pendingThankfully, having realised my mistake, I could make use of WP-CLI to fix it:
wp post list --author=2 --format=ids \
| xargs -d ' ' -I % wp post update % --post_status=publishFor everyone following along at home, my mistakes so-far were:
I’ve returned all of the wrongly-pended posts to “publish” status. I do still have an issue with Post-Kinds data being missing on most of these posts; I think this is due to some wierd interaction between WP-CLI and the plugin, but I can’t be sure. These posts (~60) I’m going to have to fix by hand — I consider it a reprimand for my earlier flippant approach!
Cross-posted to /en/wordpress.
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:
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.
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:
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?
I’ve written previously about how the archives of my blog were less full than they should be – that, between domain changes, server/CMS moves, and times when I simply didn’t care, there were potentially hundreds of posts missing from the early years in particular.
Back up your crap, people – including your blog.
For the last couple of years I’ve had an on-off project to restore as much of this personal history as possible. Every so often I’d go ferreting through old hard disks, or exploring the Internet Archive’s Wayback Machine for old content I could salvage. At first I had limited success, turning up only a handful of posts. Of those, I was fussy and only restored the “worthwhile” posts – usually longer posts about big events, or technical in nature.
This last weekend though, I revised my stance on this. If I was going to recreate my blogging history, I couldn’t – shouldn’t – just cherry-pick. I should include as much as I could possibly recover: the good, the bad, the plain inane. Anything less would feel a bit dishonest, and undermine the raison d’etre of the whole endeavour: saving the past.
The only exception would be posts which were so incomplete due to missing assets (images mainly) that any body text made no sense, or posts which were completely unintelligible out of context of the original blog – entries about downtime, for example. Also excluded were my personal pet peeve – posts “apologising” for the time between updates1!
To bring the past kicking and screaming into the present, I dove back into the Wayback Machine, going as far back on my first domain as I could. From there I worked as methodically as I could: working from the furthest back onwards, post-by-post. The basic process was:
I started on the Friday afternoon, and manually “imported” around 50 posts in the first batch.
Turning off social sharing was done so I didn’t flood my Twitter followers with a whole load of links to the posts – some over a decade old. One thing I didn’t anticipate though, and which I had zero control over, was WordPress emailing the old posts to those who had subscribed to email notifications. It wasn’t until a friend IM’d me about her full inbox that I realised what was happening – so if you found your mail filled with notifications as a result of this exercise, I apologise!
To get around this, I ended up creating a new, private WordPress blog to perform the initial manual process, so I could later export a file to import into this blog.
Between Saturday, Sunday, and Monday evenings, I tracked down and copied over a further 125 or so posts. Due to the vagaries of the Wayback Machine, not every post could be recovered. Generally speaking, it was reliable in having a copy of the first page of an archive section, but no further pages. Sometimes I could access “permalink” pages for the other posts, but this was really hit-or-miss. A lot of the time the page the WBM had “saved” was a 404 page from one of my many blog reorganisations over the years, or in other cases, it would have maybe one post out of eight.
I made a rule not to change the original posts in any way – no fixing of typo’s/correcting something I was wrong about. The only thing I would do, was mark where there was a missing asset with an “Editors Note” of some sort, when appropriate. The only content I did have to consider changing were links.
One thing I had to consider was what to do about links which might have changed or disappeared over time. When copying from the WBM, links had already been written to point to a (potentially non-existent) WBM archive page, but if the original still existed, I wanted to point to that instead. In the end I would have to check pretty much every link by hand – if the original existed, I would point to that page; if not, I would take a chance with the Wayback Machine. In some cases I had to consider what to do where the page existed, but had different content or purpose to the original. I dealt with these on a case-by-case basis.
For internal links, I pointed to an imported version, if it existed, or removed it if there was none and context allowed.
In total, I imported around 175 previously “lost” blog entries, covering 2002-2006, with the majority from 2005. These years have gone from having a handful of entries, to having dozens. Overall, this has grown the archives by roughly 50% – a not so insubstantial amount!
At some point I will go back and appropriately tag them all, but that’s a lower priority job for another time.
2007-2010 were years when my writing output dropped a lot, so while I will look for missing entries from this period, I don’t expect to find many at all.
I discovered, in the process of doing all this, that I had gone through the same exercise before, roughly 10 years ago!
Over the last few days, I’ve been working on the archives of my old site; cleaning and recategorising them. Today, I have added them to the archives of Pixel Meadow.
These additions represent everything that was left of ChrisMcLeod.Net. Over the course of its life many changes occured and data was lost – so these additions don’t represent everything that I’ve written there over the years.
You would think I might have learned from this mistake back then, but obviously not! Fingers crossed it’s finally sunk in.
You’ve come a long way, baby.
I remember when WordPress first appeared. I’d deployed the b2 blogging engine a couple of times before, and anything which made b2 easier to install/use/adapt was welcome. Amongst the (many) blog systems I’d tried up to then, b2 had the lowest technical barriers but was still an exercise in frustration to get installed and configured. In those early days of blog systems each product had its own quirks, and their own belief about what a blog was and how it should work. WordPress always tried to come across as “the Writer’s” blogging system; once you had it setup to your preferences, it would stay out of the way. For the most part, anyway.
WordPress was never perfect, and it’s still far from it, but you have to admire any system (particularly on the web) which is still going strong after 10 years, while remaining fairly close to it’s original vision and principles. It made writing on the web more accessible to a generation of users, and for all its faults that should be celebrated.
[I originally posted this as a comment on Hacker News]