Using the Last Seen Function in Simple Location

One of the features in Simple Location that doesn’t get much notice is the Last Seen functionality.

Simple Location adds a section to your WordPress user profile called Last Reported Location. It allows you to set the last reported location for a given user.  It reports latitude, longitude, altitude, and whether or not the location is public, private, or protected.

In the Simple Location Settings, you can set this to update each time you publish a post if the location isn’t set as private. So it would reflect the last post you made.

This feature can be used in one of two ways. You can add the Last Seen Widget to your page and display the last place you were seen. Alternatively, this can work in reverse. You can set it so your posts will set post location from the last seen location of the author.

But, what use is that if the only way a to update the Last Seen setting is to set it from a post(creating an endless loop) or to set it manually? If you always want to always set a default location, this can be an option.

However, that doesn’t work for me. So, I built a way to update your location from an outside service.

First, you need an IndieAuth token. If you installed the IndieAuth plugin, you can get one manually under Users->Manage Token.

curl -i -H 'Authorization: Bearer FAKETOKEN' -d "latitude=30&longitude=-115&visibility=public" "https://www.example.com/wp-json/sloc_geo/1.0/user"

Here is an example of updating your location via a curl command line command. It figures out which user based on the user of the token you created.

The parameters currently used are latitude, longitude, altitude(will be automatically derived if not present), and visibility(public, private, protected).

If you are successful, it will return ‘Updated’ and automatically lookup the name of the location you are at.

So, what can you do with this feature? Keeping in mind the day, though I call today Tuesday…Let’s say hypothetically you are in the package delivery business and you want to share your location with the people who are eagerly awaiting your deliveries. You could use this to send your location from your phone to your website to keep the display updated.

Alternatively, if you don’t trust the browser on your computer to know where you are, you could rig up a shortcut on your phone to update the location so it would be accurate if you post, for example on Android with Tasker.

There is more that is needed to enhance this feature. On my list for future is Geofencing…the idea of zones inside which the location would either be set to private or display a generic ‘Home’ or ‘Work’ etc. I already have the code to calculate this, but haven’t figured out how the UI would look. This would allow much more granular controls than the global privacy default.

Simple Location Version 3.5.0 Released

Version 3.5.0 of my location plugin, Simple Location, is now out(forgot to push a fix and had to release 3.5.1 as well). Simple Location is, as time goes on, anything but Simple. It is all about location, including the weather at your location. It adds this to posts, and offers several simple widgets to show current weather and current location on the homescreen.

The new version completely redesigns the interface inside the post editor to work in both classic and Gutenberg. It doesn’t integrate with Gutenberg in any way. It relies on Gutenberg’s compatibility functionality. Because of that, the box with the Gutenberg settings is now in the sidebar, rather than below, and expands to show the various options.

The interfaces with weather APIs like DarkSky and OpenWeatherMap were reorganized to improve the quality of the return data. And all data will be stored going forward in international units. While I am a Fahrenheit and Feet user, most of the world isn’t. So everything will be converted on the fly for display for those of us in the imperial system, making it much less fragile. Flip a setting and it changes.

Simple Location uses the WordPress REST API, and there are new endpoints for frontend use. The geocoding endpoint now has an option to return the weather as part of the lookup instead of requiring a second request. New abilities to lookup by airport code are also built in, mostly for the current conditions widgets. This will be fully functional in a future version.

For those of you worried about hitting or being charged for API usage on commercial sites, I added a simple weather provider courtesy of the U.S. National Weather Service. This will only work with locations inside the United States. It finds the nearest NWS Weather Station to you and uses the current conditions from that location.

There is a new Weather Station widget, split from the other Weather Widget, which allows you to display from a specific station.

There are a lot of good features here, but there will be more in future. So try it out.

Parkeology Challenge November 2018

On Wednesday, November 28th, I participated in the Parkeology Challenge. It is a marathon of sorts where you try to ride every ride at Walt Disney World in a single day. That is 4 different parks, and 49 rides…although only 46 were in the challenge this week due long-term closures. You can only use things available to the average guest.

