MODUL: Alternative zu googlebase.txt -> Google via XML-Feed

[Alfred]

Matt:
Die angesprochenen Kosten für Google ab 2013 sieht man in etwa hier:
http://www.google.com/commercesearch/#  (bei PREISE nachsehen)
Isses dir soviel Wert das die Ebaykrauter verschwinden ?

Hallo,

da verwechselst du was.
Das ist eine extra Suchmaschine die sich Firmen auf ihrer Seite einbauen lassen können.
Mit Google Shopping hat das nichts zu tun.

Gruß

[Da Sandro]

Wie schautsn mit diesem MOdul in zusammenhang mit der 1.06er Version aus? ISt das noch alles up-to-date und lässt sich ohne weiteres nutzen?

im backend steht nämlich "VERALTET".

[web28]

Im 1.06 Backend stehen 2 Texte:

1. Bitte überprüfen Sie die Module beim jeweiligen Hersteller auf die aktuellste Version!
2. Google Base - TXT / XML [VERALTET - Entspricht nicht den aktuellen Spezifikationen]

Das bedeutet, das Modul ist ohne Anpassungen nicht nutzbar!
Entweder besorgt man sich ein aktuelles Modul (Angebote gibt es im Internet) oder programmiert das mit dem Shop ausgelieferte Modul um.

[Da Sandro]

Und das hat sich bislang noch niemand angepasst, dass es für das aktuelle Google Merchant Center taugt?!

[noRiddle (revilonetz)]

Kommt bald von mir
Eigentlich gibt's bei dem vorliegenden Modul nur Probleme mit der char-Codierung und es müssen ein paar Anpassungen an die Anforderungen der zu übertragenden Daten erfolgen.
Finde da in der nächsten Woche Zeit für denke ich.
Ist aber kein Vesrprechen, kann auch was länger dauern.

Gruß,
noRiddle

[Simon]

Magst du deinen Zwischenstand bitte mit uns teilen ?
Ich denke das macht es leichter, dass irgendjemand eine Lösung zu vorhandenen Problemchen findet.
Ohne den Code kann man da nur schwer helfen und bis März ist nicht mehr lange hin.

[noRiddle (revilonetz)]

Okay, Zwischenstand:
Habe die Datei google_rss_feed.php

• an die neuesten Bedingnungen/Spezifikationen aus dem Google Merchant Center angepasst
• z.B. englische tags benutzt, wie vorgeschrieben bei xml
• nur die tags implementiert die es auch gibt (kein cross marketing)
• encoding Fehler behoben (einige Sonderzeichen mit str_replace() ersetzt um sicher zu gehen,
  dafür kein CDATA benutzt;
  utf8_encoding der google categories, der product names und der product description, da xml)
• google categories in der Tabelle products und der Tabelle categories,
  hat man eine in der Artikelbearbeitung angegeben, wird diese genommen, ansonsten die in der Kategorie angegebene (beides per Dropdown auswählbar)

Probleme:

• es werden nicht alle shipping module die installiert sind ausgelesen,
  bislang keine Ahnung warum...
  Lasse ich auf meinem Testshop (1.06 rev 4356) das quote-array ausgeben, ist nur Selbstabholung drin, die anderen zwei installierten shipping methods sind nicht enthalten...
• wenn gzip aktiviert ist, melden manche Browser:
  "Content encoding Fehler
  .... da sie eine ungültige oder unbekannte Form der Kompression anwendet."
  Läss sich wahrscheinlich über htaccess oder die application_top beheben...

Jemand einen Tipp was die Probleme anbelangt ?

Gruß,
noRiddle

[noRiddle (revilonetz)]

Achso die Test-Datei...

Dafür benötigt man noch die *.txt Datei für die Google-Cats und DB-Erweiterungen für selbige.
Werden die meisten schon haben.
Diese google_rss_feed.php basiert allerdings darauf, daß man in der Tabelle categories ein neues Feld categories_google
und in der Tabelle products ein neues Feld products_googlecat hat.
Kann zum Testen einfach auskommentiert werden.

[noRiddle (revilonetz)]

Und wen interessiert wie's aussieht weil er's nicht testen kann:

Code: XML  [Auswählen]

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0" >

<channel>
        <title>Produkt Feed von: SHOP_TITLE</title>
        <link>SHOP_URL</link>
        <description>Alle Produkte von: META_DESCRIPTION</description>
                <item>
                        <g:id>XXX</g:id>
                        <title>PRODUCT_NAME</title>
                        <g:description>PRODUKT_BESCHREIBUNG</g:description>
                        <g:google_product_category>GOOGLE_KATEGORIE</g:google_product_category>
                        <link>ARTIKEL_LINK</link>
                        <g:image_link>ARTIKEL_HAUPT_BILD</g:image_link>
                        <g:additional_image_link>WEITERES_ARTIKEL_BILD</g:additional_image_link>
                        <g:additional_image_link>WEITERES_ARTIKEL_BILD</g:additional_image_link>
                        <g:condition>Neu</g:condition>
                        <g:availability>auf Lager</g:availability>
                        <g:price> XX,XX EUR</g:price>
                        <g:brand>MARKE</g:brand>
                        <g:ean>XXXXXXXX</g:ean>
                        <g:shipping>
                                <g:country>DE</g:country>
                                <g:service>Selbstabholung</g:service>
                                <g:price>0</g:price>
                        </g:shipping>
                        <g:shipping_weight>XX.XX kg</g:shipping_weight>
                </item>
</channel>
</rss>
 

Vorläufig ist noch <g:ean> da drinne, sollte aber später <g:gtin> sein...,
es sei denn Google akzeptiert EAN, was durchaus sein kann.

