Simple Location Version 3.4.0 Released
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
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.