Last post 4 hours 24 min ago

Posts last week 89

Average response time last week 30 min

All time posts 67708

All time tickets 10463

All time avg. posts per day 21

Helpdesk is open from Monday through Friday CET

Please create an (free) account to post any question in the support area.

Please check the development versions area. Look at the changelog, maybe your specific problem has been resolved already!

All tickets are private and they cannot be viewed by anyone. We have made public only a few tickets that we found helpful, after removing private information from them.

#4370 – open graph image strange behavior

Posted in ‘sh404SEF’

This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Thursday, 30 November 2017 18:09 UTC

wcwon1

We have enabled open graph tags in sh404sef and we are seeing strange results with the og:image tag.

-enabled by the "social seo" tab. Selected "enable on all pages", object type of "article", and "automatic image detection" of "use first image in content". (it does not seem to make a difference if we choose the "use largest image found" option).

Here is an example page of where we are seeing the strange behavior.

https://xxxx.org/News/host-healthy-eating-and-physical-activity-roundup-thanksgiving-2017-edition

The first image in the main content is the picture of a plate of food, however, looking in the html code on our page, the og:image tag is pointing to our logo in our navbar.

Your documentation here (https://weeblr.com/documentation/products.sh404sef/4/going-further/social-seo/social-seo-configuration.html) says "sh404SEF will look at the main content of the page, and then at the full page, and search for <img> html tags. "

Why does the og:image tag point to our website logo in the navbar? Isn't it supposed to look at the main content section first, as your documentation states?

Friday, 01 December 2017 09:54 UTC

wb_weeblr

Hi

This should work normally, at least with any component that comply with the Joomla API and assuming your template is not playing fool.

1 - temporarily switch back to protostar, the default Joomla template, purge all Joomla caches, and see if the OG:image is correct.
2 - Which content is that? com_content? K2? other?
3 - Is the display done through a module?

Rgds

Friday, 01 December 2017 14:34 UTC

wcwon1

Hi,

We've narrowed the symptoms down. (without needing to try the protostar template, which we had deleted a long time ago)

-The image in the navbar is only selected as the og:image if caching is enabled in the joomla global config. (we have it set to "ON - Conservative")

If we disable the cache, the right image of the plate of food in the content is chosen for the og:image tag. Also, if we enable cache, but clear cache, the first time we load the page produces the correct results. Any subsequent loads of the page have the navbar logo as the og:image.

-Additionally, we have noticed that, with cache enabled, not only is the og:image tag wrong, the twitter:description and twitter:image tags are also wrong. The twitter:image is showing the same symptoms as that of the og:image tag. With cache enabled, the twitter:description is pulling our website name as opposed to the content introtext. (again, with joomla cache disabled, everything works)

2. That page is just a com_content article.

3. As far as I can tell, the display of the main content is not done through a module. We use the warp framework for our template (yoo theme), if that makes any difference.

Regardless, this looks like it might just be a caching issue with sh404sef?

Friday, 01 December 2017 14:45 UTC

wb_weeblr

Hi

Ah you are right, I forgot about caching.

Regardless, this looks like it might just be a caching issue with sh404sef?

Nope, there is no issue with sh404SEF. The "problem" is in Joomla and basically things work exactly as they are supposed to: when using caching, Joomla does not fire the "content" event: it reads the content directly from the cache and does not inform other extensions that it did so.

So we are not informed content has been retrieved and not given a chance to check it for the og:image. Therefore the search is performed on the full page, and not just the content, and we can't find the "plate" image.

One way to work around this is to select "largest image" and make sure your logo is not larger than your content images (250x250px is actually at the extreme limit of what Facebook actually accepts. They recommend images to be much bigger than tha). In cases where this can't be achieved, you will have to manually set the og:image for this page.

Rgds

Friday, 01 December 2017 16:04 UTC

wcwon1

Enlarging the images in the content and then choosing "use largest image" in sh404sef seems to work.

Thanks.

Friday, 01 December 2017 16:52 UTC

wb_weeblr

Hi

Cool. Like I said, Joomla simply does not allow auto-detection in content when using the cache, so there is not really any other way. Enlarging the image however is actually quite good for your sharing on FB or elsewhere.

Closing this ticket now, feel free to open a new one as needed. If you do so, please mention this ticket number in the new one.

If you created any superadmin account for us, be sure to delete or block it now to avoid unnecessary risk in the future.

Be sure to also check out wbAMP, our new Accelerated Mobiles pages plugin for Joomla - the next big thing is SEO, direct from Google themselves!

Rgds

This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.