Gelöst Unmengen Artikel In Pestrashop

[daniel.jtl]

Ich verstehe eure Ideen, nur ist euch offenbar der genaue technische Vorgang und auch das Ausmaß des ganzen Ablaufs definitiv nicht klar.
In der Theorie klingt das alles toll. Leider ist es aber weder technisch noch wirtschaftlich möglich sämtliche Fehler, Besonderheiten und Eventualitäten in den unterschiedlichsten Drittanbieter-Systemen abzufangen oder gar auszugleichen.
Mal ganz davon abgesehen dass es nicht unsere Aufgabe ist.

Der Quellcode der Connectoren steht ja für jeden frei zur Verfügung, und jeder kann und darf sich daran beteiligen.
Sofern ihr also praktisch durchführbare Lösungsvorschläge habt, könnt ihr diese als Merge-Request einreichen und wir werden diese dann gerne testen und einbauen.

 

[testjo]

Bis dies nicht alles Automatisch ist dazu hier dieser Forumbeitrag.

Aber sowass sollte in Anleitung, WIKI dan auch Fett drin.

 

[Havekost-UG]

hallo,

mir kommt gleich das Frühstück wieder hoch wen ich sowas lese. "Ich verstehe eure Ideen, nur ist euch offenbar der genaue technische Vorgang und auch das Ausmaß des ganzen Ablaufs definitiv nicht klar.
In der Theorie klingt das alles toll. Leider ist es aber weder technisch noch wirtschaftlich möglich sämtliche Fehler, Besonderheiten und Eventualitäten in den unterschiedlichsten Drittanbieter-Systemen abzufangen oder gar auszugleichen.
Mal ganz davon abgesehen dass es nicht unsere Aufgabe ist."

mal wieder eine Aussage vom JTl Support das der Nutzer die die korrekten daten zuleifern hat. Die Daten werden in der Wawi hinter und bearbeitet. Punkt.
Komisch die Amsie kann Fehler log machen und ist so aufgebaut das wenn ein Fehler passiert das sie trotzdem weider und den Fehler nicht importiert.
Warum kannn der scheiß Connector und Worker das nicht ? Das ist doch die Frage wo sich alles darum dreht.

Hätte ich das gewusst hätte ich bestimme nicht die WAWI Software genommen. Zumal man direkt über Ebay/Amazon an euch bezahlt oder Indirekt über die Servicepartner.

Fakt ist das teil funktioniert nur zu 90%

Gruß Karsten

 

[daniel.jtl]

das der Nutzer die die korrekten daten zuleifern hat.

Selbstverständlich musst du korreke Daten anlegen. Ich verstehe jetzt absolut nicht was daran unsere Aufgabe sein soll?
Fakt ist: Du verwendest nicht nur unsere Wawi, sondern bindest Drittanbieter-Systeme an.
Auf diese Systeme haben wir 1. keinen Einfluss was die Programmierung oder deren Fehler-Verhalten angeht, und 2. ist es hier auch möglich Anpassungen vorzunehmen die außerhalb unserer Kontrolle liegen.
Es kann ja nun schlecht von uns verlangt werden, dass wir die redaktionelle Prüfung deiner Daten vornehmen, weil diese im Shop eines anderen Anbieters nicht kompatibel, oder wie in dem Fall zu lang sind?

Wenn du ein System benötigst dass zu 100% mit der Wawi kompatibel ist musst du den JTL-Shop nehmen.
Andernfalls geht leider kein Weg daran vorbei, dass du dich über die Einschränkungen die bedingt durch Drittanbieter-Shops enstehen informierst, und deine Daten auch entsprechend pflegst.

 

[Kanatu]

Hi Daniel,

Ich kann verstehen, dass Änderungen and Wawi wie anpassbare Feldlängen etc. nicht einfach umzusetzen sind und es wirtschaftlich für euch keinen Sinn macht.

Bitte dennoch als Feature Request aufnehmen.

Was den Connector angeht bin ich enttäuscht, denn für dich wäre es vermutlich eine Sache von ein paar Stunden das zu fixen und damit wäre das Hauptproblem gelöst.

Schade, da der Connector was Features angeht nahezu komplett zu sein scheint.

 

[daniel.jtl]

denn für dich wäre es vermutlich eine Sache von ein paar Stunden das zu fixen

Das ist es wie jetzt mehrfach gesagt und aufgrund einer Vielzahl an Gründen leider nicht.
Es bringt aber auch nichts dass jetzt hier weiter technisch zu diskutieren und zu erklären, wenn der entsprechende Einblick und Sachverstand fehlt.
Eine allgemeine und pauschale Erwartungshaltung dass JTL dafür zuständig wäre, und das ja alles "ganz einfach" und "mal eben" machbar wäre hilft uns da absolut nicht weiter.

