Indigenous

I have been briefly testing Indigenous by Eddie Hinkle, a native micropub client for iOS, so you may have seen a couple of rogue 'likes' appear in the RSS feed recently.

While I currently use Workflow to post likes and replies from my phone there is a distinct possibility that Apple will eventually remove it from the App Store should they add some form of automation to future versions of iOS.

I, therefore, wanted to explore alternatives and this meant installing Ryan Barrett’s plugin to provide a micropub endpoint thus allowing the app to post to the blog.

It's early days but Eddie has got a lot planned and the app - which works by way of a share extension, already seems pretty robust with the functionality it's got.

I don't use the indieweb Post Kinds plugin for WordPress as it's never played nicely with my theme so I do things manually with my own plugin.

Consequently, I don't have post types such as like, reply, bookmark and RSVP - such interactions are published as status posts on the blog and include the relevant microformats2 markup.

This difference lead to the rogue likes mentioned above; they were published as standard posts so didn’t display as they normally would.

I needed to find a way for the two to work together so made a few changes.

The micropub plugin adds a hook after_micropub so I used this to change the post format of the latest post to ‘status’:

function micropub_format($post){
  $args = array(
    'numberposts' => '1',
  );
  $recent_posts = wp_get_recent_posts( $args );
  foreach( $recent_posts as $recent );
    $post_id = $recent['ID'];
    set_post_format( $post_id, 'status');
  endforeach;
}

add_action('after_micropub','micropub_format',1,2);

Next, to better match my own implementation, I have edited the plugin to display the page title in the post rather than the link (this uses the same method as my plugin) and alter the styling.

I currently have all posts submitted via the micropub endpoint published as drafts, so you likely won’t see any posted this way for now, but it’s fun to explore this as an alternative.

I look forward to watching Eddie’s progress.

Indigenous

Learning from the pastComments

There was a quick conversation on micro.blog about RSS triggered by a post from Jason Dettbarn which, in turn, was in response to David Sparks' "The case for RSS."

The upshot was that Google Reader was both the standard bearer and pall bearer for RSS at the same time.

James mentioned the ability of large companies to usurp tech like Google did with RSS and asked could it happen again with the #indieweb?

As I’ve written before, webmentions are the glue that binds the indieweb together, connecting sites from across the web by way of comments, likes, replies etc. They are detailed in a W3C recommendation well on its way to becoming a full, recognised standard - but then so was RSS.

Google cornered the RSS market and Reader became synonymous with RSS; everyone designed their feeds to best fit it, just as everyone tweaks their SEO to please Google search largely ignoring other search engines.

But Google Reader demanded certain things. Every post needed a title, for example, and the rest of the RSS ecosystem followed. It became the de facto standard for RSS, effectively pushing everyone else out.

The rise in popularity of social media as a news source meant many were already declaring that RSS was done but Reader's closure sounded the death knell and left a massive vacuum when Google decided to concentrate on Google Plus.

That synonymity between service and standard meant the closure of one symbolised the demise of the other but standards only "die" when they are superseded by something else, something better. While using social streams as news delivery mechanisms certainly became de rigueur, and the real time nature of Twitter is admittedly unsurpassed, this cannot be seen as sufficiently better to kill off a standard.

So, what of the indieweb and webmentions?

I previously argued that wider indieweb adoption would probably happen by stealth rather than being actively sought out by average users.

"What if, for example, Automattic (the company behind WordPress) suddenly decided that all standard WordPress.com themes were going to include microformats2 markup and support webmentions? You've instantly got millions of people with an indieweb presence who haven't got a clue what it is or how it works, just that things are a little different."

The WordPress community currently seems reluctant to entertain the idea of indieweb integration but what would happen if such a major player did enter the arena and started to impose its own requirements just as Google did with RSS?

The sudden injection of millions of indieweb properties would likely cause a further rush of adoption as others seek to implement a technology which they feel would generate exposure and engagement.

Such adoption, however, would not be against the recognised standard but in line with the custom requirements imposed above to (selfishly) ensure maximum compatibility rather than compliance.

James' fear of a big tech company usurping an open platform could be realised and this custom implementation may become synonymous with the technology itself.

To take this to its logical conclusion, what would happen if after a few years the major player suddenly decided to ditch indieweb technologies in favour of the next big thing?

