MultiShop im XTC

Hat jemand von euch schonmal über den Ansatz nachgedacht, den XTCommerce MultiShop fähig zu machen (ohne eine WaWi im Hintergrund, sondern direkt über den Shop).

Ich denke einige von euch kennen sicherlich das problem, der XTC entspricht nur noch zu 50% einem wirklichen XTC und der Rest wurde im Laufe der Jahre immer mehr und mehr auf den eigenen Leib geschneidet und passt so eigentlich sehr gut. Nun will man aber einen zweiten Shop auf machen und kann nicht wirklich mal schnell auf einen anderen Shop migrireren, ohne sehr viel Geld oder Zeit in die Hand zu nehmen. Aus diesem Grund überlege ich mir schon seit längen, ob man den XTC nicht "einfach" Multihop fähig machen kann. Eigentlich müsste man ja nur eine Mandantentrennung erreichen!

Gibt es hierzu vielleicht schon fertige "Module" oder hat sich jemand von euch schon einmal an dieses Thema heran getraut?

Ich habe es mir einmal in der Schnelle überlegt und mir sind nur wenige Tabellen aufgefallen, welche in hierbei berücksichtigt werden müssten! (customers (nur die Haupttabelle), orders (ebenfalls nur die Haupttabelle)) Dies war es schon fast! Natürlich müssten noch 2 oder 3 PHP-Dateien angepasst werden.

HHG Multistore kennst Du aber schon, oder? Das Rad muss nicht neu erfunden werden .....

BTW.: machst Du gerade Beitrags Olympiade?

Egal ob es so einfach geht oder nicht. Was ich ganz stark bezweifle. Dann sieht der eine genau so aus wie der andere.
Die Stuktur wäre gleich, die gleiche Navigation, die gleichen Produkte inklusive Beschreibung. Wenn das nicht gleich sein soll, dann fängt nämlich die Arbeit erst an. Entweder mit Erweiterung bestehender Tabellen oder einer Duplizierung jener welcher innerhalb der Datenbank. Du kannst davon ausgehen, dass mindestens 50 Tabellen davon betroffen sein werden.

Mit einem 2ten eigenständigen Shop hättest Du die Möglichkeit andere Technologien zu verwenden, auch hinsichtlich der Suchmaschinenoptimierung, des Templates ohne sich zu verheddern.

Einige Punkte würde ich anpassen
- beide zu syncronisieren, dass die Bestellnummern sich gegenseitig abgleichen, also fortlaufend sind.
- Lagerhaltung in die WaWI auslagern
- und in der WAWI Produkte nach Shopzugehörigkeit unterscheiden bzw. hochladen zu können

Dann seid Ihr alle ein Fall für den JTL Shop 2 - 3 .... ist in dieser Sache das derzeit einfachste System.

Das Thema ist ja, dass ich keine Chance habe den Shop zu wecheln, sondern bei dem Shop so bleiben muss! Also bei mir würden die Orders und Customers ausreichen. In beide käm ein MandantenFlag und fertig, denn die Bestellnummer kann ja ruhig auf beiden Seiten vorlaufen vergeben werden z.B. Shop1 Bestellnr. 10000, Shop1 Bestellnr 10001, Shop2 Bestellnr 10002, Shop1 Bestellnr 10003, ... hierdruch können alle anderen Tabellen identisch bleiben.
Das einzige ist, wie du schon sagtest, dass die Artikelstruktur identisch wäre .... Hier müsste man sich die Frage stellen, ob man bei den Artikeln auch noch einen Mandanten aufbaut, dann müsste dies aber auch gehen! Aber dies wäre dann tatsächlich doch etwas aufwendiger!

tja dann mal happy hippo, viel Spass bei der Umsetzung

Zitat:

---

Zitat von Sumsebum

tja dann mal happy hippo, viel Spass bei der Umsetzung

---

Ja oder sehe ich das falsch, denn den Primery-Key's kann man ja behalten, man muss "nur" durch den Mandaten festhalten, dass die Mailadresse theoretisch in beiden (bzw. X) Mandanten einmal vorkommen kann! Des Weiteren sollte durch den Primery-Key eine saubere Trennung garantiert sein, oder habe ich etwas übersehen, bzw. vergessen? (Abgesehen von den Artikeln)

Primary Key kannst du dann löschen, und einen index daraus machen, oder einen unique über mehrere Spalten legen. Zusätzlich musst Du vielen Tabellen durch einen Wert (Spalte) sagen, welches nun genommen wird oder die Tabellen parallel anlegen, beispielsweise mit einem Suffix/Präfix versehen.
Unterschiedliche Navigation bedeutet auch unterschiedliche Werte in den tabellen
categories
productc_to_categories
Das zieht die Veränderungen an mindestens
products, products_attributes, products_description, categories_description , specials(wenn verwendet) nach sich

