I'm certainly not defending the practice. I don't like repeated pull quotes either, and prefer to use highlight quotes that supplement the text without repeating myself (and I use a CSS class called pullquote to do so.)

I suspect that in an era where TL;DR is the norm (has anyone thought about naming this "Generation TLDR"?) they're mostly used to get 1% of the audience to read something more than the headline and see the featured photo before retweeting or posting to Facebook. Unfortunately, we're apparently part of the 0.001% that bothers to read through an entire post anymore, so we're the only ones to notice the UX problem.

Maybe being able to embed a pull quote in a title would help fix the issue?!

I think that for many, the advent of responsive design has done great things, but things like this fall through the cracks in the process. It would be nice if mobile displays would automatically redact CSS classes that are used in this manner as part of their workflow. I find the logic about as smart as including bulky javascript widgets for sharing articles to Facebook, Twitter, et al on mobile when almost all users will use the built-in mobile sharing ability instead.

Maybe the new AMP spec can help publishers to automatically remove these repetitive type of pull quotes for the next generation?

After upgrading yesterday to both WP 4.6 and SNAP 3.6.8 (pro), I'm getting the following error when publishing new posts:

Fatal error: Cannot use object of type WP_Post as array in /homepages/htdocs/wordpress/wp-content/plugins/social-networks-auto-poster-facebook-twitter-g/inc/nxs_functions_adv.php on line 155

The post publishes as expected and then the error is thrown. When reviewing over the post afterwards, it appears that it didn't post to Facebook, Tumblr or Twitter, which had been selected on this particular post.

Like you, I usually don't worry too much about SEO either, particularly for my personal site.

The IndieWeb community has recently been moving domains from IndieWebCamp.com to IndieWeb.org, so there have been some relatively big changes there which have thrown some functionality off. In particular, one used to be able to jump into the chat directly from the web-based chat logs, but that has been turned off (temporarily, I hope). If you don't want to set up an IRC client [details and suggestions are given at https://indieweb.org/IRC], you can also use the more friendly Slack channel as well since the IRC chat is bridged to Slack. Just click on the link on the IRC page to sign up. (I've never been a big IRC fan either, and the fewer chat clients, text messengers, etc. I can have, all the better!)

If you've managed to get WordPress installed, then you've already done the lion's share of the hard work! Most of the rest of "IndieWeb-ification" is done with simple plugins and minimal amounts of configuration. There shouldn't be anything too much more difficult (unless you want to get your hands dirty and do some hardcore coding.)

My main www.boffosocko.com site is a WordPress install, which I usually use for longer form (more interesting??) posts. stream.boffosocko.com is more quick hit content: status updates, checkins, and some photos. I also find it's a bit easier to use on my cell phone than WordPress is. It's built on the Known platform which was built from the ground up in part to support IndieWeb protocols.

If you'd like to join a small group of us in Pasadena on Wednesday night, I'm walking a few new people through some IndieWeb stuff: https://indieweb.org/events/2016-07-27-homebrew-website-club (Facebook copy at https://www.facebook.com/events/1176904038997597/). We can help you walk through the process on your site if you'd like.

I hope to have monthly meetings through the end of the year in the LA area, and there's a bigger IndieWebCamp in Santa Monica in November (https://indieweb.org/2016/LA)

