Webmention send to brid.gy only triggered when syndication link inline of post

[nysander]

I found an issue when webmention send to brid.gy is triggered only when I paste syndication link inline like in post below:

---
layout: note
date: 2019-09-14 22:44:00 +0200
categories: note
---
This is only test, nothing to read ... do not disturb yourself :)

This will be sent to brid.gy
[](https://brid_gy/publish/twitter)  << dot "." replaced with underscore "_" to not send this issue to twitter ;)

When there is no link like in this example:

---
layout: note
date: 2019-09-14 22:44:00 +0200
categories: note
---
This is only test, nothing to read ... do not disturb yourself :)

this will not be sent to brid.gy

Webmention is not sent using jekyll webmention command beside of the fact that my template looks like this:

---
layout: default
---

<article class="h-entry my-2 row">
  <div class="col-sm-2">
    <a href="{{ site.url }}" class="p-author h-card">
      <img class="u-photo rounded-circle img-thumbnail" style="width: 100px" src="{{ site.url }}/assets/img/pawelmadej-profilephoto.jpg" alt="{{ site.author.name }}" />
    </a>
  </div>
  <div class="col">
    {% if page.reply-to %}
    <p>In reply to: <a href="{{ page.reply-to }}" class="u-in-reply-to">{{ page.reply-to }}</a></p>
    {% endif %}
    <div class="p-name e-content">
      {{ content }}
      <p>{% for hashtag in page.hashtags %}#{{ hashtag }}{% unless forloop.last %}, {% endunless %}{% endfor %}</p>
    </div>
    <p>Published: <a href="{{ site.url }}{{ page.url }}" class="u-url"><time class="dt-published" datetime="{{ page.date | date: '%FT%T%:z' }}">{{ page.date | date_to_string }}</time></a></p>
    <a href="{{ site.url }}{{ site.baseurl }}{{ page.categories.first }}" class="p-category" hidden>{{ page.categories.first }}</a>
  </div>
</article>

<a href="https://brid_gy/publish/twitter"></a> << dot "." replaced with underscore "_" to not send this issue to twitter ;)

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-issue/)

[nysander]

github broke <> in template source but I think this has no influence on problem understanging

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-issue-update/)

[aarongustafson]

@nysander Does the URL show up in your outgoing webmentions cache file? I did a quick test of the content scanner and it seems to pick up that URL. Perhaps the issue is that URL is not set up to receive them? Can you turn on debugging and let me know what you see?

[nysander]

I have turned on debugging and cleared cache.

this is test post file:

---
layout: note
reply-to: https://twitter.com/PawelMadejCK/status/1172787087441047552
date: 2019-09-14 22:57:00 +0200
hashtags: [ syndication, test]
syndicate: true
categories: note
---
This is only reply test, nothing to read ... do not disturb yourself :)

I have ran bundle exec jekyll build --verbose

result from outgoing.yml

https://www.pawelmadej.com/note/225700/: {}

if you open source of above link you will see that syndication url is under <article> section - this url is from template.

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-issue-reply/)

[nysander]

On the other site please look at for example url:

https://www.pawelmadej.com/note/132100/

it has syndication links two times because I have added one url inside post markdown body and second is from template. and this one was sent to bridgy, previous one not.

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-128/)

[aarongustafson]

I suspect the issue may be that you are using reply-to as a key in the front matter as opposed to in_reply_to which is what the script is looking for. I need to review the docs to see if I need to update them.

[nysander]

this is not an issue, I have that issue also for this github issue, and this comments. And for twitter likes and new “tweets” that do not have at all reply-to

in template source there is microformats class="u-in-reply-to" when it is relevant. where not I do not use it in template and in front matter

https://pawelmadej.com/notes here you have all sources and all those you find on <brid.gy/twitter/PawelMadejCK> or <brid.gy/github/nysander> are only those that have syndication link inside post source. All with template only syndication link are not sent at all.

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-128-2/)

[aarongustafson]

I give this some fresh eyes in the AM.

[nysander]

According to https://brid_gy/about#microformats there is u-in-reply-to microformat not the in_reply_to as in attached source link.

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-128-3/)

[nysander]

I can provide my full template and example files if this will help you in resolving this issue.

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-128-4/)

[aarongustafson]

It might. Or I can check out your project and test a local build.

[nysander]

I have sent you invite. Please consider that for now this repo is private.

(Originally published at: https://www.pawelmadej.com/issue/jekyll-webmentions_io-128-comment-5/)

[nysander]

have you found where is the source of this issue?

[fancypantalons]

So, I think I see the issue, here, as I just ran into it myself.

Fundamentally, the issue is that the webmention gatherer is a Jekyll Generator. As per their docs, generators are run after the content for the site has been identified, but before the site has been generated.

Unless I'm mistaken, that means that "post.content" in the generator, contains the unprocessed markup, rather than the formatted output, and anything that's in the layout file (including, say, URLs to which you want to send a webmention) doesn't appear in the post content.

As a consequence, any Bridgy URLs in the layout are invisible to the plugin and the webmention isn't seen.

The way the plugin deals with this use case is the "in_reply_to" post header, which generates a URI in the webmention cache. But this is only appropriate when the post is, in fact, a reply to another piece of content (a post, a tweet, etc). If you're syndicating original content to Twitter via Bridgy, "in_reply_to" is not appropriate.

I suspect the solution is in enriching the plugin to look for other types of front matter. For example, I could imagine a solution where you have a new bit of front matter that perhaps looks like this:

syndicate-to: [ twitter, github ]

And then a bit in _config.yml:

webmentions:
    silos:
        twitter: https://brid_gy/publish/twitter
        github: https://brid.gy/publish/github

Then update the content scanner to look for the syndicate-to front matter, and if found, have it automatically gather the silo URLs in the webmention cache.

If this looks like a reasonable design, I can throw together a PR.

[nysander]

For me that is fine solution

[aarongustafson]

That’s an interesting idea, @fancypantalons. I like it, although with underscores (_) rather than hyphens (-) in the front matter key name. For the key in the config, I wonder if it might make sense to make the key something like notification_targets, publish_endpoints, or similar. The term silos doesn’t immediately indicate what that configuration option would govern. (Also: naming is hard.)

[fancypantalons]

Naming and cache invalidation... ;)

Great feedback! I have a prototype implementation put together. I'll tweak the names and throw a PR together.

I could see using this same method for publishing to IndieNews, for example, so something along the lines of publish_endpoint--or heck, the obvious now that I think about it: syndication_endpoints--would seem to make sense.

Random aside, there are other targets beyond in_reply_to that would be nice to also support: like_of, repost_of, bookmark_of, tag_of all would result in webmentions and also require properties to properly mark up.

Is there an existing issue covering that? If not, I can put together a separate PR to expand the current in_reply_of logic to handle these other cases (maybe by removing the hard coding and making it configurable).

[nysander]

All your work seems great addition to this plugin for me.

[aarongustafson]

Random aside, there are other targets beyond in_reply_to that would be nice to also support: like_of, repost_of, bookmark_of, tag_of all would result in webmentions and also require properties to properly mark up.

Is there an existing issue covering that? If not, I can put together a separate PR to expand the current in_reply_of logic to handle these other cases (maybe by removing the hard coding and making it configurable).

I’m open to it. Much of the original work had been driven by my own site’s needs, but I’m happy to continue increasing the functionality.