In order for the people who run Parkeology to certify the results, you have to provide a Twitter record of same. That was handled by one of my four teammates, but I kept a recording on my site of all of the locations I was in. This would be my timeline for the day. The pictures are backed up from the original challenge.

To see the individual posts, you can click here.

It was a day I can honestly say I will not soon forget.

Challengers Meetup at end of Night

Parkeology Challenge 2018 in Brief

To all the awesome teams that ran the @Parkeology today we offer a huge congratulations! It was freezing, rides broke down, hours were lost and you still crushed it! Thanks, we look forward to seeing you again soon!” via Twitter.

A few facts

  •  The Park Operating Hours for the Day Determines Difficulty. Less than 18 hours is considered Expert.
  • The last completion of the challenge was August 18th, though there have been many attempts since.
  • Over 39,000 steps
  • Over 17 miles of walking
  • The numbers above are based on my phone. My watch actually has a higher number.
  • There were 10 teams competing that day. Only one other team had 4 people on it.
  • The range of completed rides were 11-42. The other 4 person team got 42.
  • 6 Teams Completed the 3 Parks We Did. It seems like a lot of people were looking to complete on that day, which is a rarity.

 

Syndication Links 4.0.0 Released

Today, from my hotel room in Berlin, Germany, where I am preparing to attend Indiewebcamp Berlin, my first European Indiewebcamp, I released Syndication Links 4.0.0.

The major version number change is because in this version, Syndication Links takes on a new role. As promised previously, I’ve built new syndication code and added supported for Bridgy and Indienews, which both uses Webmentions to trigger a syndication action. This is disabled by default.

As my first live use outside of testing, I’m using the plugin to send this post to Indienews and Twitter(via Bridgy).

The new code adds the concept of a syndication provider, which, when registered, adds the provider as a syndication target for Micropub clients as well as adds it to the WordPress classic editor as a series of checkboxes, er postone for each service.

The Bridgy Publish plugin I announced deprecation on had additional options on a per post and a global level. While the global settings will be coming back in a future version, I likely will not bring back the per-post settings.

Instead, I’d like to add more intelligence behind these decisions, based on other properties of the post. A checkbox is all you should need. The same with auto-syndication. If you decide you want everything to go to Twitter or some site, it shouldn’t check the box…there shouldn’t be a box at all. It should just go, even if there are some more parameters to make that decision…type of post, etc.

So, you are either all in, or in on a per post basis.

I look forward to feedback. This is only the beginning. I hope to do what I did for displaying syndication links, and interface with existing plugins in addition to writing my own integrations.

Simple Location Version 3.4.0 Released

I released a new version of Simple Location this evening. I had to start this project, moving it up my list of things to do because Nominatim started blocking me. I used Nominatim for looking up addresses from coordinates.

Because of that, I completely rewrote the system that registers new location providers so I could more easily create new ones.

  • The Nominatim provider has been switched to now use the Nominatim API provided by MapQuest(Yes, they are still around).
  • You can now use Bing and Google to lookup addresses from coordinates
  • Bing, Google, and Mapquest will now fill in elevation/altitude data on posts if not supplied during lookup, based on their APIs for this.
  • Altitude will display if it is over 500 meters. So, right now, basically if I post on a plane.
  • Location visibility, which is a feature now built into at least one Micropub client, has been enhanced in here. It should work more reliably now.
  • Mapquest and HERE are new static map providers.
  • The conflict with the Jetpack plugin, which added location services in 2017 unknown to me, has been resolved.  If you activate this plugin, it unloads the conflicting Jetpack module.
  • If there is no address to display, it will now display the coordinates.
  • Dark Sky is now an alternate weather provider. I was going to add Weather Underground as well, but they apparently shut down their API.
  • When publishing using Micropub, if coordinates are provided, it automatically generates a display address if none is provided and stores the current weather conditions.
  • The default location visibility checkbox now offers any three of the visibility options… Private, Public, or Protected. Protected is show the display address but not the map or the coordinates.

What’s next for this plugin? Well, better logic around location visibility. Right now, if you do not set it, it goes to a global default.

