Spent part of the afternoon updating my production server from WordPress 4.8 to 4.9.8. Looks like some interesting tweaks they’ve been making to the system. Sadly it’s also time to rewrite a few segments of code to fix a few bits of infrastructure I rely on regularly.

was originally published on Chris Aldrich

Advertisements

An Indieweb Podcast: Episode 9 30 Days of Indieweb

An Indieweb Podcast: Episode 9 30 Days of Indieweb

If possible, click to play, otherwise your browser may be unable to play this audio file.
Running time: 0h 58m 33s | Download (18.9MB) | Subscribe by RSS | Huffduff

Summary: David is about to head off abroad for a month. We talk about what’s been happening recently and his plans for his upcoming sojourn.

Recorded: August 5, 2018

Shownotes

IndieWeb Camp NYC–September 28-29, 2018–RSVPs are open now

Micropub Plugin work for WordPress
It will include a Media endpoint
Code for integration with the WordPress REST API

rel=”alternate”
This sketch solution may be an end-around the issue of getting WordPress (or potentially other CMSes) Themes to be microformats 2 compatible, and allow a larger range of inter-compatibility for websites and communication.

Facebook API changes cause breakage of Brid.gy
Ditchbook, a micropub-based tool for exporting data from Facebook and importing into other services

Greg McVerry’s EDU522 course Digital Teaching and Learning Too (🎧 00:47:57)

An Indieweb Podcast: Episode 9 30 Days of Indieweb was originally published on Chris Aldrich

IndieWeb Summit 2018 Recap

IndieWeb Summit 2018 Recap

Last week was the 8th annual IndieWeb Summit held in Portland, Oregon. While IndieWeb Camps and Summits have traditionally been held on weekends during people’s free time, this one held in the middle of the week was a roaring success. With well over 50 people in attendance, this was almost certainly the largest attendance I’ve seen to date. I suspect since people who flew in for the event had really committed, the attendance on the second day was much higher than usual as well. It was great to see so many people hacking on their personal websites and tools to make their personal online experiences richer.

The year of the Indie Reader

Last year I wrote the post Feed Reader Revolution in response to an increasingly growing need I’ve seen in the social space for a new sort of functionality in feed readers. While there have been a few interesting attempts like Woodwind which have shown a proof-of-concept, not much work had been done until some initial work by Aaron Parecki and a session at last year’s IndieWeb Summit entitled Putting it all Together.

Over the past year I’ve been closely watching Aaron Parecki; Grant Richmond and Jonathan LaCour; Eddie Hinkle; and Kristof De Jaeger’s collective progress on the microsub specification as well as their respective projects Aperture/Monocle; Together; Indigenous/Indigenous for iOS; and Indigenous for Android. As a result in early May I was overjoyed to suggest a keynote session on readers and was stupefied this week as many of them have officially launched and are open to general registration as relatively solid beta web services.

