Eine vollständige Aufstellung kann ich dir im Moment noch nicht geben, da sind wir noch in der Planungsphase. Wir werden aber probieren, so viele Daten wie möglich zu übernehmen. Bei den Kundendaten wird man aber wohl ein neues Passwort vergeben müssen, da Oxid da ja mit einem Salt arbeitet, der nicht mit unserem kompatibel ist. Also grob gesagt: - Artikeldaten mit Varianten (Hier müssen wir noch prüfen, welche Flags / Felder wir ggf. im Moment garnicht standardmäßig haben, die kann man dann ja entsprechend auch nicht importieren. Das können aber nicht viele sein…) - Kundendaten - Bestellungen
Danke für die Infos. Hab noch eine Frage zu den Design Templates. Wenn ich diese jetzt schon anpasse, sind sie dann final verwenbar? Oder ändert sich da noch zu viel?
[quote=“taaucher”]Danke für die Infos. Hab noch eine Frage zu den Design Templates. Wenn ich diese jetzt schon anpasse, sind sie dann final verwenbar? Oder ändert sich da noch zu viel?[/quote] Wir sind gerade noch die Templatebasis final zu bekommen, aber grundsätzliche Dinge werden sich nicht mehr ändern.
[quote=„Stefan Hamann“]- Artikeldaten mit Varianten (Hier müssen wir noch prüfen, welche Flags / Felder wir ggf. im Moment garnicht standardmäßig haben, die kann man dann ja entsprechend auch nicht importieren. Das können aber nicht viele sein…) - Kundendaten - Bestellungen[/quote] Varianten in OXID sind normale Artikel, die sich nur dadurch von normalen Artikeln unterscheiden, dass sie einen „Parent-Id“ zum Master-Artikel haben… Wobei Varianten m.E. sowieso eine sehr limitierte Angelegenheit sind… Bei mehrdimensionalen Varianten kommt man schnell in Anzahl-Dimensionen, die nicht mehr handhabbar sind (Anzahl = Produkt der Optionen für alle Dimensionen). Ich denke/hoffe, Euer Konfigurator-Modul ist da wesentlich besser geeignet, auch eine größere Anzahl von Dimensionen abzubilden (mit Artikel-Nummern, Lagerbestand, Bild, Beschreibung?). Hier mal ein ganz pathologische Beispiel für viele Varianten (das ist ein stark aufgebohrtes xtCommerce): http://www.beckpc.ch/game/product_info. … rator/true Ich hatte mal ausgerechnet, dass man da so ca. 12 [color=#FF0000]Trillionen [/color]PC-Varianten konfigurieren kann… Wäre das Shopware Konfigurator-Modul geeignet, so etwas abzubilden?
[quote]Varianten in OXID sind normale Artikel, die sich nur dadurch von normalen Artikeln unterscheiden, dass sie einen “Parent-Id” zum Master-Artikel haben…[/quote] Deshalb haben wir die ein- und mehrdimensionalen Varianten von der DB-Struktur her getrennt. Man hat dadurch zwar weniger Konfigurationsmöglichkeiten bei den einzelnen Kombinationen, ballert aber auch nicht die primäre Artikel-Datenbank mit unzähligen Einträgen voll. [quote] Wobei Varianten m.E. sowieso eine sehr limitierte Angelegenheit sind… Bei mehrdimensionalen Varianten kommt man schnell in Anzahl-Dimensionen, die nicht mehr handhabbar sind (Anzahl = Produkt der Optionen für alle Dimensionen). [/quote] Das ist bei dieser Art der Artikeldarstellung ein grundsätzliches Problem. Wenn man den Standard-Konfigurator verwendet und mit sehr vielen Gruppen + Optionen arbeitet, ergibt sich da natürlich am Ende eine unglaubliche Menge an Kombinationen, die alle physikalisch in der Datenbank abgebildet werden müssen und eigene Bestände und Daten haben können. Deshalb muss man im Vorfeld schon genau schauen, welche Art von Konfigurator am meisten Sinn macht. Bei einem PC-Konfigurator würde man z.B. eher mit dem Aufpreis-Konfigurator arbeiten. Da konfiguriert man die Preise auf Optionsbasis und es wird keine “riesige” Kombinationsmatrix gebildet. [quote] Ich denke/hoffe, Euer Konfigurator-Modul ist da wesentlich besser geeignet, auch eine größere Anzahl von Dimensionen abzubilden (mit Artikel-Nummern, Lagerbestand, Bild, Beschreibung?). [/quote] Durch die Trennung von den normalen Artikeln ist das schon recht performant und zieht nicht die gesamte Shop-Performance runter. Bei sehr vielen Kombinationsmöglichkeiten würde man aber auf den Aufpreis-Konfigurator ausweichen und der bietet weniger Einstellungsmöglichkeiten. Beim Standard-Konfigurator kann man aktuell Artikelnummer, Kundengruppen-Preise, Lagerbestände, Bild und beliebige Freifelder überschreiben (Die Freifelder können dann andere Stammfelder des Hauptartikels ersetzen), beim Aufpreis-Konfigurator gibt es diese Felder nicht. Dort wird “einfach” ein Auf- oder Abpreis auf den Stammpreis des Artikels definiert. Die ausgewählten Optionen werden dann dem Warenkorb übergeben. [quote] Hier mal ein ganz pathologische Beispiel für viele Varianten (das ist ein stark aufgebohrtes xtCommerce): http://www.beckpc.ch/game/product_info. … rator/true Ich hatte mal ausgerechnet, dass man da so ca. 12 Trillionen PC-Varianten konfigurieren kann… Wäre das Shopware Konfigurator-Modul geeignet, so etwas abzubilden?[/quote] Naja, die Frage ist, welche sonstigen Anforderungen die Artikeldarstellung im Beispiel mit sich bringt. Also welche Daten bei den einzelnen Kombinationen gespeichert werden müssen. Über den Aufpreis-Konfigurator, von der reinen Darstellung her, aber auf jeden Fall lösbar!
Hatte mir das Beispiel gerade mal angesehen. Von dem, was man im Frontend sehen kann, würde man das auf jeden Fall mit dem Aufpreis-Konfigurator umsetzen. Bei den einzelnen Optionen müsste man noch einen Bild-Upload hinzufügen, der Rest müsste so per Standard gehen. Ich weiß natürlich nicht was da backenseitig dahintersteht, also ob für die Optionen ein Lagerbestand verwaltet wird. Das müsste man bei uns auch noch anpassen…
[quote=„Stefan Hamann“]Hatte mir das Beispiel gerade mal angesehen. Von dem, was man im Frontend sehen kann, würde man das auf jeden Fall mit dem Aufpreis-Konfigurator umsetzen. Bei den einzelnen Optionen müsste man noch einen Bild-Upload hinzufügen, der Rest müsste so per Standard gehen. Ich weiß natürlich nicht was da backenseitig dahintersteht, also ob für die Optionen ein Lagerbestand verwaltet wird. Das müsste man bei uns auch noch anpassen…[/quote] Im Grunde ist es ein Aufpreiskonfigurator, das ist die normale Arbeitsweise von xtCommerce. Aber: ein wesentlicher Punkt ist, dass man dort bei den einzelnen Optionen eine Artikelnummer vergeben kann. Die haben wir dazu verwendet, die im Grunde „dummen“ Optionen mit normalen Produkten zu verbinden, die als versteckte Artikel angelegt werden. Damit hat man die Möglichkeit, Bilder, Beschreibungen, Lagerbestände usw. der Optionen über diese Pseudo-Artikel zu verwalten und zu verwenden (natürlich nur nach „kleinen“ Eingriffen in die Shop-Software…). Bei OXID gibt es eine ähnliche Problematik: da gibt es sog. Auswahllisten, die vom Konzept her wohl Eurem Aufpreiskonfigurator entsprechen, und auch nur eine Beschreibung und einen Preis enthalten. Um dort Produkte wie z.B. http://web122.serv38.loswebos.de/ah3/Bi … igBag.html zu verwalten, haben wir OXID dahingehend erweitert, dass die Auswahllisten auch pro Option eine Artikelnummer bekommen. Und mit dem gleichen „Trick“ wie bei xtCommerce (Pseudo-Artikel, verbunden über die Artikelnummern in Option und Artikel) haben wir dann wieder die einzelnen Optionen mit viel Inhalt und Lagerbestand füllen können. (z.B. werden bei Anwahl von Optionen andere Options-Bilder und -Texte angezeigt, und die Produkt-Hauptbeschreibung mit den Texten der aktuellen Optionen aktualisiert.) [color=#FF0000]Es wäre also ganz toll, wenn Ihr Eurem Aufpreiskonfigurator Artikelnummern für die einzelnen Optionen spendieren würdet.[/color] Zum einen könnten die Shopbetreiber dann die zu einer Option gehörenden Artikel gezielt bestellen. Und zum anderen könnte man eben einfacher solche Konzepte wie oben beschrieben verwenden. Arbeitet der Aufpreiskonfigurator mit shopweiten Optionen? (Ich habe z.B. 50 CPU-Varianten im Shop und ordne daraus 10 einem Artikel zu.) P.S.: Über diese Abbildung von Optionen auf Artikel hat man dann auch wieder die Möglichkeit, solche Optionen mit WaWis zu verwalten, was ja i.d.R. nicht geht… Der BeckPC-Shop ist mittlerweile weitestgehend automatisiert… Der Shop-Betreiber muss nur noch ca. 200 Komponenten und die Konfiguration der einzelnen Systeme pflegen (wobei die Preise automatisch vom Lieferanten übernommen werden) . Alles andere geschieht automatisch… Und das alles wurde möglich, weil die Optionen eine Artikelnummer haben… :thumbup:
Frage zum Bilderhandling: Werden die Artikelbilder automatisch von einem Masterbild in die verschiedenen verwendeten Größen umgerechnet? (Icon, Thumbnail, Zoom,…) Wenn ja: werden die Bilder maßstabsgetreu skaliert oder auf feste Höhen/Breiten gebracht? Kann man später die gewünschten Bildgrößen ändern und die Bilder dann neu erstellen lassen? Kann man die Bilder mit einem Wasserzeichen versehen? THX
[quote] Werden die Artikelbilder automatisch von einem Masterbild in die verschiedenen verwendeten Größen umgerechnet? (Icon, Thumbnail, Zoom,…) [/quote] Ja, man kann in den Grundeinstellungen die Größe, der zu erzeugenden Thumbnails definieren. “30:30:0;57:57:1;105:105:2;140:140:3;285:255:4;720:600:5” In diesem Fall also 6 Thumbnails je Bild. (Aufbau: X:Y:ID[fortlaufend]) Im Template kann man dann z.B. folgendermaßen auf die Artikelbilder zugreifen: {$sArticle.image.src.4} // Link zu Thumbnail mit der ID 4 {$sArticle.image.src.original} // Link zur Ursprungsversion, des hochgeladenen Bildes [quote] Wenn ja: werden die Bilder maßstabsgetreu skaliert oder auf feste Höhen/Breiten gebracht? [/quote] Ist beides möglich. Je Thumbnail entweder feste Breite oder feste Höhe. Man kann aber auch auf das Originalbild im Template zurückgreifen. Im Standard werden die Bilder normalerweise auf eine feste Breite skaliert. [quote] Kann man später die gewünschten Bildgrößen ändern und die Bilder dann neu erstellen lassen? [/quote] Ja, dafür gibt es einen Wiki-Artikel. http://www.shopware.de/wiki/Nachtraegliche-Veraenderung-der-Thumbnail-Groessen_detail_35.html Es gibt auch eine aktuellere Version davon, die auf unsere API zurückgreift. Die muss ich aber noch ins Wiki stellen. [quote] Kann man die Bilder mit einem Wasserzeichen versehen? [/quote] Das geht derzeit noch nicht. Das einzubauen dürfte aber ein minimaler Aufwand sein…
Danke erstmal für deine super Anregungen zum Konfigurator. Ich kann dir noch nicht versprechen, dass wir die noch in die 3.5.0 integrieren können, aber ich könnte mir gut vorstellen, dieses Thema dann als Plugin / Entwickler-Tutorial anzugehen. Es gibt bei uns auch noch so genanntes Konfigurator-Zubehör. Das geht bereits ungefähr in die Richtung die dir vorschwebt. Da wird bei den Optionen nur eine Referenz (Artikelnummer) zu einem bestehenden Artikel hinterlegt, so dass alle Daten von diesem Artikel geladen werden. In der Storefront werden die Optionen (gruppiert) zum Artikel angezeigt und können zusammen in den Warenkorb gelegt werden. Das wäre technisch dann schon die richtige Stelle um einzusteigen, denke ich. Ich nehme es auf jeden Fall auf die 4er Roadmap und werde sehen, das wir da irgendwas in Tutorial-Form bringen.
[quote=“Stefan Hamann”] Ja, man kann in den Grundeinstellungen die Größe, der zu erzeugenden Thumbnails definieren. “30:30:0;57:57:1;105:105:2;140:140:3;285:255:4;720:600:5” In diesem Fall also 6 Thumbnails je Bild. (Aufbau: X:Y:ID[fortlaufend])[/quote] Verstehe ich das richtig, dass man im Grunde beliebig viele Bildergrößen definieren kann? OXID hat eine m.E. coole Funktion: man kann einen alternativen Bildpfad definieren… Um z.B. die Bilder von einem anderen Server zu laden… $this->sAltImagePath=‘http://www.mein_bildserver.de/images’; Würde Shopware sicher auch gut stehen… ====================================================== Frage zum Templating: Wie aktiviere ich denn das “Template override” (einige Templatedateien überlagern die entsprechenden Dateien des Basistemplates)?
Hallo, also wenn mich nicht alles täuscht gehen max. 6 Thumbnails (v3.05), aber man kann halt verschiedene Größen angeben. Mit alternativen Bildpfaden über einen http-Pfad, das ist meiner Meinung nach nicht ganz ohne. Denn auf der Bestellabschlussseite werden diese Bilder ja auch noch einmal angezeigt. Die Bestellabschlussseite wird aber auch per https aufgerufen. Und wenn da dann die Bilder als externe Quellen über http geladen werden, wird das eigene SSL-Zertifikat für ungültig erklärt. Also wenn, dann muss man schon sichergehen, das die Bilder auch über https verfügbar sind. Viele Grüße Thomas
Moin! [quote] also wenn mich nicht alles täuscht gehen max. 6 Thumbnails (v3.05), aber man kann halt verschiedene Größen angeben. [/quote] Nein, das ist nicht korrekt 
Man kann beliebig viele Thumbnails in den Einstellungen definieren, die dann automatisch generiert werden. Wenn man das im Nachhinein macht, muss man allerdings mit unserem Hilfsscript die Thumbs neu erzeugen. [quote] OXID hat eine m.E. coole Funktion: man kann einen alternativen Bildpfad definieren… [/quote] Dadurch das wir externe Ressourcen grundsätzlich über eine eigene Smarty-Funktion laden, kann man das sehr einfach umsetzen. Der Bildpfad z.B. ist global definiert, da kann man ohne Probleme auch einen externen Host angeben. @Thomas Wenn der Bild-Server auch https unterstützt, sollte das kein Problem sein…
[quote]Nein, das ist nicht korrekt Man kann beliebig viele Thumbnails in den Einstellungen definieren, die dann automatisch generiert werden. Wenn man das im Nachhinein macht, muss man allerdings mit unserem Hilfsscript die Thumbs neu erzeugen.[/quote] Okay, das werd ich noch einmal ausprobieren. Ich hatte bei einem Shop schon mehrere Thumbnails dazugefügt und dann in einem Artikel das Bild mal testweise neu hochgeladen, aber da hatt ich nur die standardmäßigen Thumbnails 1-5… Habsch bestimmt irgendwo nen Fehler eingebaut 
[quote]@Thomas Wenn der Bild-Server auch https unterstützt, sollte das kein Problem sein…[/quote] Ja wenn er das unterstüzt, dann geht das. Aber da sollte man halt drauf achten find ich…
@Avenger Dazu passend: Wir wollen zukünftig eine Anbindung an verschiedene Cloud-Dienstleister integrieren, z.B. Amazon S3. Dort kann man dann statische Ressourcen auslagern und das ggf. auch als CDN für die Template-Ressourcen verwenden.
Ohhh ne Anbindung an Amazon S3??? So ne Idee hat ich schön länger Aber das klingt richtig gut. Das könnte mir gut in ein kommendes Projekt hineinpassen
[quote=“Stefan Hamann”][quote] OXID hat eine m.E. coole Funktion: man kann einen alternativen Bildpfad definieren… [/quote] Dadurch das wir externe Ressourcen grundsätzlich über eine eigene Smarty-Funktion laden, kann man das sehr einfach umsetzen. Der Bildpfad z.B. ist global definiert, da kann man ohne Probleme auch einen externen Host angeben.[/quote] Wie würde das z.B. konkret aussehen?
<?php class Shopware_Plugins_Frontend_PathChanger_Bootstrap extends Shopware_Components_Plugin_Bootstrap
{
public function init()
{
$type = Enlight_Hook_HookHandler::TypeBefore;
$handler = new Enlight_Hook_HookHandler('sArticles', 'sGetArticlePictures', __CLASS__.'::changePath', $type);
Shopware()->Subscriber()-\>subscribeHook($handler); } static function changePath($eventArguments){ Shopware()-\>System()-\>sPathArticleImg = "http://www.test.de/images/"; } } Das z.B. unter engine/Shopware\Plugins\Local\Frontend\PathChanger ablegen - damit wird ein Hook implementiert, der vor der Funktion sGetArticlePictures aus der Klasse sArticles aufgerufen wird (TypeBefore) - dieser setzt den Image-Pfad im System Objekt neu (System ist in den älteren Frontend-Klassen das zentrale Konfigurationsobjekt)
[quote=“Stefan Hamann”]<?php class Shopware_Plugins_Frontend_PathChanger_Bootstrap extends Shopware_Components_Plugin_Bootstrap
{
public function init()
{
$type = Enlight_Hook_HookHandler::TypeBefore;
$handler = new Enlight_Hook_HookHandler('sArticles', 'sGetArticlePictures', __CLASS__.'::changePath', $type);
Shopware()->Subscriber()-\>subscribeHook($handler); } static function changePath($eventArguments){ Shopware()-\>System()-\>sPathArticleImg = "http://www.test.de/images/"; } } Das z.B. unter engine/Shopware\Plugins\Local\Frontend\PathChanger ablegen - damit wird ein Hook implementiert, der vor der Funktion sGetArticlePictures aus der Klasse sArticles aufgerufen wird (TypeBefore) - dieser setzt den Image-Pfad im System Objekt neu (System ist in den älteren Frontend-Klassen das zentrale Konfigurationsobjekt)[/quote] Irgendwann werde ich das sicher/hoffentlich auch verstehen, aber es hat schon mal den Anschein, als ob man da sehr gezielt in den Code eingreifen könnte… 
Aber das wolltet Ihr ja noch in Tutorials näher erläutern…
Zur Info - Hooks dienen der Integration von eigenem Code in beliebige, bestehende Funktionen - es gibt folgende Hook-Typen: TypeBefore Der Code wird vor der Ursprungsfunktion aufgerufen und erhält die Funktionsparameter & Referenz zum Objekt TypeAfter Der Code wird nach der Ursprungsfunktion aufgerufen und erhält Rückgabe & Funktionsparameter & Referenz zum Objekt TypeReplace Die Ursprungsfunktion wird vollständig ersetzt. Darüber hinaus gibt es noch Events, mit der man auch mit extrem wenig Code viele Frontend-Bereiche erweitern kann. Zum Beispiel: $event = new Enlight\_Event\_EventHandler( 'Enlight\_Controller\_Action\_PostDispatch', array($this, 'onPostDispatchAction'), 50 ); ... public function onPostDispatchAction(Enlight\_Event\_EventArgs $args) { $this-\>view = $args-\>getSubject()-\>View(); $this-\>view-\>TrackingCode = "1234"; // Smarty Variable zuweisen oder $this-\>view-\>extendsTemplate('frontend/plugins/meinTest/index.tpl'); } In meinTest/index.tpl {block name="frontend\_index\_header\_javascript" append}<script type="text/javascript" src="%7Blink%20file='frontend/_resources/javascript/meinejavascriptdatei.js'%7D"></script>{/block} Das ->extendsTemplate definiert eine Template-Datei, mit der man beliebige Blöcke aus beliebigen Sub-Templates modifizieren kann. In diesem Fall würde halt eine eigene JS-Datei in die Seite inkludiert… Damit wird ein Event registriert, der die lokale Methode onPostDispatchAction bei jedem Seitenaufruf ausführt - so kann man Code integrieren, der bei jedem Request ausgeführt werden soll - z.B. eine Anbindung an eTracker etc.