[gelöst] Produktpflege über Commerce oder page-Node?

Mach es hiermit http://www.commerceguys.com/resources/articles/276
http://drupal.org/project/commerce_product_display_manager

oder mit rules siehe den link da im artikel

Super. Ich schaue mir das Modul mal ganz in Ruhe an. Ich hatte das schon auf meiner Liste, wusste aber nicht das es zu meinem Problem passen könnte.
Danke für den Hinweis!

Komisch, dass das überhaupt so ein Problem ist, da doch alles was man braucht bereits da sein sollte?
Eine One-Many-Relation Produktview/Produktdetail ist zumindest theoretisch sogar weniger komplex als die existierende Many-Many-Relation Textnode/Taxonomy.
Letzeres ist sogar noch komplexer und dennoch einfach auch für Laien zu bedienen.

Wie wäre es statt Commerce Ubercart zu nutzen. Da kannst du hinterher Nodes zu Produkten machen! Außerdem beherrscht der immerhin einen Steuersatz. und man muss nicht wie du so schön sagst Produkte an zwei Stellen aufbauen. Finde ich ziemlich schlecht und upraktikabel: nicht nur für den Kunden, auch für mich....

Sehr gute Frage!

Ich war mal wieder sehr ehrgeizig und wollte gleich das Neueste: Commerce. Das Konzept ist ja toll. Aber Commerce ist noch so in den Kinderschuhen, auch was Übersetzungen und Module betrifft, dass die Frage zu Recht heisst, warum nicht das bewährte "Ubercart".

Den Weg werde ich nun wohl gehen - in der Hoffnung, dass es später mal gute Konvertierungsmöglichkeiten gibt, wenn Commerce ein bisschen mehr Marktreife hat.

Danke jedenfalls für die Meinungen zum Thema.

ubercart ist der Vorlaeufer - es gibt wichtige Gruende, warum der Programmierer nocheinmal neu ansetzt.

Das hat er dann wohl. Die Idee mit Produkt und Produktview ist ja auch gut, wenn auch nicht neu.
Nur baut die übrige Welt da draußen die Dateneingabe genau andersherum auf, aus gutem Grund.

Ich glaube das wird sich alles verbessern aber momentan muss man noch etwas warten, meine ich.
Ich finde Commerce aber äußerst vielversprechend und freue mich schon darauf es einsetzen
zu können.

Mit dem Display_Manager kann in einer Maske das hinterlegte Produkt und das Display bearbeitet werden.

Das wichtige an dieser Trennung ist, dass damit Produktvariationen und deren Lagerhaltung, und auch mehrsprachige Displays problemlos machbar werden.

Für einen Shop, der einsprachig ist, und keine Produktvariationen (Größen, Farben etc.) kennt, mag das kompliziert aussehen.

Mit dem Displaymanager ist es aber einfach zu handhaben.

Die Trennung ist mir klar. (Ich habe schon größere Shops gebaut (4D und Filemaker... ist aber lange her) und da mussten wir das auch so lösen: Eine Tabelle für die generellen Angaben (Produktdisplay)- mit einer eine-zu-viele-Verbindung zu den Attributen ("Produkt"), wobei die Attribute letztendlich das Lager steuern.

Meine Baustelle ist nicht das Modell, sondern die Benutzerfreundlichkeit.
Wenn man einen Shop z.B. für Kosmetik macht, darf man nicht so hohe Ansprüche an die Computerfähigkeiten der Betreiber stellen. :-) Ein Produkt an 2 Stellen verwalten: Keine Chance.

Es geht bei der unglücklich gewählten Bezeichnung los:
Man würde annehmen (aus Sicht des Shopbetreibers), das Produkt ist das unveränderliche und das Display das veränderliche.
Genau umgekehrt ist es, Bsp. Kosmetik: Die Beschreibung der Inhaltsstoffe bleibt (Display); die Preise, Größen und Looks ändern sich ständig (Produkt). Herkömmliche Shops haben daher aus gutem Grund andere Bezeichnungen, auch wenn das dahinter liegende Datenbankmodell (das Attribut steuert das Lager) vermutlich das gleiche ist.

Ich hatte den Displaymanager tatsächlich installiert und getestet (Anfang Februar). Er kam mir nach dem richtigen Weg vor. Aber ich erinnere, dass der zum damaligen Zeitpunkt viel zu wenig konnte.

Was erwarte ich von einem Shop:

Bearbeiten vom "Produktdisplay" aus:
Ich pflege ein Produkt ein. Wie beim Displaymanager sehe ich in der Eingabmaske eine Liste von Eigenschaften, die abweichend vom alltemeinen sind: Preise, etc. Mit Bildminiatur. Man kann aktivieren, deaktivieren. Diese Werte stammen aus einer Relation.