So, I’d like to include geofencing. That would be a list of zones. Zones would be a location with a radius around it that if you are inside, it would automatically set to protected and/or replace the address with a generic one. For example, if you are within 50 meters of home, it would always use a pre-identified location of ‘Home’ and/or default to a city level description.

The plugin supports Location providers other than the browser. This means that the plugin could query a server to get the current location of the user.

However, there aren’t any I’ve implemented yet really. But this would allow me to query an API to get my location, which has a lot of potential in future, especially if I want to look up my historical location.

For example, I’ve let Google store some of my location history since March of 2013. There is no API I know of to poll the data, but you can export it. I would just have to find a place to import it to. 6 years, 50mb of data. If I had some way to load it up, query it by date and time, I would be able to add location to all posts and photos that didn’t have it, based on the location of my phone at the time the post was made.

I already have a program on my phone that sends my location periodically to my home automation system, but I’d have to try something different to store historical data. There are several options for this. I’m tempted to write something into WordPress, as I have a tendency to build things into my website. Not sure if there is an off the shelf project to suit my needs, though I’ve looked at Aaron Parecki’s Compass. I could build similar functionality into my site to accommodate this, but I think I need something that both my house and my website can query.

Either way, look to see me testing this on my upcoming trip to Indiewebcamp Berlin.

 

 

 

Version 2.0 of the Micropub Plugin Released

At the Indieweb Summit in June, someone said something to me that made me decide to embark on a major rewrite of the Micropub endpoint for WordPress.

For those of you not familiar with it, Micropub is a standard that allows for you to publish to a website.

The major work on this actually finished in August, but due to some bug issues, most of them in the accompanying IndieAuth plugin, that affected some of the testers, I held off on releasing the plugin till today. If there is anyone still experiencing issues, please open an issue on the Micropub plugin Github repository.

The core functionality of the plugin remains the same, as does much of the original code. So, what changed?

  • The plugin is no longer a single file. The code that handles the endpoint, the code that handles authorization, and the code that handles rendering are now separated.
  • The code no longer works outside of WordPress.
  • The original design didn’t log the user into WordPress. It determined which user was supposed to be represented and posted as them. If it couldn’t figure out what user was represented, it posted it anyway, which is no longer permitted.  The new version is much better integrated into the WordPress stack, which admittedly revealed some new login issues.
  • The Micropub endpoint is now implemented using the WordPress REST API functionality. Again, this means that it is implemented inside functionality built into WordPress for creating custom endpoints as opposed to the previous system, where a query variable bypassed the WordPress load and substituted a separate one. It also has the positive advantage of a pretty permalink for the endpoint(wp-json/micropub/1.0/endpoint).
  • Dozens of little bugfixes and checks to remove nagging error notices
  • Improved error handling
  • Fixes to better comply with the Micropub spec, which was finalized after the initial creation of this plugin
  • A nag for those who use the plugin on a site without encryption(http as opposed to https). It can be disabled if you want to live dangerously.

And only one major new feature. A media endpoint. A media endpoint handles uploading of media files and hands back a URL to the Micropub endpoint. This one uploads to the WordPress Media Library.

The Post Kinds update last week already ensured that Post Kinds will work well with the changes.

 

Thoughts About Assertion Workflows

This is a preliminary technical workflow proposal for assertions, which would be needed for badges, endorsements, and other ideas. It is based on thoughts that I had listening to the badges session at Indiewebcamp NYC 2018.

Scenario 1: Individual creates criteria and wants to assert that other individual has achieved said criteria. Example: Professor wants to certify students completed coursework.

  • Professor Posts Criteria for Each Achievement as a unique page (A).
  • Student completes assignment as a post (B).
  • Professor Posts Badge/Assertion/Endorsement post on their website as an h-review, with a p-item property to student’s URL (B). Would need a new or existing property to represent the relationship to the original assertion (A). Suggest u-assert and u-assert-of?j Can use u-in-reply-to possibly.