Gruß,
noRiddle

[Matt]

Huh, selbstgebautes XML. Ketzerische Frage: DOMDocument() kaputt?

Die Attributwerte sind meines Wissens auch englisch anzugeben, also:

Code: XML  [Auswählen]

<g:availability>in stock</g:availability>

Code: XML  [Auswählen]

<g:additional_image_link>

darf maximal 10 mal vorkommen. sollte also entsprechend abgefangen werden.

// ean number, !! possibly must be <g:gtin>

Das würde ich auch mal so sehen. Wobei es sicherlich nicht schadet, sowohl <g:ean> als auch <g:gtin> mit dem gleichen Wert zu übergeben.

es werden nicht alle shipping module die installiert sind ausgelesen,
bislang keine Ahnung warum...
Lasse ich auf meinem Testshop (1.06 rev 4356) das quote-array ausgeben, ist nur Selbstabholung drin, die anderen zwei installierten shipping methods sind nicht enthalten...

Kann es sein, dass die Query für die Default-Werte nichts vernünftiges zurückliefert? Bei mir funktioniert das mit allen Modulen, wenn die Query Werte enthält (die aktuelle liefert nichts, weil ich die Bundesländer für Deutschland gelöscht habe und somit die Joins kein Ergebnis liefern).

Diese str_replace-Blöcke könnte man aber schon noch etwas verkürzen, oder?

Code: PHP  [Auswählen]

$array_search = array(";","'","\n","\r","\t","\v","&",chr(13));
$array_replace = array(", ", " ", " ", " ", " ", "&amp;", " ");
$products_description = str_replace($array_search, $array_replace, $products_description);
$products_short_description = str_replace($array_search, $array_replace, $products_short_description);
$products_name = str_replace($array_search, $array_replace, $products_name);
 

[noRiddle (revilonetz)]

Huh, selbstgebautes XML. Ketzerische Frage: DOMDocument() kaputt?

Nee , habe ja nur versprochen das im Forum angebotene file auf den neuesten Stand zu bringen und wollte das mal hier erfüllen.

Die Attributwerte können/sollen in deutsch sein.

Die additonal images werden bereits begrenzt:

Code: PHP  [Auswählen]

        foreach($images as $image) {
            $b++;
            echo "\t\t\t" . '<g:additional_image_link>' . HTTP_SERVER . DIR_WS_CATALOG . DIR_WS_THUMBNAIL_IMAGES . $image['image_name'] . '</g:additional_image_link>' . "\n";
            if($b==9)
                break;
        }

Jau, die str_replace-Blöcke "komprimiere" ich noch , war erstmal der Übersicht halber der erste Entwurf.

Die Queries muß ich nochmal genauer betrachten und sehen was sie ausgeben.

Merci für die Stellungnahme.

Gruß,
noRiddle

[Modulfux]

@Matt
DOMDocument ist ja schon ne feine Sache und sieht irgendwie cooler aus.

Aber wo ist hier der Unterschied, wenn bei beiden Sachen dasselbe herauskommt.

Code: PHP  [Auswählen]

$header = $xml->createElement('description', $description);
$channel->appendChild($header);

und

Code: PHP  [Auswählen]

$header = $xml->createElement('description');
$header->appendChild($xml->createTextNode($description));
$channel->appendChild($header);

Ich persönlich bevorzuge die 1.Variante, weil sie kürzer ist und in meinen Augen auch übersichtlicher.

Gruß
Ronny

[Zaldoran]

Die Attributwerte können/sollen in deutsch sein.

Wo steht das derart genau? Ich kenne nur diese Passage:

• Wenn Sie ein Format mit Trennzeichen verwenden, können Sie die Attributnamen entweder auf Englisch oder in der Sprache des Ziellandes eingeben. Achten Sie jedoch darauf, dass die Attributnamen (z. B. 'zustand' und Werte (z. B. 'neu' [new]) immer in derselben Sprache sind.
• Bei Verwendung von XML oder API müssen die in Klammern angezeigten englischen Attributnamen verwendet werden.

Da steht jetzt zwar nicht explizit, dass der erste Punkt bei XML nicht zutreffend ist, das Gegenteil wird jedoch auch nicht behauptet. Imho ist es aber unlogisch, dass bei XML die englischen Attributnamen verwendet werden müssen, die Attributwerte gleichzeitig dann aber deutsch sein können/sollen. Bei Datenfeeds mit dem Zielland USA geht es schon damit los, dass die Attributnamen eben zwingend in Englisch angegeben werden müssen, egal in welchem Format der Feed vorliegt.

[Matt]

Bei Datenfeeds mit dem Zielland USA geht es schon damit los, dass die Attributnamen eben zwingend in Englisch angegeben werden müssen, egal in welchem Format der Feed vorliegt.

Guter Punkt, von daher sollte man auf englische Bezeichnungen gehen, da ist man, egal für welches Land der Feed sein wird, auf der sicheren Seite.

[noRiddle (revilonetz)]

Nöö, denn Zaldoran hat nicht alles zitiert:

• Bei Verwendung von XML oder API müssen die in Klammern angezeigten englischen Attributnamen verwendet werden.
• In diesem Fall müssen Sie Leerzeichen in Attributnamen durch Unterstriche ersetzen, zum Beispiel "image_link" anstelle von "image link". Leerzeichen innerhalb von Attributwerten sind zulässig, zum Beispiel "auf lager" [in stock].

Wie man deutlich in Punkt zwei sieht, deutsch für die Attributwerte ist nicht nur möglich ("auf Lager") sondern für das deutsche Googlebase geradezu erwünscht.

Gruß,
noRiddle