Lösung für RDFa Fehler

Guten Tag,
ich bin auf der Suche nach der Fehlerbehebung zur Übertragung der RDFa Daten.

Der erste Fehler ist bekannt und wurde schon oft im Forum diskutiert. Leider habe ich nur keinen aktuelleb Beitrag gefunden mit einem Lösungansatz. Im BUG-Report fand ich leider auch keine Lösung.

Google sagt im “Structured Data Testing Tool” das:
http://purl.org/goodrelations/v1#Offering & http://purl.org/goodrelations/v1#SomeItems kein Typ ist der Google bekannt ist.

Mein zweites Problem ist die häufige Platzierung von “Anführungzeichen” in Produkt-Titel und Produkt-Beschreibung.

Die aktuelle Property wird im Prinzip zu früh abgeschnitten durch die [B]" [/B].

Um das zu verdeutlichen:


/* Aus folgender Property */
 <div property="gr:name" content="Meine "Produktbezeichnung" in blau" ></div>

/* Wird logischerweise */
http://purl.org/goodrelations/v1#name: Meine

Leider habe ich einige Produkte wo sowohl im Titel als auch in der Beschreibung Anführungszeichen genutzt werden.

Hat jemand vielleicht eine Idee wie ich das verhindern kann ohne die Artikel abzuändern zu müssen?

Ich danke euch für eure Unterstützung.

micro

// edit 26.10.16 //
Ich nutze nun “schema.org” um die Daten bereitzustellen, da mir mit den bestehenden RDFa Daten immer wieder Fehler entgegengekommen sind.

Ein Beispiel-Snippet findet ihr hier: https://iblogg.de/oxid-eshop-rdfa/

Das Problem der Anführungszeichen lässt sich letztlich auch lösen in dem man hochkommata verwendet.

Hallo @micro,

mach doch dazu mal zwei Bugreports auf bitte, wenn keine vorhanden sind.

Gruß

Guten Tag!

gibt es zum Thema “kein Typ ist der Google bekannt ist” etwas neues?

Bei uns (oxid PE 4.9.9 und ein angepasstes Template!) taucht dieses Problem auf den Produktseiten i.H. auf “Offering” und “ProductOrServiceModel” auf.

Ich komme nicht weiter und bin dankbar für jeden Tipp.
Christian

“Offering” gibts eigentlich
http://www.heppnetz.de/ontologies/goodrelations/v1#Offering

also dürfte das Problem “nur” in der Anordnung der einzelnen Tags im Code sein.
Hast du einen Link zu deinem Shop? Am besten zu dem Produkt mit dem “ProductOrServiceModel” Problem, da ich dieses Problem in meinem Demo-Shop nicht nachvollziehen konnte .

Vielen Dank für das Kümmern. Ich würde mich sehr freuen, wenn es am Ende “nur” eine Kleinigkeit sein sollte!
Unser Testshop ist zwar abgesperrt und ich kann die Zugangsdaten schlecht posten. Die gleiche Konstellation ist aber auch auf bei unserem Kunden z.B. unter www.acupunctureworld.de/Akupunktur/Akupunkturnadeln/Dauernadeln/asia-med-Dauernadeln-Apex-Stahl.html. zu finden. Die zwei Fehler tauchen praktisch auf jeder Produktseite auf.

Grüße Christian

ich weiß nun was los ist:

Du hast zwei mal

<div rel="foaf:depiction v:image" resource="http://www.acupunctureworld.de/out/pictures/generated/product/1/480_430_90/[email protected]"></div>

drin, ein mal unter gr:Offering und ein mal unter gr:ProductOrServiceModel

Dieses foaf ist kein gültiger Bestandteil von schema.org / RDFa
Einfach beide rauswerfen oder durch gültige ersetzen.

Ist das hier zufällig dein Topic?


habe ich gefunden, als ich gesucht habe, was foaf sein soll :smiley:

