Jump to content

Export Von Produkt-Listen?


Recommended Posts

Nö, nicht per default.

 

kostenlos: mit phpMyAdmin oder einem anderen Tool z.B. Heidi-SQL (mit PS 1.5. sollte es auch mit dem SQL-Manager aus dem Back-Office funktionieren, habe es aber nicht getestet):

 

Mit dem folgenden SQL-query exportierst du die wichtigsten Daten. Die Datei als csv abspeichern für die Weiterverarbeitung.

 

SELECT p.id_product AS 'ID',
p.active AS 'Active (0/1)',
pl.name AS 'Name',
p.id_category_default AS 'Default Category',
p.price AS 'Price tax excl.',
p.id_tax_rules_group AS 'Tax rules ID',
p.wholesale_price AS 'Wholesale price',
p.on_sale AS 'On sale (0/1)',
p.reference AS 'Reference #',
p.supplier_reference AS 'Supplier reference #',
sl.description AS 'Supplier',
ml.description AS 'Manufacturer',
p.ean13 AS 'EAN13',
p.upc AS 'UPC',
p.ecotax AS 'Ecotax',
p.weight AS 'Weight',
p.quantity AS 'Quantity',
pl.description_short AS 'Short description',
pl.description AS 'Description',
pl.meta_title AS 'Meta-title',
pl.meta_keywords AS 'Meta-keywords',
pl.meta_description AS 'Meta-description',
pl.link_rewrite AS 'URL rewritten',
pl.available_now AS 'Text when in stock',
pl.available_later AS 'Text when backorder allowed',
p.available_for_order AS 'Available for order',
p.date_add AS 'Product creation date',
p.show_price AS 'Show price',
p.online_only AS 'Available online only',
p.condition AS 'Condition'
FROM ps_product p INNER JOIN
ps_product_lang pl ON p.id_product = pl.id_product LEFT JOIN
ps_supplier_lang sl ON p.id_supplier = sl.id_supplier LEFT JOIN
ps_manufacturer_lang ml ON p.id_manufacturer = ml.id_manufacturer

 

zum Kaufen: in den Add-ons: http://addons.prestashop.com/en/search?id_category_filter=&id_category_filter=&search_query=export+products

  • Like 2
Link to comment
Share on other sites

Einfach den query in phpMyAdmin ausführen und das Ergebnis abspeichern in eine csv.

 

Ich verwende phpMyAdmin nicht, weil ich es unübersichtlich finde. Ich verwende Heidi-SQL und hänge hier die Bilder an.

 

Dort den Query ausführen, dann im Ergebnis-Fenster rechts unten mit rechter Maustaste klicken. In diesem Fenster Export grid auswählen und die Abfrage als csv, wie im zweiten Bild, abspeichern.

  • Like 1
Link to comment
Share on other sites

In meinem Live-Shop stimmen die aber. Die ID's werden so oft exportiert, wie sie den Kategorien zugeordnet sind. Ist der Artikel in 10 Kategorien, dann wird die ID auch 10X erscheinen. Du kannst diese Datei ja mit Excel dann ausfiltern und die Dubletten dort löschen. ;)

Link to comment
Share on other sites

@Fun4Ever

 

Versuch's mal im SQL-Manager des PrestaShop Back Office (über Erweiterte Einstellungen/SQL Manager) mit der folgenden Abfrage. Dann funktioniert es und du landest mit deiner Liste direkt in Excel:

 

SELECT p.id_product, p.active, pl.name, GROUP_CONCAT(DISTINCT(cl.name) SEPARATOR ",") as categories, p.price, p.id_tax_rules_group, p.wholesale_price, p.reference, p.supplier_reference, p.id_supplier, p.id_manufacturer, p.upc, p.ecotax, p.weight, p.quantity, pl.description_short, pl.description, pl.meta_title, pl.meta_keywords, pl.meta_description, pl.link_rewrite, pl.available_now, pl.available_later, p.available_for_order, p.date_add, p.show_price, p.online_only, p.condition, p.id_shop_default
FROM ps_product p
LEFT JOIN ps_product_lang pl ON (p.id_product = pl.id_product)
LEFT JOIN ps_category_product cp ON (p.id_product = cp.id_product)
LEFT JOIN ps_category_lang cl ON (cp.id_category = cl.id_category)
LEFT JOIN ps_category c ON (cp.id_category = c.id_category)
LEFT JOIN ps_product_tag pt ON (p.id_product = pt.id_product)
WHERE pl.id_lang = 1
AND cl.id_lang = 1
AND p.id_shop_default = 1
AND c.id_shop_default = 1
GROUP BY p.id_product

Edited by eleazar (see edit history)
  • Like 2
Link to comment
Share on other sites

Hier gibt es eine neue Lösung INKL. Bilder-Export.

 

http://www.prestashop.com/forums/topic/229440-free-php-script-export-ps-14-to-15-import-format/

 

Kurze Übersetzung dazu:

 

Die dort angehängte Datei downloaden, öffnen und so bearbeiten, dass auf dem korrekten Verzeichnissen zugegriffen werden kann. Die Datei bitte nach dem Bearbeiten auf dem Server (FTP) unter einen anderen Namen laden, damit andere sie nicht missbrauchen können.

 

Hier das Shop Verzeichnis ändern, falls der Shop in einem Unterverzeichnis angelegt ist (z.B. /shop/)

define ('MY_ROOT_DIR', '/');

 

Produkt-Ordner URL

define ('URL_IMG_DIR_P', ​​'http://deine domain/img/p/.');

 

