hi Brajesh,

yes, the images are “linked to media” as per your screenshot.

It is important in this case to note that all the blogs on my site are built using the buddyBlog and SFEP plugin from buddyDev, from the FRONT END. My users simply use whatever the buddyBlog interface provides them, automatically sets for them, on the front end.

R.

yes, but I think that’s just “post_type=post”, which is fine, but doesn’t help us identify buddyblog itself 🙂

hi Brajesh,

I understand it’s not simple to understand 🙂 There is a ticket, for the WPSSO plugin, which I have opened and may help with clarifying what the issue is.

http://support.surniaulula.com/support/tickets/4684

Essentially, WPSSO *assumes* that if an item is a component therefore it is also an activity. I think this assumption is wrong. For instance a member is a component, but a member is not an activity. It is the same with the buddyBlog, I think, as imho. buddyBlog is a component but not an activity. Their logic seems to be:

if component {
  therefore activity 
}

I think it should be:

if component {
  may be activity
}

The problem is with WPSSO-RRSSB-Free which displays buddyBlog share links in the free version, (which does not support buddyPress). and WPSSO-RRSSB-Pro which does NOT display buddyBlog share links, (and does support buddyPress). It’s weird, I know 🙂

R.

• This reply was modified 6 years, 3 months ago by Richard Foley.

yep, I see your reasoning. Given that my existing (u)likes are also in (to mediapress) unknown tables, if existing (u)likes were to be brought across, then this might be a moderately simple SQL operation. Although on each site, it would be different plugins/tables, so we can’t expect mediapress to handle that in any case.

Ok, thanks for the feedback, this is helpful to locally plan ahead.

yes, Brajesh, I’d forgotten about the Oembed link. I think the placeholder text is fine as it is. The error message could mention both the two types of link: direct link (jpg, etc) and Oembed. That might make things much clearer.