open graph plugin ignoring set image

[ppetree]

I downloaded your plugin today and I'm using it on Joomla 3.4.x

I'm not sure why its doing this but...
My homepage has an image rotator on it and I want to set the open graph image to the first image (cover of a book)

I set this image in open graph plugin but you ignore it and choose another image. The image you chose produces an error in facebook object debugger and resorts to one of the other images in the rotator.

If I enter the url manually on facebook (like I were going to share it on my timeline) facebook offers up 3 images from the rotator (just not the one I want).

You can view the site: themanpuzzle.com

The image I want is here: themanpuzzle.com/images/slideshow/cover-the-man-puzzle.png

The og:image property should read:
<meta property="og:image" content="http://www.themanpuzzle.com/images/slid ... puzzle.png" />

What you're generating is this:
<meta name="og:image" content="http://www.themanpuzzle.com/images/book ... -cover.jpg" />

How can I get your software to use the image I want?

thanks!

Pete

[Jan]

Hi, sorry, I don't understand what you mean?

If you are setting an image in Options of Phoca Opengraph plugin, you are setting it with the full path to the image.

So if your site displays this image:

images/book_covers/the-man-puzzle-front-cover.jpg

this means, you have select it in options

Jan

[ppetree]

This is what is stored in the database:
{"title":"The Man Puzzle: A Guide To Understanding Men (Heart, Mind and Soul)","type":"website","image":"images\/slideshow\/cover-the-man-puzzle.png","url":"http:\/\/www.themanpuzzle.com","site_name":"themanpuzzle.com","description":"Based on interviews with 1000's of men, the author opens the door and shows you what's really going on inside of men. Explaining how men really communicate and argue, what man really think about se x and how men experience emotions. Simply put, The Man Puzzle is the most revealing book to date about the inner workings of men.","titlef":"","typef":"article","imagef":"images\/slideshow\/cover-the-man-puzzle.png","urlf":"","site_namef":"","descriptionf":"","displayf":"1","titlec":"","typec":"article","imagec":"images\/slideshow\/cover-the-man-puzzle.png","urlc":"","site_namec":"","descriptionc":"","displayc":"1","app_id":"761765007269633","other":"","render_type":"1","desc_intro":"0"}

Now, in this first image you can see how the plugin is configured:


In this next image is the output source code being generated:


These two are NOT the same. Facebook accepts the .png so this is something in your code that is causing it to ignore the name of the image that is entered and stored in the table. Since I used the picker from the admin UI the image must be present so I think you have a bug.

[Jan]

Hi, really no idea what can be wrong, see the code:

Code: Select all

if ($this->params->get('image'.$suffix, '') != '') {
			plgContentPhocaOpenGraphHelper::renderTag('og:image', JURI::base(false).$this->params->get('image'.$suffix, ''), $type);
		} if (isset($pictures->{'image_intro'}) && $pictures->{'image_intro'} != '') {
			plgContentPhocaOpenGraphHelper::renderTag('og:image', JURI::base(false).$pictures->{'image_intro'}, $type);
		} else if (isset($pictures->{'image_fulltext'}) && $pictures->{'image_fulltext'} != '') {
			plgContentPhocaOpenGraphHelper::renderTag('og:image', JURI::base(false).$pictures->{'image_fulltext'}, $type);
		}

Which means, when the plugin has defined the image (your case), just use the image:

plgContentPhocaOpenGraphHelper::renderTag('og:image', JURI::base(false).$this->params->get('image'.$suffix, ''), $type);

I cannot imagine that there will be some feature to change the URL of the image? Why? When you set the image path, why to change it?

Do you use some system plugin, etc, which overwrites links on your page?

As this code:
JURI::base(false).$this->params->get('image'.$suffix, '') : JURI::base(false) -> path on the server, $this->params->get('image'.$suffix, '') - image with path set in parameters does not have any specific code to change the URL and there is no reason to do it

Is this a link to article view or category view or blog view?

Anyway if you are good in PHP, you can test with "print_r" which image the code will print.

Jan

[ppetree]

I understand your post but the problem is, even if another plugin was changing the URL (none are), your output is prior to any of theirs.

Which means, when the plugin has defined the image (your case), just use the image:
plgContentPhocaOpenGraphHelper::renderTag('og:image', JURI::base(false).$this->params->get('image'.$suffix, ''), $type);

The image being set in the header as og:image by your plugin is not the same image set by your admin UI and saved in the database, it looks like you're ignoring what was set. Didn't I see code in there that checked to see if the image exists?

You can look at the og:image url and at the image url in the database and test those in a browser and see they both exist.

I would suggest you create a .png in a slideshow folder and a .jpg in bookcover folder, then use the admin console to pick that image. Save it, verify that the image url was saved in the database and then see what your code produces.

[Jan]

Hi,

I understand your post but the problem is, even if another plugin was changing the URL (none are), your output is prior to any of theirs.

no, Joomla! does not work this way. With help of some system plugin, you can overwrite the output again and again. Content plugin is not prior.

When you create something in component and then e.g. in content plugin (if content is used) then you can change the output with help of system plugins. Some plugins use this - e.g. template system plugins - they change the classes of image tags e.g. so the image then follow the template design rules. There are many different options how to change the output after it has been created.

The image being set in the header as og:image by your plugin is not the same image set by your admin UI and saved in the database, it looks like you're ignoring what was set

This is what I have written in previous post. Of course I have tested it many times, it is tested by thousands users and for now it works like it should work. I really don't know what will be the reason "ban own settings"? Why to do option and then somehow ignore it? This is like some conspiracy theory. I will do option for something but then I will do everything to not use it? I see no reason for this. Anyway this is why I have pasted the code here in the post - you can see it directly in the PHP code that the settings option is used.

Anyway 2, I really have no idea how to do such feauture which will change the path of the image which will be set in options. Just imagine. I spend e.g. 5 minutes to develop the standard feature: take the image from option and diplay it. But then I will spend e.g. one month to make some weird behaviour to somehow change the path? But for what? What will be the reason?

I am testing it on my different servers, seeing the code and really have no idea, why you get such behavior on your server.

Will be great you can print_r the values so you will know if the right value is set on your server.

This code do nothing else than:

Code: Select all

JURI::base(false).$this->params->get('image'.$suffix, '')

It adds server paths ( JURI::base(false) ) to the image which is set in parameters ( $this->params->get('image'.$suffix, '') )

Anyway 3 this is the Joomla! feature, not Phoca feature - getting the value from options is Joomla! feature - options of plugin are stored in Joomla! extensions table and getting $this->params->get('image'.$suffix, '') is a Joomla! feature to get value from the plugin Options.

So just try to print_r the value in your code, to see which value you get from Joomla! plugin parameters.

Jan

[Jan]

Anyway 4 I cannot test this:

I would suggest you create a .png in a slideshow folder and a .jpg in bookcover folder

As default, there are no such folders and I don't have them in my Joomla! websites

I really don't know and cannot test specific behavior and settings which is running on your server, so I will suggest, you should really test it directly in the code, which is the easiest way to test which value the plugin really gets.

Jan