Kategorien-Ordner URL

define ('URL_IMG_DIR_C', 'http://deine domain/img/c/.');

 

Die Sprache der ID ändern, welche exportiert werden soll (1 = EN, hier die ID eintragen die für DE definiert ist)

define ('lang_id', 1);

 

Das Akzent im Code so belassen oder den Separator selbst umdefinieren, falls der Server keine Akzent " ` " akzeptieren sollte und nur mit dem hochgestellten Komma arbeiten sollte " ' "

define ('FIELD_SEPARATOR', '`');

 

Diese Anweisung ist, um alle Kategorien, welche nicht exportiert werden sollen, auszusortieren (in PS 1.5. stehen alle Produkte im Root = 1)

define ('CAT_ID_OFSET', 1);

 

Bitte die Datei nach dem Export löschen, oder sie mit einem Passwort schützen, damit niemand unerlaubt Ihre Informationen downloaden kann.

Link to comment
Share on other sites

@eleazar: .... das geht gut mit den SQL-Manager. Vielen Dank.

Nur die description und description_short funktioniert nicht.

 

Warum steht in der Abfrage einmal "p." und einmal "pl."?

p.description_short, pl.meta_title,

 

Kann ich nicht einfach alle Merkmale aus den Tabellen auslesen?

ps_product

ps_product_lang

Edited by Fun4Ever (see edit history)
Link to comment
Share on other sites

Ja klar, kannst du auch. Aber dann musst du hinterher den ganzen Kram wieder zusammenführen. Für die Beschreibungen reicht:

 

SELECT * FROM `ps_product_lang` WHERE 1

 

Trotzdem weiß ich nicht, warum du die Lang- und Kurzbeschreibungen nicht exportiert bekommst. Bei mir funktioniert es nämlich, obwohl die z.T. richtig lang sind. Auch die HTML-Formatierungen werden mit ausgegeben.

 

Warum steht in der Abfrage einmal "p." und einmal "pl."?

pl.description_short, pl.meta_title,

 

Bei den mit pl bezeichneten Feldern handelt es sich um sog. translatable fields. (Dir ist da selbst ein Schreibfehler unterlaufen ^_^) Sie sollen ja in der Landessprache ausgegeben werden. Dazu zählen:

 

pl.description_short, pl.description, pl.meta_title, pl.meta_keywords, pl.meta_description, pl.link_rewrite, pl.available_now, pl.available_later

 

Da PrestaShop für den Im- und Export jeweils nur eine Sprache zulässt, bedarf es noch einer Bedingungen, die der SQL-Abfrage mithilfe der Landes-ID die richtige Sprache zuweist:

 

LEFT JOIN ps_product_lang pl ON (p.id_product = pl.id_product)
(...)
WHERE pl.id_lang = 1

 

Das Einzige, was hier wirklich variabel ist und ggf. angepasst werden muss, ist das Präfix der Tabelle. Zufällig hast du genau wie ich den Defaultwert ps - aber der ist nun mal beliebig.

 

Ein ausführliches Tutorium findest du übrigens hier. Ich hab das zwar mal vor über 20 Jahren gelernt, aber ... lang, lang ist's her. ;)

Edited by eleazar (see edit history)
  • Like 1
Link to comment
Share on other sites

@eleazar:

"SELECT * FROM `ps_product_lang` WHERE 1" fragt die Beschreibung ab. Das funktioniert.

Da habe ich dann wieder das Problem mit den vielen IDs.

 

Und wie ist das mit den Sprachen? Englisch und Deutsch beim Importieren?

Link to comment
Share on other sites

Nee, du hast kein ID-Problem! Es hat auch nichts mit der Mehrfachzuordnung zu den Kategorien zu tun.

Du hast eine Mehrsprachenproblem. :)

 

Schau dir mal die Spalte id_lang an. Da wird immer von 1 bis 6 gezählt, also hast du 6 Sprachen im Shop.

 

Deswegen musst du auch spezifizieren, in welcher Sprache du die Beschreibungen brauchst. Wenn es nur die deutschen sein sollen, dann lautet der Befehl:

 

SELECT * FROM `ps_product_lang` WHERE `id_lang` = 1

  • Like 1
Link to comment
Share on other sites

Du möchtest den Export für alle Sprachen haben, oder nur für eine. Wenn du nur für eine den Export benötigst, dann musst du die ID der Sprache, die du exportieren möchtest auch definieren. EN ist in der Regel die ID_1. DE (wenn du nichts an den Sprachen geändert hast), ist standardmäßig ID_3 (kann aber auch 4 sein, wenn du deinen Shop von PS 1.3 auf 1.4. und dann auf 1.5. upgegradet hast)

  • Like 1
Link to comment
Share on other sites

Jetzt haben wir die LÖSUNG der IDs.

Ihr habt beide Recht - DANKE!

ID 3 = Deutsch, deshalb hatte ich auch keine description im Script von eleazar, da ID 1 abgefragt wir.

 

 

Kann ich die Produkte bei einem Import einfach überschreiben?

Meine ID fangen zum Beipspiel erst bei 8 an und möchte die Produkte gerne neu sortieren.

Edited by Fun4Ever (see edit history)
Link to comment
Share on other sites

Da musst du aber leider jede Menge Tabellen anpassen. Genau die Produktabelle greift in sehr viele anderen Tabellen ein (Abhängigkeiten). Für was soll denn der Export dienen ? Wenn du diesen in eine neue Datenbank direkt importieren möchtest, würde ich das so belassen. Wenn du aus dem BO die Produkte neu anlegst, dann ist es egal, denn PS legt die Produkte mit der nächsten freien ID an.