Scenario 2: Individual creates assertion post and solicits others to endorse that statement as factual.

  • Individual makes a post to their site(h-resume for references on a resume, not sure what to request endorsement of a statement? p-assert with a nested h-item?) and invites other individuals(using existing invitee property used for RSVPs?) to endorse or assert it. Criteria might be included for achievement.
  • Others create ‘assertion’ posts on their site(assert-of) and send webmentions, which would cause the post to be updated to note that it had been achieved.

Existing microformats for h-resume and h-review seem to allow additional context.

  • Education
  • Experience
  • Skill
  • Rating
  • Best
  • Worst

Brainstorming on the Indieweb wiki under assertion.

Your Endpoint Did Not Return a Location Header

There have been some issues with Quill and other services advising that the WordPress Micropub endpoint did not return a Location header. There seems to be some confusion about this, which is partly because the message is a bit technical. One individual thought that this was related to Simple Location.

This indicates an error on the part of the Micropub plugin. Regrettably, in addition to not displaying the error response prominently, the Micropub specification dictates that the error response returns one of 4 error codes, and may return a human readable error description to assist the client developer in understanding the error, but is not meant to be shown to the end user.

This does not account for errors on the endpoint side that may need to be debugged. Currently, the WordPress plugin that creates the endpoint does not surface error messages on its side either to allow you to figure this out.

Better error messaging to the end-user on one side or the other seems to be a common issue amongst Indieweb tools to help them figure out the issue.

The most common issue that explains the failure is an inability to associate the URL with the user account. There are two versions of the software that does this.

  • In the IndieAuth plugin, to ensure accuracy, the plugin passes the WordPress user ID in the return to ensure that it can find it.
  • If you don’t have the IndieAuth plugin installed, the Micropub plugin uses an external IndieAuth endpoint instead of a built-in one, and the following techniques to find the WordPress user from your URL
    • If you have the Indieweb plugin installed, it looks in its settings for the default author on a single author site.
    • If you are using the URL of your author post archive, usually /author/username it will try to use that to get your username and therefore your user ID
    • If you have set a website URL in your profile, it will try to use that. Please make sure your website URL uses https if your website does, as this has caused some issues in matching.

In both plugins, we continue to improve the functionality in this case and I often port ideas that improved functionality in one version into the other, as they are both authorize Micropub using IndieAuth, but in the case of the Indieauth plugin, it also implements the IndieAuth functionality.

Right now, I’m working on improvements to the Micropub plugin to improve the error handling, among other things, and hopefully this will help.

 

Brainstorming on Implementing Vouch, Following and Blogrolls

Vouch is an extension to the webmention protocol. Webmentions usually have two parameters…source and target. Target is the URL on your website  that the Source URL is linking to.

The vouch parameter is a third URL to help the target determine whether or not they should accept the webmention. This should block automated spam and aid in moderation.

Several people have implemented receiving vouches. It is relatively easy  to look at a vouch URL and see if it links to a third-party who you have approved of in the past.  While there are more advanced things you can do, that is the basic summary of the protocol.

The harder part, and less implemented by others is sending of vouches. Where do you find people who have been approved by people you have approved of? It would really help if we had some more discussion on this.

So, at the Indieweb Summit, we talked about this a bit, after which I implemented a primitive Vouch receiver. My solution was to use a manually curated domain whitelist that I’d previously built as my source for acceptable domains.

There are some suggestions on where to get this list. Several people generate a list from referrers. This sent me down the road of looking as to whether I’d want to implement refbacks to add more mentions to my website…except there is a lot of noise. Refbacks are basically the same as webmentions, except the source is gleaned from the  referrer header that sites send when a page is accessed.

Even if I  have a list of sites that I approve of, I would have to crawl them to find links from them to other sites. So, I think we should all help each other out on this.

That means we need to post our list of approved domains somewhere on our site. That used to be quite popular. It was called a Blogroll. It was sites you read, followed, or recommended. There are other terms for it. But, this is a perfect place to get a nice list, and if we publish them, then we can help the Vouch cause.

