Hallo,
nochmal ich:). Diesmal nur was kurzes. Hat jemand schonmal probiert Bilder OXICON und so per Download zum Server automatisch zu downloaden beim Import?
Ich bin da halb am verzweifeln:)
Grüße Kai
Hi Kai,
sorry für die platte Frage, aber wo genau liegt das Problem. Ich verstehen wohl dein Szenario nicht genau ?!?!
Grüße
Mathias
Hallo Mathias,
danke für Deine Nachfrage. Also folgendes zum Problem. Ich wollte um den CSV-Import besser zu verstehen (ich model nich gerne im Quelltext rum solange es auch andere WorkArounds gibts (special csv-converter-skript, oder openoffice.org calc nachbearbeitung)) einen CSV-Export machen. Nunja siehe mein anderes Posting der CSV-Export spuckt fast janix aus:). Okay also eine CSV blind in den CSV-Import reingepustet und siehe da, mein erster Erfolg MySQL-Tabellennamen = CSV-Tabellenamen. Wunderbar, openoffice.org an durch Spaltennamen angepaßt (wunderbar andere Shopsysteme nehmen dort nur Zahlen als Anker) und der erste Import hat prima geklappt.
Nur als ich dann die http-links (http://www.bilderdomain.de/products/images/thumbs/image.jpg) oder dergleichen reingenommen habe in OXICON und so weiter hat der Import nur die Namen der Bilder ohne url und ohne sie für das oxid-system hochgeladen und angepaßt wurden übernommen. Nun suche ich nach einer möglichst schnellen Lösung dies anzupassen.
Klar ich könnte mir ein Skript schreiben, was dies alles automatisch per shell-skript oder dergleichen macht, aber ich suche noch nach einer direkten Erweiterung der CSV-Import Skripte von OXID. Praktisch wenn externe Url dann kopiere die images auf den server und füge sie in die oxid-logik ein. Ich denke mal articlenummer_icon und artikelnummer_1 wäre ganz handy:).
Bin auch gerade dabei mich in die Skripte einzuarbeiten aber vielleicht gibt es ja andere Workarounds oder jemand arbeitet ebenfalls daran.
Danke und Grüße
Kai
So…
das meiste funktioniert schon aber ich habe leider im Kern gehackt und leider noch keine Möglichkeit gefunden, Datenbankeintrag der PICS[x] und externen FileDownload zu koordinieren.
/core/oxerpbase.php
dort habe ich eine Möglichkeit gefunden mich einzuhacken in der _importOne() Funktion. Dort mache ich folgendes, als Beispiel an dem Thumbnails:
if( $aData)
{ $blRet = true; $blImport = false; $sMessage = ‘’; $sType = $this->_getImportType( $aData); $sMode = $this->_getImportMode($aData); $oType = $this->_getInstanceOfType( $sType); $aData = $this->_modifyData($aData, $oType);
if ($aData[“OXTHUMB”]){ $picname = parse_url ($aData[“OXTHUMB”]); $picname = pathinfo($picname[“path”]); $picname = $picname[“basename”];
…
Copy Files von externer Url in PicturePath
…
}
…
Nun meine zusätzliche Frage. Wie kann ich Hacks im Core am besten in ein Modul auslagern? Oder besser implementieren?
Irre immer noch im Kern rum und suche eine Möglichkeit den Bildnamen der abgespeichert werden soll, mit den Datenbank eintragen in OXTHUMBS und OXPICS[x] zu koordinieren. OXID selber macht dies ja schon beim import, wenn es um _ico s geht.
Danke
und
Grüße
Kai
Sooooo diese Funktion wird langsam aber Sie sie ist noch superunsauber
For-Schleifen Parsing der möglichen Spalten
for ($i=0;$i<=17;$i++) { $pictype=“OXPIC”.$i; if ($i==0) $pictype=“OXTHUMB”; if ($i>=13 && $i<=16) $pictype=“OXZOOM”.($i-12); if ($i==17) $pictype=“OXICON”; }
Und sie ist immer noch im Kern fest einprogrammiert. Gefällt mir garnicht. Ich würde der Community gerne meine Arbeit zu Verfügung stellen, möchte aber auch nicht als Kern-Beschmutzer dastehn. Falls jemand aus meinen Posting schlau wird, würde ich mich freuen wenn ich ein kleines FeedBack bekommen würde, wie ich diese Änderung am besten als Modul zur Verfügung stelle, damit es andere vielleicht optimieren können und dieses OldScool-Coding säubern:).
Dann muss ich noch schauen dass ich endlich Dateiname und Datenbankeinträge konforrm auf Artikelnummer trimme.
Und eine OXPIC_HIRES-Variable soll auch noch kommen, damit die GDLib was zu tun bekommt:).
Danke
Grüße und Nacht
Kai