Link to comment
Share on other sites

Hallo cd2500,

 

ich möchte gerade nicht jedes Produkt einzeln im Backoffice anlegen, sondern einfach per Copy & Paste eine Tabelle pflegen und diese dann importieren.

Das hört sich für mich viel logischer an.

 

Am liebsten möchte ich alle Produkte nochma löschen, um dann mit der ID 1 ein Produkt im Backoffice SAUBER anlegen mit allen Details, dieses exportieren und die nächsten Artikel darauf aufbauen.

Da kann ich erkennen welche Merkmale genutzt worden sind und so weiter machen.

Link to comment
Share on other sites

Importieren kannst du nur mit dem Back-Office Tool, oder mit einem externen Tool wie den Presta Store Manager. Artikeln direkt in die Datenbank kannst du nicht einpflegen/importieren, weil diese sehr viele Abhängigkeiten während des Imports/Anlage schreiben.

 

Ich dachte du möchtest einen Export, um die Daten in externen Preislisten oder so weiterverwenden zu können.

Link to comment
Share on other sites

Da hat CD2500 aber recht. Natürlich kannst du die Produkte komplett exportieren und dann beim neuerlichen CSV-Import neue IDs automatisch wieder ab 1 vergeben lassen. Aber du musst wirklich an die Interdependezen denken. Das sind nicht einfach nur Zahlen, sondern Indexfelder, über die andere Tabellen - z.B. die Kategorien - mit den Produkten verknüpft sind.

 

Du fängst dann quasi wieder von vorn an.

 

Wenn du das willst, ok. Dannn einfach nur per PHPMyAdmin Produkte als CSV exportieren, und direkt über das BO nach entsprechender Bereinigung wieder importieren.

 

Du kanst die Tabelle zwar nicht per Copy & Paste pflegen, aber du kannst jederzeit auch in bereits bestehende Tabellen (Podukte, Kategorien, Kunden etc.) über das BO importieren, sofern du das Häkchen bei IDs der Importdatei beibehalten nicht vergisst. Da muss die CSV-Datei auch nicht alle Felder enthalten. Du kannst auch nur ein oder zwei Felder aktualisieren, sofern die ID in der Datei enthalten ist und du wie beschrieben vorgehst.

Edited by eleazar (see edit history)
Link to comment
Share on other sites

Möchtest du deine Artikel immer wieder mittels Importe bearbeiten (Lagerstand, Preise, usw.), dann empfehle ich dir ein externes Tool zu verwenden. PSM habe ich dir schon genannt. Hiermit gleiche ich alle Preise und Lagerstände mit meinen Lieferanten per Cron 1X/Tag ab. Ich kümmere mich um keine 20.000 Artikel die ständig sich ändern...

 

Die Importfunktion im Back-Office ist lediglich für die Erstbestückung geeignet, aber nicht für die Verwaltung von vorhandenen Daten.

Link to comment
Share on other sites

Importierst du deine exportierte Liste bereinig jetzt wieder, dann kommt die ganze Datenbank in Durcheinander. Du hast dann falsche Bilder bei falschen Produkten, falsche Varianten, usw...

 

Auch kann man mit dem Back-Office Tool Varianten z.B. nich importieren, das muss man in einem zweiten Schritt erledigen, vorausgesetzt man kenn die ID der Produkte.

Link to comment
Share on other sites

... und welchen Sinn ergibt dann diese Funktion beim CVS-Import?

Das hat ja nichts mehr mit Erstbestückung zu tun?

 

IDs der Importdatei beibehalten.

Wenn Sie diese Option nicht anklicken, wird Prestashop neue IDs generieren und automatisch hochzählen.

  • Like 1
Link to comment
Share on other sites

Nö, das kann er jederzeit. Das ist ja gerade das Praktische an dieser Funktion von PrestaShop. Machen wir an dauernd. Siehe meinen Post weiter oben.

 

Meines Erachtens geht das garnicht über das BO. Man muss da alle Daten wieder importieren. ALLE, sonst bleiben die Felder leer, denn der Import überschreibt die Daten. Es wäre mir neu, wenn PS da bereits was daran geändert hat.

Ich werde es mal ausprobieren mit PS 1.5.3.1. und berichte.

 

Viele User haben bereits diesen Bereinigungsweg gewählt und hatten dann falsche Bilder zu falschen Produkten und ein Chaos in der Datenbank, sowie leere Beschreibungen, weil eben dann der Versuch war nur Preise abzugleichen.

Link to comment
Share on other sites

Das ging auch schon vor Version 1.5.3.1 so. Wenn man es richtig macht, überschreibt der Import wirklich ncihts, kannst du mir gern glauben. Wichtig ist nur dieser kleine Klick auf das Kästchen, das bis Version 1.52 noch die kryptische Beschriftung Force all ID's during import? trug.

 

Vor allem aber, dass der Primärschlüssel der Tabelle in der CSV-Datei bei jedem Produkt steht - und das ist, wie ich an anderer Stelle im Forum ausgeführt habe, nicht etwa das Feld Reference sondern IMMER das erste Feld der Tabelle: id_product, id_customer, id_category usw.

 

s. dazu hier (S. 2)

 

Das kannst du also gefahrlos machen, Lars - und das sage ich dir aus Erfahrungen mit über 200 Kategorien und mehr als 6000 Produkten. Hätte es dieses Feature nicht gegeben, hätte meine Frau den Umstieg auf PrestaShop nie auch nur in Erwägung gezogen. Erst nachdem wir das hin- und her ausprobiert hatten, fiel die Entscheidung.

  • Like 1
