Créer des microdata imbriquées (hiérarchie d'éléments) avec des FieldGroup de plus de deux niveaux

pas de soucis c'est toi qui vois
il faut juste savoir que nous faisons notre possible, sur un composant gratuit avec support gratuit et documentation gratuite ...
c'est difficile de prévoir TOUS les cas ... mais je comprend tes retours

Pas de soucis.

Voici les résultats fournis par Yandex pour une page.

Pour le json-ld, c'est ok.
Pour les microdatas, il manque "Offers" pour faire le lien entre "Product" et "Offer" ("offers field missing or empty").

Il y a ce "//" dans le lien d'image que j'ai corrigé dans le json-ld.

Soit le problème vient de ma configuration, soit il vient de l'extension.

Résultats de Yandex ( webmaster.yandex.com/tools/microtest/ ) :

"
jsonld
@type = (http://)schema(.)org/Product
(http://)schema(.)org/name
@value = Notice d'entretien 750 VATT
(http://)schema(.)org/image
@id = (http://)www.arbracam(.)org/images/stories/flexicontent/m_150629-boutique-arbracam-57-1.jpg
(http://)schema(.)org/description
@value = Notice d'entretien 750 VATT.
(http://)schema(.)org/offers
@type = (http://)schema(.)org/Offer
(http://)schema(.)org/url
@id = (http://)www.arbracam(.)org/content/89-boutique-terrot/9624-notice-d-entretien-750-vatt.html
(http://)schema(.)org/priceCurrency
@value = EUR
(http://)schema(.)org/price
@value = 5
(http://)schema(.)org/availability
@value = Épuisé

resource = (http://)www.arbracam(.)org/content/89-boutique-terrot/9624-notice-d-entretien-750-vatt.html

product
ERROR: Unmet requirement for product snippets: offers field missing or empty
itemType = (http://)schema(.)org/Product
name = Notice d'entretien 750 VATT
image
href = (http://)www.arbracam(.)org/images/stories/flexicontent//m_150629-boutique-arbracam-57-1.jpg
text = Notice d'entretien 750 VATT

offer
itemType = (http://)schema(.)org/Offer
price = 5
pricecurrency = EUR
availability = Épuisé
"

Ce qu'il manque, c'est dans le FieldGroup la possibilité d'indiquer que "Offer" est une propriété de "Product" (c'est facultatif). C'est ainsi que se fait le lien entre les deux, avec " itemprop="offers" ".
Voici la balise complète au niveau du FieldGroup : <div itemprop="offers" itemscope itemtype=" schema.org/Offer ">

Tu peux trouver un exemple de code ici : schema.org/Product

Voici un extrait de code d'une page. On voit qu'il manque " itemprop="offers" " :

<div id="flexicontent" class="flexicontent fcitems fcitem9914 fctype11 fcmaincat87 menuitem529 group" itemscope="" itemtype=" schema.org/Product ">
<h1 class="contentheading">
<span class="fc_item_title" itemprop="name"> moteurs JAP - MAG </span>
</h1>
(...)
<div itemscope="" itemtype=" schema.org/Offer " style="display:inline-block;">Prix:
<strong>
<div style="display:inline" itemprop="price">700</div>&nbsp;
<div style="display:inline" itemprop="priceCurrency">EUR</div>
</strong>
- Disponibilité:
<strong>
<div style="display:inline" itemprop="availability">En stock</div>
</strong>
</div>
</div>

Voilà des pistes pour l'amélioration de la prise en compte des microdatas et de JSON-LD dans Flexicontent.

ok on en prend note apres ... la grande question c'est json ou dans le html ... pas simple de tranché

Pour toutes les raisons évoquées dans les posts précédents, JSON-LD permet une (beaucoup) plus grande liberté - séparation de la forme (présentation) et du fond (modèle) qui est strict (pour la validation) - et est de ce point de vue plus adapté aux contraintes d'un CMS.

Pour les microdatas, on a déjà vu les limites :

1. Pas de hiérarchie de plus de deux niveaux (Type et FieldGroup) dans le CMS ce qui limite les possibilités par rapport au modèle Schema.org.
(En fait, en l'état actuel, un seul niveau : soit définit au niveau du Type d'item, soit définit au niveau du FieldGroup, car il n'y a pas de relation sémantique créée entre Type et FieldGroup.)

2. L'organisation des données dans la pages se trouve contrainte par le modèle Schema.org : il y a celles qui sont obligatoirement au niveau du Type et celles qui le sont dans le ou les GroupFields.

3. Les Fields ne devraient pas avoir de microdatas en dur au risque de créer un conflit entre la publication des données et le modèle Schema.org (ex. les champs "Date de Création" et "Date de Modification" qui sont incompatibles avec le modèle du type "Product" en l'état actuel, alors que.) Toutes les infos concernant les microdatas devraient être configurables et facultatives.
Edit : Il y a quelques microdatas qui sont peut-être valables quelque soit le contexte comme pour "image" (et tout ce qui va avec schema.org/Thing ) et peut-être le "voting". Mais elles doivent pouvoir être désactivées si l'on préfère l'option JSON-LD. Question de flexibilité.

Si la contrainte 3. est levée et que toutes les informations de microdata deviennent configurables et facultatives, pourquoi ne pas conserver la possibilité d'afficher des microdatas malgré les contraintes 1. et 2. ? Elles peuvent être utiles dans certains cas en complément de JSON-LD.

L'option JSON-LD offre plus de flexibilité et permet de couvrir tous les cas d'utilisation (ce qui n'est pas négligeable pour un CMS). Elle permet aussi travailler sur des pages existantes sans avoir besoin de les reconfigurer.

Après, pour l'implémentation, c'est une autre histoire. Mais quelque chose de simple serait le bienvenue. Un text area de niveau Type d'item/Template qui permette de saisir le JSON-LD avec les Fields, le tout en PHP afin de pouvoir retraiter les données des Fields si besoin (suppression des tags, des '"', des &nbsp;, etc.) sur le modèle l'édition des fichiers du template (modular.php), et que le résultat remonte au bon endroit dans le <head>, avec une doc minimale, ce serait parfait. Mais, est-ce techniquement faisable ?

Edit : Il y a des discussions pour savoir où il est possible de mettre le JSON-LD.
Comme pour les microdatas, on devrait pouvoir publier les JSON-LD dans le <body>. C'est quand même plus simple. A confirmer.
Schema.org - JSON-LD - Where to Place? stackoverflow.com/questions/28687653/sch...on-ld-where-to-place