Where would that leave everyone?

Those who relied directly on the platform dropping support would obviously be affected until an alternative became available. In the case of something like WordPress this would obviously be via plugins.

But, the advantage this has over the RSS issue, even with a major player dropping support, is the very nature of the indieweb itself.

When Google Reader closed people had to actively seek an alternative in order to continue consuming their RSS feeds. This pushed many towards simply using their social streams - they couldn’t be bothered to find an equivalent service and re-add all their feeds.

No such need would exist with something like webmentions. People may not be able to immediately interact with as many properties but things wouldn’t stop working for those not hosted on the major player’s platform.

Sites interact directly with each other without the need for any central agency. If everyone had decided to adopt a custom implementation it would still work between all those sites that used it.

The very fact the technology would have been deployed across many different platforms means it couldn’t contain any showstopping proprietary requirements even if it did not adhere strictly to the original standard.

The overall impact would be significantly reduced.

Learning from the past

Doing things properly

While quickly discussing an issue (where native comments from others were posted as from me on micro.blog) Aaron Parecki pointed out on the #indieweb slack that the microformats markup was incomplete in that the comments were missing h-cards.

The h-card gives machine readable information about the author of an on page element so it was wondered if this was the cause of the issue.

Manton has confirmed it's not but that doesn't mean I shouldn't fix things.

So, hopefully, I’ve made some changes to the theme that resolve this and correctly identify the author (name and URL) for each comment, although I did have to force every comment to have the class h-as-reply to ensure child comments (replies to replies) are distinguished from their parents.

To ensure correct parsing I also had to add a filter to the comment_text() function so that the comment body was marked up with the e-content class:
 

function add_class_comment_text($content) 
    return "<div class='e-content'>" . $content . "</div>";
}
add_filter('commenttext', 'add_class_comment_text');
Doing things properly

More on comments, platforms and the indiewebComments

Colin Devroe wrote a thorough and thought-provoking response to my most recent musings on replies and comments. I would urge you to check it out.

He makes some very interesting and compelling points while outlining his particular answer to the question about comments.

One such point is that he doesn't like micro.blog becoming a comment platform that every reply has to be sent or received via, otherwise it's akin to a silo and you might as well just use Twitter.

It's an interesting angle.

I've likened it to a comment platform myself but one that's not like a social silo but a feed reader with an inbuilt two-way communication system.

If all you could do was list and reply to posts from blogs hosted with the service then it would, indeed, be considered a silo. Being able to add any RSS or JSON feed to your account, however, opens it up but Colin's objection is still well articulated and I can certainly see his point.

Forcing people to interact via only one avenue is bad for conversation and bad for the web.

I'm personally guilty of limiting my reader's options (although I am reconsidering this) but, if you are using micro.blog as a comment platform it means that your site accepts webmentions which can obviously originate from anywhere able to send them.

It's a shame this isn't more widespread.

But what really got me thinking was Colin's observation:

"I do have a M.b account but I’m beginning to wonder if I need one as I have my own fully functional weblog."

That's both perfect and prophetic.

Ideally, this is the open web's goal: for people not to need something like micro.blog; for connective technologies to be sufficiently simple and widespread that ideas can be posted and conversations had between any site regardless of platform or hosting.

I think something like micro.blog is a stepping stone, a proof of concept, if you will. Because the web is so dominated by platforms and silos we need it (or, rather, a familiar platform-style service) to serve as an effective illustration of how blogs in different locations can be truly connected and interact directly with each other via #indieweb style technologies.

Whether that is the way it will ultimately pan out remains to be seen but, as things stand, it is an elegant solution as long as you're willing to work within its limits.

It's not ideal but, if it gets people interested in blogging again and plants the seeds of a more connected open web, I'm all for it.

More on comments, platforms and the indieweb

The sands are shiftingComments

Blogging is a particularly singular and personal act despite your posts being publicly available - the unedited voice of a person and all that.

Reading and commenting on blog posts, however, is an inherently social act carried out on a range of scales. Unfortunately, over the years, we have slipped towards the lower end of that range.

Recent posts, discussion and approaches, however, are converging to give me renewed optimism that blogging can regain some of its status and power.