Link to comment
Share on other sites

Oh la la. Da hat sich mit PS 1.5 einiges geändert. Die Tabellen, welche man nicht angibt werden nicht mehr überschrieben als leer. Da hat man offensichtlich einiges dazugelernt. War unter PS 1.4 noch nicht möglich, zumindest nicht bis Version 1.4.6.2.

 

Du kannst die Produkte schon importieren, aber sie müssen die gleiche ID haben, um diese abzugleichen. Gibst du keine ID an, dann werden sie alle neu angelegt mit einer neuen ID. Ist es denn so tragisch, dass die mit ID 8 beginnen, anstatt ID 1 ? Wenn du Artikel löschst, dann werden die gelöschten ID's sowieso reserviert bleiben, wenn bereits nachfolge Dokumente vorhanden sind (Aufträge, usw.).

 

Wenn du alles neu haben möchtest, dann einen neuen Shop installieren, OHNE Muster und dann die exportierte Liste importieren. Was mir allerdings beim Import aufgefallen ist, ist dass man dort keine Steuer mehr angeben kann. Wer also Produkte mit verschiedenen Steuersätzen verwendet, der hat ein Problem. Die Preise in der Datenbank werden auch nur Netto gespeichert (dein Export enthält nur Netto-Preise und eine eigene Spalte mit dem Steuersatz), so dass man beim Import auch einen Steuersatz angeben sollte. Diese Funktion ist aber nicht vorhanden. Da hat man offensichtlich wieder nur halben Gedankengang erledigt...

 

Du kannst ja den PSM 30 Tage kostenlos nutzen. Nutze ihn, um deinen Shop einzurichten mit Importe/Exporte. Danach musst du ihn ja nicht kaufen. Auf jeden Fall bist du damit 10X schneller.

Link to comment
Share on other sites

Danke für den TIPP mit dem PSM - ABER wie heißt das genau?!?

Aber wie gesagt meine exportierte CSV-Datei mit allem möglichen kann ich wohl nicht einfachimportieren ohne diese wieder für Produkte/Kategorien/usw. anzupassen.

Da ist es dann auch Sprachenabhängig.

Edited by Fun4Ever (see edit history)
Link to comment
Share on other sites

Sorry ich verstehe nicht das Problem. Ich dachte du hast bereits nur eine Sprache exportiert ? Wenn nicht, dann sortiere die mittels Excel doch aus... (Filteroption kennst du ?) Der PSM liest auch die Tabellen korrekt aus, wo du mit drei Mausklicks dann alle deine Produkte in der Datenbank hast. Der PSM berücksichtigt nämlich auch den Steuersatz.

 

Ich würde alles mit PSM exportieren (mit drei bis vier Klicks erledigt) und dann alles mit dem PSM in die neue Datenbank importieren. Die Kategorien falls nicht angelegt, werden beim Import mitangelegt.

Link to comment
Share on other sites

@Fun4Ever

meine exportierte CSV-Datei mit allem möglichen kann ich wohl nicht einfachimportieren ohne diese wieder für Produkte/Kategorien/usw. anzupassen.

.

 

Doch, die gute Nachricht ist: Kannst du - wenn du dich an ein paasr Eigenheiten gewöhnst. Nehmen wir mal an, dass du sie mit Excel erstellt hast. Dann machst du Folgendes:

  1. Datei im BO laden (hier kommt schon die erste Hürde: Falls du so etwas mehrmals hintereinander gemacht hast, ist das Prestshop schnurzegal - dir wird immer die erste Datei angeboten. Also Dropdown-Menü öffnen und die richtige nachschlagen. Als kleinen Anhaltspunkt fügt PrestaShop immer Upload-Datum und -Zeit hinzu, so dass man sich nicht vertun kann. Wenn die Dropdownliste mal zu lang wird, die überflüssigen Dateien einfach im Verzeichnis admin<xx>/import löschen.
  2. PrestaShop andet immer wieder in der obersten Auswahlvarianten Kategorien. Also immer drauf achten, wohin du importierst.
  3. Bei Excel-Dateien, die normalerweise nicht utf8-codiert sind, nicht vergessen, ein Häkchen bei ISO-8859-1 codiert (Excel-CSV)? zu machen.
  4. Bei bloßen Aktualisierungen auf keinen Fall Vorhandene Kategorien vor Import löschen? anklicken!!
  5. Stattdessen ein Mausklick bei IDs der Importdatei beibehalten.
  6. Dann auf Button WEITER klicken
  7. Da die Excel-Tabelle normalerweise in der ersten Zeile die Feldbezeichner enthält, im Feld Überspringen ... Zeilen eine 1 eintragen.
  8. Und nun kannst du die Felder, die indeiner CSV-Datei ruhig andere Feldnamen tragen dürfen, hier zuordenen. Die Reihenfolge spielt keine Rolle. Felder, die nicht vorhanden sind, oder die nicht aktualisiert werden sollen, könen auch durch Auswahl dr Option "Diese Spalten ignorieren" vernachlässigt werden.
  9. Und das Sahnehäubchen: Wenn du alles richtig eingestellt hast, speichere diese Konfiguration für die künftigen Importe unter einem beliebigen Namen über der Auswahl im Feld, das mit Speichern und passende Konfiguration laden überschrieben ist, ab. Beim nächsten Import brauchst du nur die jeweiligen Konfiguration laden, und schon weiß PrestaShop, was es importieren soll.

  • Like 1
Link to comment
Share on other sites

@CD2500

Was mir allerdings beim Import aufgefallen ist, ist dass man dort keine Steuer mehr angeben kann. Wer also Produkte mit verschiedenen Steuersätzen verwendet, der hat ein Problem. Die Preise in der Datenbank werden auch nur Netto gespeichert (dein Export enthält nur Netto-Preise und eine eigene Spalte mit dem Steuersatz), so dass man beim Import auch einen Steuersatz angeben sollte. Diese Funktion ist aber nicht vorhanden.

 

Na ja, vielleicht solltest du dir die Importfunktion von PrestaShop 1.5.3 doch einfach mal ansehen. ;) Ich weiß nämlich nicht, wie du darauf kommst. Es ist zwar richtig, dass die Datenbank Nettopreise speichert. Doch beim Import kann man ebenso wie bei der Eingabe der Produkte wahlweise den Netto- oder Bruttobetrag importieren, und den Steuersatz selbstverständlich auch.

