#7963 – Open Graph Images are broken with 4SEO installed

Hi

Prior to 4SEO installation, all my pages showed the first image of the article, when linking in

Facebook, which is correct.

I cannot comment much without actually looking into it, with 4SEO enabled at least.

Which extension are you using for this right now?

This is not what I expected. Is it possible to get a refund please?

4SEO brings you structured data, sitemap, Open Graph and you want a refund because you have experienced one small issue and without even letting us look at it?

If the open graph tags are not working satisfactorily at the moment for you, why not just disable OGP tags in 4SEO configuration until we found the source of the problem and fix it?

Best regards

Yannick Gaultier

weeblr.com / @weeblr

Hi

I looked it up and I can see the problem happening on your site. It's bit odd as the image selected is actully smaller than the desired one (normally, 4SEO will go for the larger image in the content, not the first).

I can't explain this but I'll look into it right now. It might be a good benefit for you as I can see that currently you have to manually enter the selected image for each article instead of automated way in 4SEO.

I'll get back to you soon,

Best regards

Yannick Gaultier

weeblr.com / @weeblr

Hi John,

So I spent a large part of this weekend on your site, it's quite interesting as it has several edge cases that were not properly handled, or not well enough.

Regarding the image selection for OpenGraph, and why it would not pick up that particular image, the following was happening:

- these "invisible" images were linked using a fully qualified URL (ie http + full domain instead of the usual /images/xxxxx).

- should have been no problem (it's faster to read local images but we can also read remote ones) but they were linked using the http version of the site instead of the httpS version (that's the big problem when yo use fully qualified links to pages and images)

- should not have been a problem either as our code follows the redirects BUT when trying to load some of those image files to dtermine their size (needed to know if they can be used as OGP), there was an error of some kind and so the image was discounted as invalid as we did not know their width and height

I fixed that by updating the library used to read remote image dimensions to one that uses a different methodology and this one can read your images dimensions allright. I believe the error is linked to how the files were created and the library was probably not handling correctly the files header.

Anyway that's solved and your site currently runs a version that properly reads the size of your images and therefore can make a decision on which to use.

You'll note that on some pages, the "top" image, 500 x 500 px is not always the one selected. Instead, a larger one from the article can be used if found. We can talk about that on specific examples, I have found generally that the choices are ok and using the 500 x 500 is usually not the best option as it's cut off when shared on Facebook (desktop) or you only get a small thumbnail when sharing on Facebook mobile.

It's also possible to switch to using the first image in article instead of the largest, but it's a hidden setting for now as it's not a good option generally speaking.

As this was fixed I ran the analysis on the site and found that it got stuck at some point, constantly analysing a few pages, then adding a few more and so on. 

I added some logging information and found out what's happening: one of those edge cases I mentioned:

- you have a number of articles also linked from other articles using fully qualified URLs (FQDN)

- however and again, the FQDN is not always correct: many times, the links are http instead of httpS and in a few cases, the links are missing the www prefix.

- A second problem appeared after that: all pages were considered non-canonical. After quite a bit of debugging I found that you have added a domain value in the SEF system plugin, which is fine but Joomla actually expects internally this domain withouit a trailing slash (ie https://www.xxxx.com instead of https://www.xxxx.com/).

Normally, that does not cause any issue because when using that value the SEF plugin does clean the canonical links when outputting it into the page BUT when 4SEO was asking Joomla for the canonical value "internally", in code, it was getting an additional slash: https://www.xxxx.com//some-article

And this broke the mechanism to decide whether a page is canonical. I added some clean up code and this is working as expected now.

- Now the problem that got 4SEO stuck is about www: you did put an HTTP to HTTPS redirect, but not a non-www to www one and so your entire site can be accessed through both. That's bad and you need to add a redirect (that's just a switch in sh404SEF under Advanced tab of configuration).

- What threw 4SEO off was the fact that http://xxxx.com/some-article is considered an external page (because the site home address is https://www.xxxx.com) but when requesting the page http://xxxx.com/some-article, we did get a response from the site itself.

I had to make some changes to 4SEO to accomodate that situation and it should be working OK now.

As I made the changes late yesterday, I could not try install the latest version on your site to complete the testing but I plan on doing that today. Obviously, for validating that code, it would help if you did NOT switch on non-www to www redirect right away.

Best regards

Yannick Gaultier

weeblr.com / @weeblr

Hi

I can see you spent a bit of time trying to fix things.

Yes, those images of yours have something in their header that the previous version of the image size library we used could not handle and we could not measure the size of those images, therefore they were rejected. Before one gets to realize what's happening, a lot of time needs to be spent...

Should i change it to :

Enforce access through www URL

or

Enforce access without www

That's your call. You have to decide whether you want your site to be used under www or no-www. Then the point if this setting is to make sure the choice you make is enforced and any attempt to reach a page at, https://xxxx.com/something  is redirected to https://www.xxxx.com/something (assuming you select to use the www version of your site as the main version,).

If you communicated publicly already on the www version, it makes sense to enforce that. For instance, searching for xxxx in google gives me the www version, so I think that' s likely what you want to use.

Also, most of the main article images are 500x500 pixels, but I have 1200x1200 pixel images selected in the OGP plugin.

The OGP plugin is unrelated to us. It does what it wants and output its own OGP tags. Meaning that when 4SEO OGP tags output is enabled, you will have 2 sets of OGP tags output to your pages.

- Your current OGP plugin requires that you manually select an image to be used as OGP in the article meta data.

- 4SEO automatically select images from your content (and description, etc) so that you don't have to worry about the OGP tags. Therefore it will select the 500 px images because that's what in your article. You can of course then change that manually in 4SEO, and select another image but the point is that it's interesting mostly if automatic. If you have to manually change the selected images in 4SEO, you migth as well just use your current plugin and keep dointg it manually I'd say. In that case, just deactivate the OGP feature in 4SEO.

Should I change the main article images to 1200x1200 pixels? I don't mind if they look weird on facebook, as the images are record covers, so I don't really have a lot of options in terms of aspect ratio.

It's not about aspect-ratio, that will be fine. The only important thing is that below 600px wide, you get a different layout on Facebook when sharing

Below 600px:

Above 600px:

So the larger the better because with images below 600px, you will get smaller exposure in the Facebook feeds as the small layout will be used.

In short: as the 1200 pixels images are not actuall present in your articles, 4SEO will not be able to automatically detect them. 4SEO will just take the largest image on each page, which can be the 500 px ones, or sometimes there's a larger one and it will use that.

If you want to ensure the "large layout" is used when sharing on FB, you need large images such as the 1200 px ones you are currently using and that requires manually selecting them. You can manually select them with your current plugin or with 4SEO, it's only a matter of which one you find easier. 

Note that:

- with 4SE0, you don't need to enter a specific title and description of OGP tags, they'll be picked up automatically

- with 4SEO, you can also select the OGP image from the front-end

Best regards

Yannick Gaultier

weeblr.com / @weeblr