I’m hoping that future versions of this provide the Twitter permalinks for the syndicated copies there to be returned to my WordPress site for storage. In my case, I’m using the simple Syndication Links plugin which has storage and/or finds the storage location in WordPress to allow for the display of those permalinks in my post to indicate where I’ve syndicated the copies. This does two things: it’s a reminder of where my content lives elsewhere on the web (especially if I later want to go back and delete them, or to delete them if I’m deleting or making the original post private/unpublished) and it allows services like Brid.gy to find my original post and backfeed replies to the Twitter versions back into the comments section of my post using the Webmention spec (via the Webmention plugin and the Semantic Linkbacks plugin).
Tag: syndication links
Inspired by this weekend’s IndieWebCamp West, I added support to record and display syndication urls for my posts on this site.
The indieweb community encourages posting your content to your own site, and then liberally sharing either copies or links elsewhere on the web. The idea is that you own...
To document the change, I’ll include a syndication link on my website to the permalink for the edit on the wiki. Having subscribed to feeds of wiki changes/edits before the user interfaces are far less than useful/ideal, so having a better contextual bookmark on my website makes more sense for readers while somewhat reformatting things for the readers of the wiki (a related but somewhat different context) works better for that, but still provides bi-directional links and references.
Perhaps I’ll create an edit post kind in the future? For the moment I’ll just post some (like this one) as an annotation? Small steps…
Example bookmark of a commonplace book: https://boffosocko.com/2020/03/14/neils-noodlemaps/
with a syndication link to the diff of the addition to the example on the IndieWeb wiki: https://indieweb.org/wiki/index.php?title=commonplace_book&oldid=69042
Participating in PressEdConf20 directly from WordPress
(Meta: Welcome to my talk: I know it’s cheating & early, but I’m hoping a few presenters will borrow this method.)
My general thought was:
The only thing better than A WordPress and Education, Pedagogy and Research Conference on Twitter would be A WordPress and Education, Pedagogy and Research Conference using WordPress itself!
(Meta: Sure, post it to Twitter: but why not own a copy of your presentation on your own website when you’re done?)
So let’s give it a spin by providing an outline for how to accomplish it in true #IndieWeb & #DoOO fashion? Perhaps a few people might trying doing this year’s conference this way? Here’s an early #PressEdConf20 presentation to get the juices flowing.
(Meta: Hint for those on Twitter: I’m including links to my website, so you can get just a little bit more information than Twitter limits me to–oh, the fringe benefits of having one’s website where they’re not censored by the confines of the platform on which they’re creating!)
First, we’ll start off by making the humble presumption that you’ve got your own domain and an install of WordPress running on it. Hopefully this covers most #PressEdConf20 attendees.
(Meta: If it doesn’t there are lots of options: You could do something similar a bit more manually if you like using WordPress.com. You’ve also got a great community of people who could help you to better own your online identity and domain right here! I’ll bet our friends at Reclaim Hosting could help as well.)
Next we’ll want the Webmention Plugin (+Semantic Linkbacks) which will let our site communicate with other websites as well as to receive replies and reactions on Twitter with the help of Brid.gy. Install and activate both.
(Want to go deeper into the idea of what Webmention is and how one could use it? I wrote an article for A List Apart that goes into details.)
One could manually syndicate content from WordPress to Twitter, but there are multiple plugins and ways to syndicate it. My favorite is the Syndication Links plugin, which we can use for syndicating to other services. Install and activate.
Next we’ll want an account on Brid.gy for Twitter. This will allow us to publish from our website to Twitter; it will also allow us to reverse syndicate reactions from #PressEdConf20 on Twitter back to our posts using Webmention.
(Meta: Publishing this way will require Microformats: Your theme will need the proper microformats support to use this method, but again other methods are available.)
Authenticate your website and Twitter account with Bridgy and enable Bridgy publish on your account page: https://brid.gy/twitter/username
.
In Syndication Links settings at example.com/wp-admin/admin.php?page=syndication_links
- Enable Syndication to Other Sites
- Enable Twitter via Bridgy
Add a custom provider using the following:
- name: XYZ pressEdconf20
- UID: XYZ-pressEdconf20
- target URL: https://indieweb.xyz/en/pressEdconf20/
Save the settings.
Now write all of your posts in your presentation as status updates (without titles) and include any media (photos, videos, etc.) making sure to mark up the photos with a class of u-photo in the HTML. Don’t forget the hashtag #PressEdConf20.
Set posts for one every minute. Use the SL Syndicate To meta box to syndicate your Twitter account and to the indieweb.xyz sub where everyone can find them (if they’re not following the proceedings via Twitter).
Others at #PressEdConf20 with Webmentions can reply to your posts on their sites. Replies will show up in comments depending on settings. Bridgy will also find responses to your content on Twitter & syndicate those back to your website automatically.
(Meta: Give it a whirl!: Reply to this post on Twitter to see it boomerang back to the comment section of my website.)
Those who are paying attention at #PressEdConf20 will see the value in webmention for allowing cross-site interactions without the need for “social media”. WithKnown, Drupal, Grav, and other CMSs are capable of doing this too.
(Meta: Ownership of your Open Pedagogy Anyone? Who needs invasive corporate social media to interact online now?)
With luck, I’ll have created this entire #PressEdConf20 presentation on my own website and syndicated it to Twitter without actually needing to visit Twitter itself. I’m around for questions. Thank you for your time and attention. [more…]
Those looking for more details can find documentation on the IndieWeb wiki at https://indieweb.org/Getting_Started_on_WordPress, or https://boffosocko.com/2018/04/27/setting-up-wordpress-for-indieweb-use/
I’m also happy to help people set things up and make alternate suggestions via video chat or you can find online help in the IndieWeb WordPress chat.
P.S. There’s still some time to submit your talk for #PressEdConf20. Since it’s all designed to be online from the start, I’m hoping it won’t be cancelled like all the other events lately.
(Meta: PressEdConf 2020: A WordPress and Education, Pedagogy and Research Conference on Twitter March 26, 2020)
example.com/wp-admin/admin.php?page=syndication_links
- Enable Syndication to Other Sites
- Enable Twitter via Bridgy
Add a custom provider using the following:
- name: XYZ pressEdconf20
- UID: XYZ-pressEdconf20
- target URL: https://indieweb.xyz/en/pressEdconf20/
Save the settings.
I hacked together some tweaks to add the following:
- Improved support in my theme for time related microformats including
dt-published
anddt-updated
- Because I post so frequently, I added a visible timestamp next to the date so it’s easier to follow my timeline of posts.
- I removed the data for my location, weather, and syndication links from
the_body
of my posts and appended it to my post meta data. This should prevent it from showing up in Webmentions to others’ websites or in syndicated copies, but still be available to parsers to attach that data to my posts in readers and other services. - I modified my CSS so that the text in the Simple Location and Syndication Links plugins matches that of the rest in its section.
- I added a cute little bullhorn icon in front of my Syndication Links so that it has some parallelism with the rest of the meta data on my site.
- I’d always liked the idea of adding in related posts data on my site, but didn’t like how it had worked in the past. Things were even worse with replying to other people’s posts as my markup (and far too many others I’ve seen in the WordPress world) was hacky and caused the related posts data to show up in their Webmentions sent to other sites. I looked through some of Jetpack’s documentation and figured out how to remove their Related Posts functionality from
the_body
, where it defaults, and append it instead to the post meta section of my posts. It’s not perfect yet, but it’s much closer to how I’d like it. Best of all, that data shouldn’t show up in my replies to other sites now either! I had disabled the functionality ages ago because it made me feel like a rude-IndieWebber.
With IndieWebCamp Online 2020 coming up this weekend, I hope to fix a few outstanding issues and roll these changes up into my open sourced IndieWeb Twenty Fifteen WordPress theme as my hackday project. If you’re using it on your own site, do let me know. Not that I can promise to fix it if it’s broken in places, but I’d at least like to know how it’s working out for you or where it could be improved.
Things left over to fix:
- Simple Location data still needs some CSS help to display the way I want it to.
- I need to target the Simple Location icon so I can have its color match that of the other icons.
- Because so many of my posts don’t have titles, I’ll need to tweak something there so that the Jetpack related posts will pick up better meta data as a pseudo-title instead of displaying the relatively context-less commentary that appears in
the_body
. - It may take a day or two for the related posts to populate properly, but I should make sure that it’s putting out relevant/interesting results.
- Is it worth adding a default featured photo for the related posts that don’t have one? Could I pull one from other meta fields for some classes of posts?
Using IFTTT to syndicate (PESOS) content from social services to WordPress using Micropub
Introduction
What follows may tend toward the jargon-y end of programming, but I’ll endeavor to explain it all and go step-by-step to allow those with little or no programming experience to follow along and use the tools I’m describing in a very powerful way. I’ll do my best to link the jargon to definitions and examples for those who haven’t run across them before. Hopefully with a bit of explanation, the ability to cut and paste some code, or even make some basic modifications, you’ll be able to do what I and others have done, but without having to puzzle it all out from scratch.
Most readers are sure to be aware of the ubiquitous “share” buttons that appear all over the web. Some of the most common are “share to Facebook” or “share to Twitter”. In my examples that follow, I’m doing roughly the same thing, but I’m using technology called webhooks and micropub to be able to share not just a URL or web address, but a variety of other very specific data in a specific way to my website.
This “share”–while a little more complicated–gives me a lot more direct control over the data I’m sending and how it will be seen on my website. I would hope that one day more social websites will have built in share buttons that allow for direct micropub integration so that instead of only sharing to corporate sites like Facebook, Twitter, et al. they’ll let people share directly to their own personal websites where they can better control their online identity and data. What I’m describing below is hopefully a temporary band-aid that allows me to keep using common social services like Pocket, YouTube, Meetup, Goodreads, Letterboxd, Diigo, Huffduffer, Reading.am, Hypothes.is, and hundreds of others but to also post the content to my site so that I own and control more of my own online data.
An example using Pocket
Following in the footsteps of Charlotte Allen and Jan-Lukas Else, I’ve been tinkering around with improving some of my syndication workflows for a number of social silos including Pocket, a social silo that focuses on bookmarking material to read later.
I have long used IFTTT (aka If This, Then That), a free and relatively simple web service that allows one to create applets that tie a large number of web-based and social services together, to send data from my Pocket account to my WordPress-based website. I’d done this using my Pocket RSS feed to create WordPress draft posts that I could then modify if necessary and publish publicly if I desired. Since I regularly use a number of Micropub clients in conjunction with the WordPress Micropub plugin and IFTTT supports webhooks, I thought I’d try that out as a separate process to provide a bit less manual pain in mapping the data for posts to appear like I want them to on my website.
Now I can use my Pocket account data and map most of it directly to the appropriate data fields on my website. Because Pocket has direct integration into IFTTT, I can actually get more data (particularly tags) out of it than I could before from the simple RSS feed.
Below, you’ll find what I’ve done with a quick walk through and some example code snippets. I’ll break some of it down into pieces as I go, and then provide a specific exemplar of some of the code properly strung together at the end. I’ll also note that this general procedure can be used with a variety of other silos (and either their integrated data or RSS feeds) within IFTTT to post data to your website. Those running platforms other than WordPress may be able to use the basic recipe presented here with some small modifications, to send similar data from their accounts to their sites that support Micropub as well.
Directions for connecting IFTTT to publish to WordPress via Micropub
Preliminaries
Install and activate the Micropub plugin for WordPress. This will give your website a server endpoint that IFTTT will use to authenticate and send data to your website on your behalf.
If you don’t already have it, install the IndieAuth plugin for WordPress and activate it. This will allow you to generate an authorization token (think password) with the appropriate scopes (think permissions to do specific actions on your website) to allow IFTTT to securely post to your website.
Within the WordPress administrative interface/dashboard go to Users >> Mange Tokens
or go to the path /wp-admin/users.php?page=indieauth_user_token
on your website.
At the bottom of that page under the section “Add Token” add a convenient name for your new token. You’ll see in the following screencapture that I’ve used “IFTTT for Webhooks”. Next click the check boxes to add scopes for “create” and “media”. Finally click the “Add New Token” button.
On the resulting page, copy the entirety of the returned access token in a safe place. You’ll need this token later in the process and once you’ve navigated away from the page, there’s no way to retrieve the token again later. The same token can be used for multiple different recipes within IFTTT, though one could create a different token for each different recipe if desired.
Sign up for an IFTTT account (if you don’t already have one).
Register Pocket as a service you can use within IFTTT.
The IFTTT Applet
In your IFTTT.com account, create a new applet.
For the “if” part of the applet, search for and choose the Pocket application.
Choose the trigger “Any new item” (other triggers could be chosen for different combinations of actions).
Click the “then” part of the applet, and search for and chose the Webhooks application.
Choose the “Make a web request” option (currently the only option on the page).
Next we’ll fill in the action fields.
Fill in the four action fields with the following values, with the appropriate modifications as necessary:
URL: https://www.example.com/wp-json/micropub/1.0/endpoint
Be sure to change example.com
to the appropriate URL for your website. If you’re using a platform that isn’t WordPress in combination with the Micropub plugin, you can quickly find your appropriate endpoint by looking at your homepage’s source for a <link>
element with a rel="micropub"
attribute.
Method: POST
Content Type: application/x-www-form-urlencoded
More advanced users might experiment with other content types, but this will naturally require different data and formatting in the Body
section.
Body:
The Body
portion is one of the most complicated portions of the operation, because this is where you can get creative in how you fill this out and the end results you end up with on your website. You can use the available variables in the recipe to custom create almost anything you like and some services will give you a tremendous amount of flexibility. I’ll walk through a handful of the most common options and then tie them all together at the end. Ultimately the Body
will be a string of various commands that indicate the data you want to send to your website and all of those commands will be strung together with an ampersand character (“&
“) between each of them.
There are some small differences you may want to experiment with in terms of what you put in the Body
field based on whether or not you’re using the Post Kinds plugin to create your posts and reply contexts or if you’re not.
Depending on which pieces you choose, I recommend doing a few test runs for your applets to make sure that they work the way you expect them to. (The Micropub plugin has a setting to mark incoming posts automatically as drafts, so you’re not spamming your readers while you’re testing options if you’re testing this on a live site.) Sometimes formatting issues (particularly with setting a publish time) may cause the post to fail. In these cases, experiment to find and excise the offending code and see if you can get things working with minimal examples before adding additional data/details.
For those who would like to get into more advanced territory with the programming and methods, I recommend looking at the W3C’s Webmention specification.
The first thing you’ll want in the Body
will be your access token. This is similar to a password that allows the webhook to publish from IFTTT to your website. You’ll want a line that reads as follows with the AccessTokenHere
replaced with the access token from your token provider which you created earlier and saved. You’ll want to keep this secret because it acts like a password for allowing remote applications to post to your website.
access_token=AcessTokenHere
Next will come the content you want to be published to your site.
&content=<<<{{EntryTitle}}<br>
{{EntryPublished}}>>>
I’ll mention that the content snippet can include almost anything you’d like using the variables provided by IFTTT as well as a reasonable variety of HTML. I’ve used it to add things like <blockquotes>
for annotations and even <audio>
tags for making listen posts or bookmarking audio with Huffduffer!
The following snippet tells your site what kind of content it’s receiving. Unless you’re doing something more exotic than bookmarks, likes, favorites, replies, or most post kinds (except maybe events), you’ll want to use the h-entry
snippet as follows:
&h=entry
If you’d like your post to contain a formal title, then you’ll want to include the following code snippet. Generally with shorter content like notes/status updates, bookmarks, reads, likes, etc., I follow the practice of publishing titleless posts when they’re not required, so I personally skip this piece in most of my posts, but some may wish to include it.
&name=<<<{{Title}}>>>
To have your website create or use the correct category or tag taxonomies on your posts, you’ll want to have something similar to the following snippet. If you want to specify more than one category, just string them together with ampersands. If your category/tag has a blank space in it you can replace the spaces with %20
. The Micropub server on your site should automatically check to see if you have categories or tags that match what is sent, otherwise it will create a new tag(s).
&category[]=Bookmark&category[]=Social%20Stream
I’ve found that in practice, some silos that allow for multiple tags will actually publish them via micropub using something along the lines of the following if the appropriate variables on IFTTT exist. In these cases, I append this to the other categories and tags I want to specify.
&category[]=<<<{{Tags}}>>>
If you’re using your Pocket account to send your bookmarked articles to read later, you’ll want to create a bookmark with the following line:
&bookmark-of=<<<{{EntryUrl}}>>>
Alternatively, if you were using your Pocket account to archive your articles once you’ve actually read them, you could have IFTTT post these archived items as “reads” to your site by choosing the “New Item Archived” element in the Pocket portion of the IF set up process. Here you’d replace the above bookmark-of
line with the following:
&read-of=<<<{{EntryUrl}}>>>
If you were creating different sorts of posts you might also use the appropriate alternate verbiage: like-of
, watch-of
, listen-of
, rsvp
, etc. (find details for the appropriate mark up on the IndieWeb wiki or the correct microformats v2 property within the code for the Post Kinds plugin). If you are using the Post Kinds plugin, this is the piece of data that it receives to specify the correct post kind and create the reply context for your post and will likely preclude you from needing to send any data in the content portion (above) unless the services applet will let you send additional commentary or notes that you want to appear in the body of your post.
Next, if your site supports syndication links with a plugin like Syndication Links for WordPress, you would use the following line of code so that those are set and saved properly. (This presumes that the URL specified is the permalink of the content on the social silo. I’ll note that Pocket doesn’t provide these (easily) as most of their links are canonical ones for the original content, so I don’t use this on my IFTTT recipe for my Pocket workflow, but I do use it for others like Huffduffer and Reading.am. It conveniently allows me to find copies of my content elsewhere on the web.)
&syndication=<<<{{EntryUrl}}>>>
If you’d like to have the timestamp on your post match the time when you actually bookmarked the item in Pocket, you’ll need to add the following line of code. Without this line, the publication time will match the time of the Webhook action, which for most IFTTT things can be a delay of a minute or two up to an hour or more afterwards. In practice, I’ve noticed that most content posts to my website within about 10-15 minutes of the original, and this is based on the polling lag within IFTTT checking your triggers. (Sadly, I’ll report that I’ve never gotten this code snippet to work for me in practice, and I suspect it may be because the time format from IFTTT doesn’t match what is expected by the Micropub server on my website. Perhaps David Shanske or Ryan Barrett may have a more specific idea about what’s causing this or suggest a fix? I’ll try to dig into it shortly if I can. As a result, I generally have left this snippet of code off of my triggers and they’ve worked fine as a result. Until this issue might be fixed, if you want to have the exact timestamp, you could alternately include the data, if provided, in the content section instead and then copy it over manually after-the-fact.)
&published=<<<{{EntryPublished}}>>>
If you’ve got syndication endpoints set up properly with something like the Syndication Links plugin, you can use the following sort of code snippet. I generally eschew this and prefer to save my posts as drafts for potential modification prior to publishing publicly, but others may have different needs, so I’m including the option for relative completeness so people can experiment with it if they like.
&mp-syndicate-to[]=twitter-bridgy
This concludes the list of things that might commonly be included in the Body
portion of the IFTTT applet. Tying these all together for combination in the Post Kinds Plugin one would want something along the lines of :
Body:access_token=AccessTokenHere&content=<<<{{EntryTitle}}<br>
{{EntryPublished}}>>>&h=entry&category[]=Bookmark&category[]=Social%20Stream&bookmark-of=<<<{{EntryUrl}}>>>
Here’s another example of the code I use in conjunction with a similar applet for Diigo, a bookmarking service. The “Description” portion allows me to add a note or comment on the bookmark when I make it and that note is transported over to the post on my website as well.
Body: access_token=AccessTokenHere&content=<<<{{Description}}>>>&h=entry&category[]=Bookmark&category[]=Social%20Stream&category[]=<<<{{Tags}}>>>&bookmark-of=<<<{{Url}}>>>
Note that when the string of commands is done, you do not need to have a trailing ampersand. Most of the examples I’ve used are from the Pocket set up within IFTTT, but keep in mind that other services on the platform may use alternate variable names (the portion in the braces {{}}
). The differences may be subtle, but they are important so be careful not to use {{EntryTitle}}
if your specific recipe expects {{Title}}
.
To finish off making your new applet, click on the “Create Action” button. (If necessary, you can test the applet and come back to modify it later.)
Finally, give your applet an appropriate tile and click the “Finish” button. For my Pocket applet I’ve used the name “Pocket bookmark PESOS Micropub to WordPress”.
Now that your applet is finished, give it a whirl and see if it works the way you expect! Don’t feel discouraged if you run into issues, but try experimenting a bit to see if you can get the results you’d like to see on your website. You can always go back to your applet recipe and modify it if necessary.
Conclusion
Hopefully everyone has as much fun as I’ve had using this workflow to post to their websites. It may take some patience and experimentation to get things the way you’d like to have them, but you’re likely to be able to post more easily in the future. This will also let you own your data as you create it while still interacting with your friends and colleagues online.
I know that it may be possible to use other services like Zapier, Integromat, Automate.io, or other similar services instead of IFTTT though some of these may require paid accounts. I’d love to see what sorts of things people come up with for using this method for owning their own data. Can you think of other services that provide webhooks for potential use in combination with Micropub? (Incidentally, if this is your first foray into the Micropub space, be sure to check out the wealth of free Micropub clients you can use to publish directly to your website without all of the set up and code I’ve outlined above!)
Currently I’m using similar workflows to own my data from social services including Pocket, Diigo, Huffduffer, Reading.am, YouTube, Meetup/Google Calendar, and Hypothes.is. I’ve got several more planned shortly as well.
Thanks once again to Charlotte Allen and subsequently Jan-Lukas Else for the idea of using Micropub this way. Their initial documentation was invaluable to me and others are sure to find it useful. Charlotte has some examples for use with Facebook and Instagram and Jan-Lukas’ example may be especially helpful for those not using WordPress-specific solutions.
And as always, a big thank you to the entire IndieWeb community for continuing to hack away at making the web such a fun and vibrant space by making the small building blocks that make all of the above and so much more possible.
With the rise of social platforms and an uptick in threatening comments, the newsroom is taking reader engagement in a different direction.
We analyzed our Disqus data and we found that roughly 17,400 comments were made on our site in 2019, but 45% came from just 13 people. That data tells us that social media, email, phone calls, letters to the editor, our Crosscut events and an occasional visit to the newsroom are far better tools for us to hear about your concerns, story ideas, feedback and support.❧
The Disqus data statistics here are fascinating. It also roughly means that those 13 people were responsible for 600+ comments on average or roughly 2 a day every day for the year. More likely it was a just a handful responsible for the largest portion and the others tailing off.
Sadly missing are their data about social media, email, phone, and letters to the editor which would tell us more about how balanced their decision was. What were the totals for these and who were they? Were they as lopsided as the Disqus numbers?
Annotated on January 08, 2020 at 04:33PM
In the meantime, stay in touch with Crosscut by:
Liking us on Facebook
Following us on Twitter
Following us on Instagram
Chatting with us on Reddit
Signing up for one (or all) of our newsletters ❧
It seems like they’ve chose a solution for their community that boils down to pushing the problem(s) off onto large corporations that have shown no serious efforts at moderation either?
Sweeping the problem under the rug doesn’t seem like a good long term answer. Without aggregating their community’s responses, are they really serving their readers? How is the community to know what it looks like? Where is it reflected? How can the paper better help to shape the community without it?
I wonder what a moderated IndieWeb solution for them might look like?
Annotated on January 08, 2020 at 04:42PM
It would be cool if they considered adding syndication links to their original articles so that when they crosspost them to social media, at least their readers could choose to follow those links and comment there in a relatively continuous thread. This would at least help to aggregate the conversation for them and their community while still off-loading the moderation burden from their staff, which surely is part of their calculus. It looks like their site is built on Drupal. I would suspect that–but I’m not sure if–swentel’s IndieWeb Drupal module has syndication links functionality built into it.
Rather than engaging their community, it almost feels to me like they’re giving up and are allowing a tragedy of their commons when there may be some better experimental answers that just aren’t being tried out.
The worst part of this for me though is that they’ve given up on the power of owning and controlling their own platform. In the recent history of journalism, this seems to be the quickest way of becoming irrelevant and dying out.
Released some minor bugfix editions today.
Simple Location
- Rounds all numbers to a maximum of two decimal points, as I introduced a bug in the last version that would fail to fill in numbers in the post editor due form validation requirements.
- Extracts additional location information from Compass…mostly the information I store when I’m on a plane, to generate a better description of the location. It also passes this info to WordPress more effectively so it could do more in future.
- I also introduced a new location provider. If set, if you enter a 3 letter airport code in the location name box, it will replace it with the location and name of that airport, as well as the weather. In future, I may add a similar reverse address lookup for people.
- Misc bug fixes
Syndication Links
- Some bug fixes introduced in 4.2.0
- Due to the request to allow syndication provider checkboxes to be checked by default, I introduced two new filters: syndication_link_checked and syndication_link_disabled. The first parameter of each is a boolean that if true, will set either checked or disabled on that Syndication Provider. The second and third parameter is the uid of the provider and the post_id of the post.
Syndication Links now supports per-post syndication to Micro.blog from WordPress
In addition to some other useful upgrades and bug fixes, the big new feature this release adds is excellent syndication support for Micro.blog.
While many people use RSS feeds, JSONfeed, or other plugin methods for syndicating their WordPress website’s content to Micro.blog, this plugin now provides for a per-post decision about exactly what content to send to Micro.blog. It also naturally provides a syndication link from your site back to the Micro.blog post. To my knowledge no other method provides this syndication link functionality.
As I suspect many may already be aware, if your site supports Webmention (typically done with the Webmention and Semantic-linkbacks plugins), then Micro.blog will notify your site with replies and comments to your post as they appear on Micro.blog. This provides one the ability to do two-way communication between the two platforms.
Set up and configuration for Micro.Blog syndication
If you don’t already have it, install the plugin and activate it, otherwise update it within your site’s administrative interface.
Add your Micro.blog account username to your user profile on your WordPress site. This is typically found at /wp-admin/profile.php
. In my case I simply added c
to the field labeled Micro.blog username.
Adjust your WordPress Syndication Links settings page (typically found at /wp-admin/admin.php?page=syndication_links
) to include Micro.blog by using the appropriate checkbox. Be sure to save the setting.
Remove, if necessary, any of the RSS, JSON, or other syndication feeds from your Micro.blog account so you’re not accidentally duplicating the syndication.
Add the JSONfeed URL from the bottom of the Syndication Links plugin settings page into your list of feeds at https://micro.blog/account/feeds.
Create a post, select Micro.blog as an endpoint in the relevant meta-box, and publish your post.
Once published, your post will ping Micro.blog’s server to indicate the new content which will then be displayed in your timeline. The Syndication Links plugin will then find the permalink URL of your post on Micro.blog and display it on your post (as per your settings) along with any other syndicated copies. This notification process is roughly real time, but may take a minute or two for your post to display and the syndication link to appear on your site based on the processing times on the relevant servers.
As an added bonus, Syndication Links plugin will also find the syndication links from Micro.blog in your current feed and add those to your original posts.
If you have any questions, need clarifications, or find bugs with regard to your set up, you can file issues for the plugin on GitHub.
A manual tweak for icons in the Syndication Links plugin
Within the code at class-syn-link-domain-icon-map.php, I added the following two lines to the obvious spot in the list within the code to fix the icon issues I was having:
'chrisaldrich.wordpress.com' => 'wordpress',
'reading.am' => 'book',
I then reuploaded the edited file to my server. Essentially I’m hard-coding the domain name and the default icon I’d like to have the plugin display.
If the plugin is updated, I’ll obviously have to manually add them again, but the disappearance of the icons again will be pretty obvious and this post will document the necessary changes.
Although upon tweaking this I’m noticing that the reading.am icon isn’t working (I also tried ‘website’ instead of ‘book’ but that didn’t work either). Perhaps the .am tld is causing an issue? Alas…
I suspect that there’s some other bug hiding in the works as one or both of the two types of links above should default to the generic ‘website’ icon when a syndication link exists, but the system isn’t able to specify a particular icon. There may be some small if/else bug hiding in the logic of the plugin.