But the problem is, how do you tell a Vouch receiver where your list is. There are some brainstorming items about blogrolls and following/follower lists

  • Follower lists marked up with rel=”follower” or rel=”following”
  • Contact lists marked up with rel=”contact”
  • Follow Posts marked up with u-follow-of

Follow posts would create an h-feed of follow posts that could be used to generate a list. You can have a specific page on your website, but there isn’t a way to indicate this to someone looking for it.

There is rel-directory, which is the reverse direction. It indicates that the link is to a directory in which the current page is listed. What we seem to be missing is a property that says that a page is a feed of followers that can be placed inside an h-card or on a home page.

u-follow-of is a proposed property that indicates that an h-entry is considered a follow post, which is a post indicating you have followed someone, then a feed of follow posts could be parsed and read by a reader. If you add in the XFN relationships to that, you can build even more detail.

The reverse relationship would, in theory, be u-follow, which would be a URL to the follow post of the current URL(the thing being followed).

Feeds are identicated by rel=”feed” to link from your homepage to those feeds. But there is a lack of indicating what type of feed it is, such as rel=”blogroll” or rel=”following”.  I’m not sure, and need more discussion about what to use for this.

But, this has the ability to solve a lot of problems. Imagine I…

  • Post Follow posts when I follow someone
  • Use this to generate a blogroll/followers list
  • Send webmentions when I follow someone so they can build relationships
  • Use that list as a vouch list. Use other people’s blogrolls/followers lists as a means to generate vouch lists…which reduces the implementation cost of Vouch.

Needs work, but suddenly I want to do Follow posts.

Privacy

I admit to a certain amount of frustration on the subject of privacy lately. It seems, in all aspects of my life, both personal and professional, the new data privacy regulations that the EU rolls out May 25th are a theme in every discussion.

I don’t live in the EU, and I know that the European view on privacy is very different than the American one. Anything I say below is my opinion.

I am also an archivist and librarian by education, if not by profession. We learn about the past by reading the materials of the day. The fact that email is so easy to keep and delete makes things difficult for us to archive for the future. Does the right to privacy mean we lose the ability to look back, because we don’t want to remember?

Historical concerns aside, let’s think about today. In the majority of states in the US, only one party partipating in a phone call is required to record a conversation and even post it. Privacy is very lopsided. There is no such thing as absolute privacy.

For me, keeping a copy of communications I was a party to is perfectly acceptable. My website is where I keep my copy. It is not covered by privacy regulations. I have no business agenda there. I will not sell your data or use it for anything else but archiving that conversation.

The thorny issue is whether or not I have the right to display that information publicly. This is because I am, in some cases, copying that data from another service. For example, Twitter or Facebook. Those services got permission to store that information and you have the right to manage it. But you may not know that I have copied it to ask me to remove the public display of your image.

But how is that different than someone creating a screenshot of the post? Which was public information at the time?

As a private individual, I think it is mandatory that I post a policy about what I do. And that I will hide or remove information on request. As a developer of Indieweb tools, I think I should give people the option to not store information if they so choose.

So, I am going to build the tools for people to not collect data. I am going to stop what I am working on and do some of this right now. But I still will. I am going to try to better secure that data. I am going to be clearer about it. That is the lesson I can take away from this and should. That we need to think about privacy impact.

I hope those who are more concerned about this tell me through my site they don’t want me to share our public conversations that they were happy to put in a public forum. I will then restrict them to my eyes only.

In Indieweb terms, I support webmention deletion. If the original source changes and you send a webmention, my site should remove or update my copy.

Disclosure: Your responses to this may be captured for archival purposes. Please advise me if there is an issue.

 

Deprecating and Replacing Bridgy Publish for WordPress

I’ve decided to take a different direction for the Bridgy plugin for WordPress. I’ve never quite been able to explain to people it doesn’t actually do anything. It’s a user interface for the Bridgy service. I’ve decided that the best thing to do is to is to change the approach radically.

Bridgy is a service that integrates with various sites…Facebook, Flickr, Twitter, Github, and sends back comments, likes, etc to the original copies of the same posts on your site. There are a few similar services I’ve integrated with. It also has a feature called Publish where it allows you to syndicate your posts to those services.

