Since raising the version of the ‘Likes and Replies’ plugin to 0.9.0 and calling it a release candidate I don’t think I’ve come across any problems. It’s hard to believe that the last commit logged on GitHub was 17 days ago.
One thing I like that Dave Winer does on his blog is have posts listed chronologically for any given day – you start the day at the top and read down in time order. We read top to bottom normally so it’s natural.
Des asked if I was planning to release my Webmentions Directory as a plugin rather than a page template.
I hadn’t considered it but he got me thinking.
I wondered about the best way to do it and came up with creating a shortcode that can be entered on any post or page, and also in a template with the
There are times when I feel like a bit of an idiot. This is one of those times!
As you will no doubt recall, I was trying to separate out the plugin actions into various included files. The relevant code triggered correctly when posting via the REST API (I.e. from Workflow) but the action that should be run when posting natively failed.
What started as a quick update to split the plugin into parts (so that it wasn’t all one monolithic file) became quite a major one.
My original plan was to move both hooks for updating the post content to separate included files – it hasn’t quite gone according to plan.
After getting the meta box working I realised that the code hooked into
save_post wasn’t being triggered when posting via the Workflow app.
The app is probably using the WordPress REST API to create the post which doesn’t behave in the same way as native posting and bypasses the hook.
Numerous tutorials exist for adding and using meta boxes; some manage to make it seem like a dark art by rushing through too much in one go without explaining exactly what is going on.
After getting the directory page to display all replies, I thought:
“What if when a comment is received we immediately perform the linkbacks type check and, if true, rewrite the comment_type value back to the comments table in the database?”
When creating my webmentions author directory I originally wanted to avoid any reliance on the #indieweb Semantic Linkbacks plugin, as not everyone will be using it, and I wanted to keep things fairly self-contained.
A big part of learning by doing is getting things wrong. You’re never going to get it right first time, every time and just have to accept that.
It’s what prompted me to write that I needed a second WordPress installation to test against rather than keep breaking the blog.
I added a filter to functions.php to truncate posts in the RSS feed of type ‘status’ that were longer than 280 characters, then insert a permalink at the end, so that they would play nicer with Micro.blog.
I previously detailed a method of automatically replacing blank post titles so that I didn’t have multiple items (posted from the Micro.blog app) listed as ‘(no title)’ in the WordPress back end.
The security of any code should be of the utmost importance but, if creating a plugin that might be distributed to other people’s sites, it should be paramount.
It’s one thing messing up your own site but another entirely breaking someone else’s when they’ve put their trust in what you’ve written.
I mentioned recently that I need to learn to code properly but it’s more a case of learning the environment in which I’m working.
When I used to do a bit of VBA (Visual Basic for Applications) in a previous role the VB side of it wasn’t an issue, the more complicated part was the A, the applications with their object models, and how you get them to do what you need.
In this post I will outline why I wanted to self-host a microblog, what I felt was required to do it properly, how I accomplished the various steps and, where appropriate, explain why I made some of the decisions I did.