Syndication Links for WordPress 4.2.4 is out. It tries for a few fixes to the scheduling of syndications, refreshes the icons, and introduces one new feature. A custom query. /?syndication=twitter.com or such. It tries to return all posts that have a matching syndication link and can be added to any archive page.

Micropub 2.2.0 for WordPress Released

Micropub 2.2.0 has one major change in it. IndieAuth client code was removed. This code now lives in the IndieAuth plugin. This means that Micropub does not check for scopes. It uses the built-in WordPress capability system to determine if an action should be performed.

The IndieAuth plugin limits capabilities based on scope as of Version 3.5.0, so the capability checks will work perfectly.

On a practical note, this allows the code to be simpler on the Micropub side. The scope limiting code is unit tested now inside the IndieAuth plugin and will continue to be iterated on there.

This allows Micropub to focus on the publishing side of things. Also, there was a request to remove a dependency on IndieAuth.com as the default for the built-in code. The IndieAuth plugin has no external site dependencies by default.

IndieAuth 3.5.0 for WordPress Released

Earlier in the week, I noted the release of IndieAuth 3.5.0, but I didn’t explain the major under the hood changes that occurred here in a post, which I need to do as at least one person is experiencing issues(probably necessitating a 3.5.1 as soon as I figure out why.)

I also noted I forgot to describe this clearly in the readme, if people read changelogs and will have to correct that as well.  I wrote some of this code in January and it was merged, but didn’t release it till July, so…

IndieAuth 3.5.0 implements scope support. Previously, scopes were handled by the Micropub plugin. It would check what scopes you had and implement accordingly. But WordPress does not have the concept of scopes. It has the concept of capabilities. And users have roles, which are collections of capabilities.

So Indieauth 3.5.0 implements scopes also as collections of capabilities. If you are doing a capability check in WordPress, and the request was authenticated with an IndieAuth token specifically, it will filter your capabilities by the ones defined in the scopes the token has.

That means if your user didn’t have the capability to begin with, you can’t use it. In a future version, I’ve considered on the authorization screen, not even issuing a token with that scope, but this is ultimately more secure than before.

It means that plugins don’t have to understand scope at all. They just have to enforce and support native WordPress capabilities, which they should anyway.

For now, the system only supports built-in capabilities, but there is nothing that says it cannot move to custom capabilities as needed, as everything is filterable and we accept pull requests.

The second big change I did mention in the changelog brings the code to support using a remote IndieAuth endpoint back into this code. However, it is disabled by default. This is based on the code removed from Micropub, which had a parallel IndieAuth class that was only used when the IndieAuth plugin was not enabled. By having it here, it allows anyone who wants to use it to enable it, but simplifies the experience for the bulk of users. It also allows it to be enhanced by any of the scope or other enhancements put into the main plugin.

The plugin also simplifies the site checks to ensure that your site will work with the plugin, putting them into the Site Health checks where they logically belong. This includes an SSL check and a Authorization header check.

People Seem Confused about IndieAuth

When I first started in the IndieWeb community, IndieAuth confused me. It confused me up until I built an IndieAuth endpoint for WordPress. It may confuse you as well. And that has been a problem in its adoption.

The biggest confusion seems to be conflating IndieAuth and IndieAuth.com. IndieAuth.com is a reference implementation of the protocol built by Aaron Parecki, who edited the IndieAuth specification. Aaron works extensively with OAuth as part of his day job.

OAuth is that technology you see all around the web. It allows you to log into one site using the credentials of another. So, “Sign in with Google”, “Sign in with Facebook”, etc. The site you signed into uses one of these sites to verify your identity.

IndieAuth is a layer on top of that. It allows you to sign in with your website. So, to login you provide the URL of that site, which represents your identity. The client goes and retrieves your site, and looks for hidden links to your IndieAuth endpoints and asks you to verify your identity to it. Then, once you have, it issues permission to the client to act as you, with whatever permissions you have approved.

IndieAuth.com, being a reference implementation, wouldn’t know how to verify your identity. So, it uses a workaround called RelMeAuth. If you put a link on your website to your GitHub account, or other sites that support OAuth, marked up in HTML with rel=”me”, it would go to the sites of those services it supported, check to see if, using the GitHub example, if your GitHub profile had a link back to your website. This would prove your GitHub account and your website were owned by the same person. Then if you could successfully authenticate to GitHub, it would then issue the client the permissions it requested.

Since for IndieAuth.com to work with your site, you had to link to it on your site in a certain way, designating it as the authentication endpoint for that URL, it meant that unless someone had the ability to edit your page(a bigger problem), they couldn’t use it to get into your site.

But IndieAuth.com isn’t meant to be a permanent service and the fact people think that IndieAuth.com = IndieAuth the protocol is a problem. It is meant to be a bridge for people.

So, I came in, naively, when I started using IndieAuth.com and said…I want to do the same thing, but I don’t want to log in using GitHub…I want to log in using my WordPress credentials. So, in 2018, I learned enough to write an IndieAuth endpoint for WordPress. So, you can, instead of putting indieauth.com as your provider, install a WordPress plugin and your site will become a provider.

Try to login with your URL and it will redirect to letting you login with WordPress, then issue credentials to the client in the form of a token that can be revoked from the WordPress admin.

But people continue to see IndieAuth as logging into other websites via IndieAuth.com and therefore via GitHub…that can certainly be a service and a thing you can do. However, that’s not IndieAuth.

So, going forward, I’ve decided that I’ll be disabling the code from the IndieWeb WordPress plugin that allows you to use IndieAuth.com in favor of the built-in solution. Those who want to use an external service will still be able to do so, but this will be an ‘expert’ feature. Because enabling a plugin and it just working is what most people want.

