K2 Incorrect Image Shown Using JFBCLike tag

That description comes from the meta description of the page that's being liked. JFBConnect tries to strip out any facebook tags from this description, and I suspect that the logic could be smarter to replace more text from the article.

Could you send me a link to the page you're seeing this on so that I can look at the page source to confirm this is the problem?

Getimo,
This is currently an issue with K2 only that we're investigating. Basically, K2 will take the first 150 (or so) characters from the article and use it as the meta description. When you set the Like button to the top, we prepend our Like button to the article, which then, K2 uses as part of it's meta description. Later on, we do a check to make sure that our Facebook Like button doesn't get inserted into the meta description area in the head of the document, because that can cause bad things. However, that also then removes a large (if not all) of the description from your article.

There's 2 solutions to this that I'd recommend:
1) Increase the meta description length parameter in K2 to something much larger (like 400 characters). This will give ample room for us to remove the Like button while still leaving a valid description.
2) Manually set the meta description on your K2 items. This will ignore our Like button entirely.

We're looking for other automated solutions, but for now, haven't come up with anything that would work well across all sites. Hopefully, one of the above will work for you.

Good luck,
Alex

Getimo,
Currently, JFBConnect only supports the automatic image tag for the first image in a K2 article, not for the Image that can be set with an article. We've looked into supporting that in the past, but it's done in a different (and harder) way that we can't easily access in the content plugin. The same goes for the positioning of the Like button. We put it at the top of the article, but then K2 places the image before the entire article contents, including our Like button. There isn't an easy way around this now, but when we figure something out, we'll definitely implement it.

As for the URL being used, yup, you found a bug. We're not including the alias in the URL for K2 items. We just updated our code for the 4.0 release that's due out tomorrow actually. It's going through testing, but is a pretty minor change, so we don't foresee any problems. There's quite a few other improvements and changes for our K2 integration to make it even more solid.

Hope that answers your questions, thanks for the feedback, and the URL issue will be resolved soon with the next release!
Alex