I love how Greg has implemented Reply on Mastodon on the individual posts. Considering that we have Reply by Email and Conversation on Micro.blog, is there a possibility for a ‘Reply on Mastodon’ plugin that pulls in the account we have linked in our cross-posting settings?
It’s definitely possible. Until someone eventually makes it a reality, Greg shares the solution in his blog post:
<a href="https://{{.Params.mastodon.hostname }}/@{{ .Params.mastodon.username }}/{{ .Params.mastodon.id }}">Reply on Mastodon</a>
In your custom theme, paste that snippet where you want the link to show up. Probably in a template named layouts/post/single.html or similar.
If you only cross-post some of your posts, you might want to check for the presence of .Params.mastodon.id and only print the link if it’s there. The below code should work, but I haven’t tested it:
{{ with .Params.mastodon.id }}
<a href="https://{{ $.Params.mastodon.hostname }}/@{{ $.Params.mastodon.username }}/{{ . }}">Reply on Mastodon</a>
{{ end }}
1 Like
Thanks. So if I wanted to add it to the end of every individual post, I just cut-paste the first bit of code?
And happy to contribute financially, if you choose to make it a plugin 
Yes, the first snippet is enough if all your posts are cross-posted to Mastodon.
That’s very kind of you, but I’m not a Mastodon user myself, so I should leave this one to a developer who’s better equipped to actually develop, test, and maintain the plug-in.
2 Likes
Thanks @sod , however I was unable to get it working using the with block.
I ended using
{{ if isset .Params.mastodon "id" }}
<a href="https://{{ .Params.mastodon.hostname }}/@{{ .Params.mastodon.username }}/{{ .Params.mastodon.id }}">💬 Reply on Mastodon</a>
{{ end }}
1 Like
Thanks for this. This worked for me too.
For those of us who don’t cross post and just use the native Mastodon integration, I wonder if there’s a way for a button like that to open the post in a reader’s Mastodon instance for them to reply. I imagine it would be difficult because you wouldn’t know their server. But maybe there’s a way?
Thanks for letting me know. I’ve updated my post with what I think is a working example now (I had missed a couple of $ signs.)
You would have to find a pretty severe security/privacy bug/leak in the Mastodon software to be able to pull off something like that. 
And if you did, and the visitor was signed in on more than one instance, which should you choose to redirect to?
In theory, the button could ask the visitor for their instance and redirect them that way. (Like the remote follow feature.) The problem is, Mastodon servers on a version earlier than 4.0 would just redirect them back to Micro.blog.
So, to answer your question, there’s a way, but it’s clumsy and won’t work in all situations.
Folks, I’m creating the plugin so that it’s easier for everyone to integrate the button on their blogs. Please send me your GitHub username so that I can add you all to the repository as authors.
For now it’s just the core of it. I still have to write the README file with information on how to integrate the plugin with the blog theme.
I’ve also submitted a Pull Request to add it to the Tiny Theme (theme which I currently use in my blog).
Cheers,
OC
5 Likes
That’s kind of what I thought. Probably best to wait a while and let things shake out…although that remote follow stopgap doesn’t sound terrible. At least it’s actionable!
I’ve added the README file. Let me know if you have any suggestions for it.
For those experienced with the Hugo architecture, how does a plugin or a Hugo template gain access to all these parameters, including the Mastodon post ID, when the page is constructed prior to the post being cross-posted to Mastodon?
I encountered an issue yesterday when I published a new post; it didn’t display the “Reply on Mastodon” link at the bottom of my post. It only appeared after I rebuilt the blog.
You don’t, unfortunately. It’s impossible; you would literally have to invent time travel to be able to get the Mastodon post ID before it gets cross-posted to Mastodon. We, as third-party developers, can only make users aware of the problem and tell them to force a rebuild when it happens.
In theory, you could add some JavaScript to your plug-in that checks for the Mastodon ID from the visitor’s browser. But I don’t think there’s any API that exposes that information. I could be wrong, though.
@manton, however, has control over the build environment and could mitigate this in a couple of ways:
- postpone the build step until all cross-posting has happened, or…
- trigger a (full or partial) rebuild of the site when cross-posting is done.
I think @sod’s #2 option is a good one. I’m going to make that change so that it republishes the site after the cross-posting is completed. I’ll roll it out within the next day.
Wish I had time to work on time travel too. That is unfortunately outside my skillset. 
2 Likes
That would be so cool, though! Your next Kickstarter. 
When I asked about the Hugo architecture for plugins, I had hoped to learn about configurations or mechanisms that could be used to selectively reconstruct content based on specific rules.
Picture Hugo in the process of assembling a blog, followed by a pipeline of plugins that modify content sections, all without necessitating a complete blog reconstruction.
These plugins would be assigned a priority value to determine their execution timing. Lower priority plugins, for example those handling minor updates like adding a button or text, could run after the cross-posting step.
If we can’t build a time machine, we can fake it
Yeah, that’s not really how the build pipeline or plug ins or Hugo works. The closest thing to something like that would be things like Render Hooks, but even that doesn’t really change it in a sequential fashion. The bottom line is Hugo, as a static site generator, requires information at build time to impact your site. Without javascript, even with some cool things they have like hitting APIs, you’re just gathering data at the point of the build and building. All of the sequencing/queuing etc is Micro.blog code and not the Hugo build that we’re touching with Plug-ins. So things like “cross post first so that the ID is available as meta data” isn’t a plug in thing, since cross posting requires building your site content, which use Hugo, which then generates the blog (not exactly, but close). And I don’t think Manton would want to cross post then publish because then you could cross post without a post that can publish because of an error down the line. And you also can’t get micro.blog permanent link until you build the site either for linking to long posts.
Etc etc etc.
This is all limitations of static sites, though there are meaningful benefits that are worth the costs IMO.
Manton, perhaps it would be more prudent to remove the plugin rather than incorporating this change into Micro.blog. Rebuilding the blog incurs a cost, both in terms of time and money, and carrying out a complete rebuild for every cross-post on every blog with cross-posting enabled could result in substantial overhead.
People can still make the desired modification directly to their blog theme. And they can manually initiate a rebuild whenever they deem it appropriate.
I want to continue to improve Micro.blog publishing so that clicking “rebuild” is needed only very rarely. So let’s keep the current setup that now rebuilds the site automatically after cross-posting. I think that is the most consistent behavior that people will expect.
I love that there are plug-ins like the Mastodon one for doing something with the cross-post data!