I spent a few minutes in a session at the end of Tuesday and managed to log into Aperture and create an account (#16, though I suspect I may be one of the first to use it besides the initial group of five developers). I also managed to quickly and easily add a microsub endpoint to my website as well. Sadly I’ve got some tweaks to make to my own installation to properly log into any of the reader app front ends. Based on several of the demos I’ve seen over the past months, the functionality involved is not only impressive, but it’s a properly large step ahead of some of the basic user interface provided by the now-shuttered Woodwind.xyz service (though the code is still available for self-hosting.)

Several people have committed to make attempts at creating a microsub server including Jack Jamieson who has announced an attempt at creating one for WordPress after having recently built the Yarns reader for WordPress from scratch this past year. I suspect within the coming year we’ll see one or two additional servers as well as some additional reading front ends. In fact, Ryan Barrett spent the day on Wednesday hacking away at leveraging the News Blur API and leveraging it to make News Blur a front end for Aperture’s server functionality. I’m hoping others may do the same for other popular readers like Feedly or Inoreader to expand on the plurality of offerings. Increased competition for new reader offerings can only improve the entire space.

Even more reading related support

Just before the Summit, gRegor Morrill unveiled the beta version of his micropub client Indiebookclub.biz which allows one to log in with their own website and use it to post reading updates to their own website. For those who don’t yet support micropub, the service saves the data for eventual export. His work on it continued through the summit to continue to improve an already impressive product. It’s the fist micropub client of its kind amidst a growing field of websites (including WordPress and WithKnown which both have plugins) that offer reading post support. Micro.blog has recently updated its code to allow users of the platform the ability to post reads with indiebookclub.biz as well. As a result of this spurt of reading related support there’s now a draft proposal to add read-of and read-status support as new Microformats. Perhaps reads will be included in future updates of the post-type-discovery algorithm as well?

Given the growth of reading post support and a new micropub read client, I suspect it won’t take long before some of the new microsub-related readers begin supporting read post micropub functionality as well.

IndieAuth Servers

In addition to David Shanske’s recent valiant update to the IndieAuth plugin for WordPress, Manton Reece managed to finish up coding work to unveil another implementation of IndieAuth at the Summit. His version is for the micro.blog platform which is a significant addition to the community and will add several hundred additional users who will have broader access to a wide assortment of functionality as a result.

The Future

While work continues apace on a broad variety of fronts, I was happy to see that my proposal for a session on IndieAlgorithms was accepted (despite my leading another topic earlier in the day). It was well attended and sparked some interesting discussion about how individuals might also be able to exert greater control over what they’re presented to consume. With the rise of Indie feed readers this year, the ability to better control and filter one’s incoming content is going to take on a greater importance in the very near future. With an increasing number of readers to choose from, more people will hopefully be able to free themselves from the vagaries of the blackbox algorithms that drive content distribution and presentation in products like Facebook, Twitter, Instagram and others. Based on the architecture of servers like Aperture, perhaps we might be able to modify some of the microsub spec to allow more freedom and flexibility in what will assuredly be the next step in the evolution of the IndieWeb?

Diversity

While there are miles and miles to go before we sleep, I was happy to have seen a session on diversity pop up at the Summit. I hope we can all take the general topic to heart to be more inclusive and actively invite friends into our fold. Thanks to Jean for suggesting and guiding the conversation and everyone else for continuing it throughout the rest of the summit and beyond.

Other Highlights

Naturally, the above are just a few of the bigger highlights as I perceive them. I’m sure others will appear in the IndieNews feed or other blogposts about the summit. The IndieWeb is something subtly different to each person, so I hope everyone takes a moment to share (on your own sites naturally) what you got out of all the sessions and discussions. There was a tremendous amount of discussion, debate, and advancement of the state of the art of the continually growing IndieWeb. Fortunately almost all of it was captured in the IndieWeb chat, on Twitter, and on video available through either the IndieWeb wiki pages for the summit or directly from the IndieWeb YouTube channel.

I suspect David Shanske and I will have more to say in what is sure to be a recap episode in our next podcast.

Photos

Finally, below I’m including a bunch of photos I took over the course of my trip. I’m far from a professional photographer, but hopefully they’ll give a small representation of some of the fun we all had at camp.

Final Thanks

People

While I’m thinking about it, I wanted to take a moment to thank everyone who came to the summit. You all really made it a fantastic event!

I’d particularly like to thank Aaron Parecki, Tantek Çelik, gRegor Morrill, Marty McGuire, and David Shanske who did a lot of the organizing and volunteer work to help make the summit happen as well as to capture it so well for others to participate remotely or even view major portions of it after-the-fact. I would be remiss if I didn’t thank Martijn van der Ven for some herculean efforts on IRC/Chat in documenting things in real time as well as for some serious wiki gardening along the way. As always, there are a huge crew of others whose contributions large and small help to make up the rich fabric of the community and we wouldn’t be who we are without your help. Thank you all! (Or as I might say in chat: community++).

And finally, a special personal thanks to Greg McVerry for kindly letting me join him at the Hotel deLuxe for some late night discussions on the intersection of IndieWeb and Domain of One’s Own philosophies as they dovetail with the education sector.  With growing interest and a wealth of ideas in this area, I’m confident it’s going to be a rapidly growing one over the coming years.

Sponsors

I’d also like to take a moment to say thanks to all the sponsors who helped to make the event a success including Name.com, GoDaddy, Okta, Mozilla, DreamHost, and likely a few others who I’m missing at the moment.

I’d also like to thank the Eliot Center for letting us hosting the event at their fabulous facility.

IndieWeb Summit 2018 Recap was originally published on Chris Aldrich

An Outline for Using Hypothesis for Owning your Annotations and Highlights

I was taken with Ian O’Byrne’s righteous excitement in his video the other day over the realization that he could potentially own his online annotations using Hypothesis, that I thought I’d take a moment to outline a few methods I’ve used.

There are certainly variations of ways for attempting to own one’s own annotations using Hypothesis and syndicating them to one’s website (via a PESOS workflow), but I thought I’d outline the quickest version I’m aware of that requires little to no programming or code, but also allows some relatively pretty results. While some of the portions below are WordPress specific, there’s certainly no reason they couldn’t be implemented for other systems.

Saving individual annotations one at a time

Here’s an easy method for taking each individual annotation you create on Hypothesis and quickly porting it to your site:

Create an IFTTT.com recipe to port your Hypothesis RSS feed into WordPress posts. Generally chose an “If RSS, then WordPress” setup and use the following data to build the recipe:

  • Input feed: https://hypothes.is/stream.atom?user=username (change username to your user name)
  • Optional title: 📑 {{EntryTitle}}
  • Body: {{EntryContent}} from {{EntryUrl}} <br />{{EntryPublished}}
  • Categories: Highlight (use whatever categories you prefer, but be aware they’ll apply to all your future posts from this feed)
  • Tags: hypothes.is
  • Post status (optional): I set mine to “Draft” so I have the option to keep it privately or to publish it publicly at a later date.

Modify any of the above fields as necessary for your needs. IFTTT.com usually polls your feed every 10-15 minutes. You can usually pretty quickly take this data and turn it into your post kind of preference–suggestions include read, bookmark, like, favorite, or even reply. Add additional categories, tags, or other metadata as necessary for easier searching at a later time.

Here’s an example of one on my website that uses this method. I’ve obviously created a custom highlight post kind of my own for more specific presentation as well as microformats markup.

A highlight from Hypothesis posted on my own website using some customized code to create a “Highlight post” using the Post Kinds Plugin.

Aggregating lots of annotations on a single page

If you do a lot of annotations on Hypothesis and prefer to create a bookmark or read post that aggregates all of your annotations on a given post, the quickest way I’ve seen on WordPress to export your data is to use the Hypothesis Aggregator plugin [GitHub].

  • Create a tag “key” for a particular article by creating an acronym from the article title followed by the date and then the author’s initials. This will allow you to quickly conglomerate all the annotations for a particular article or web page. As an example for this article I’d use: OUHOAH062218CA. In addition to any other necessary tags, I’ll tag each of my annotations on the particular article with this somewhat random, yet specific key for which there are unlikely to be any other similar tags in my account.
  • Create a bookmark, read, reply or other post kind to which you’ll attach your annotations. I often use a bookmarklet for speed here.
  • Use the Hypothesis Aggregator’s short code for your tag and username to pull your annotations for the particular tag. It will look like this:
    [hypothesis user = 'username' tags = 'tagname']

    If you’re clever, you could include this shortcode in the body of your IFTTT recipe (if you’re using drafts) and simply change the tag name to the appropriate one to save half a step or need to remember the shortcode format each time.

If you’re worried that Hypothes.is may eventually shut down, the plugin quits working (leaving you with ugly short codes in your post) or all of the above, you can add the following steps as a quick work-around.

  • Input the shortcode as above, click on the “Preview” button in WordPress’s Publish meta box which will open a new window and let you view your post.
  • Copy the preview of the annotations you’d like to keep in your post and paste them over your shortcode in the Visual editor tab on your draft post. (This will maintain the simple HTML formatting tags, which you can also edit or supplement if you like.)
  • I also strip out the additional unnecessary data from Hypothesis Aggregator about the article it’s from as well as the line about who created the annotation which isn’t necessary as my post will implicitly have that data. Depending on how you make your post (i.e. not using the Post Kinds Plugin), you may want to keep it.

As Greg McVerry kindly points out, Jon Udell has created a simple web-tool for inputting a few bits of data about a set of annotations to export them variously in HTML, CSV, or JSON format. If you’re not a developer and don’t want to fuss with Hypothesis’ API, this is also a reasonably solid method of quickly exporting subsections of your annotations and cutting and pasting them onto your website. It does export a lot more data that one might want for their site and could require some additional clean up, particularly in HTML format.

Perhaps with some elbow grease and coding skill, sometime in the future, we’ll have a simple way to implement a POSSE workflow that will allow you to post your annotations to your own website and syndicate them to services like Hypothesis. In the erstwhile, hopefully this will help close a little of the data gap for those using their websites as their commonplace books or digital notebooks.

An Outline for Using Hypothesis for Owning your Annotations and Highlights was originally published on Chris Aldrich

Allowing arbitrary HTML in the Summary/Quote field in the Post Kinds Plugin

Reply contexts

One of my favorite parts of the Post Kinds plugin isn’t just that it provides me the flexibility to add a huge variety of post types to my website or the semantic HTML and microformats it provides to help my site dovetail into the IndieWeb. It’s that it allows me to quickly and easily provide very rich reply contexts to my posts so that I more easily know what I’ve bookmarked, liked, favorited, read, or replied to online. In some sense it helps guard against some of the problem of context collapse found in many social media sites on the internet. As my friend and foodie extraordinaire Jeremy Cherfas has said, “a reply without context is like an egg without salt.”

For a long time I had been wanting a bit more control of how the Post Kinds plugin presented some of the data it allows.1,2 After one inputs a URL, the plugin uses several methods to scrape the related web page and returns a lot of metadata about it including the title, a summary, the site name, tags, a featured image, publication date and time, the author and author’s website among others. The data returned depends on how the page is marked up and is generally based on available microformats or open graph protocol data when they’re provided.

The plugin has a setting to “Embed Sites into your Response” on its settings page, and this is generally okay, but it relies on sites to have some sort of oEmbed set up predefined. For bigger sites like YouTube and WordPress, this is generally alright, but it’s not always the case that any data is provided by the external site. Even in YouTube’s case you’ll only display the video with no other meta-data about it. As a result I leave it turned off.

Let’s take a quick look at what some of these default outputs for the reply context with a short comment underneath them look like.

This is the default  Post Kinds output for an automatically parsed YouTube video with the embed function off. While it’s a good start, it’s not necessarily inspiring or a good reminder of the content you watched. One could manually change or add some of the fields for additional data, but we would still be a bit limited.
This is what Post Kinds outputs for an automatically parsed YouTube video with the embed function turned on. It’s nice to have an embedded copy of the video, but where did it come from? What is it about? Why should we care? Is there any other metadata we can display?

With the embed option turned off the plugin will return a “Summary” of the parsed website page. This too is generally well supported in 90% of websites in my experience. But the data it returns is (smartly) filtered using wp_kses for security so that a malicious page couldn’t inject random html or code into your page. This means that useful functionality is often being stripped out of the “Summary/Quote” field in the reply context. I’d prefer to have the ability to have text with links, video, and audio to appear in-line in these contexts so that there’s a better representation of the actual post I’m reacting to.

The question then, is how can I make this happen?

In older versions of the plugin there was a setting for this feature, but it wasn’t well documented and most people didn’t know what the setting was or what it meant. For simpler UI and support it was ultimately stripped out although the raw code for it was left in. In fact, it’s literally the first short block of code within the plugin’s main code! It looks like this:

if ( ! defined( 'POST_KINDS_KSES' ) ) {
	define( 'POST_KINDS_KSES', false );
}

To enable the ability to manually add arbitrary html, links, audio, video, etc. you can go to your main administrative user interface in WordPress and go to Plugins >> Edit and then choose the Post Kinds option in the drop down selector in the top right hand corner and click select. Search for the code listed above (it should be right at the top, underneath the title and details for the plugin) and change the single word false to true. Next scroll down the page and click the Update File button.

Now you should be able to manually change any of the fields within the Response Properties metabox and they’d display in full HTML as you’d expect them to. (Caveat: because you’ve disabled a small layer of security, you should keep a close eye on what data appears in your “Summary/Quote” field and make sure you’re not allowing your site or your readers to be led astray or hacked. In my case, I’m almost always modifying it by hand, so it’s not a big issue. Your mileage may vary depending on what you’re posting.)

This is what Post Kinds outputs for a parsed YouTube video with the embed function off. We’ve gone in and manually tweaked the author name, URL, and photo and added manual HTML to render a sysnopsis with links and an in-line playable  iframed embed of the video. This is a much richer reply context! It doesn’t get much better than this. Thanks Post Kinds!!

Updates

But wait… What happens when I update the plugin? Won’t the update overwrite the change? Yes, you’re absolutely correct. You’ll have to remember to go back and make this change any time the plugin updates. To prevent this, you could instead modify your wp-config.php file in the root folder of your WordPress install. To do this add the following lines of code to the bottom of this file:

/** Sets up initial variable for the Post Kinds plugin to not filter the Summary/Quote field  */
if ( ! defined( 'POST_KINDS_KSES' ) ) 
	define(' POST_KIND_KSES', true );

Next save the file and upload it to your WordPress install. Now you should be all set.

References

1.
Aldrich C. Post Kinds Plugin for WordPress. BoffoSocko. https://boffosocko.com/2017/08/11/post-kinds-plugin-for-wordpress/. Published August 11, 2017. Accessed June 9, 2018.
2.
Aldrich C. Manually adding a new post kind to the Post Kinds Plugin for WordPress. BoffoSocko. https://boffosocko.com/2018/06/06/manually-adding-a-new-post-kind-to-the-post-kinds-plugin-for-wordpress/. Published June 7, 2018. Accessed June 9, 2018.

Allowing arbitrary HTML in the Summary/Quote field in the Post Kinds Plugin was originally published on Chris Aldrich