Frage bzgl. Media Management und Verlinkung auf ein Produkt

[mb5]

Hallo allerseits,

ich war in letzter Zeit auf der Suche nach einer vernünftigen Shoplösung, wobei ich diese am liebsten in Contao integriert hätte. Nachdem ich die für Contao existierenden Lösungen nicht 100% praktikabel fand, bin ich bei isotope sehr hoffnungsfroh, auch wenn sich der Shop sicherlich noch mitten in der Entwicklung befindet. Aber soweit: Chapeau! Das wird vermutlich ein großer Wurf werden.

Nun sind mir bei den ersten Versuchen zwei Fragen gekommen, die ich nicht über das Forum/Handbuch klären konnte. Falls ich etwas überlesen habe, reicht jeweils der entsprechende Link bzw. Hinweis!


1. Wenn ich aus dem CMS heraus gerne auf ein Produkt verlinken würde, wie ich es z.B. auf einen Artikel tue, ohne die sich evtl. über den Zeitablauf auch noch mal änderende URL zu verwenden: Gibt es da eine Möglichkeit oder ist da etwas in Planung?

2. Für das CMS habe ich für die angebotenen Produkt bereits Bilderordner erstellt, die dann im redaktionellen Bereich verwendet werden. Die separate Bilderverwaltung ist in meinen Augen sinnvoll, würde sich dann für mich jedoch doppeln.
Ich kann ja meines Wissens nur auf den Ordner tl_files inkl. Unterordner zugreifen, um Bilder für redaktionelle Teile per Auswahl zu verwenden. Wäre eine Auslagerung dorthin möglich? Oder kann ich die Bilder aus der Isotope-Bilderverwaltung auch in Contao verwenden, um eine Doppelung zu verhindern?


Beste Grüße und vielen Dank für Antwort!

[andreas.schempp]

Hallo mb5,

1: das ist leider noch nicht möglich und auch nicht ganz einfach. Damit das gehen würde, müsste das System ja wissen auf welcher Seite sich dein Reader befindet. Dann müsstest du wie beim News-Archiv eine Seite wählen, aber wir haben ja keine Archive weil ein Produkt auf mehrereen Seiten erscheinen kann...

2: die Bilder sind ausserhalb der Dateiverwaltung, weil sonst bei vielen Produkten die Dateiverwaltung schnell überlastet wäre. Leider lassen sich diese aktuell nicht von aussen einbinden. Wenn du ne Lösung hättest, kann ich mir das aber gerne ansehen.

[soletan]

Hallo Andreas,


ich erlaube mir mal diesen Thread aus aktuellem Anlass wieder aufzugreifen. Auch mein Kunde fragt, wie er komfortabel auf ein Produkt verlinken kann, bspw. wenn er es in der Ankündigung einer Veranstaltung zum Produkt bewerben möchte. Deine Einwände sind aus technischer Sicht berechtigt, aber IMHO kein Hindernis. Dass man einen Reader wählen müsste, kann man ja aus dem Konjunktiv in den Imperativ transferieren ...

{{product_link::<reader-page-id>::<product-alias>}}

Damit ist einem Content Manager eher geholfen als mit der Aussage, dass das gar nicht ginge oder man URLs von Hand kopieren müsse. Und es laufen ja nicht nur Software-Entwickler durch die Welt.

[andreas.schempp]

Wo siehst du den Unterschied zwischen manuellen Links und deinem Beispiel? In beiden Fällen muss die Seite definiert werden, wodurch ein Link eigentlich nicht mehr dynamisch ist?

[soletan]

Ich sehe das zum einen vermutlich weniger technisch, sondern mehr aus Sicht eines eben technisch unbedarfteren Nutzers wie im Falle mehrerer meiner Kunden. URLs können durchaus eine gewisse Länge erreichen und damit auch fehleranfälliger werden.

{{product::details::mygadget}}

ist strukturell leichter als

http://meinesite.de/details/product/mygadget.html

Ehrlich gesagt wäre die mir optimal erscheinende Lösung eine Auswahlbox wie bei der Verlinkung der Seiten & Dateien, weil man von Nutzern nicht immer erwarten sollte, URLs und dergleichen eintippen zu müssen.