This is something of an arms race, as APIs change all the time. Sometimes, there is no official established API. Ryan Barrett, the creator of Bridgy, announced in a blog post this week that due to Facebook API changes scheduled to take effect on August 1st, the Publish features of Bridgy for Facebook would be discontinued at the same time.

I’m writing this partly to lay out my plan in my mind as I’m working on writing this now. I’ve gone through a few different versions of this idea before settling on this.

The Bridgy plugin consists of two parts: The first part is a UI that is added to the post editor that consists of a series of checkboxes, and the corresponding code that triggers the same action from a post made over Micropub. The second part was added last summer, and is basically a registration page for registering for Bridgy.

I’ve opened an issue for discussion on whether I should move the second part into the main Indieweb plugin. Newcomers to the Indieweb could install the plugin, register for Bridgy inside it, and instantly start getting backfeed from other sites.

That brings us to the first part. The checkboxes. They will need to be rewritten, if I want them to continue, for the new post editor, Gutenberg, at some point. But, I don’t just want to syndicate via Bridgy. I want to syndicate to anywhere I can or choose to integrate in, both using the WordPress post editor and Micropub.

So, I’ve decided to integrate the top level of this, the logic that gets a request for syndication from the post editor or Micropub, inside Syndication Links.

Syndication Links displays icons which link to syndicated copies of posts. You’ll see them on this post. I keep adding in integrations to other plugins as people ask. I have Mastodon Auto Post, Keyring Social Importer, Medium, Social Network Auto Poster, and a few more. And I’ll likely continue to look at plugins that syndicate to other sites, figure out where they store their data, and display it as part of this plugin.

But now, this second part will expand the plugin into this territory of being a middleman for actually syndicating content. This is similar to what I did in Simple Location, where I have a series of providers for weather, location, maps, etc. and anyone could write a plugin(though only I have so far) that adds another provider.

To start, the first provider I’ll be including will be a rewritten version of Bridgy Publish, as well as my plan to add Indienews, as both are triggered by sending a webmention to a site.

At the point that I finish the alternative with feature parity to the existing code, I will discontinue development on the separate Bridgy plugin. It will mean one less plugin to maintain. Anyone who does not want to use the new features in Syndication Links…they will be off by default to start with.

It also means that, if I wanted to, I could add native publishing support for services in future. While there are certainly no end of Twitter/Facebook/etc plugins for WordPress, none of them quite understand syndicating a favorite to Twitter doesn’t mean a new tweet, it means something else. I can continue to write integrations for other plugins, or add new providers myself.

Not saying I’m going to do that. I’m only committing to what I’ve said above.

Finally, to all of you who liked the Bridgy Publish plugin…I’m curious to hear your comments on this. Bear in mind, I built the Bridgy Publish plugin to use it, and I still never migrated myself over to it. I would like to finally leave what I am using, and this would mean I could change providers without changing interfaces if I ever add something in future.

How I Set Up My Indieweb WordPress Site – 2018 Edition

This is an update to my 2014 article on how I set up my WordPress site. It was requested I update it.

