Topic-icon Inferred Property: The 'og:image' property should be explicitly provid

Support Specialist
Antonio,
I just got into the admin area of your site. I ran JFBConnect's Autotune, and it specified that the sh404SEF Social Buttons plugin was enabled, and should be disabled. I removed that, since it conflicts with Facebook integration.

Then, I went to the following articles, and all of them have the correct og:image tag if you open the HTML and look at the contents (search for og:image):
/POLITICA/relator-de-mp-da-seca-quer-associar-credito-com-medidas-para-evitar-endividamentos-de-produtores.html
/MERCADO/emenda-sobre-imposto-para-comercio-eletronico-nao-ameniza-guerra-fiscal-dizem-tributaristas.html
/POLITICA/sarney-diz-que-cpmi-do-cachoeira-tem-autonomia-para-atuar-no-congresso.html

However, there's a few things I see that are causing problems:
1) On the pages above, the og:image tag is *only* included if I'm logged in. If I go to the page not logged in, the og:image tag is missing. What are you using to check if the user is logged in? I believe that's altering the article in some way that's preventing JFBConnect from detecting the image. Can you disable that feature (temporarily) and see if the image detection works? If so, let us know what you're doing so we can investigate further.
2) On you're article pages, you're re-including the Facebook Javascript library multiple times (the 'all.js' file). This should only be included once on the page. I'd recommend removing the other instances, as they will cause issues with logging in and other features. I don't believe they are causing the Open Graph issues though.

Hope that helps,
Alex
The topic has been locked.
Active Subscriptions:

None
Hey man every penny paid for this subscription is 1000% Worth I will give some feedbacks around about you!
I will investigate all the precious information you gave me, and i will come back shortly to you.
Many thanks!
Antonio
The topic has been locked.
Support Specialist
Glad to hear you're happy, and definitely hope our investigation helps you get to the bottom of the problem. If you run into any questions, just let us know!

Finally, once you've used JFBConnect for a bit, please consider leaving a rating and review on the Joomla Extension Directory for it, or our support. It's certainly not required, but very appreciated:
extensions.joomla.org/extensions/social-...ook-integration/7215

Thanks!
Alex
The topic has been locked.
Active Subscriptions:

None
Hi Alex,
we are working for eliminating the various all.js instances as you suggested...
Now the strange stuff:
for preventing users to access content without login...we use...Joomla access system...!!
and to let user register and access we use...JCLogin from JFB Component...!! :D
I took an article:
/NACIONAL/investir-em-educacao-e-saude-de-criancas-e-atacar-desigualdade-na-raiz-destaca-dilma.html
and changed access level from "registered" to "public" (from article panel)...
and worked! the og:image is correctly displayed.
Your component give a full user access / registration that perfectly integrates with Joomla user management system, using facebook login...
Is it possible that it does not work with content that are just for registered users?
Am I the only one that have this big issue related to images?
The issue is blocking because if the crawler/script (that one which is responsible for scan an article, find the first image, and create the og:image meta property) does not work when a Joomla article has access level set to "registered", it makes no sense to use that automatic function.
In fact if I want an user to login /register, it's because there is something in terms of content that is just for him (as registered).
This is a function that was born with Joomla (set an article permission as registered).
Moreover, the fact that the crawler does not work over content for registered user, create a cascade of negative effects:
1)when a user post a comment over an article for "registered" users, on his facebook wall is published a totally random image;
2)on reccomendations module, images associated to articles are wrong;
3)on every aspect of the Component that involves images, that images are wrong....
4)even if a user login, the image is not correctly shown in comments/reccomendations/etc...
I think we can start investigating from the fact that other parameters, such as "title" are correctly fetched from article (also registered), the only thing that is not is the image (og:image). I think it's something with your code, but I don't know, really...
Now: the milion dollar question: how to solve? Put a manual reference to the og:image for each article will triplicate the workout.
If you explain to me which script/files are involved into the process of scanning pics from articles, I can ask our engineers to take a look on it, maybe we can also help to find a solution.
Thanks, Antonio
The topic has been locked.
Active Subscriptions:

None
Another information, i don't know if that can help: the images are generally put before the readmore button.
The topic has been locked.
Support Specialist
Antonio,
We're doing more testing with the J2.5 and registered articles in public category layouts. The image should definitely be before the readmore button for our code to work. If it's not, that would be part of the issue. The Content plugins are sent the contents of the article, as it would be displayed to the user, so if that doesn't include the image, that's why JFBConnect can't detect it.

As for JFBConnect working with registered content, that shouldn't be a problem at all. I believe you are using the "Use beginning of article as description" Open Graph setting, which is working. So, JFBConnect is accurately seeing the article, just not the image.

Finally, yes, unfortunately you are the only user that's reported this issue. We haven't heard this reported by any other users, which is why it's a bit more difficult to narrow down.

We'll let you know what we find, but please verify that the image is within the readmore text for now.

Thanks,
Alex
The topic has been locked.
Support Specialist
Alright, Antonio, got something for you to try. We've done a bit of testing now and can recreate the error if the article is set to registered, but the view is public, so that just introtext is shown. This isn't a way we were testing before. While it's a great feature of Joomla, it doesn't seem to be widely used by our subscribers.

To fix, please edit libraries/sourcecoast/articlecontent.php. At line 188, remove the "else" in the line "else if (isset($article->introtext))" to be "if (isset($article->introtext))"
When done, the full function should look like:
private static function _prependToIntrotext(& $article, $fbText)
    {
        if (isset($article->text))
            $article->text = $fbText . $article->text;
        if (isset($article->introtext))
            $article->introtext = $fbText . $article->introtext;
    }
This change will not be in the 4.2.2 release, coming out later today or tomorrow. There's simply not enough time to test it and verify it won't cause other issues.

Please let us know how it goes for you though.

Thanks,
Alex
The topic has been locked.
Active Subscriptions:

None
Hi Alex, and thanks for your support. For some reasons we encountered difficulties in make plugins working on registered content.
So we temp solved the issue creating a function that automatically search for pic and create the meta property "og:image" directly using template.php.
So we achieved our result, but i will test your solution and let you know.
Thanks, Antonio
The topic has been locked.
Support Specialist
Antonio,
Glad you got something going. We definitely tested our solution a bit, and it works on a standard Joomla installation. Other plugins and extensions could always cause issues, but we think it's a pretty good solution for what you mentioned.

When you do get around to trying it, please let us know how it goes!

Good luck,
Alex
The topic has been locked.