I have just gone through the process of setting up Medium's plugin, so I'm giving that a spin for a couple weeks prior to kicking the tires of SNAP's integration. SNAP has done an excellent job on other platforms, so I'm guessing they're using all the available features there and probably have a stronger 1-1 mapping of data from one platform to the other, particularly as Medium is aiming at WordPress directly first. The one thing you might want to be careful about with Medium is making sure you don't have a "rel=canonical" tag [https://indieweb.org/rel-canonical] showing up on your Medium post, otherwise you might be getting docked by Google and others with respect to SEO. I know the Medium plugin handles this well, but haven't checked on how IFTTT or SNAP handle this yet.

I'm curious what specifically you found confusing about IndieWeb? Some of us in the WordPress group have been trying to make the value proposition and workflow better, particularly over the past several months. (Admittedly, before about April, the onboarding process was MUCH messier and the end user had to do a lot more reading/discovery and work to set things up, but I think the hurdle has moved much lower since then.) If you take a look at it again, I'd love to know where you experience problems/issues, so we can make things better for others. If you need help, there are many of us on IRC [https://indieweb.org/IRC] who can often help in real time.

As for privacy, in general, Facebook, Google+, et all are all public facing networks, so people posting there are really posting for everyone to see in the first place. If they're posting privately, I believe that the IndieWeb protocols respect that and don't import private webmentions. Most of the rest is about data ownership for you and your blog as well as trying to maintain a central repository for your blogs posts of all the conversation taking place around what you're posting. Part of the downfall of social media is that it can often fragment conversations. In some sense IndieWeb helps glue them all back together.

On your last point, I had a bit of cognitive dissonance with this as well when I started into IndieWeb, but I've just streamlined my workflow significantly (and for the better). I've turned off all the emails and notifications from individual social media platforms (at least as they relate to my content) and I rely on my WordPress install to do all the notifications. This way, for example, when someone replies to one of my posts on Facebook, I see the webmention via WordPress, and then use that to click on the contained link to the reply on Facebook. I'll then reply natively on Facebook so the other party sees it there (typically by Facebook notification), but then the IndieWeb backend ports over my comment back to the comments section of my own blog. My "audience" can follow me on their platform of choice, and I can still interact, but I still own all the resulting data: Win-win-win!

Mitch, I also love SNAP! If you didn't see it, they added Medium support in their last update after Medium released their write API. Medium also has their own WordPress plugin which will allow you to broadcast there easily and quickly too.

if you're game, there's a few other tools you might think about adding to your workflow:
First you should know about http://indieweb.org and take a look at their WordPress section at indieweb.org/WordPress. It'll help you more easily suck back likes and replies of your syndicated posts to Facebook, Twitter, Google+, et al. so that you own all the data and comments from them. (This will also make your blog look more "lived in". They've got a cool range of other nifty tools for making/using your WordPress blog -- all of them free.

One particular one that integrates well with SNAP is Syndication Links [https://wordpress.org/plugins/syndication-links/] which pulls in the URLS of the social sites you send your content to with SNAP and displays them under your content so you (and others) have a better idea of where you've sent them in the past.

Syndicated copies to silos include "Syndicated to:" text · Issue #32 · dshanske/syndication-links https://github.com/dshanske/syndication-links/issues/32

Similar to this issue with Jetpack: https://github.com/Automattic/jetpack/issues/4399

The text output from Syndication Links (the default text "Syndicated to:" ) shows up in the syndicated copies (and I'd generally think that most wouldn't want it from a UI/UX perspective). I've tried syndicating to most of the major platforms and Facebook and Tumblr appear to be the primary offenders.

Example:
Original: http://boffosocko.com/2016/07/16/the-indieweb-ified-library/
Syndicated Tumblr Copy: http://chrisaldrich.tumblr.com/post/147515812392/the-indieweb-ified-library
Syndicated FB Copy: https://www.facebook.com/ChrisAldrich/posts/10101055831666725?pnref=story

Perhaps the checks and the patch mentioned in https://github.com/Automattic/jetpack/issues/4399 could provide a solution?

@jeherve, It would appear that that patch seems to take care of the issue. I ran a few quick tests on some variations on the settings and didn't see the offending sharedaddy div appear after the patch was applied.
Compare: http://boffosocko.com/2016/07/19/the-memory-palace-of-matteo-ricci/ and http://chrisaldrich.tumblr.com/post/147683457752/the-memory-palace-of-matteo-ricci

I'll test a few additional things over the next few days (I recall another social platform acting somewhat like Tumblr had, but don't recall which at the moment), but otherwise this seems to fix things.

@dshanske Perhaps these same types of checks (or the patch code mentioned) could serve as a template to prevent the similar issue within Syndication Links which shows "Syndicated to" on several platforms including Tumblr and Facebook. I'll open an issue there as a reminder.

@djsardine @owenpeery I'm happy to help you both set up a personal website if you're interested. Alexander, I could do it at the HWC mtg coming up on 7/27 (that I'd mentioned). Owen, if you're on WordPress, you can prettily easily add some IndieWeb goodness to what you've already got, then syndicating your work from there out to silos like Facebook, Twitter, Medium, etc. (for the extra reach) is pretty easy.

Syndicating WP content to Tumblr includes sharedaddy div · Issue #4399 · Automattic/jetpack https://github.com/Automattic/jetpack/issues/4399

<!-- Thanks for contributing to Jetpack! Pick a clear title ("Sharing: add new Facebook button") and proceed. -->

#### Steps to reproduce the issue
I'm using Social Network Auto-Poster [https://wordpress.org/plugins/social-networks-auto-poster-facebook-twitter-g/] (rather than Jetpack's Publicize because it includes more control over post types and additional platforms) to syndicate my WP content to my Tumblr. I'm using their standard "Text Post" option with the text set to include `<p><img src='%IMG%'/></p><p>%FULLTEXT%</p>`

#### What I expected
The copy on Tumblr should simply transfer only the user's input in the post from WP into the Tumblr post.

#### What happened instead
I get the content of the post, but I'm also getting a div with all the class=sharedaddy etc. (see below) appended to the bottom of the post which generates the Like prompt/button/functionality and the word "Loading...". (Example: See bottom of http://chrisaldrich.tumblr.com/post/142661877457/a-new-view-of-the-tree-of-life which was syndicated from http://boffosocko.com/2016/04/11/a-new-view-of-the-tree-of-life/)

Here's the HTML that's being copied over and displaying unnecessarily.
`<div class="sharedaddy sd-block sd-like jetpack-likes-widget-wrapper jetpack-likes-widget-unloaded" id="like-post-wrapper-67433065-0-570c56a68fcae" data-src="//widgets.wp.com/likes/#blog_id=67433065&amp;post_id=0&amp;origin=boffosocko.com&amp;obj_id=67433065-0-570c56a68fcae" data-name="like-post-frame-67433065-0-570c56a68fcae"><h3 class="sd-title">Like this:</h3><div class="likes-widget-placeholder post-likes-widget-placeholder" style="height:55px"><span class="button"><span>Like</span></span> <span class="loading">Loading...</span></div><span class="sd-text-color"></span><a class="sd-link-color"></a></div></div>
`

Generally, this doesn't happen when syndicating content like this into other platforms (though this could be because other platforms, Facebook for example, may be stripping out all other html and thus precluding this). Additionally, for example, it's not copying over Jetpack's "Share This" or "Related" posts content which also sit inside the main `<div class="e-content">` which I suspect is the general section being copied over.

In short: Why is the "Like" functionality being copied over while "Sharing" and "Related" aren't?

<!--
PLEASE NOTE
- These comments won't show up when you submit the issue.
- Everything is optional, but try to add as many details as possible.
- If requesting a new feature, explain why you'd like to see it added.
- This issue tracker is not for support. If you have questions about Jetpack, you can [start a new thread in the Jetpack support forums](http://wordpress.org/support/plugin/jetpack#postform), or [send us an email](http://jetpack.com/contact-support/).
- Do not report potential security vulnerabilities here. For responsible disclosure of security issues and to be eligible for our bug bounty program, please submit your report via [the HackerOne portal](https://hackerone.com/automattic).
-->

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.