Link to comment
Share on other sites

Aha, heisst wohl ID Steuerregel (wobei ein Newbie damit nicht sehr viel anfangen kann...)

Na ja der Import war schon immer nicht so optimal gelöst, viel Besserung von PS 1.4. zu PS 1.5. hat da nicht wirklich stattgefunden, bis auf, dass der Bug mit den Feldern die nicht zugeordnet werden NICHT mehr überschreiben werden.

 

Bei der Import-Funktion gibt es noch viel Verbesserungspotential. Ich mache das seit eh und jeh mit einem externen Tool, weil schon unter PS 1.3. war das nur Käse. Ist zwar verbessert worden, aber optimal ist diese Funktion noch lange nicht.

Link to comment
Share on other sites

Ich verstehe nicht warum du dich damit noch abmühst. Mit PSM wäre das schon lange erledigt. Aber ok.

 

Ich sehe in deinem Screen auch, dass die Beschreibungen nicht UTF8 sind. Genauso wie das im Bild abgebildet ist, wird es dann auch geschrieben.

 

Die Tabellen musst du zuordnen zu den was prestashop in der ersten Zeile zur Auswahl anzeigt. Wenn du diesen Import als Vorlage speichern möchtest, dann kannst du die Option speichern verwenden (im Bild das erste Feld).

Link to comment
Share on other sites

Erstmal finde ich den PSM nicht.

Und außerdem öffne ich die exportierte Datei im UTF8 Format und speichere diese dann einfach als .csv ab.

Nachdem ich die Drop Down Menüs der Spaltenbezeichnung angepasst habe funktioniert der Import sehr gut.

Sieht zumindest so aus.

Fehlen zwar noch die Kombinationen, aber das könne wir später lösen :-)

Edited by Fun4Ever (see edit history)
Link to comment
Share on other sites

http://addons.presta...prestashop.html

 

Schau einmal im Bild unter der Spalte EAN - Palmeras cocoa butter und weiter unten asolida formula mit den "a" als Sonderzeichen.

 

PSM importiert kombis mit Preiserhöhung und Gewichterhöhung gleich mit, so dass du nicht 2X importieren must. Auch benötigst du dort keine ID, also du musst nicht die ID des Produktes vorher raussuchen um die Kombis zu importieren.

Link to comment
Share on other sites

Ich glaube € 199,00 . Auf der Downloadseite sollte der Preis stehen. Ist aber auch abhängig, ob du mehrere Lizenzen benötigst und Multishop, bzw. noch andere Module dazupassend. Ich habe das Tool schon über 2 Jahre, deshalb weiß ich den Preis nicht.

Link to comment
Share on other sites

Nur mit UTF-8. Wenn ich aber ehrlich bin, habe ich alle meine Beschreibungen nicht mit dem Importer von PS importiert. Ich habe diese mit dem PSM importiert und zwar in einem zweiten Import (nur Spalte Referenz + Spalte Beschreibung). Der HTML-Code ist ein Hund und hat immer wieder alles zerrissen. Mit PS ging es garnicht, mit PSM habe ich dann ale Einzelimport keine Probleme mehr gehabt.

 

Du musst den Text ändern. PSM hat mit Hochkommata keine Probleme. Ich habe z.B. einen Artikel mit Mac's. Diese wurden ohne Probleme importiert.

Mein Katalog enthält 20.000 Produkte, da muss alles passen.

Link to comment
Share on other sites

@Fun4Ever

und wie bekomme ich die Formatierung hin:

Palmer's und 'solid' Formula.

 

In der Praxis sehe ich da gar kein Problem: Das kriegst du viel einfacher und auch kostengünstiger mit dem PrestaShops CSV-Import und Excel hin. Da brauchst du auch keine UTF-8-Kodierung.

Das â bekommst du eigentlich nur hin, wenn du aus Versehen irgendein Sonderzeichen an die Stelle gesetzt hast.

 

PrestaShop ist für den Import gut gerüstet. Beim CSV-Import nur ein Häkchen bei ISO-8859-1 codiert (Excel-CSV)? setzen, und dann werden alle Sonderzeichen einschl. Apostroph problemlos übernommen. Sollte das 'solid' am Anfang eine Excel-Spalte stehen, dann benötigt Excel für die korrekte Darstellung am Anfang noch ein zusätzliches Apostroph. Excel ist eben in erster Linie eine Tabellenalkulation und nicht unbedingt auf Texterfassung eingerichtet.