Und dynamischer sind die Inserttags eben dadurch, dass man keine fertige URL eingibt, sondern nur die Entität anhand ihrer Parameter innerhalb des Datenmodells des CMS wählt. Nutzt man den Inserttag, schadet es nicht, wenn man das URL-Rewriting umstellt oder bspw. Übersetzungen ergänzt und deren Auswahl Teil der URL werden lässt oder aber mit Microsites und alternativem Hostname oder HTTPS herumspielt oder oder (natürlich müssten diese Fälle ebenso für die Inserttags dann durch dritte Extensions nachgeliefert werden, doch wozu hat (hätte?) man eine saubere API, die man praktisch überladen kann). Die URL könnte ja auch wie folgt lauten:

http://meinesite.de/index.php?details/product/mygadget.html

oder es wäre der obige Fall und man müsste bspw. aufgrund von Fehlern im Zusammenspiel aus Core und einer Extension vorübergehend das Rewriting abschalten.

[andreas.schempp]

Die URL wäre sicherlich relativ (ohne http), oder?

[soletan]

Sicher kann man auch mit relativen URLs arbeiten, der BASE-Tag im Header tut sein übriges. Unter'm Strich bleiben aber stets unlösbare Probleme. Würde man aber von Anfang an die Nutzung eines InsertTags motivieren, würde man Nutzern wie Erweiterungsentwicklern das Leben leichter machen. Allein der Umstand, dass ich nicht erst einen Hook bauen muss, der in der Seitenausgabe diese erneut komplett parst und vorhandene URLs umschreibt, falls das - warum auch immer - nötig werden sollte, könnte mit Blick auf den Ressourcen-Bedarf attraktiv sein.

URLs sind öffentliche Addressierungen auf das interne Datenmodell. Innerhalb des Datenmodells auf URLs zu setzen ist wie über den Fußweg vom Wohnzimmer in die Küche zu kommen.

Dass man mit dem Status Quo klarkommen kann, bestreite ich auch nicht. Mir geht es nur um Verbesserung und eine einfachere Handhabe. Wohl muss ich meinem jetzigen Kunden die URLs erklären ...

[andreas.schempp]

Ich meinte, dass auch der InsertTag die relativen URLs generieren müsste
Der Rechenaufwand, ob das im Core oder als Erweiterung generiert wird, bleibt der gleiche. Ich bin mir nur nicht sicher wie/ob der InsertTag so sinnvoll ist. Besser wäre doch, das System würde automatisch erkennen wo der Reader liegt?

Wie wäre es denn, wenn pro Seite in der Seitenstruktur eine (eventuelle) Reader-Zielseite definiert (und vererbt) werden könnte? Dann wüsste Isotope auf jeder Seite immer, wo sich der Reader befindet. Damit liessen sich dann auch die Produkte in eine XML und die Suchmaschine aufnehmen. Oder nutzt jemand mehrere Listen mit verschiedenen Reader-Zielseiten auf einer Seite?

[soweit_ok]

Wie wäre es denn, wenn pro Seite in der Seitenstruktur eine (eventuelle) Reader-Zielseite definiert (und vererbt) werden könnte? Dann wüsste Isotope auf jeder Seite immer, wo sich der Reader befindet. Damit liessen sich dann auch die Produkte in eine XML und die Suchmaschine aufnehmen. Oder nutzt jemand mehrere Listen mit verschiedenen Reader-Zielseiten auf einer Seite?

Hab den Thread sehr interessiert mitgelesen. Ja, das wäre ganz hervorragend und trifft es auch aus meiner Sicht auf den Punkt. Nicht nur, weil ich es ebenfalls sehr praktisch fände, so an beliebigen Stellen einen Produktlink zu platzieren.

Mein Anliegen war, von der die Readerseite jeweils aufrufenden Kategorie ein individuelles Design mitgeben zu können. Wegen relativ vieler Kategorien eben ohne dafür ein extra Layout mit eigenem Reader-Template zu benötigen.

Zwar konnte ich das mit nur wenigen Zeilen im Template einbauen, doch es ist ein wenig "vom Knie durch die Brust ins Auge geschossen". Und nicht perfekt, aber immerhin kann ich so nun beliebig viele unveröffentlicht in der aufrufenden Kategorieseite hinterlegte Inhaltselemente an definierten Positionen vor und hinter der Produktdetaildarstellung anzeigen.

Tja, wenn Du die von Dir genannte Lösung tatsächlich mal implementieren solltest - ich vermute, viele Isotope-Benutzer würden sich sehr darüber freuen.