Wie bereits angeboten:
Wer entsprechende Ahnung hat darf sich gerne den Quellcode angucken, und realistische und vor allem praktisch durchführbare Lösungsvorschläge einbringen.
Ich gucke mir das dann gerne an, und werde es in jeglicher Hinsicht mit unterstützen und ausarbeiten.

 

[Andreas Grambow]

Hallo,

ein einfacher Workarround wäre, ein Workflow prüft beim erstellen und beim ändern ob die Beschreibung über x Zeichen hat, wenn ja, dann Mail mit Hinweis. Diese Artikel müssen dann nochmal überarbeitet werden.

Das wäre eine rel. einfache Lösung. Die zwar Aufwand macht, aber in der summe wohl viel Arbeit spart.

Man könnte das ganze dann sicherlich noch soweit aufblassen, dass man wenn der Artikel mehr als 400 Zeichen in der kurzbeschreibung hat, dann per Worklfow der Artikel in eine nicht Shopkategorie verschoben wird, so sollte auch kein Shopabgleich mehr erfolgen.

Das mal 2 rel. einfach denkbare Szenarien.

 

[css-umsetzung]

ja ist es a...............ber
dazu muss man als Shopbetreiber erstmal wissen das es beschränkt ist, wie gesagt ich habe keine Infos darüber gefunden, in der DB ist das als TEXT eingestuft.
zusätzlich betriffft es ja jeden erdenklichen Fehler der bei der Variablenkonvertierung passieren könnte (ein bestimmtes Zeichen das nicht erlaubt ist bis hin zu anderen Artikelfelder bei denen es noch nicht bemerkt wurde das es möglich ist nicht valide übergaben zu machen).

es nutzt auch nichts weitere Ideen zu haben, da JTL sich hier ganz auf die externen User verlässt, die das dann schon fixen werden wenn es sie stört (sorry muss ich so sagen)

 

[daniel.jtl]

da JTL sich hier ganz auf die externen User verlässt

In dem Fall richtig, die Gründe wurde ja mehr als ausgiebig erklärt.
Speziell zu diesem Thema übrigens auch noch ein Hinweis: Die Länge kann je nach Shop-Version unterschiedlich sein, und es ist auch möglich diese shopseitig zu ändern.
Allein die Google-Suche " prestashop description limit" dürfte hier klar verdeutlichen, dass das eine sehr individuelle Sache ist, die sich nicht durch eine statische Beschränkung oder einen redaktionellen Eingriff unsererseits lösen lässt.

 

[Havekost-UG]

Fakt ist ihr macht Werbung mit dem Connector. Das alles läuft. Man sollte mal hinzufügen das es zu problemen führen kann und wird. Klar ihr macht es euch einfach " der Kunde" selbst korrekte Daten liefern.
Ein beispiel in pestra shop kann ich die Länge der Kurzbeschriebung festlegen nur dem Connector ist das sowas von scheiß egal der macht einfach weiter.

 

[daniel.jtl]

Fakt ist ihr macht Werbung mit dem Connector. Das alles läuft.

An keiner Stelle wurde jemals behauptet das "alles läuft".
Ganz im Gegenteil: Es gibt eine Feature-Matrix, die ganz klar darauf hinweist welche Dinge pro Shop unterstützt werden und welche nicht, siehe hier:
https://www.jtl-software.de/JTL-Wawi-Onlineshop-Anbindung
Zudem gibt es in der Anleitung einen ausgiebigen Abschnitt über die Thematik "Einschränkungen und Besonderheiten" wo erneut auf derartige Dinge hingewiesen wird, siehe hier:
https://guide.jtl-software.de/jtl/Kategorie:JTL-Connector:Presta

Informieren muss man sich schon selber, und sich vor allem der Einschränkungen seines Drittanbieter-Shops bewusst sein, für den wir ganz klar nicht zuständig sind.
Ich werde mich daher jetzt diesbezüglich nicht auf weitere Diskussionen einlassen. Es wurden ausreichend Fakten, technische Erklärungen und Verweise auf Anleitungen geliefert.
Das Problem ist zudem in diesem Fall jetzt hinreichend bekannt: Wenn du nicht bereit bist deine Daten entsprechend aufzubereiten, musst du entweder halt deinen Shop entsprechend modifizieren um längere Beschreibungen zuzulassen, oder eben auf den Einsatz von Shop und Connector verzichten.

 

[daniel.jtl]

So, um hier mal auf einen Nenner zu kommen, habe ich den Connector gerade um eine entsprechende Option erweitert:
In den Modul-Einstellungen bekommt man jetzt den zusätzlichen Schalter "Kurz-Beschreibungen abschneiden".
Sofern dieser aktiviert ist, werden die Beschreibungen radikal auf die derzeitig durch den Shop vorgegebene Länge gekürzt bzw. abgeschnitten.
Die aktuell eingestellte Länge wird hier auch in der Options-Erklärung mit angezeigt.