Firstly, micro.blog is a force for blogging connectedness, as I keep saying. Next, there is Richard MacManus' intention to reinvigorate a blogging community. And then Dave Winer's idea to make blogging more like Facebook (but not a silo) and his first efforts with the technology behind "Instant Dave" look interesting.

Then, of course, there is the indieweb movement which, as a whole, is built around the idea of interconnected personal sites.

It feels that there is a concerted effort not to usurp the social networks (they are ideal for certain things which is why they're so popular) but to ensure that blog posts are in the places most suited.

And not just that: to also get bloggers discovering and talking to each other again; to build a genuine dialogue rather than be isolated voices shouting into the abyss.

It may seem like I am repeating myself (and you'd probably be right) but this is something I think deserves repeating.

We have reached a point where a small number of outlets control the bulk of the web's communication, outlets that initially seem ideally suited to the task but operate according to their own rules and agendas. Outlets that control how information is presented, filtered and potentially removed.

Without any real accountability.

Medium tried to buck the trend attracting many influential people but their approach doesn't look sustainable, jumping between business models with no clear path.

What Medium did achieve, however, was to bring blogging back from the wilderness and reintroduce it (as an important means of expression) to the online conversation, raising awareness within the "social generation" who never knew life before Facebook and Twitter.

Never mind SnapChat and the multitude of messaging apps.

It may have become disparagingly known as the place to rant about losing/quit your job but the ease with which celebrities, CEOs and presidents could share extended thoughts with the world cannot be understated. In fact, that ease needs to be replicated by other tools allowing casual or infrequent bloggers to publish as often or as little as they like without a heavy investment or learning curve.

Just in a better environment.

Those looking to do something about it may be coming from different directions with different approaches but their goals are as good as the same.

The sands are shifting and I hope we can find a true oasis in the desert.

The sands are shifting

Turning back the clockComments

In a kind of "end of chapter 1" post over at AltPlatform, Richard McManus has been able to articulate something that I've been going in circles around but never quite settling on.

"For me, blogging is primarily about connecting to other people around ideas and shared passions."

He goes on to say that he wanted to find a blogging community again.

I've mentioned the way blogging used to be a number of times over the past few months, the way conversations went back and forth between different blogs and bloggers but I didn't invoke the 'c' word: community!

I'm not exactly sure that's what it really is but I know where he's coming from and, in lieu of something better, it's as good a description as any.

Noise

He also points out that the indieweb principle of ownership can contribute to the problem of noise. If everything we do is posted on our own sites and syndicated out it can be a lot of information:

"I certainly don’t want a bunch of other peoples’ checkins clogging up my feed reader."

It's not, however, ownership that's the issue but the management of that which we own.

As I have written:

"Just as not everything needs to be pulled back to your own site does it all need to be pushed out and cross-posted as well?"

Taking possession of your tweets or check-ins or images is great, there's not a problem with that, but specific data types have their intended places; tweets belong on Twitter, check-ins on Swarm, etc. If one data type is cross-posted to a non-native destination it starts to lose its value and diminish the value of that destination.

This applies equally to our sites and feeds.

Own your data, yes, absolutely, but manage it properly and allow your visitors or subscribers to also manage it according to their needs. They should not have to struggle through a quagmire of tweets and check-ins just to reach a blog post.

Back to blogging

As I have made apparent in previous posts, and wholeheartedly agree with Richard, webmentions are the poster child of indieweb technology and are one aspect which can join myriad blogs into this quasi community he seeks.

His post title spells it out, he is "searching for an Open Web blogging model" but:

"the question is how to create a community around these Open Web developments, or at least feel like you’re contributing to the conversation, via blogging."

A set of tools is already there. I'd argue the real question is how to encourage its use when the social behemoths already make it so easy.

And that's why I like micro.blog but there's still such a long way to go.

We can talk all we want about ownership. We can preach about the untrustworthiness and potential demise of social networks taking our data with them to the grave, but billions of people demonstrate on a daily basis that this really isn't an issue for them.

It's like trying to turn back the clock but the world has moved on. Even a lot of old school, staunch bloggers have moved on.

Building that community is going to be hard.

Hard, but not impossible. I think it's a question of scale and expectations.

The old vs the new

We have an ideal way to link things together but support for webmentions is still very limited. Not only do we need to encourage more blogging but also encourage those bloggers to use a consistent means of communicating, whether that's webmentions or something else not created yet.

And we still need better means of discovery.

You can't feel like you're contributing to the conversation if no one knows who or where you are.

Blogrolls had a brief resurgence but that's all gone quiet. A number of people jokingly mentioned resurrecting webrings but are these stalwarts of the old web suited to the new?

Perhaps we need an entirely new model of discovery and consumption, one more suited to the modern, social web.

What form that takes, however, is beyond me.

Turning back the clock

The beauty of micro.blogComments

In the latest episode of the Core Int podcast Manton re-emphasised that micro.blog is a blogging platform rather than a social network.

It's flexibility, however, means it can be different things to different people.

For me, rather than being a blogging platform, it has become an extension of my blog almost like a comment engine. The webmention support means that the conversations around my posts get fed straight back.

Because I don't take advantage of micro.blog's hosting it is definitely more a social environment for me and, because of this, I see how it starts to achieve one of Manton's goals: to act as a layer tying the blogosphere together.

If we go back to Tantek's reasoning for why social networks took over (a combined reading and posting interface) we also see the true depths of the service.

It looks like a basic Twitter-style network but that is only scratching the surface; its simplicity belies its power.

At its core is a feed reader presenting posts in the usual reverse chronological order but, although it feels like you are following users on a social network you are actually subscribing to their blogs - and not just microblogs depending on what feeds they include.

The social element allows us to reply to posts in situ but these aren't simply replies, they are also comments which, as mentioned above, can automatically co-exist on externally hosted blogs.

And then you can use exactly the same interface to post to your own blog, be it natively hosted by micro.blog (a massive part of the offering) or external, or any other tool that supports the APIs used.

While a degree of web plumbing can be used to back feed posts from social networks to our own sites, micro.blog does all this natively - and that is the beauty of it.

There is a lot going on behind the deceptively simple façade.

The beauty of micro.blog

Well, yesterday's post caused a bit of discussion (and, frankly, that was always the intention) but it was largely denied that there was any kind of existential crisis within the indieweb community.

I may have used the term for a bit of dramatic effect but I believe the point still stands.

I'm not alone.

The main argument against my point seemed to be that the different generations of indieweb users are well understood and documented.

The page states the division into generations allows advocates to "build tools for and create language to encourage growth" but this is a primary issue: the current tools are not simple enough and the language used is definitely confusing to most non-developers.

We may be seeing moves into Generation 2 with bloggers adding indieweb functionality to their sites but I would argue, due to the amount of manual intervention required to achieve a satisfactory result, they are still borderline Generation 1.

There is talk about trying to get certain indieweb technologies into WordPress core or the Jetpack plugin and this would be fantastic; it would be the start of "adoption by stealth" that I wrote about before.

Were this to happen we could effectively be skipping Generation 2 and going straight to Generation 3: those with personal domains managed by third parties, e.g. wordpress.com.

But, as I also wrote, were this to happen it would probably not be couched in indieweb terms and the responsibility for creating the language to encourage growth would be passed on.

Status

The confusion about the indiewebComments

Alex Kearney wrote about her first two years of indieweb. It makes for a very interesting read.

One thing that really came through was the confusion people feel when looking to "join the #indieweb" - it illustrates a common misconception that sites have to implement every bit of technology going.

Dave Winer said in a blog post that the indieweb community "chose such an inclusive name, but have an exclusive approach" giving RSS as an example, arguing that this established web technology has been ignored.

He obviously has a vested interest because RSS is his baby; I also thought some of his initial comments about JSON Feed were particularly harsh.

Such a comment understandably hasn't gone down too well in some quarters and there is a sense of defensiveness. But there is also a move for the community to look at itself, especially the wiki, in order to identify why these confusions and misconceptions arise.

When new technology is introduced it threatens the status quo whether it intends to or not.

Incumbents can reject 'new' because the status quo is how they've always done things and see no reason to change.

Conversely, the inventors of 'new' will have done so because the status quo doesn't meet their needs or they feel there is a better way.

It's a tricky situation but doesn't need to be either/or.

It's not all about the tech

At its core the indieweb has a set of principles such as owning your data, building tools for yourself and dogfooding them on your own site. The principles even state that user experience design is more important than protocols.

I wrote recently that the indieweb:

"promotes and relies on the open web but recognises that the closed web exists, plays a large part of people’s lives, and tries to integrate with it"

So much of what is discussed and developed as part of the movement relates not to the replacement of social networks and data silos but the integration with them whilst retaining ownership.

That doesn't sound very exclusive to me.

The problem, however, goes back to the perception that the indieweb is effectively insular because of the knowledge required to implement all the various technical elements. Plugins can only take you so far.

The community wrestles with the self-realised existential crisis that it is, currently, a developer community not a user community.

What to implement?

Look back at the principles above.

Okay, they talk about building tools but put the emphasis on the experience before protocols.

For me the indieweb is an idea, a way of doing things rather than the specific technology used to achieve it.

When examining how to establish the number of indieweb properties that existed it was suggested you could:

"consider a page part of the IndieWeb if it has a microformats2 class or advertizes a webmention or micropub endpoint."

This is looking at it from a technical perspective - an obvious indication that the page or site has implemented some form of identifiable indieweb technology. Not all are required, just one.

Yet there is still a problem, and that is the apparent insistence on the implementation of specific technologies as implied by the guides and documentation.

So much for design over protocols.

It is entirely possible for a site to be considered part of the indieweb and conform to its principles without any of these elements being present.

Stepping back

Just as the likes of Winer can seem too close to an established technology so proponents of a new way can be too focused.

Perhaps this is because many of the indieweb developers have been involved for a number of years and, psychologically, moved beyond the initial stages. They can see the destination and are driving full speed to get there.

Perhaps the principles become obscured by the need to get the tools ready for the next generation but they haven't even begun the journey so see completely different scenery.

In the drive to create systems that are simple enough for anyone to use (and we are nowhere near that stage) the how has become more important than the why.

Fortunately, the community already acknowledges the need to step back and view things from a user's perspective rather than that of a developer.

The confusion about the indieweb

Sonant Thoughts – Episode 28: Pressing The CaseComments


The widespread adoption of #indieweb technologies will only happen if it is made simple, maybe even simpler than the alternatives.

This will likely only happen by stealth, by introducing it as core functionality rather than something that needs to be manually configured.

Links:

cleverdevil

Indieweb adoption - how does a new way spread?

"Unless things are ridiculously simple to implement most will not entertain them..."


Subscribe: via RSS or iTunes

Sonant Thoughts

Sonant Thoughts – Episode 28: Pressing The Case

Getting plugged in – epilogue

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.

Where does the time go?

There might be some tidying up I could do to the code but, on the whole, I think it's achieved exactly what I was after and reached its natural conclusion.

That's not to say there won't be future updates if I think of new functionality, find problems or want to do things differently. But, for now, I think it's safe to put down a marker and bump it to a 1.0 release.

Although the plugin is reasonably simple I've learnt some good techniques which can be applied again and again while also learning from mistakes that, hopefully, won't be repeated.

It's been fun to go through the process of documenting this publicly, with nowhere to hide, and am glad I could contribute something to those who may use it.

Getting plugged in – epilogue

Whither microblogging?

I never actually considered Twitter to be a microblogging platform, at least not for my own purposes.

At its most basic level your Twitter profile fits that brief (a reverse chronological list of short posts from a single author) but the lack of true ownership and the overarching social aspect meant I could never really see it as such.

It just never felt like a blog, even a micro one.

A new way

Micro.blog seeks to usher in a new era for microblogging but if there wasn't the self-hosted option I feel it would suffer in the same way. If everything was just hosted on the platform then you would essentially have just another Twitter clone.

But it's not, the idea behind it is wider reaching. However, that still doesn't mean there aren't issues.

I think Micro.blog's one problem is that it has multiple use cases and, because of this, some don't really understand exactly what it is.

The description on its About page includes:

"Micro.blog shows recent posts from sites and people you are following"

Fair enough, it's an aggregator, but we also have:

"Micro.blog is a new social network for independent microblogs"

Two use cases within the first couple of lines but they are not incompatible - remember FriendFeed? Later, the description expands and clarifies this position:

"Instead of trying to be a full social network, Micro.blog is a thin layer that glues the open web together, making it more useful. Micro.blog adds discovery and conversations on top of previously unconnected blog posts."

Now we're getting somewhere; this is where it starts to get interesting and is what really appeals to me on a visceral level.

But people have a hard time understanding "layers" - we only need to go back to Google+ to see this. It was never meant to be just a social network, it was supposed to be the glue that bound all of your Google activity together.

Just like Google+ some can only see Micro.blog as a social network, they don't understand why it is needed, why they should participate or the relationship with content on your own site. As I mentioned yesterday, many just don't see the need.

Add hosted microblogging to the mix and some are confused about Micro.blog's purpose. Surely, if microblogs are hosted then they are not independent as mentioned above.

Connected

Whether you get the purpose of Micro.blog or not, blogs themselves are more valuable, more powerful when they are connected, when there is an exchange of ideas. I go on about having conversations via blog posts as I feel this is an important part of the web - how it used to be and how it should be again.

But Micro.blog can't do this alone which is why it sits squarely atop the principles of the #indieweb and why so much emphasis is placed on webmentions.

The hope is that as Micro.blog grows, the proliferation of webmentions will drive the adoption of ways to consume them across different blogging platforms, in turn driving wider adoption of the indieweb as a whole.

As I have also written, I hope that microblogging may spawn a resurgence in longer form writing - especially on people's own sites. If a mechanism exists to reduce the isolation of blogging then more may be tempted to share their thoughts in more depth.

The indieweb provides such a mechanism but the technology and terminology are beyond many. Micro.blog has the advantage of using a familiar trope (the social network) to introduce this mechanism and its concepts in a more accessible way.

It just needs to better explain what it is and how its different use cases relate.

It just needs to better explain why.

Whither microblogging?

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 do_shortcode() function.

An initial version is in place on my site and seems to be working fine. It relies on the indieweb Semantic Linkbacks plugin being installed and domain exclusions can only be added by modifying the plugin code - for now.

I will look to add a settings page for the easy addition of exclusions. For example, I have my own domain and micro.blog currently excluded from the list.

As always, you can find it on GitHub.

Status

What’s in a name?

I have been wondering recently if the name of this blog, Social Thoughts, is still relevant or valid.

When talking about 'social' in the context of the web we are normally referring to social networks - the mainstream players like Facebook, Twitter, Instagram - but I haven't been writing about them very much lately.

But then I remind myself that being social on the web is far more than engaging on these networks or silos.

Being social online predates the web, just go back to bulletin boards where people came together in one place because of a mutual interest or purpose, communicating and sharing over impossibly slow dial-up connections.

Then we had forums and chat providing a multitude of ways for people to connect. They were actually the social networks of their day - predominantly enclosed "spaces" with specific rules and access requirements.

And then came blogging.

Eli took my framing of the subject to be that "the indieweb is more social network-y than the big-name social networks because those are each self contained" - and outside them the network is more, perhaps, genuine. Maybe he's right.

Maybe it's just that the openness grants us certain affordances that the more self-contained networks never could.

But what of social thoughts?

Originally this was just meant to mean my thoughts on social - simple and clean. Over time, however, it has taken on a new dimension.

Our thoughts are our most private of things; in internet parlance they are like the posts of a single member in their own silo - inaccessible to others.

A lot of them we wouldn't want to share, and rightly so, but it's no fun only playing in your own sandbox, and we are inherently social animals. We want some of our thoughts and ideas out there, we want them exposed to an audience.

And that's where social comes in.

Just look at the etymology of the word: social is derived from the Latin socialis and socius meaning ally, friend, companion. By sharing our thoughts we are seeking discourse with our intellectual allies, those with similar beliefs and ideals, those who can appreciate or build on them.

We seek to become part of something, whether as the seed or the gardener, looking to grow our thoughts and ideas into something useful, meaningful.

So, while I may not frequently write about, or now even engage on, social networks I am being inherently and deliberately social.

The name still applies, albeit in a different way.

What’s in a name?

Getting plugged in – part 6: includes

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.

I couldn't work out why.

So, I started disabling the safety checks to see if I could find out why it wasn't working. I soon discovered that it was the nonce check that was failing.

And then it dawned on me...

I had copied the code directly from the main plugin file to an include but not altered the condition for the nonce check.

Why did this matter?

Well, the original condition was basename( __FILE__ ) - used when you want to check that the action is being triggered within the same file. Quite obviously it now wasn't, so the check failed and the code never ran.

Changing the condition to a manually entered string meant the nonce verification would now pass and the code be triggered.

(At least we know that nonce verification works.)

I have now separated all functions into includes called from the main plugin file and everything appears to be working nicely.

I have, therefore, bumped the plugin version to 0.9.0 and called it a release candidate. Barring any glitches or obvious problems this will be the final code.

As always, the latest version is available in the GitHub repository.

Getting plugged in – part 6: includes

Getting plugged in – part 5: settings

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.

The hook for wp_insert_post_data (used when posting via Workflow) has worked fine. When the save_post hook and function were moved to a separate file, however, I couldn't get it to trigger.

I have had to move it back into the main plugin file until I find a solution but this setback gave me an excuse to look at adding a settings page and adding the code for that to an include instead.

As when creating the meta box, this was very much a case of doing it in stages, ensuring each worked before moving on.

Settings page

First up we need to create an admin menu entry using the admin_menu hook and add_menu_page() function:

add_action('admin_menu', 'landr_menu');

function landr_menu() {
    add_menu_page('Likes and Replies Settings', 'Likes and Replies', 'administrator', 'landr-settings', 'landr_settings_page', 'dashicons-admin-generic', 3 );
}

The parameters for the function are as follows:

  • the settings page title (in the header title tag)
  • the text for the menu item
  • who can see the menu item (capability)
  • the URL slug for the page
  • the callback function used to populate the page
  • the menu item icon
  • the position in the menu (if not entered it will be at the bottom)

That's all you need to create a settings page, it'll be empty but it's surprising how simple it is to create. Now we just need to add to it.

Form and options

We use the callback function mentioned above to populate the settings page - whatever you include within the function gets display. Essentially you are just building a HTML form but with a few special features.

I wanted to have the option to change the text used by the plugin to precede the like and reply links so that's what the form here will set.

The form fields need to be identified so their values can be saved so we first have to make WordPress aware of the options we are going to be saving to the database. They must be contained in a settings group which we can think of as like a HTML fieldset.

function landr_settings() {
    register_setting( 'landr-settings-group', 'like_text' );
    register_setting( 'landr-settings-group', 'reply_text' );
}

The form itself is simple and pretty standard but should include at least the below:

  • the post method points to WordPress' built in options.php for saving any settings
  • calling the settings group for the form using settings_fields() - it must match the group registered above
  • the fields will be named the same as the registered settings.
  • the standard WordPress submit_button();

Registering the settings we intend to use, calling the settings group and naming the fields correctly means that WordPress takes care of everything for us. Using options.php in the post method does exactly as you would imagine: saves the settings to the options table in the database.

Using the values

We use the saved settings in a couple of ways: firstly, the form itself needs to show the current values when loaded, and the code to update the post needs to pull them in.

Luckily, reading the values is simple because of where they are stored - we just use the get_option() function with the setting name as a parameter. Then, just to be on the safe side, we escape the values to remove any invalid characters:

esc_attr( get_option('reply_text') );

We just echo this wherever the option is needed.

Defaults, activation and deactivation

Whenever options are being written to the database it is good practice to remove them if the plugin is deactivated or uninstalled - we don't want to leave unnecessary data lying around.

We also need to set some defaults in place when the plugin is activated. Yep, you guessed it, we're using hooks again:

register_activation_hook( __FILE__, 'landr_activate' );
register_deactivation_hook(__FILE__, 'landr_deactivate');

function landr_activate() {
    add_option('like_text', 'Liked:');
    add_option('reply_text', 'In reply to:');
}

function landr_deactivate() {
    delete_option('like_text');
    delete_option('reply_text');
}

__FILE__ is used in the hooks because they are included in the main plugin file.

And that's it, we're done.

I will try to get the save_post hook working from an include in a future revision but, for now, the updates have been pushed to the GitHub repository.

Getting plugged in – part 5: settings

Getting plugged in – part 4.5

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.

John Johnston suggested hooking into wp_insert_post_data instead for posts made in this way.

I didn't know anything about this method so had to do a bit of research but discovered that it was actually pretty simple to use.

The main caveat was that, as I needed to access the post ID to work with the meta data, I had to pass the second, optional parameter $postarr to my function or it wouldn't work.

add_filter( 'wp_insert_post_data', 'filter_post_data', '99', 2 );

function filter_post_data( $content, $postarr )

It was then largely a case of repurposing the same code from the save_post hook to build the updated post content and return it from the function:

$content['post_content'] = /* new content value here */;

return $content;

It seemed to be working when viewing the post preview but when going to edit the post draft in wp-admin only the original post content was showing.

And I couldn't work out why.

I broke the site a few (a lot) times trying to figure it out before, eventually, realising that the content displayed by the front end and the edit post page are actually saved in different places.

The post as seen by the reader takes its content from the post_content field but the edit post screen pulls its version from post_content_filtered - I had been updating the former but not the latter, hence the confusion.

With this accounted for everything works as planned either locally within WordPress or when posted from Workflow.

Thanks John.

Getting plugged in – part 4.5

Getting plugged in – part 4: meta boxes

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.

This isn't going to be a guide, more a detailing of the steps I have taken to get a meta box in place for adding the 'liked' and 'reply' custom fields on posts then converting those into #indieweb webmention links.

Display a simple meta box

This is the easy bit, and I actually mean easy.

WordPress provides the add_meta_boxes hook and add_meta_box() function to easily register a custom box. We first need to create a function which calls add_meta_box() then add that function as an action to the add_meta_boxes hook:

function landr_custom_meta() {
    add_meta_box( 'landr_meta', 'Like and Replies', 'landr_meta_callback', 'post' );
}

add_action( 'add_meta_boxes', 'landr_custom_meta' );

The add_meta_box() function needs four parameters although more can be used to control where the meta box sits on the page, these are: ID, the box title, a callback function which actually does the work, and the type of post we want it to be used with.

Just to prove everything is set up properly a callback function can be created:

function landr_meta_callback() {
    echo 'Likes and replies go here.';
}

And, just like that we have a meta box.

It doesn't do anything yet, but it was easy to create. Now comes the fun stuff.

Adding fields and saving values

Getting the required fields in is just a case of adding some standard HTML (so I won't go in to that here) ensuring that the fields are named properly so they can be referenced later.

With the fields added we need to be able to write their values to the database if they have been populated. Another function coming up added as an action to the save_post hook.

As we saw before, security is paramount when dealing with WordPress plugins. Because we are dealing with something that can write to the WordPress database we need to ensure that this is handled securely.

There are two steps to take: firstly, adding a nonce (number used once) field to the meta box which will prevent improper access, and double-checking that the person trying to save the data is allowed to do so:

//create nonce

wp_nonce_field( basename( <strong>FILE</strong> ), 'landr_nonce' );

//check if nonce exists and is verified

if ( ! isset( $_POST[ 'landr_nonce'] ) ) {
    return;
}

if ( ! wp_verify_nonce( $_POST['landr_nonce'], basename( <strong>FILE</strong> ) ) ) {
    return;
}

//check permission to edit post

if ( ! current_user_can( 'edit_post', $post_id ) ) {
    return;
}

The 'liked' or 'reply' values can then be written to the postmeta table using add_post_meta() ready to be converted into webmention links.

if ( isset( $_POST['liked-url'] ) ) {
    $liked_url = sanitize_text_field( $_POST['liked-url'] );
    add_post_meta( $post_id, 'Liked', $liked_url );
}

if ( isset( $_POST['reply-url'] ) ) {
    $reply_url = sanitize_text_field( $_POST['reply-url'] );
    add_post_meta( $post_id, 'Reply', $reply_url );
}

Webmentions

Previously, the plugin used the content_save_pre hook to add the webmention link to the start of the post content. With the new code linked to save_post it wasn't going to work as it fires after content_save_pre.

The original code to write the link was modified slightly and moved into the same function so everything is processed at the same time.

It needs some tidying up but the updated plugin can be viewed in the GitHub repository.

Getting plugged in – part 4: meta boxes

Sonant Thoughts – Episode 20: BrokenComments


The web is broken, at least in how it rewards content and creativity. The attention economy favours extremes in the name of views and ad impressions with social platforms accused of compounding the problem. But there is a growing backlash.

Links:

The social web, not social networks (untitled)


Subscribe: via RSS or iTunes

Sonant Thoughts

Sonant Thoughts – Episode 20: Broken