Vielen Dank für die Hilfe! Mal sehen, ob wir das Template entsprechend “repariert” bekommen ohne dabei neue Fehler zu bekommen.

[QUOTE=vanilla thunder;181025]
Dieses foaf ist kein gültiger Bestandteil von schema.org / RDFa
Einfach beide rauswerfen oder durch gültige ersetzen.
[/QUOTE]

Ist das dann ein OXID-Bug? Der [I]foaf:depiction v:image[/I]-Tag ist nämlich in allen OXID-Themes (Azure, Mobile, Flow) auch drin, einmal in [I]rdfa/details/details.tpl[/I] und dann in [I]rdfa/details/inc/object.tpl[/I].

Es gibt mehrere Formate für strukturierte Daten, z.B. schema.org, goodrelations und dieses FOAF.
Scheinbar ist im Azure alles zusammen gemixt, damit jede Suchmaschine theoretisch das nehmen könnte, was sie will.

Ob das überhaupt ein Bug ist und von OXID oder von Google (weil das Test-Tool foaf als Teil von schema.org validieren will), weiß ich nicht. Dafür habe ich mich zu wenig mit strukturierten Daten beschäftigt. Könnte sein, dass dieses foaf die echte Suchmaschine gar nicht stört.

Auch wenn der Beitrag in Vergessenheit gerät.
Ich habe so das ein oder andere Problem mit strukturierten Daten unter OXID gehabt.

Nachdem ich mich mit “Rich Cards” bei Google beschäftigt habe, habe ich einfach mal die Anleitungen in Google befolgt und erstelle nun die Inhalte nach schema.org

Falls noch jemand auf der Suche ist wie das funktioniert:
https://iblogg.de/oxid-eshop-rdfa/

Ich werde den Beitrag bei Gelegenheit erweiten und ausführlicher schreiben. Über Feedback freue ich mich natürlich.

Gruß

micro

Hallo Micro,
das hat sich doch mit der neuen Flow-Theme bereits erledigt oder etwa nicht?

Zumindest im Quellcode sieht alles gut aus. Ok, ein bisschen Hand anlegen müsste man schon damit alles korrekt übertragen wird. Aber das ist auch eine Beta-Version.

Azure-Theme müsste man um Shema.org noch erweitern. Wir haben dafür ein fertiges Modul. Falls Interesse besteht einfach kontaktieren.

Grüße
Rafig

Das Snippet bezieht sich aktuell auf das Azure-Theme.
Da ich das Azure Theme noch verwende und das neue Design an dem ich arbeite zwar auf Azure basiert aber komplett mit bootstrap umgesetzt ist.

Das ist ein Stück weit “learning by doing”. Und meine Fehler aus dem Beitrag haben sich somit erstmal erledigt.

Ich verzichte so gut es geht auf Module, in meinem neuen Theme werde ich dann erstmals tatsächlich außer dem “PayPal Plus”-Modul keine weiteren Module verwenden.

Aber danke für den Tipp.

Gruß

micro

[QUOTE=microchip;183606]Ich verzichte so gut es geht auf Module, in meinem neuen Theme werde ich dann erstmals tatsächlich außer dem “PayPal Plus”-Modul keine weiteren Module verwenden.[/QUOTE]

Ok. Ich zähle mal auf was ohne Modul einfach nicht funktioniert:

  • XML-Sitemap
  • HTML-Sitemap
  • Google-Shopping
  • Google Analytics
  • PDF-Rerchnung Ausgabe Backend
  • PDF-Rechnung im Kundenkonto
  • PDF-Rechnung per Email-Versand
  • Mindestbestellmenge
  • TMP leeren :smiley:

Ich habe mindestens 10-15 Module in meiner Auflistung vergessen. Möchtest du den Shop NUR als Anfrage-Shop einsetzen benötigst du schon wieder einen Modul. Also ganz ohne Modul funktioniert doch nicht.

Grüße
Rafig