Ich halte es nach wie vor für die erheblich sinnvollere Lösung, sich der Beschränkungen bzw. Einstellungen seines Shops bewusst zu sein, sowie seines redaktionellen Inhalts.
Auch wenn der Connector jetzt mittels dieser Option eingreifen kann, ist es weder schön noch Kunden- oder Suchmaschinen-freundlich die Kurz-Beschreibungen einfach wegzuschneiden.
Zumal es eine Sache von 10 Sekunden ist, die Länge der Kurz-Beschreibung in den Shop-Voreinstellungen höher zu setzen, wodurch das Problem auf saubere Weise beseitigt wäre.

Die neue Version steht zunächst mal nur testweise hier zur Verfügung:
http://downloads.jtl-software.de/jtlconnector/Presta/jtl_connector_prestashop_1.4.7.zip

 

[Leos Global]

mit Interesse habe ich die lebhafte Diskussion in diesem Thread gelesen. Auch ich hatte das Problem mit der Kurzbeschreibung und noch ein paar andere beim Upload. Da ich vom JTL-Support am letzten WE so schnell keine Antwort erhielt, habe ich die 2 Tage genutzt, um die Ursachen zu suchen. Nach der Antwort vom Support am Montag bin ich dann auch schon selber drauf gekommen, daß JTL bestimmt nicht jeden Murks von Drittanbietern ausbügeln muss.

Das Problem liegt bei Prestashop, genauer gesagt in der Datenvalidierung und da habe ich es als alter Hobby-Programmierer auch gelöst. Und das geht so:

1.) Im Ordener "classes" findet ihr die Datei "ObjectModel.php"
2.) Dort Zeile 895 bis 916 mit folgendem Code ersetzen:

public function validateFields($die = true, $error_return = false)
{ return true; }

Das war's! Bumms-aus-Nikolaus...fertig Ertser!

Ab jetzt habt Ihr den Validator ausgeschaltet und könnt (fast)* alles hochladen, was ihr wollt. Für eventuelle Crashs übernehme ich werde Haftung noch Verantwortung weil ich nicht weiß, was für Sachen Ihr da so alles hochladen wollt.

Viel Freude & Beste Grüße

Oliver

