Webmentions failing sporadically · Issue #682 · snarfed/bridgy https://github.com/snarfed/bridgy/issues/682

Sometime in the last week I find I'm sporadically missing webmentions from both Twitter and Facebook. It doesn't happen all the time, but I feel like I'm missing about a quarter or so of what should be coming back.

I've tried resending them through the brid.gy UI and it seems they then make it about 50% of the time.

The responses I'm seeing on those that fail are similar to the text below

> 2016-07-11 09:48:49.613280 I Giving up this target. {'body_json': {u'error': u'Could not find WordPress.com account for boffosocko.com. Is it registered with Bridgy?'}, 'code': '...', 'request': u'POST https://www.brid.gy/webmention/wordpress (with source=https://brid-gy.appspot.com/react/facebook/5410052/10101051440366925/10152707877027963/10101051440366925_wow_by_10152707877027963, target=http://boffosocko.com/2016/07/10/lunch-at-wordcamp-orange-county/)', 'http_status': 400}

This appears to me to be that Brid.gy thinks I have a WordPress.**COM** account rather than a self-hosted .**ORG** version. I'm unsure what could be causing this and don't seem to find any type of commonality for why some fail while others go through.

I just saw a session at WordCamp Orange County on Elastic Search (http://www.elasticpress.io/ with https://github.com/10up/ElasticPress) that was able to scrape/sync SQL databases and provide incredibly fast google-like search as well as predictive search (10up had a separate Github respository for predictive search I think). This might be an interesting additional alternative with relatively low overhead.

UX Suggestion · Issue #3 · kshaffer/hypothesis_aggregator https://github.com/kshaffer/hypothesis_aggregator/issues/3

Towards the end of using this plugin as part of an online "notebook" or commonplace book, it would be nice to have finer control over the listings of the annotations.

As an example, look at: http://boffosocko.com/2016/06/18/a-new-thermodynamics-theory-of-the-origin-of-life-quanta-magazine/
The original post was a "bookmark" to an article which was then annotated, solely by me. When embedding the annotations (in this case the shortcode included one author and one specific tag), it becomes overly redundant to repeatedly include that the annotations were by me, that they're from the same article, and including the picture multiple times. As this is likely a frequent use case for such a plug in, perhaps when the same annotator is repeated all the annotations could come under one heading and similarly if it's the same article, those could be concatenated along with just one photo as well.

Suggested output:
TITLE OF PAGE1 | #
PHOTO from PAGE1
Annotations by AUTHOR1:
- annotation 1 from PAGE1
- highlight 2 from PAGE1
- highlight 3 from PAGE1
- annotation to go with highlight 3 from PAGE1

TITLE OF PAGE2 | #
PHOTO from PAGE2
Annotations by AUTHOR1:
- annotation 1 from PAGE2

Annotations by AUTHOR2:
- annotation 2 from PAGE2
- annotation 3 from PAGE2

This type of logic isn't too difficult given the current configuration though it may require some thought for the pending changes to add and/or functionality for multiple authors and multiple tags.

One particular hurdle may be cases where the order of annotations could potentially tell a "story" and even more so when there are multiple authors providing multiple annotations (for example when using this in a classroom setting versus a single-author notebook.)

Providing a visual indicator like # which includes a wrapped permalink URL for the particular article could allow the user to also quickly jump to that page and see the broader flow of annotations on a single page, especially in a classroom type setting where dozens of students may have made hundreds of annotations which may provide a slightly better contextual UI experience, while still allowing the (shortcoded) web page to include all of the annotations for historical purposes.

Loqi barfs up useless retweet title in IRC · Issue #14 · kylewm/KnownReactions https://github.com/kylewm/KnownReactions/issues/14

Last night I'd retweeted something that made total sense to me and looks reasonable when viewed directly on my site http://stream.boffosocko.com/2016/repost-of-kevin-markss-tweet-1e9b300e28, but it may be problematic

I imagine that I could do a better job giving a "description" of the tweet rather than relying on the default presented, which would also help in creating a more descriptive URL as well.

The bigger issue is that Loqi (and presumably other sources like feed readers) punt it when reposting from http://indiewebcamp.com/irc/2016-06-15/line/1466059495504 based on cweiske's reaction following it. I'd view it as a bigger issue for Loqi, but in some part it's a UX issue that those using KnownReactions should be aware of.

Maybe using the UI phrase "title" instead of "description" may be more apt and would prompt people to do better than the default.

Alternately, and because the functionally is generally used for Retweets, which are such short pieces of content, I look at the reposted content in the "body" as the technical "title" which may also be more useful as the permalink/URL as well.

Potential future features · Issue #2 · kshaffer/hypothesis_aggregator https://github.com/kshaffer/hypothesis_aggregator/issues/2

This plugin is spectacular by the way... Here are some thoughts on future development:

It would be great if the displayed text output from the shortcode included a permalink to the original annotation on Hypothesis. As a UI suggestion, perhaps you could place it after the title of the annotated page thusly:
URL WRAPPED TITLE | < a href="permalinkhere">#</a>

Being able to circumscribe dates for displayed annotations could be useful, particularly in cases where one wants to highlight only a handful of annotations from a particular user with a particular tag but specific ones within certain time parameters. Additionally pages with embeds could, over time, require importing huge numbers of annotations which may not be ideal, or the context may change with significant future annotations that aren't relevant to what could be a static post that's trying to highlight just a few particular annotations. Time parameters could also prevent future possible spam on unwatched embeds with only "tag" parameters that could be targeted by bad actors.

Issue un-authenticating while moving from one site to another · Issue #29 · aaronpk/OwnYourGram https://github.com/aaronpk/OwnYourGram/issues/29

I was moving my Instagram posting target from a WordPress install to a Known install.

For my WP install, on IG I revoked access from OYG and then reauthenticated for my Known site at http://stream.boffosocko.com. However, I'm still getting micropub posts to the WP install at www.boffosocko.com. (Note that I would like to keep both sites listed in my Instagram profile/bio, if that makes a difference.)

Is there something else I need to do to deactivate ownyourgram from publishing to my WordPress install?

Is it possible that OwnYourGram holds the same authentication for two separate sites using the same Instagram account? This could mean that one would need an "off" switch through the ownyourgram interface to deauthorize one site. It could also separately be the case that Instagram didn't flush a cache which allowed my last IG post to the WP site to slip through.

Class entry-content div contains too much · Issue #470 · WordPress/twentysixteen https://github.com/WordPress/twentysixteen/issues/470

It appears that the <div class="entry-content"> spans more content than it should. (I'm actually a bit surprised that a modern facing theme like TwentySixteen doesn't fully support [microformats 2](http://microformats.org/wiki/microformats2) instead of the older microformats1 spec.)

Specifically I think that the entry-content div should end before the following functionalities when they're included:
<div class="sharedaddy> (Jetpack's Share This functionality),
<div id="jp-relatedposts"> (Jetpack's related posts functionality)
<div class-"author-info"> (Gravatar author information)

Essentially the semantic class "entry-content" should only contain the content written in the body of a post by the user and shouldn't really include the additional information by these other plugins.

As an example, by having entry-content include these additional pieces, users, when syndicating content semantically to other services like Tumblr, Facebook, or even RSS readers, will include this additional (often unwanted content). See also:
https://github.com/kylewm/KnownReactions/issues/11#issuecomment-224120974
https://github.com/dshanske/syndication-links/issues/23

Cross Reference: http://microformats.org/wiki/hentry

I'd mentioned something like this a while back at https://github.com/dshanske/syndication-links/issues/23 as I was seeing it in pop up in Woodwind.xyz and a few other places. I'm not quite sure what's causing the problem (which is sporadic and depends on who's resharing or where it's being resyndicated to.) In general it's not a problem with KnownReactions (really), but something to do with the WordPress install/configuration.

I'm hoping that @dshanske and the fix he mentioned clears it up, but if not I'll continue to look into it on the WP side, because I want to get rid of it too. This is the first time I've seen the "related", "author", and "share" this portions show up. Usually it's just the blank "Syndicated to" portions that sneak in. (I've also seen this with POSSE from WP to Tumblr as well as with Woodwind. I haven't seen it happen on many other platforms however.)

Excerpt not copying properly · Issue #7 · meitar/wp-crosspost https://github.com/meitar/wp-crosspost/issues/7

When I do this:
Post something on my self-hosted WP blog without anything in the "Excerpt" field

This happens:
The crosspost that appears on WordPress.com seems to have cut and pasted a portion of the body of the original along with the notice about the original post into the excerpt field.

Complicating things somewhat is that I'm using the 2016 theme which utilizes the excerpt as a magazine-like "kicker" or subtitle, so it publishes the excerpt as a teaser line between the title of the post and the traditional body of the post. With most themes this "bug" isn't as problematic as the excerpt is used as metadata, but in my case it's publishing content in a duplicative fashion.

Example:
Original post: http://boffosocko.com/2016/06/04/55673397/
Syndicated post: https://chrisaldrich.wordpress.com/2016/06/04/55673397/

As an aside, given your personal philosophy and the motivation behind this particular plugin and your tumblr crossposter, if you're not already aware of them, I thought I'd mention the [IndieWeb movement](http://indiewebcamp.com) which is firmly behind people owning their own data (as opposed to corporate silos like Facebook, Twitter, et. al. owning it) as well as their online identities. (It's also part of the reason I've been using this particular plugin). I suspect you'll appreciate their mission and potentially be able to use portions of their opensource code and related work.

Display Text toggle not working · Issue #25 · dshanske/syndication-links https://github.com/dshanske/syndication-links/issues/25

I've updated to the most recent and everything works properly (I've toggled through most, but not necessarily all of the various combinations).

The one that doesn't seem to be working is the "Display Text", which as I recall swapped between the icons only view and the actual text (eg. "Facebook"). It doesn't seem to matter whether the "Display Text" is checked or not, it only displays the icons.

Call to undefined function extract_domain_name() · Issue #24 · dshanske/syndication-links https://github.com/dshanske/syndication-links/issues/24

After updating IndieWeb plugin and Syndication Links I get the following:

Fatal error: Call to undefined function extract_domain_name() in /wp-content/plugins/syndication-links/includes/class-syn-meta.php on line 52

This shows up in the page display where the content is usually otherwise output, so I still get the featured image, but no content and the error appears instead.

If I check the box for "Disable Syndication Links in the Content" the error disappears, but of course then the links don't show up on the page.

Cannot redeclare class RelMe_Widget · Issue #36 · indieweb/wordpress-indieweb https://github.com/indieweb/wordpress-indieweb/issues/36

Just updated to the newest IndieWeb plugin and got:
Fatal error: Cannot redeclare class RelMe_Widget in /wp-content/plugins/indieweb/includes/class-relme-widget.php on line 87

I hadn't gotten a chance to do the update to Syndication Links yet. Could that be related? Do they both need to be updated simultaneously?

So it sounds like you really want is the https://wordpress.org/plugins/syndication-links/ which will give you a field under your content to show where the content was syndicated to (and properly mark the links up with rel-me).

I don't think brid.gy automatically puts the syndicated link into the field, so you'd have to do it manually. Other plugins like Social Network Auto Poster (SNAP) or using micropub with clients like OwnYourGram or OwnYourCheckin have intercompatibility with Syndication Links and those URLs will be sucked in automatically.

If you find issues like this, please file them in the github issues repositories for the appropriate plugin so that the issues are known and can potentially be fixed. (Naturally if you can code well enough, you may be able to patch them with a pull request too.)

B0RG, if you need it you can read some of the details I've sketched out at:
https://github.com/chrisaldrich/wordpress-indieweb/blob/ee1cfb72203f1feef05b9225c4bb465abc82e094/readme.md

Let us know if you need any additional help!