Edited by eleazar (see edit history)
Link to comment
Share on other sites

Excel ist eben in erster Linie eine Tabellenalkulation und nicht unbedingt auf Texterfassung eingerichtet.

 

Das ist korrekt, dennoch ist der Importer von Prestashop leider nicht so ausgereift, dass er mit bestimmte Dinge auch umgehen kann. Importiere ich das mit dem PSM, dann wird er die Sonderzeichen auch korrekt umsetzen. Dort habe ich auch keine Option für UTF-8 oder ISO. Dem ist das völlig Wurscht. Auch mit HTML-Code kann er besser umgehen, als der Importer von PS. So hat auch jede Software seine eigene Daseinsberechtigung, ohne dass man die eine oder die andere schlecht reden muss...

Link to comment
Share on other sites

Weißt du, bloße Behauptungen gewinnen auch durch stetige Wiederholung nicht an Wahrheitswert. Ich lass mich ja gern eines Besseren belehren, aber dazu musst du endlich auch mal Belege liefern.

 

Alle wichtigen Sonderzeichen wie Hochkomma, Apostroph, Anführungszeichen, Währungssymbole, auch Umlaute, Buchstaben mit Akzent etc.werden fehlerlos importiert - und das sage ich jetzt als jemand, der es wirklich ausprobiert hat. Und deswegen weiß ich auch, dass bestimmte Steuerzeichen oder mathematische Symbole wie das Wurzelzeichen nicht importiert werden.

 

Importiert werden:

! " #   ø % & ' ( ) * + , - / : ; ? @ [ \ ] ^ _ ` { | } ~ £ ¥ $ € § © ® µ « » ¼ ½ ¾ É À Á È á à â ä ë

 

Nicht importiert werden Unicode-Zeichen wie:

 

√ = < > ⅛ ⅜ ⅝ ≤ ≥ № ℠ ™ ℅ 

 

Aber mal im Ernst: Braucht die jemand für einen Online-Shop? ;)

 

Was geht denn deiner Meinung nach nun genau nicht, was unbedingt benötigt wird? Mit welchen HTML-Befehlen, die für die Formatierung gebraucht werden, kann PrestaShop nicht oder schlecht umgehen?

 

Und wie kommst du darauf, dass PrestaShop einen 128-Bit-Zeichensatz nicht von einem 256-Bit-Zeichensatz unterscheiden kann? Denn ich vermute mal, das meinst du, wenn du von UTF-8 und "ISO" sprichst.

Edited by eleazar (see edit history)
Link to comment
Share on other sites

@ Fun4ever - Muß man selbst wissen, ob man es benötigt oder nicht. Zunächst ist es kostenlos und du kannst den Shop komplett und viel bequemer damit einrichten.

PSM hat auch noch viele andere Vorteile, was sich natürlich im Preis auswirkt. Ich erspare mir mit dem Tool mindestens 2 Std. Arbeit am Tag. Jeder muss selbst abwegen was er für sinnvoll hält oder nicht.

Ich gebe lediglich Tipps weiter, die sich bei mir als Besitzer mehrerer Prestashop (einer davon mit 20.000 Artikeln) bewährt hat. Ich habe natürlich da viel mehr ausgegeben, weil ich mehrere Module verwende und auch ein Kassensystem angebunden habe, sowie die automatische Lagerverwaltung mittels Barcodescanner. Für mich hat sich der finanzielle Aufwand gelohnt und ich bin nach oben offen. Aus dem BO von Prestashop kann ich all die Funktionen die mir der PSM bietet garnicht erledigen, oder teilweise nur durch komplizierte Umwege, die Zeit kosten.

 

Die Funktionen vom Prestashop BO greife ich schon seit Jahren nicht mehr an, was die kaufmännische Abwicklung anbelangt. Nicht einmal für den Versand von Mails oder irgendwelche Vorlagen oder Listen für den Steuerberater. PSM kann das alles erledigen (auch mittels cron).

Link to comment
Share on other sites

@eleazar - Lieber eleazar, jetzt muss ich mich als IT-Fachmann hier mal einmischen.

 

Wir haben Prestashop im Einsatz bei unseren Kunden offensichtlich schon etwas länger, nämlich seit Version 1.2.X. Wir verfolgen daher die Entwicklung also schon sehr, sehr lange und müssen cd2500 in seinen Aussagen Recht geben.

Beim Importer von Prestashop hat sich sehr viel geändert, und zwar mit jedem größeren Release. Er wurde verbessert und funktionierte bisher für Datensätze ISO codiert eher schlecht als recht.

 

Es ist auch nicht ganz korrekt was du schreibst:

Primär ist das "Verstehen" der Zeichenketten von der Einstellung der Datenbank abhängig. Eine Datenbank welche mit Charset ISO-8859-1 angelegt ist, wird per se auch keine anderen Unicode-Zeichenketten (UTF-8, UTF-32, UTF-16, usw...) korrekt sortieren können, weil der Codepunkt ein ganz anderer ist.

Die meisten Hosting Provider hier in Deutschland haben Ihre Server standardmäßig mit dem charset ISO- 8859-1 (latin1) Codesatz eingestellt, was schon mal Probleme macht.

 

Viel wichtiger ist hier zu erwähnen, welches Decoder-Skript (Konvertierungsskript) + welches replacement Skript dahinter läuft.

 