Weiterhin musst du dutzenden Dateien erklären, welche Daten rel***nt sind. Welcher Shop das ist ließe sich per _SERVER Variable leicht feststellen, aber dann in fast jedes SQL Statement händisch mit eingreifen. Schau in die includes hinein, wieviel Arbeit ist das. Ganz zu schweigen von dem Ausfall zwischendurch, weil einiges nichts funktioniert. Wenn Du der mit der Punkt/Link Geschichte bist, was ich vermute, würde das schon ein KO Kriterium sein.

Dann geht die Geschichte mit dem Admin Backend los. Wenn unterschiedliche Navigation, dann viel viel Arbeit. Ok man könnte den kompletten admin Ordner parallel ziehen und die Abfragen darin anpassen.

Ich rate Dir, nimm einen neuen Shop. Da kannst Du Dinge anders und besser umsetzen. Mehr auf Optimierung achten, viele nicht verwendete Abfragen im Code "löschen/einkommmentieren", SQL Abfragen und Tabellen optimieren, den Beschreibungstext mit diversen div Containern im Quelltext direkt hinter dem <bod> tag, URL Adresse dem Keyword anpassen und nicht der Ordnerstruktur etc. Wir haben damit sehr gute Ergebnisse gemacht.

jay-ar

hm...
man könntes aber auch rein theoretisch so machen, dass der komplette XTC auf der neuen Domin aufgesetzt wird und die Reine Bestellung später per CRON-Job in den anderen Shop übertragen wird. Somit hätte man in einem Adminbereich alle Bestellungen und müsste nur die Statis zum anderen Shop transportieren.

Wegen des Wechsel müsste man die Kosten einfach gegenrechnen, was die Neuentwicklung im neuen Shop kosten würde und was die Umprogrammierung des XTC kosten würde.

Kann nur HHG Multishop oder ist OXID inzwischen auch in diesen Bereich vorgedrungen?

@freelancer
Noch was, wenn Du sagst, dass Du keine Chance hast den Shop zu wechseln. Dann ist das schon krass ausgedrückt der Anfang von Ende. Du schiebts es ja nur vor Dir her, besser wird es eh nicht. Dann ist aber die Konkurrenz schon wieder ein Stück mehr an Dir vorbei, womöglich schwinden dann noch die Umsätze. In solchen Situationen kommt es häufig zu Hau/Ruck Aktionen mit unerwarteten Ausgang.

schönes WE
jay-ar

Den Einzigen Vorteil eines Mutlishops sehe ich nur darin, dass Du deinen Zwischenhändlern, welche nah am Kunden sind, eine einheitliche und mit Produkten die du verwaltest Plattform lieferst. Alles andere macht keinen Sinn, da es zuviel Umbauarbeiten sind und ggf. Kompromisse dabei bedeutet.

jay-ar

Naja man kann es auch so ausdrücken, dass man eigentlich nicht wechseln will :-p. Wechseln kann man immer, es geht halt nur nicht mit einem 0815 Merge der Daten. Es müssen natürlich interne prozesse, ... übernommen werden, welche den Ablauf einfacher machen, ...
OK, Multishop war an dieser Stelle vielleicht falsch ausgedrückt. Es geht eigentlich mehr um Partnershops, welche Kunden finden, Kunde bestelle, Partnershop bekommt Provision und wir machen den Rest! Also weniger ein Multishop, als mehr eine Plattform!

Wenn du nur eine Lösung für den Verkauf schaffen willst, musst du keinen Multishop aufbauen! Du kannst das ganze ja auch so gestalten, dass die Bestellungen gesondert erst abgelegt werden und du diese Bestellunge alle 15 Minuten oder jede Stunde über eine CSV oder XML-Datei in den Shop lädst. So bekommt der Kunde zwar etwas später erst seine Bestellbestätigung, aber das sollte dem Kunden egal sein!

Das mit der Plattform ist eine gute Idee. Somit wäre man auch definitiv offen, wenn man das Backend, oder den ganze Shop mal tauschen würde! Die Plattform wäre dann nicht gebunden und könnte sogar komplett anders gestaltet werden als der Shop!
Danke für den Tipp!

Zitat:

---

Zitat von Freelancer

... OXID inzwischen auch in diesen Bereich vorgedrungen? ...

---

Ein physischer Shop, mehrere Themes, unterschiedliche Domains kann der OXID ... paar Zeilen Code ... und es läuft ....