Das verstehe ich. Ich schreibe jedoch alles selbst oder nutze Scripte die ich anpassen kann.

[B]Html & XML Sitemaps[/B] werden von einem PHP Script automatisch erzeugt.

[B]Google Shopping[/B] nutze ich nicht.

[B]Google Analytics[/B] habe ich im Design integriert - warum sollte das nicht gehen?

Zum [B]TMP-Leeren[/B] kann man sich ohne Modul super behelfen…

Für die [B]PDF’s[/B] bastel ich gerade auch was, die werden dann auch gleichzeitig für mich als Backup direkt unter einem bestimmten Pfad gespeichert… Funktioniert einwandfrei.

Warum sollte die Mindestbestellmenge nicht gehen / mal abgesehen davon das ich das nicht nutze?

Ich verstehe nicht wofür ich Module laden soll? :eek:

Gruß

micro

Wow!
Wenn du jetzt noch einen Skript für das Paypal Plus schreibst, ach was rede ich denn da schreibe gleich eigenes OXID Micro-Edition und gut ist.

Ich würde auf der OXID Micro-Edition auf die Ordner-und Datei Struktur komplett verzichten. Alle 200 Dateien packst du in einer Datei und brauchst nicht mehr die nervigen Controllers, Models und Klassen.

Verwirrte Grüße
Rafig

@Oxid-Design: Auch wenn mir dein schwarzer Humor gefällt glaube ich nicht, dass du microchip damit dazu bringst mehr Module zu verwenden…

… den Vorteil von Modulen wird er erst bei den nächsten Oxid-Updates feststellen und den Aufwand der ohne Module entsteht. Nicht zu updaten wäre ja auch fahrlässig.

cya
Firefax

Du hast recht. Es konnte der eindruck entstehen das ich micro dazu animiere noch mehr Module einzusetzen, am besten alles von mir.

Mich Interessiert wirklich der wahre Hintergrund dieses vorhaben. Ich begrüße wirklich sparsamen Einsatz vom Modulen, JavaScripts und CSS Dateien. Aber einzelne Module mit externen Skripten zu ersetzen macht nach meiner Meinung wenig Sinn.

Grüße
Rafig

Hi OXID-Design,
mir erschließt sich der Sinn einfach nicht unmengen an “modulen” zu installieren.

Ich muss vielleicht dazu sagen,… meine OXID Versionen sind immer schon sehr weit angepasst. Ich nutzte mehrere Datenbanken, erstelle automatisch Backups, Pumpe automatisch unter der Verwendung von Cronjobs Artikeldaten und Lagebestände in den Shop und so weiter…

Es wird kein Modul und kein Shopsystem geben, dass meine Anforderungen “out of the box” abdeckt. Umschreiben muss man immer irgendetwas…

Warum dann nicht eigene Scripte, die ich verstehe und nach meinen wünschen anpassen kann? Wobei ich auch jeden Script und jedes Update in der Testumgebung teste?

Sicher werde ich mich jetzt nicht erst noch Stundenlang mit der PayPal Api beschäftigen, aber so leichte Sachen wie Sitemap, Google Analytics etc… nutzt ihr da immer ein Modul?

Gruß

micro

Und Du meinst also, dass manuelle hardcoded Anpassungen an vielen diversen Stellen im Shop besser sind, als ein sauber zusammengestelltes und abgekapseltes Modul, das jeder Zeit updatebereit und in den anderen Shop übertragbar ist?

Das würde ich so nicht unterschreiben.
Es ist immer eine Frage des Nutzens, der Kosten und des Aufwandes, sowie natürlich überwiegend der Funktionalität um das Ergebnis zu bekommen das ich möchte.

Ich wollte hier auch keine grundsatzdisskussion lostreten.
Ich werde sicher immer wieder mal auf ein Modul zurückgreifen müssen, aber wie gesagt: “Bei kleinen Dingen” sehe ich keine Notwendigkeit.

Grüße

mirco