Mindestens ein Listeneintrag muss hinterlegt sein. In der Liste selbst kann ich Texte direkt verändern (Preise, etc) und für die Bilder muss ich auf die Liste klicken und kann in gelange in eine Maske ("Produkt") wo ich die Attributdinge ("Produkte" alle noch einmal sehe und hier auch Bilder ändern kann.

Wenn ich in dieser anderen Maske bin muss erinnert werden, dass das "Display" noch nicht gesichert ist.

Ich kann im "Display" in der "Produkt"-Liste sortieren und hier auch, bis auf eins, löschen. (Kann der Displaymanager das?)
"Löschen" heißt Löschen und nicht nur Relation aufheben.
Löscht man das umklammernde "Display", werden alle verbundenen "Produkte" mitgelöscht.

Beim Löschwunsch eines "Produkts" ist viel zu beachten, da ja vieles am "Produkt" dranhängen kann, wie Lager, Faktura....)
Da Löschen nicht immer geht, kann man sowohl das Display also auch enthaltene Produkte zumindest deaktivieren.

Bearbeiten vom "Produkt" aus:
Ich bearbeite alle individuellen Eigenschaften: In der gleichen Maske kann ich ein Display zuordnen oder anlegen. Ein "Display" braucht man, sonst kann man nicht speichern. Ist es angelegt, sieht man dessen Felder eingeblendet und man kann auch die Werte eintragen und ändern. Alles direkt vom Produkt aus.

Wenn der Displaymanager jetzt soweit ist, schaue ich mir Commerce gern wieder an. Ansonsten warte ich ab, die Einsicht, dass Nachbesserung sein muss, wird sich noch breiter durchsetzen, da bin ich sicher. Die momentane Lösung "Produkt" vs. "Display" kommt mir ein wenig praxisfremd vor und ich habe keine Lust auf das Gejammere meiner Kunden, dass sie nicht klar kommen.

Ubercard als Zwischenlösung?

Mein Kunde braucht vermutlich für die Einpflege der Produkte 1/2 Jahr. Mindestens, Solange habe ich dann Zeit, das Drumherum gemütlich aufzubauen und bis dann wird Commerce auch viel reifer sein und die wichtigsten Module vielleicht nicht mehr "beta". Das war mein Plan.

Nun ist ausgerechnet der Bereich Dateneingabe so eine Problemzone.
Ich kann für den Kunden natürlich schnell was mit Filemaker bauen und das Endergebnis anschließend importieren. Der Massenimport geht ja schon super in Commerce. Aber das ist höllische Arbeit mit Filemaker und ich würde das gern ersparen.

So war meine faule Idee: Erst mal Übercard nehmen: Damit dem Kunden die Produkte einpflegen lassen - und darauf hoffen, dass Commerce in 1/2 Jahr in der Lage ist, Ubercard-Shops zu übernehmen. - Denkfehler?

Wenn das Erfassungsprogramm eine CSV-Datei erzeugen kann, kann man die Erfassung der Artikel natürlich auch außerhalb realisieren.

Mit Feeds und den commerce Erweiterungen, evtl. feeds_tamper ist nahezu jeder import möglich.

Auf gleiche Weise ist eine Migration aus einem anderen Shopsystem denkbar.

Für Übercart gibt es ein Migrationstool, das sich die Daten direkt aus der Datenbank holt.

Hi, danke für die Anmerkung. Wie meine, geschrieben zu haben: der Massen-Import per CSV ist nicht mein Problem (ich kenne den Weg). Ich will aber vermeiden, Daten extern erzeugen zu müssen. Wir haben 2012. Das sollte schon mit D7 gemacht werden. :-)

Ein neuer, umfangreicher Katalog ist aufzubauen (und nicht von irgendwo her fertig zu übernehmen). Den Katalog erstmal extern aufbauen zu müssen, wäre eine Notlösung und kein Ruhmesblatt für Commerce. Dann lieber gleich Magento. Dieser Katalog besteht aus Hunderten von Artikeln. Es kommen sogar während des halbjährigen Aufbaus noch ständig Änderungen im Sortiment. Dafür kommen Werkzeuge für einmalige Aktionen wie Display Manager(?) und Import per Feed m.E. nicht infrage.

Auf keinen Fall setze ich auf eine Lösung, die vielleicht nett ausgedacht ist, aber in der Praxis vielleicht scheitert, weil die Leutz sich nicht trauen, Daten einzugeben. Leider keine ich keine Stelle im Web, wo über Commere wirklich mit den Machern in der Tiefe diskutiert wird, was das UI betrifft. Immer wenn es zu der Split-Problematik kommt, hört man ein "das ist ja das Geniale". Man redet aneinander vorbei: das Konzept mag toll sein, die Komplexität muss aber hinter einem einfachen Inferface versteckt werden, sonst kommt das nicht bei Shopleuten an.

commerceguys.com

..nein, nicht wirklich. - Oder hast Du mit denen schon erfolgreich über UI-Fragen diskutiert? ;-)

Aber immerhin schreibt Ryan aktuell von einem Release-Date für Kickstart2 von August 2012.
Auch denen ist wohl klar, das Commerce noch nicht beim verwönhnten "Alles einfach"-User
angekommen ist.