UX: Bridgy to Twitter makes some unfortunate default photo choices

[chrisaldrich]

I'm using WordPress and https://github.com/dshanske/bridgy-publish/ in my workflow. I like that brid.gy allows for up to 4 photos and how they're laid out, but we (WordPress users) may need some additional control over what photos are chosen by default...

Crossposted from dshanske/bridgy-publish#10 (comment) as well.

Surely I should have put in a featured image, but otherwise it's grabbing multiple low res photos on the same page (in widgets, footer, or from gravatar author block) which don't correspond well with the content :

Maybe default to none if not a featured image or appearing within the_content()?

[snarfed]

oops! heh, that is indeed unfortunate.

looks like your site's h-entry is too broad. it's currently on body, which means bridgy thinks everything on the page is part of your post, including the u-photos in your own h-card and your site's footer. if you narrow your h-entry to just your actual post content, that should prevent this.

background:
http://microformats.org/wiki/h-entry#Example
http://microformats.org/wiki/h-entry#u-photo
http://indieweb.org/photo#Distinguishing_Photos_from_Notes

[snarfed]

sorry, i misspoke a bit. the two avatar pictures with u-photo are from your author-info section (maybe gravatar author block?) after your e-content, not your h-card.

[dshanske]

I picked up the h-entry on the body practice from @pfefferle . I always assumed best practice suggested that it be on the top level element. Will revisit.

[snarfed]

it's definitely unusual, but you can probably make it work if you want. you'd just need to remove u-photo from those three images. (it shouldn't be on them anyway. :P)

[tantek]

@chrisaldrich, @snarfed is right. The name of this issue is misleading, as "some unfortunate default photo choices" is not true at all, but rather, it is your site that is making some unfortunate default photo markup choices. Sounds like Bridgy is doing the right thing and paying attention to the markup as it's coded in your site. I couldn't find the permalink of your post to look at the markup. Could someone post a URL that has the microformats markup on it so we can look at it?

[snarfed]

@tantek http://boffosocko.com/2016/07/28/ten-simple-rules-for-taking-advantage-of-git-and-github/

[dshanske]

The issue with the avatar is it always assumes an avatar is inside an h-card. Will have to rethink that assumption.

[chrisaldrich]

Thanks everyone for taking a look and for the help!

Apologies if I offended anyone -- without having read through any of the brid.gy code, I wasn't quite sure what was going on. My suspicion for a while has been that using the uf2 plugin for WordPress certainly isn't quite always the best, though it's fairly impressive what it will allow. I've been hacking around at a new/different theme that adds microformats directly rather than programmatically to have greater control of exactly where they're put, but it's also a one-off solution rather than a solution for the masses. Better microformats injection into themes is certainly a small stumbling block for coming generations.

I was previously aware that the entry-content div on my theme overextended itself (WordPress/twentysixteen#470), but didn't realize that the hentry/h-entry was being injected too early via uf2.

I saw some of the resulting discussion in the #indieweb-dev channel, so I'm glad my beastly banging on and breaking of things may help improve things for coming generations. ;)

@dshanske We should remember to ping the Independent Publisher theme if you decide to make changes, as I suspect it'll have the same issue(s). It's been a while since I looked at the code for it, but I recall he created a mf2.php in the theme to inject microformats similarly to uf2 or one of your recent blogposts.

[snarfed]

np @chrisaldrich! and heh, i use the uf2 plugin too, and i just checked my own site, and sure enough, i have h-entry on body too. :P i just don't have extra u-photos. i shouldn't have been so quick to blame body!