Insoferne hat cd2500 dann auch Recht zu behaupten, dass mit dem Charset ISO 8859-1 (was vermutlich damit gemeint ist) einige Sonderzeichen nicht korrekt umgesetzt werden können, weil mit diesem Charset nur eine kleine Fraktion vom UTF-8 Zeichensatz kodiert werden kann. Außerdem arbeitet Prestashop mit Java-Skripten, was das ganze unter ISO-8859-1 noch komplizierter macht. Die meisten Konvertierungsfehler sind dann erkennbar an den falschen replacement Zeichen. Das gilt im Übrigen auch für die HTML-Zeichenfolge (darunter < und >) wenn sie falsch geparst ist, dann wird sie auch falsch gerendert (ausgegeben). Auch falsch gesetzte BOM's können das ganze System wieder zunichte machen.

 

Die von dir genannten Zeichen sind im Übrigen reine ISO-8859 Zeichen (daher schon klar, dass sie auch korrekt importiert werden, wenn der Dekoder oder das Konvertierungsskript sie so umsetzen). Ein Schwede kann ganz andere Importprobleme haben wie wir, wenn der Decoder oder Server nicht mitspielt. Auch kann das "™" sehr oft in Beschreibungstexte vorkommen die als englische Beschreibung zur Verfügung gestellt werden. Das Wort "№" kommt auch sehr oft vor wenn man Spanisch oder Portugiesisch verwendet.

 

Aber wollen wir hier doch nicht weiter Fachsimpeln, denn ein Expert weiß worum es geht und ein Anwender will garnicht wissen wie, was funktioniert. Die wenigen Informationen, die cd2500 hergegeben hat, sind korrekt und mehr muss kein Anwender wissen. Die Angelegenheit zu zerreden und ins Tausendste zu gehen wird hier niemanden etwas helfen. Einen Anwender ist es doch viel wichtiger, dass alles so funktioniert wie er es benötigt. Sei es standardmäßig oder mit dem PSM, welchen wir selbst auch bei einigen unserer Kunden einsetzen.

Edited by ITJSchmitt (see edit history)
  • Like 1
Link to comment
Share on other sites

@ITJSchmitt

 

Hallo ITJSchmitt,

 

na gottseidank, dass sich mal ein IT-Fachmann einmischt. :)

Danke für deine präzisen Erläuterungen. Ich finde es schade, dass sich fachkundige Leute wie du hier nur selten äußern. Das würde manch sinnloses Scharmützel wirklich überflüssig machen.

 

Ansonsten gebe ich dir völlig recht: Den deutschsprachigen Anwender (und nur darum geht es ja hier) interessiert nicht, wie es funktioniert, sondern was funktioniert und was nicht geht. Natürlich ist bei einem so jungen Open-Source-Produkt wie PrestaShop noch einiges im Fluss - aber gerade deswegen brauchen Anwender klare und aktuelle Informationen über das, was inzwischen problemlos läuft. Aber ich glaube, das ist jetzt wirklich hinreichend geklärt.

Link to comment
Share on other sites

  • 1 month later...

Eine Frage und bitte haut mich nicht,

 

da das Update von Prestashop 1.5.3.1 auf die neuest bei mir nur Ärger macht bin ich am überlegen einen neuen Shop aufzusetzen.

 

Wäre es evtl möglich meinen alten Shop upzudaten. Dann ein SQL Backup zu machen, die Foto Ordner abzuspeichern und das dann bei einer neuen Prestashop Version in die Ordner reinzukopieren sowie das SQL Backup aufzuspielen?

Link to comment
Share on other sites

... sowie das SQL Backup aufzuspielen?

Das auf keinen Fall, wenn die Versionsgruppe schon mal eine andere ist ohne absolutes Expertenwissen der beiden Versionen.

 

Innerhalb einer Gruppe (PS 1.5. auf PS 1.5, PS 1.4. auf PS 1.4, usw.) kein Problem, aber auch nur mit Mapping und Expertenwissen über die Struktur der beiden Versionen.

Link to comment
Share on other sites

Also mein Shop ist ein 1.5.3.1 geupdatet auf 1.5.4.1

 

Da aber durch das update soviele Fehler entstehen würde ich gerne komplett eine neue Version installieren sowie die Produkte übernehmen. Da der Shop noch nicht in Betrieb war und ich nur die Artikel eingespeist habe wäre das evtl ne Möglichkeit.

Link to comment
Share on other sites

Welche Fehler entstehen denn ? Verwendest du irgendwelche Module, die nicht Original mit dem Downloadpaket von Prestashop mitkommen ? Dann solltest du die vor dem Ugrade deinstallieren und mit dem 1-Klick-Upgrade Modul ganz normal upgraden. Und dann die Module wieder installieren. Sehr oft sind Module nur bis zu einer Version X gecodet und für die kann kein Upgrade gemacht werden.

 

Fremdmodule daher bitte immer vor einem Upgrade deinstallieren oder zumindest deaktivieren.

 

Bei keiner einzigen Seite die ich betreue und von 1.5.3.1 auf 1.5.4.x upgegradet habe, konnte ich irgendwelche Probleme beim Upgrade feststellen. Es verlief alles reibungslos. Außer die Bugs die mit der nächsten Version mitkommen hatte ich bis jetzt keine Probleme mit einem Upgrade.

Link to comment
Share on other sites

Ich hatte keine Fremdmodule installiert deswegen wundert es mich auch

 

Ein Bug mit der ich zB in der englischen Community um Hilfe angesucht habe ist der Blockviewed Bug

http://www.prestashop.com/forums/topic/243542-problem-with-blockviewed-after-update/page__fromsearch__1

 

Bei einem anderen zB wenn ich ein Produkt auswähle das man kaufen kann wird zB die Kategorien nicht mehr angezeigt.