* sofern die SQL-Datenbankfelder mitspielen. Beschreibungen sind kein Problem, aber wer eine 13-stellige UPC eingeben will, muß den Wert in der DB vorher erhöhen. (Ja, ich weiß, daß die UPC nur 12 Stellen hat, aber ich nehme lieber die EAN als UPC und suche nicht Tausende UPC's im Netz, nur weil ein paar Amis neben Ihren Kindergarten-Maßeinheiten auch noch eigene Produktnummern haben wollen)

PS: Falls jemand weiß, in welcher der gefühlten 3 Millionen Prestashop-Dateien die interne Validierung des UPC-Codes stattfindet, oder wo diese Variable definiert ist, wäre ich für jeden Tipp dankbar

 

[css-umsetzung]

Das Problem liegt bei Prestashop, genauer gesagt in der Datenvalidierung und da habe ich es als alter Hobby-Programmierer auch gelöst. Und das geht so:

Als Hobby-Programmierer darfst du das auch gerne so machen, für jemand der das professionell macht ist das keine Lösung.

 

[daniel.jtl]

für jemand der das professionell macht ist das keine Lösung.

Richtig, die Lösung die ich aber jetzt auf diverse Bitten eingebaut habe ist da genauso wenig professionell.
"Professionell" wäre einzig und allein einen Wert in den Voreinstellungen einzutragen der den persönlichen Anforderungen gerecht wird. Denn genau zu diesem Zweck gibt es diese Option...

 

[css-umsetzung]

Also, irgendwo weiter vorne habe ich geschrieben, dass ich diesen Wert auf 3000 erhöht hatte und nein, ich habe nicht gesagt, einfach abschneiden, da bin ich ziemlich sicher, denn ein html markup einfach mittendrin abzuschneiden ist ja fast noch schlimmer, als vor dem Münzautomat zu stehen und immer wieder zu versuchen, ihm Scheine unterzujubeln.

Ich hätte es gerne gesehen, dass die Übertragung mit einer entsprechenden Fehlermeldung, dass Daten nicht valid waren, beendet wird, oder wenn eine Übertragung warum auch immer, mittendrin abgelehnt wurde, kompl. wieder entfernt werden. Da ihr das nicht einbauen möchtet, habe ich meinen Kunden zu einem JTL Shop gedrängt und weiß, dass ich dieses konstrukt, so nicht mehr in die Hand nehmen werde.

Ich hatte bei den ersten Fehlern, dass Problem, dass die länge des Textes nicht passte, am Ende kamen noch andere Fehler hinzu bei den Artikeln, die den gleichen Effekt auslösten, da passte dem Shop irgendein Zeichen nicht....

 

[Leos Global]

Das Ergebnis spricht wohl für sich...Ich kann alles hochladen und zwar JETZT SOFORT.

Versuche es doch einmal so zu betrachten: Ich bin zu 95% Online-Seller und zu 5% Programmierer. Das heißt, ich muss sofort und gleich eine Lösung haben, sonst verkaufe ich nichts und kann mich beim RotKreuz an der Suppenküche melden. Du bist zu 100% Programmierer, lebst davon, willst es perfekt haben und es kann dir egal sein wie lange es dauert.

Aber versetze dich doch auch einmal in deinen Kunden, der zu 100% Seller ist. Der braucht auch eine schnelle Lösung, denn sonst kann oder will er dich bald nicht mehr bezahlen.

Wenn Du so gut bist, warum löst Du die Probleme nicht dort, wo sie entstehen. PrestaShop ist Open-Source und der Code ist nur so lange in Stein gemeißelt, bis Jemand kommt uns ihn seinen Bedürfnissen entsprechend anpasst. Um es mal mit Herrn Nike zu sagen:"Just Do It!"

Auch ich weiß, daß ich mit meiner Lösung nicht den Nobelpreis im PHP-Coden bekomme und es bestimmt besser ginge. Aber zumindest habe ich einen funktionierenden Workaround, der mir und meinen Verkäuferkollegen unsere süßen Hintern rettet, bis ein noch unbekannter Held der Programmierkunst den perfekten Prestashop präsentiert.

Also übernimm deine Verantwortung, kritisiere nicht vorhandene Lösungen, versuche nicht deine Probleme von JTL lösen zu lassen und werde deinen Namen gerecht: SETZE ES UM. Viel Erfolg.

 

[Kanatu]

Ist doch super, dass Daniel für das Problem nun doch eine Lösung geliefert hat. Es sind vermutlich weitere Felder potentiell kritisch, aber solange keine Probleme reported werden ist verständlich wenn nichts gemacht.

@css-umsetzung: du kannst Software von Oracle und SAP für €€€€ kaufen und auch da haben die Interfaces zwischen zwei Systemen fast immer auch ihre Grenzen und decken niemals jeden möglichen Fehlerfall ab.

Welche weiteren Probleme hast du genau gehabt?

Ich persönlich habe bei der Datenmigration Probleme mit Meta-Description und Meta-Keywords gehabt (Länge>255). Unwahrscheinlich bzw sinnlos, dass hier manuell mehr eingegeben wird.


@Leos Global: In classes/Product.php 280

  'upc' =>                        array('type' => self::TYPE_STRING, 'validate' => 'isUpc', 'size' => 12),

und in classes/Validate.php 557

    public static function isUpc($upc)
    {
        return !$upc || preg_match('/^[0-9]{0,12}$/', $upc);
    }

 

[css-umsetzung]

@Leos Global ich habe deine Lösung nicht kritisiert, sie ist nur nicht machbar weil ich dafür haftbar gemacht werden kann, wenn eine Datenbank durch mich geschrottet wird weil ich "mutwillig" validierungsroutinen deaktiviere. Du kannst das für dich so machen und du weißt auch das du das beim nächsten Update nachpflegen musst.

Es war in meinem Fall, bei den ersten fällen, die Anzahl der Zeichen, die Erweiterung auf 3000 nutzte nichts, dann habe ich alle Artikel einfach, über die MSSQL Datenbank auf 350 zeichen gekürzt da die eh nicht im Shop angezeigt wurde und es daher egal war. Als nächstes Problem kamen dann Sonderzeichen, das war der Punkt wo es genug war, sich damit zu beschäftigen, da es eben unnötiges Geld verbrannte.

Der Vergleich mit anderer Software hinkt da ein wenig, nur weil andere schlechte Software machen muss ich mich da ja nicht direkt einreihen.
Ich mag mich auch gar nicht rechtfertigen, nur weil ich es gerne sehen würde, wenn eine Software Ihre Daten prüft, denn für mich ist das ein normaler Vorgang.

 

[Leos Global]

@css-umsetzung Es wäre echt riesig, wenn Du eine dauerhafte Lösung mit Validierung findest und präsentierst. Und solltest Du im Gegenzug auch 3-Taler-Fuffzig hierfür aufrufen, dann soll dir auch ein gerechter Lohn für deine Mühen zustehen und ich werde dein Kunde (sofern ich mich nach meiner derzeitigen Testphase dauerhaft für Prestashop entscheiden sollte).

@Kanatu Vielen Herzlichen Dank! Lobgeprisen sei dein Name und der Boden auf dem Du wandelst...Du hast mir bestimmt einen halben Nachmittag schnöder Codesuche erspart