Standard Plugins

  1. Character Count for Post Content and Excerpt(Link) – Because I need to be aware of the 140 character limit of Twitter, one of the services I send my content to, I need to know the character count of what I’m typing. This adds that to my editing screen. No longer using this plugin and could not find a replacement.
  2. EWWW Image Optimizer(Link) – It reduces file sizes for images to ensure faster loading
  3. Pushover Notifications(Link)or the forked alternative Pushbullet Notifications(Link) for WordPress – This plugin sends notifications of site events to my phone. The Pushover version is actively maintained and allows for extensions.
  4. Simple Local Avatars(Link) – Overrides the default of using the Gravatar service for profile pictures to storing them locally. However, this plugin hasn’t been updated in years. May look for a new one.
  5. WordPress SEO by Yoast(Link) – While I’m not obsessive about Search Engine Optimization, I find this plugin assists in my writing by reminding me about the importance of certain elements. While this is still a popular plugin and good for many people, it’s become a bit too aggressive for me.
  6. The SEO Framework (Link) – Sometimes, I think about getting rid of all SEO plugins. I’m not really obsessed with this. This does add non-Indieweb markup for some sites that require it. It isn’t worth it for me to manually add this right now.
  7. Hum(Link) – This is a simple URL shortener. So for each post, there is an equivalent URL address at di5.us. This allows me to give out easier to enter links to longer post titles.
  8. JSON Feed(Link) – Adds a JSON Feed to a WordPress site. This is an alternative to RSS as a feed. I’ve used it to feed my content to Micro.blog more effectively, as the specification was co-created by Manton Reece, who is the creator of that service. The plugin could stand some enhancement.
  9. Series(Link) – Creates a simple taxonomy called ‘Series’. I added this to my site to allow creating series of articles.
  10. WP Photo Sphere(Link) – For the rare occasions that I post 360 degree images. Rare as in I’ve only posted one.
  11. Social Network Auto Poster(Link) – I keep wanting to get rid of this thing. But I haven’t spent the time to replace it. Thinking of doing that soon.
  12. Simple Location(Link) – You can call this an Indieweb plugin, but it isn’t specifically an Indieweb technology(although it does use Microformats markup). It adds location and weather awareness to a post. So, you can click to add your location and the current weather conditions at that location to a post.
  13. Home Assistant for WordPress(Link) – I use Home Assistant for my Home Automation integration. Since it has an API, I wrote this simple plugin. While at the moment, I hope to add the ability to display information from any sensor and to update a sensor on the Home Assistant side from WordPress, I use it right now as an enhancement to Simple Location. Instead of getting my location from the browser, it gets it from my Home Assistant installation, which tracks my presence.

The Indieweb Stuff

  • WordPress Webmention(Link) – Adds webmention support for WordPress. This allows communications between sites.
  • Semantic Linkbacks(Link) – Adds richer content to WordPress comments received by Webmention. For example, interprets them as reply, repost, like, favorite, mention, etc. This allows different displays and actions to be done with them.
  • Semantic Comments(Link) – One of my own plugins. It changes the display of WordPress comments based on the information from Semantic Linkbacks. It presents the profile pictures in a Facepile for the various types of mentions with the comments separately below. This functionality has now been rolled into Semantic Linkbacks and is even better than it was.
  • Indieweb Taxonomy(Link) – Semantic Linkbacks is all about receiving webmentions for the various semantic types. But this plugin, another one of mine(although I credit several with contributions), adds new terms to WordPress posts for responding to content on another site. So, a post on this site can be a reply to another site, a like, etc. It will automatically send a webmention to the other site, if that site supports it, of course. Replaced by Post Kinds
  • Post Kinds (Link) – This replaced Indieweb Taxonomy. It is a replacement for the WordPress Post Formats which uses Indieweb post types. It allows you to respond to content on other sites, generates previews of those sites for context, allows you to post activity type posts(like watching, listening, reading, etc).
  • Syndication Links(Link) – Another project, which adds fields to a post for the corresponding versions on other networks. It also adds links to same to the post.
  • H-Card Tools – Still under development and not yet available for download, this is just the profile widget marked up appropriately, in the sidebar of the site. Some of this was rolled into the Indieweb plugin
  • Indieweb Plugin(Link) – The Indieweb plugin is not only a plugin installer, but it contains tools for adding rel-me links based on your profile, declaring the default author for your site, and adding a simple h-card widget to show off a primary author.

A Few Choices

  • There is an alternative to my Syndication Links plugin…a plugin called WordPress Syndication (Link).  It automatically adds the links to the post, and extracts the data from a variety of sources that post to other sites. This includes NextScripts Social Network Auto-Poster(Link) or Mailchimp’s Social plugin(Link), and even Bridgy(we’ll get back to Bridgy in a moment).
  • The theme I use is a custom one I built, but the most popular theme for Indieweb sites is Sempress(Link). My theme isn’t quite refined, but if you want it, a copy can be downloaded here. The version in use on my site is just a colored version of the minimal style the theme offers. I am currently using a fork of the WordPress Twenty-Sixteen theme(link) I modified for Microformats and support of the plugins I use.