Link to comment
Share on other sites

Das einzige Problem was ich sehe, ist dass du ein eigenes Theme verwendest. Themes von PS 1.4. funktionierten nicht mit PS 1.4. Auch Theme von kleineren Version PS 1.5.3.1. funktionieren nicht mit PS 1.5.4. wenn man Anpassungen gemacht hat. Zwischen PS 1.5.2. und PS 1.5.4.0 wurde smarty komplett auf Version 3 upgegradet. Wenn du jetzt ein altes Modul verwendest oder ein altes Theme, welches noch alte Anweisungen enthält, dann kommt es zu solchen Problemen. Generiere dir ein Theme passend zu deiner Prestashop-Version mit Theme Maker oder nimm das aktuelle Theme von PS 1.5.4.0, clone es und passe alles nochmal an. Du wirst feststellen, dass auch der Theme Maker mit den Versionen mitgeht. Das hat auch seinen Grund.

 

Da Module auch vom Theme abhängig sind und vom Core der nach wie vor ständig angepasst wurde in den letzten PS-Versionen, gibt es keine andere Möglichkeit.

 

Ich habe mit dem Theme Maker selbst ein Theme für Ps 1.5.2. erstellt und musste es für PS 1.5.3.1. geringfügig anpassen, sprich upgraden. Für PS 1.5.4.1 war dann nochmals ein Upgrade nötig, weil eben einige Dinge nicht mehr funktionierten.

Ich würde das auch nicht als Bug bezeichnen, denn ein alter Code oder alte Strukturen müssen nicht unbedingt mehr mit neuester Technik funktionieren. Es wird zwar ein Downgrade immer versucht, aber Garant gibt es keinen, weil auch jeder einen anderen Server, andere PHP-Version, andere SQL-Version verwendet. Alles kann man leider nicht abdecken. ;)

Link to comment
Share on other sites

Ich fahre schon lange mit einer Testversion angepasst mit den Fixen hier aus dem Forum seit PS Version 1.5.0.17. Diese Version ist Original in allem (bis auf die Fixe) und wurde mit dem 1-Klick-Upgrade-Modul jedes Mal upgegradet auf die aktuellste Version. Den einzigen wirklich echten Bug den es gibt ist der Block Suche, welcher gefixt wurde und die Navigationsleiste, wofür es noch keinen Fix gibt und der Report im forge noch offen ist. Wie du erkennen kannst ist der Block "angesehene Produkte" bebildert und auch fehlt keine Kurzbeschreibung. Das Theme ist also default untouched seit Version 1.5.0.17 und auch die Module dazu mit den jeweiligen Upgrades (bis auf Paypal und andere Zahlungsmodule wegen des 1-Button-Fixes).

 

Ich bin mir sicher, dass du irgendwo noch auf alten Core in deinem Template verweist und deshalb die Probleme davon kommen.

post-60291-0-47981200-1367762785_thumb.jpg

Link to comment
Share on other sites

  • 4 weeks later...

Guten Tag,

 

ich habe meine Produkte per SQL-Manager des PrestaShop Back Office exportiert. Dafür habe ich die weiter oben vorgeschlagene Abfrage angegeben.

Die Datensätze die ich erhalte sind nicht aktuel. Es fehlen Änderungen die ich seit der Produkt-Erstbestückung per csv-Import gemacht habe.

Hat jemand eine Erklärung dafür? Wie bekomme ich die aktuelen Produkt-Daten?

 

Vielen Dank im voraus und Sonnige Grüße

 

 

Hat sich geklärt, musste id_lang korrekt angeben.

Ciao

Edited by caravntrader (see edit history)
Link to comment
Share on other sites

Beim Importer von Prestashop hat sich sehr viel geändert, und zwar mit jedem größeren Release. Er wurde verbessert und funktionierte bisher für Datensätze ISO codiert eher schlecht als recht.

 

Es ist auch nicht ganz korrekt was du schreibst:

Primär ist das "Verstehen" der Zeichenketten von der Einstellung der Datenbank abhängig. Eine Datenbank welche mit Charset ISO-8859-1 angelegt ist, wird per se auch keine anderen Unicode-Zeichenketten (UTF-8, UTF-32, UTF-16, usw...) korrekt sortieren können, weil der Codepunkt ein ganz anderer ist.

Die meisten Hosting Provider hier in Deutschland haben Ihre Server standardmäßig mit dem charset ISO- 8859-1 (latin1) Codesatz eingestellt, was schon mal Probleme macht.

 

Viel wichtiger ist hier zu erwähnen, welches Decoder-Skript (Konvertierungsskript) + welches replacement Skript dahinter läuft.

 

Insoferne hat cd2500 dann auch Recht zu behaupten, dass mit dem Charset ISO 8859-1 (was vermutlich damit gemeint ist) einige Sonderzeichen nicht korrekt umgesetzt werden können, weil mit diesem Charset nur eine kleine Fraktion vom UTF-8 Zeichensatz kodiert werden kann. Außerdem arbeitet Prestashop mit Java-Skripten, was das ganze unter ISO-8859-1 noch komplizierter macht.

 

Wenn man für das Erstellen der csv-Datei libre office verwendet, dann kann man dort die csv Datei explizit als utf-8 Datei speichern. Ich finde allgemein, dass sich csv-Dateien mit libre office besser bearbeiten lassen als mit Excel.

 

post-280425-0-53165300-1369778106_thumb.png

Link to comment
Share on other sites

  • 6 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...