Archive of: Tag: Wordpress


Intermittent Oddities Sending Webmentions from WordPress

I’m having a weird time with the WordPress Webmentions plugin right now, where it only seems to send a webmention when I update a post after the initial inclusion of the mention. So: add mention (a href link) to the post > update/publish > update a second time.

Until I figure out what’s going on there’s no way to be sure it’s the plugin that’s the having the issue, or something in my particular setup. Once I can figure that out I’ll know whether to open an issue on GitHub or not.

Something else to add to the ever-growing todo list 😅



Small Site/K Theme Updates

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.

  1. That’s almost twice the previous high water mark of August 2018.


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…



“K” Theme MF2 Markup Update

(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.



“K” Theme Update 24-Jan-2019

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.



After some further exploring, Ulysses’ export to WordPress is really nice; it gives full options to set tags/categories, and by default will save the post then open the WordPress editor so you can add any extras before publishing.



Misadventures with WP-CLI (or: Always Backup First)

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:

  • The display column names are the names of the columns in the database, so to list the post author, you would refer to it as post_author.
  • The filter column names are as they are referred to in WP_Query, not how they are named in the database.

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=pending

The correct command should have been

wp post list --author=3 --format=ids \
| xargs -d ' ' -I % wp post update % --post_status=pending

Thankfully, 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=publish

For everyone following along at home, my mistakes so-far were:

  • Not reading the documentation fully
  • Not taking a backup before altering a live site
  • Not double-checking my test results before running the command “for real”

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.



The Road to Open-Sourcing “K” for 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:

  • 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.



Open-Sourcing My IndieWeb WordPress Theme?

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?