Bridgy

Bridgy is not a WordPress plugin, or something you need to install(although you can host it yourself). Bridgy now has a WordPress plugin(link) which acts as a UI for registering and posting to Bridgy. Oddly enough, I wrote the plugin, but don’t actively use it. I need to fix my handling of syndication.

Bridgy is a service that you can link your accounts on places like Twitter, Github and Facebook to, and it will pull in comments, likes, etc from those sites and send them to your site to be integrated. This requires the Webmention and Semantic Linkback plugins to understand what is being sent.

To the Future

I enjoy developing this site as a learning tool. I hadn’t done much WordPress development before this and it is very useful to know.

For anyone who comes here considering trying my setup, I’m always available to help. For those who are trying my plugins…they are still being refined, but feedback and contributions(of code) are appreciated.

This site is under development, so it does change regularly. I will often summarize some of the changes with a post, but sometimes not.

IndieAuth for WordPress

Part of my own project for this week, while taking off for the holiday, was to complete work on an Indieauth endpoint for WordPress.

IndieAuth is a layer on top of OAuth 2.0, a standard that grants websites or applications access to their information on other websites but without providing passwords.

OAuth is already being used by a variety of services…Login with Facebook or Login with Google options on sites are usually OAuth based. The difference is that for IndieAuth, users and clients are all represented by URLs.

Authorization Prompt for Indieauth for WordPress

So, why did I want to build one? A few reasons. The most popular use for a IndieAuth server as authentication for Micropub clients. Micropub is a standard for creating posts using third-party clients.

WordPress is moving toward deprecating their post interface in favor of a totally new one called ‘Gutenberg’. As a long time WordPress user, the focus on this concerns me as it does not necessarily represent my needs or desires as a user of the platform. So, I want to have options.

Currently, OAuth servers for WordPress of all types are limited. The REST API, which was heralded with much optimism, lacks an OAuth authentication method. In fact, it lacks any built-in authentication options other than the WordPress login for external authentication.

There is an incomplete project for an OAuth2 server for WordPress I did get some useful ideas from, however. I also have to thank Aaron Parecki, who wrote a book on OAuth2 and wrote the Indieauth specification, for reviewing my work and giving lots of feedback.

What I’ve built, with help, is a working IndieAuth authentication method that works for the REST API, among other things.

Since I wanted this to be widely adoptable, I needed to make sure of a secure implementation, and I think the results are a good initial version. There is an opportunity for further refinements and improvements, but it means that WordPress users are no longer dependent on Indieauth.com, the reference implementation of the spec which uses OAuth providers like Github and Twitter to authenticate.

This leads to my hopes for the future. There are people working on Micropub clients for Android. And if any of them pans out, or my own mobile options, I could easily post notes to my site from wherever I am using tools that are much more flexible to my needs than are available now, the culmination of nearly 4 years of moving toward this point, on and off.

The success for me will be able to read something on my phone, and quickly share that to my site. Or have a thought and quickly share it to my site, without having to spend so much time setting it up I think better of it.

There are still pieces that need work to achieve that, but this is a major piece knocked off.

Working on Integrations

Spending some time working on integrations. Specifically, integrating data from my home automation systems into my website. In previous iterations, I have added support for weather to posts…but not directly from my own weather station. Added support for location, but not directly from my own phone’s location.

I am trying to decide how far I want to go. For example, in addition to actual coordinates, I have a property for my location that allows for the following options: At Home, Just Left Home, At Work, Just Left Work, Just Arrived Home, Away, and Extended Away. do I want to actually identify where I am, either with granular or general location just because I can? Or do I just want to add context to a post when I’m saying something else.

There are lots of other integrations I’m looking to do, for various reasons. There is a lot of data I’d like to store in my site that you won’t be able to see, for historic and future purposes.

This is a problem people may have solved on other sites, but I’m trying to solve it for myself. Especially since anything I post on my site is syndicated elsewhere.