Structured Data Markup for Schema, Facebook Open Graph, Twitter...

[gernot]

Hi mc12345678
Yes, the file made a difference!
$canonicalLink is still the same, but when I try to access the relative link at the top of a Zen Cart page I can do so. So that is a success

However, it only works when there is a single "&".

It does not work when there is a "&" which in the Structured Data plugin is for the Twitter Card URL, which further encodes with htmlentites($canonicalLink).

[mc12345678]

Hi mc12345678
Yes, the file made a difference!
$canonicalLink is still the same, but when I try to access the relative link at the top of a Zen Cart page I can do so. So that is a success

However, it only works when there is a single "&".

It does not work when there is a "&" which in the Structured Data plugin is for the Twitter Card URL, which further encodes with htmlentites($canonicalLink).

Does FB still provide 404 response with the file or did that get resolved? Some of the other issues are actually in discussion (at least the issue with a products page being /index.php?products_id=xxx). I can provide what I also think is the solution to that issue as proposed by another zenner whose name I forget at the moment but I remember a few of those that were involved in the last couple of days.

[gernot]

Hi mc12345678,

Facebook debugger now finds the page perfectly! Response 200, and all content seems to be fine.

I notice that in the Structured Data plugin, only the Twitter card does a further encoding, as follows:

 <meta name="twitter:image:alt" content="<?php echo htmlentities($image_alt, ENT_QUOTES, 'UTF-8'); ?>" />
 <meta name="twitter:url" content="<?php echo htmlentities($canonicalLink); ?>" />

I expect there was a reason for that so I am not going to remove it right now (and Twitter seems to find my page even with the broken encoding).

[mc12345678]

I'd question why the data fed to the twitter card was already encoded with htmlentities and then encoded a second time; however, may be able to change the command to:

htmlentities($variable, ENT_COMPAT, CHARSET, false)

adding the ", false" at the end so that it doesn't double encode and cause the & situation... The intent of the false is to not encode content to an htmlentity if it is already encoded. The default though (which is used here) is to encode everything even if it is already encoded...

As for my use of CHARSET above, well ideally that is already set to 'UTF-8'; however, what it does is to ensure that the conversion is to the format supported by the site (current language/character set of the site/language pack).

[gernot]

Hi mc12345678
Thanks, I changed the existing to :

 <meta name="twitter:image:alt" content="<?php echo htmlentities($image_alt, ENT_QUOTES, 'UTF-8', false); ?>" />
 <meta name="twitter:url" content="<?php echo htmlentities($canonicalLink, ENT_COMPAT, CHARSET, false); ?>" />

for now. Perfect! Source code now shows only a single "&" in the URL, and Twitter shows the card fine (as before, mind you).
The alternative image content I added "false" for good measure, not sure if that encoding definition is perfect or not.

BTW, doing a regular trawl of the forums again today I came across a related issue here, with encoding of "&":
https://www.zen-cart.com/showthread....my-Admin/page2

[torvista]

Sorry not been able to look at this yet....thanks for the continued investigation..

[gernot]

Probably useful to re-iterate here, that the Schema part (not Facebook or Twitter) for the product (not the direct constants for shop information) in Japanese are all \u...\u.... unicode characters. It looks like that encompasses all the parameters using json_encode().
Is that the intended effect, that (presumably) all non-ASCII UTF-8 characters become human-unreadable?
(Presumably there is nothing syntactically incorrect about the result, since it is merely a different form of the same characters, but not legible anymore by humans)

[torvista]

I've added this to the Github, thanks. Please check if there is anything else required.

[mc12345678]

Presumably such characters would get translated to a utf-8 readable format. Though how that is performed is possibly open for debate. Torvista commented that normally uses Ceon URI Mappings which I believe has some sort of translater associated with it to do that type of conversion at least for uris and possibly other input...

[gernot]

Hi mc12345678 and torvista
I'm totally cool with whatever you think is good as long as it works reliably for SEO purposes, even if I as a human can't read the characters myself. I was merely raising the issue since I am using a non-European language and it might have been something buggy that had not been discovered yet.