And if it doesn’t work, please report the bug and we’ll fix it.

Deployed IndieAuth for WordPress 3.5.0 this morning. So I’m writing this release note using Micropub, to ensure that IndieAuth still works on my site(no reason I think it shouldn’t.) No new user facing features, but tried to improve security.

Simple Location 4.1.6/7 Released

I didn’t plan on doing another Simple Location run, or having to immediately release a fix due a mistake. This change was prompted by a new request to allow for saving maps locally.

For various reasons, I was reluctant to do that. But I came up with another solution. Adding a map provider that supports a custom hosted service. In this case, a fork of a Static Maps API written 6 years ago by someone I know. You can find my fork here.

By using a self-hosted but external static map API, I keep the option out of the plugin for now.  It will also work with anything that implements the same API.

In the same update, I also fixed a few bugs, and added moonrise and moonset calculations, which display along with sunrise, sunset, and moon phase in the Last Seen widget for now.

 

Simple Location 4.1.5 Released

weather widget design
Newly Released Weather Widget Design

This evening I released Simple Location 4.1.5. This was prompted by the realization that Wikimedia Maps was no longer permitting third-party usage.

  • I replaced it with Yandex Maps, which doesn’t require an API key either for non-commercial use. I may additional Yandex services in future.
  • I also added Geoapify as a map provider…I may also add in its geocoding service in future.
  • Open Route Service, as it is an open initiative, is now supported as a geolocation/elevation provider.  I like to support any open source options when I can.
  • Preliminary Moon Phase calculation, though the formula is not up to my standards and needs to be replaced. I spent 20 minutes on it and I spent a week learning enough about how to adjust the sunrise and sunset based on location and elevation.

In the last major update to Simple Location, 4.1, I added in additional icon sets. In this version, I redid the presentation of all of the widgets to show additional properties and standardized all the widgets so they use the same display logic.

So what is next:

  • In a previous version, I switched to storing everything in metric(meters, celsius, etc).  I already convert back to imperial measurement for temperature if the configuration option is set. I still need to do so for other metrics…as I’m showing visibility and rain in metric still. I need to do the same on the backend. But as someone who uses Fahrenheit and Feet…I would use this.
  • I also continue to think of what other weather parameters I can offer and display. Heat index, dewpoint, which are derived from the humidity and temperature, would be relatively easy to answer.
  • Being able to pull in station data from my own weather station is still a goal. The issue with this is designing an implementation that is not limited to working only with my setup, and always pulls from my endpoint except if they are not available.
    • I have the concept of zones for location, which are areas around a location. Anything inside of a zone will be hidden on a post, and the label replaced with the zone name.
    • A long time ago, I declared I wanted to add venues for location, which would essentially be to allow for archive pages for locations.
    • Now I’m looking at stations, which would be a fixed weather location.

The above three things are too similar for me to feel comfortable going any further till I think about this. Zones may need to stay separate, as they are a privacy matter. But stations and venues are both public items…but no one posts from a weather station…they might post from a venue…so maybe I should build stations regardless.

If I do build the station model, it would likely merge custom stations like mine with station IDs from the Met Office, National Weather Service, OpenWeatherMap and AerisWeather, as well as any future services that support weather stations, and allow those to be kept in a list. It would then have to determine if it was close to such a station…and use that data. Not quite sure how to do that simply.

 

Thoughts on IndieWebCamp West

Over the weekend, I co-organized IndieWebCamp West 2020. This was a replacement for a physical event that I have attended for the last few years in Portland, Oregon. I attended many in-person IndieWebCamps last year, and it is looking like we won’t be having such things for the foreseeable future.

We’ve tried online IndieWebCamps before, but I felt we missed some opportunities in the past. So, we tried some new things. The whole event was conducted using Zoom.

  • A Cook Your Own Dinner pre-party where we shared a meal together and socialized.
  • A room serving as a ‘Hallway Track’ for off-topic chatting
  • Two rooms with 4 each.

The sessions were a good mix of conversation types. And even afterward, I found myself sitting up each night after the event just chatting with people. It was the first time I feel we captured more of the in-person Indieweb feeling by adding in those social opportunities.

Hoping for an East Coast timezone event later this year, and some popup sessions in between, to keep things alive. If not for the current state of the world, we might have had one IndieWebCamp a month in 2020. We’d already had one in February, an Online one, and one in March that was converted into a remote event last minute.

Doing IndieWebCamp West Hack Day, and added another Simple Location for WordPress trick. I was doing custom rewrite improvements for Post Kinds, and added the ability to generate map views from any taxonomy or user.  Just add /map to the archive URL.
Released Post Kinds for WordPress 3.3.4. this includes a refresh of the Parse This library, which adds a lot of improvements in getting data, some minor tweaks, and a bug fix for an issue where pagination was not working on the custom archive pages the plugin creates, such as /onthisday/06/09, /kind/article/2020, and /kind/photo/pool (tag), which were not working.
Released Simple Location 4.1.3. This fixes an issue raised where the Airport Weather Widget only accepted 3 letter airport codes, not 4. Now it accepts both, as I supported both in other places. I also added additional error handling to support this. At the same time, I replaced the ‘master’ branch with the ‘trunk’ branch and added deployment code to auto create a Github release going forward.
RSVPed Attending IndieWebCamp West

IndieWebCamp West 2020 is an online gathering for independent web creators of all kinds, from graphic artists, to designers, UX engineers, coders, hackers, to share ideas, actively work on creating for their own personal websites, and build upon each others creations.