Suchfunktion innerhalbs des catalogs

Zu allererst möchte ich dem Entwickler und den Supportern dieser Extension danken - diese Extension ist der Hammer! Unglaublich was man alles damit erstellen kann ;)

Leider bin ich heute auf ein kleines Problem gestoßen wenn ich nach Inhalten innerhalb des Catalogs suchen will, ich kann den Fehler nur leider nicht finden. Und zwar habe ich folgende Konfiguration im Katalog erstellt:

3 Bedingungen + zig Unterbedingung in der Taxonomy Verwaltung

- Bedingung 1
-- Bedingung 1.1
-- Bedingung 1.2

- Bedingung 2
-- usw

Im Katalog habe ich dann 3 Selectboxen in denen ich diese Bedingungen auswählen kann und im Frontend werden diese als Liste ausgegeben.

Aber ich bekomme es einfach nicht hin das ich mit der Catalogsuche zu einem Ergebnis komme.
Was muss ich denn bei der Weiterleitungsseite angeben? Beim normalen Suchformular muss man ja das Modul "Suchmaschine" erstellen und einbinden - beim Catalog habe ich solch eine Funktion noch nicht gefunden. Könnte daran liegen das ich beim Suchen auch kein Ergebnis bekomme ;-)

Ich hoffe ihr könnt mir etwas auf die Sprünge helfen.. :D

PS: Wahrscheinlich eine lächerliche Frage aber nach Stunden der Suche finde ich es einfach nicht.

Die Weiterleitung sollte auf eine Seite gehen, auf der eine KatalogListe angezeigt wird.
Der Filter wird dann automatisch ausgewertet und die Liste zeigt nur die zutreffenden Eintraege an.

Danke dir für deine schnelle Hilfe. Ich werd es sofort ausprobieren! :-)

Hm irgendwas mache ich immer noch falsch. Auf der Startseite wird der Katalogfilter und die Katalogliste eingebunden. Beim Katalogfilter ist als Weiterleitungsseite die Seite "Suchergebnisse" eingestellt auf der ich das selbe Kataloglisten Modul von der Startseite eingebunden habe.

Wenn ich jetzt nach dem Suchbegriff "Farbe" suche werde ich zur Seite "suchergebnisse/search/Farbe" weitergeleitet und bekomme die Meldung "Page not found" :(

Anbei hängt ein Screenshot meiner Konfiguration in der Katalogliste...

Kann es sein, dass du folder_url installliert hast? Wenn ja, dann musst du darin noch ein paar Ausnahmen definieren. wie z.B. "search".

Weiterhin fehlt an deiner URL das .html am Ende, dies ist in den Einstellungen einzutragen bzw. die .htaccess dementsprechend anzupassen, dass mod_rewrite richtig weiterleitet.

Ok das .html habe ich eingefügt, obwohl ich es eigentlich nicht haben will ;) ich hoffe es ist später nicht zwingend erforderlich. Das mod_rewrite funktionierte bis zum jetzigen Zeitpunkt auch ohne Suffix!

Aber wie kann ich denn Ausnahmen im FolderUrl definieren? Diese Funktion habe ich ja noch nie gesehen?!

Zitat:

---

Zitat von jared

Aber wie kann ich denn Ausnahmen im FolderUrl definieren? Diese Funktion habe ich ja noch nie gesehen?!

---

Im Backend gibt es diesbezüglich in den "Einstellungen" ein (neues) Eingabefeld "URL Schlüsselworte"

Juhu es klappt!!! Man lernt wirklich nie aus. Das Feld mit dem Schlüsselwerten ist mir bisher nie aufgefallen. Danke euch Männer für den unschlagbaren Support um 1 Uhr nachts ;)



Ich würde gerne eine weitere kleine Frage hinten anhängen, wenn ich darf? Aber mehr struktureller Natur. Ich habe mir bisher alle möglichen Tutorials zu der Mehrsprachigkeit angeschaut aber wie ich es auch drehe und wende - mehrsprachige Kataloge sind meiner Meinung nach grausam in der Verwaltung sobald man mehrere Taxonomy Bedingungen + zig weitere Datenfelder hat.

Ich muss einen 25-sprachigen Katalog anlegen und ca. die Hälfte aller Datenfelder müssen dabei in die jeweilige Sprache übersetzt werden (Farben, Produktkategorien usw.)... Ist sowas mit dem Katalog überhaupt machbar?

Zitat:

---

Zitat von jared

Ich würde gerne eine weitere kleine Frage hinten anhängen, wenn ich darf? Aber mehr struktureller Natur. Ich habe mir bisher alle möglichen Tutorials zu der Mehrsprachigkeit angeschaut aber wie ich es auch drehe und wende - mehrsprachige Kataloge sind meiner Meinung nach grausam in der Verwaltung sobald man mehrere Taxonomy Bedingungen + zig weitere Datenfelder hat.

---

Was soll ich sagen, da kann ich Dir nur zustimmen. Hab selbst auch einen mehrsprachigen Katalog im Einsatz, wobei alle erforderlichen Eingabefelder - wie im betreffenden Tutorial beschrieben - dupliziert wurden. Weiters muss dazu gesagt werden, dass über diese Vorgangsweise jeweils nur die Katalog-Einträge der "Hauptsprache" im Index der "sitemap.xml" auftauchen; alle anderen werden in diesem Fall nicht berücksichtigt.

Zitat:

---

Zitat von jared

Ich muss einen 25-sprachigen Katalog anlegen und ca. die Hälfte aller Datenfelder müssen dabei in die jeweilige Sprache übersetzt werden (Farben, Produktkategorien usw.)... Ist sowas mit dem Katalog überhaupt machbar?

---

Machbar schon, aber das wird wohl sehr, sehr aufwändig werden. Viel Spaß!

Was wäre denn der geschickteste Weg um sowas zu realisieren? Die doppelte Datenpflege ist nicht mal das Problem da ich alle 1500 Einträge mit einem selbst geschriebenen Importscript in die DB übernehme, aber am Ende muss man auf der deutschen Seite nach "rot" suchen können und auf der englischen Seite nach "red"...

Derzeit stelle ich es mir so vor:

- DE | Katalog
- EN | Katalog
- usw.

Die jeweiligen Kataloge bekommen dann die Datenfelder in ihrer Sprache angelegt und zugeordnet.
Die Taxonomy Bedingungen würde ich dann so anlegen:

- DE | Bedingungen
-- Bedingung 1
--- Bedingung 1.1
-- Bedingung 2
--- usw

- EN | Bedingungen
-- usw


Und am Ende muss ich wohl oder übel 25 Katalogfilter und Kataloglisten erstellen und auf der jeweiligen Seite einbinden.



Wenn jemand eine bessere Idee hat, ich bin für jeden kleinen Tip dankbar!

Ok, dann beschreib ich mal kurz, wie ich das angegangen bin.

Für die Ausgabe der unterschiedlichen Übersetzungen verwende ich die Erweiterung "Insert-Tags / Platzhalter"; damit kann ich mir nämlich Platzhalter nach folgendem Schema anlegen, z.B. für Dein Beispiel mit der Farbe:

Platzhalter: "Farbe" -> Insert-Tag: "{{custom::Farbe}}"
Ersatz: {{iflng::de}}rot{{iflng}}{{iflng::en}}red{{iflng}} {{iflng::it}}rosso{{iflng}} usw.

Diese Insert-Tags werden dann in den jeweiligen Datensätzen des Katalogs/Taxonomy-Moduls verwendet. So hab' ich das dann für sämtliche Eingabefelder des Katalogs bzw. im Taxonomy-Modul gemacht.

Für meine Zwecke funktioniert das über diese Methode eigentlich ganz gut. Wahrscheinlich gibt es dafür ja auch eine viel bessere Vorgangsweise, aber DIE optimale Lösung habe ich in diesem Zusammenhang noch nicht wirklich gefunden...

Eine Frage hätte ich aber noch zu deiner Vorgehensweise - wo genau schreibst du den folgenden Insert-Tags Code hin?

{{iflng::de}}rot{{iflng}}{{iflng::en}}red{{iflng}} {{iflng::it}}rosso{{iflng}}

Das habe ich noch nicht ganz begriffen?!
Weil als Taxonomy Bedingung kann ich es ja so leider nicht nutzen, er zerhaut mir alle Insert-Tags.

Zitat:

---

Zitat von jared

Eine Frage hätte ich aber noch zu deiner Vorgehensweise - wo genau schreibst du den folgenden Insert-Tags Code hin?

{{iflng::de}}rot{{iflng}}{{iflng::en}}red{{iflng}} {{iflng::it}}rosso{{iflng}}

Das habe ich noch nicht ganz begriffen?!
Weil als Taxonomy Bedingung kann ich es ja so leider nicht nutzen, er zerhaut mir alle Insert-Tags.

---

In das Eingabefeld für den Insert-Tag (Erweiterung "Insert-Tags")

Aso! Und das {{custom::Farbe}} kommt dann in das Template?

Ich habs mal so versucht wie du es beschrieben hast!
Der neue Insert-tag wurde im Backend angelegt, {{custom::Farbe-rot}}, und dann mit der entsprechenden Ersetzung definiert. Das ganze habe ich erstmal für Rot, Blau und Grün gemacht.

Da das Produkt mehrere Farben haben kann, hatte ich bisher immer die Checkboxen innerhalb des Katalogs verwendet. Deswegen habe ich das Feld "Farbe" insofern geändert das die DB in der Tag-Funktion auf den neuen Datensatz "tl_inserttags" zeigt und ich dann später auswählen kann welche Farbe das Produkt bekommt.

Die Screenshots liegen bei! Leider funktioniert es noch nicht so ganz, ich hangel mich grade von Funktion zu Funktion.


PS: Danke dir für deine Geduld ;)

Sorry für meinen knappen Beitrag vorhin. War leider ziehmlich in Eile und musste kurz weg!

Ja, im Prinzip hast Du's schon richtig gemacht.

Soweit ich auf Deinen Screenshots sehen kann, wählst Du diese Platzhalter über die entsprechende Tabelle aus. Ich hab so zwar noch nie gemacht, könnte aber durchaus auch funktionieren. Da musst Du eh wahrscheinlich ein bisschen rumspielen, bis Du das gewünschte Ergebnis erhälst.

Ich selbst verwende z.B. die Platzhalter-Insert-Tags im ersten Feld "Bezeichnung" des Datensatzes und weiters dann auch noch im Taxonomy-Modul zum Festlegen der hierarchischen Bedingungen; so erspar ich mir nämlich, dass ich dieselben Bedingungen für jede einzelne Sprache getrennt anlegen muss.

Weil ich das grad seh auf Deinen Screenshots: Müsstest Du bei den Platzhalter-Insert-Tags nicht die Option "Platzhalter anwenden im -> Frontend" auswählen? Ich hatte glaub ich das ausgewählt und zusätzlich noch "Ausgabe zwischenspeichern".

So, muss mich jetzt leider wieder vertschüssen.

Das "Ausgabe zwischenspeichern" war der richtige Hinweis ;)
Jetzt klappt es zumindest im Backend und ich kann alle Farben als Inserttag anlegen, derzeit werden Sie nur noch nicht im Frontend angezeigt.

Ist das eine reine Templateproblematik?
Ich setze mich da mal dran!

Zitat:

---

Zitat von jared

Das "Ausgabe zwischenspeichern" war der richtige Hinweis ;)
Jetzt klappt es zumindest im Backend und ich kann alle Farben als Inserttag anlegen, derzeit werden Sie nur noch nicht im Frontend angezeigt.

---

Und in den Einstellungen des Insert-Tags hast Du "Platzhalter anwenden im -> Frontend" ausgewählt?

Ja genau! Siehst du auch nochmal im angehängten Screenshot.

Zitat:

---

Zitat von jared

Ja genau! Siehst du auch nochmal im angehängten Screenshot.

---

Ja, sollte eigentlich so passen. Probier mal dieses Insert-Tag {{custom::Farbe-rot}} irgendwo in einem normalen Artikel/Inhaltselement einzufügen und schau, ob Du dann im Frontend eine Ausgabe erhälst!

Auf den Gedanken war ich bereits auch schon gekommen und hatte es ausprobiert. Das klappt leider auch nicht. Der Firebug zeigt mir dann nur ein leeres <p></p> Element an.

Zitat:

---

Zitat von jared

Auf den Gedanken war ich bereits auch schon gekommen und hatte es ausprobiert. Das klappt leider auch nicht. Der Firebug zeigt mir dann nur ein leeres <p></p> Element an.

---

Ok, dann müsste man auf jeden Fall zuerst mal schauen, dass dieser "normale" Weg der Ausgabe des Insert-Tags ordentlich funktioniert, bevor Du denselben dann in weiterer Folge für den Katalog bzw. Taxonomy verwendest...

EDIT: Hab das jetzt bei mir mal in meiner lokalen Installation getestet - funktioniert soweit ohne Probleme! Hab den Custom-Insert-Tag einfach in eine CE "Text" eingefügt. Im Frontend wird mir dann die korrekte Übersetzung für die aktuelle Seiten-Sprache ausgegeben. Du könntest ev. auch noch versuchen, ob denn normale TL-Insert-Tags funktionieren und eine Ausgabe im FE erzeugen, also beispielsweise {{last_update}} oder{{date}} usw.

Soeben nochmal mit den regulären Inserttags ausprobiert. Diese funktionieren einwandfrei! Verstehe nur noch nicht ganz wieso das Custom Modul nicht funzt?! :/

Zitat:

---

Zitat von jared

Soeben nochmal mit den regulären Inserttags ausprobiert. Diese funktionieren einwandfrei! Verstehe nur noch nicht ganz wieso das Custom Modul nicht funzt?! :/

---

Caching oder so hast Du nicht aktiviert oder? Hmm, vielleicht die Erweiterung mal neu installieren/reparieren lassen...

Nein noch rein garnichts.
Hab es auch mittlerweile komplett gelöscht, neu installiert und 2 Inserttags neu erstellt. Und nach wievor wird es nicht angezeigt.

Liegt es eventuell an TL 2.8.2?

PS: Ich habe mir auf einer Testinstallation soeben Catalog2 installiert, da ich mit der vorherigen Version nicht ganz die Anforderungen abdecken konnte wie gewünscht. Um nicht 100te Kataloglisten erstellen müssen wollte ich meine Seitennavigation eigentlich durch die Taxonomy erstellen lassen - wie ich im Forum gelesen habe, geht das erst ab Catalog2. Ich habe die Hoffnung das es dort auch besser mit den Inserttags funktioniert :)

Zitat:

---

Zitat von jared

Liegt es eventuell an TL 2.8.2?

---

Glaub' ich kaum, hab das nämlich vorhin bei mir auch unter dieser Version getestet!

Zitat:

---

Zitat von jared

PS: Ich habe mir auf einer Testinstallation soeben Catalog2 installiert, da ich mit der vorherigen Version nicht ganz die Anforderungen abdecken konnte wie gewünscht. Um nicht 100te Kataloglisten erstellen müssen wollte ich meine Seitennavigation eigentlich durch die Taxonomy erstellen lassen - wie ich im Forum gelesen habe, geht das erst ab Catalog2. Ich habe die Hoffnung das es dort auch besser mit den Inserttags funktioniert :)

---

Nichtsdestotrotz sollten/müssen die Insert-Tags auch in normalen Artikeln bzw. Inhaltselementen korrekt verarbeitet werden, sonst - denke ich - wird's auch im Catalag(2) nicht ordentlich funktionieren.

Ich werde noch verrückt. Das will einfach nicht funktionieren.

Weiß noch jemand einen Rat? Bisher gabs noch nie solche Schwierigkeiten bei Modulen.

Zitat:

---

Zitat von jared

Ich werde noch verrückt. Das will einfach nicht funktionieren.

Weiß noch jemand einen Rat? Bisher gabs noch nie solche Schwierigkeiten bei Modulen.

---

Jetzt glaub ich, hab ich Deinen Fehler gesehen: Schau Dir mal Deinen Screenshot hier an - Du schreibst oben im Eingabefeld bei Platzhalter bereits den kompletten Insert-Tag rein, dort sollte aber nur "Farbe-rot" stehen!

Man wird irgendwann betriebsblind. Danke dir, jetzt klappt zumindest das schonmal ;-)


Aber hattest du nicht gesagt das der Inserttag bemerkt wenn ich dann auf der englischen Seite bin und wendet die Ersetzung an? Das passiert zurzeit leider nicht. Es wird jetzt "zum Glück" schonmal die deutsche Farbe angezeigt aber das wars dann auch schon wieder.

Auf der englischen Seite springt er nicht in die nächste Condition

{{iflng::de}}rot{{iflng}}{{iflng::en}}red{{iflng}}

Edit:

Zumindest springt er nicht im Catalogmodul in die englische Farbe. In normalen Artikeln klappt es einwandfrei!

Zitat:

---

Zitat von jared

Man wird irgendwann betriebsblind. Danke dir, jetzt klappt zumindest das schonmal ;-)


Aber hattest du nicht gesagt das der Inserttag bemerkt wenn ich dann auf der englischen Seite bin und wendet die Ersetzung an? Das passiert zurzeit leider nicht. Es wird jetzt "zum Glück" schonmal die deutsche Farbe angezeigt aber das wars dann auch schon wieder.

Auf der englischen Seite springt er nicht in die nächste Condition

{{iflng::de}}rot{{iflng}}{{iflng::en}}red{{iflng}}

Edit:

Zumindest springt er nicht im Catalogmodul in die englische Farbe. In normalen Artikeln klappt es einwandfrei!

---

Ja, bei mir klappt das. Hab aber auch meine Katalog-Frontend-Module alle in den entsprechenden Sprachen dupliziert und in weiterer Folge auch nur im betreffenden Seitenbaum eingebunden.

Das ist mir einfach zu viel Trickserei! :(

Ich werde mich diese/nächste Woche mal dranmachen und die Catalog- und Taxonomyextension um eine Option für die Mehrsprachigkeit erweitern. Im Grunde fehlt da ja nicht viel.

1. Die Taxonomyextension ist derzeit rein strukturell nur für eine Sprache ausgelegt. Da genügt es schon sie um "Sprachfelder" innerhalb der Tabelle zu erweitern.

2. Der Catalog bekommt dann bei den Datensätzen ein weiteres Feld = Mehrsprachige Felder. Über die genaue Struktur mache ich mir noch Gedanken.

3. Catalog_ext erhält in den Frontend-Modulen eine Sprachabfrage. Mal schauen wie ich das genau mache - entweder im Code versteckt oder als Auswahl innerhalb des Moduls.


Diese ganze Gefrickel macht mich sonst noch wahnsinnig. Kenne ich so einfach nicht von TYPOlight.

Zitat:

---

Zitat von jared

Ich werde mich diese/nächste Woche mal dranmachen und die Catalog- und Taxonomyextension um eine Option für die Mehrsprachigkeit erweitern. Im Grunde fehlt da ja nicht viel.

---

Dann tu dir und uns einen Gefallen und mach es bitte gleich auf der aktuellen svn Version, dann kann ich es uebernehmen und einbauen.

Zitat:

---

Zitat von jared

1. Die Taxonomyextension ist derzeit rein strukturell nur für eine Sprache ausgelegt. Da genügt es schon sie um "Sprachfelder" innerhalb der Tabelle zu erweitern.

---

Das Problem hierbei wird sein, dass jedes element eine eigene id besitzt. Du brauchst jedoch dann mehrere mit jeweils derselben id aber anderen language ids. Das richtige hierbei ist, dies ueber eine subtabelle zu loesen (parent: id in der taxonomy, child: pid aus der taxonomy, Text mit language id).
Problematisch wird es jedoch dann beim auswerten dieser Felder in anderen extensions, diese myssten ueber deine mehrsprachigkeit "unterrichtet" werden.
Beim Catalog geht dies nicht ohne weiteres, da die Taxonomie hier als select auf eine Fremdtabelle (beliebig, nicht gezwungenermassen tl_taxonomy) eingebunden wird.
Der Weg ueber die Taxonomy ist hierfuer aber meiner Meinung nach sowieso nicht notwendig, da die Sprachkuerzel ja schon bekannt sind (system/modules/backend/languages/de/languages.php ist die aktuelle Liste).
Richtiger ist es meiner Meinung nach nun, bei 2. Anzufangen.

Zitat:

---

Zitat von jared

2. Der Catalog bekommt dann bei den Datensätzen ein weiteres Feld = Mehrsprachige Felder. Über die genaue Struktur mache ich mir noch Gedanken.

---

Genau hier beginnt nun die richtige Planung.
IMO sollte man nun bei Textfeldern angeben koennen, ob dieses mehrsprachig ist bzw. wie du schon sagst, mehrsprachige Felder als custom Fieldtype implementieren (seit catalog v2 moeglich).
Diese Felder legen dann ihre Werte in einer Subtabelle ab, welche beim parseValue Aufruf fuer dieses Feld zur Ausgabe herangezogen werden. Wie genau das im Backend dann vor sich gehen soll, das weiss ich gerade auch noch nicht. ggf. wird es auf einen neuen Widget Typ hinauslaufen oder aehnliches.

Zitat:

---

Zitat von jared

3. Catalog_ext erhält in den Frontend-Modulen eine Sprachabfrage. Mal schauen wie ich das genau mache - entweder im Code versteckt oder als Auswahl innerhalb des Moduls.

---

Das sollte man beim Modul selbst nicht einstellen. Richtiger ist es, wenn du, wie oben fuer das ParseValue schon angerissen, bei einer Frontendausgabe (TL_MODE FE) nachsiehst welcher Sprachcode gerade in $objPage gesetzt ist. Damit hast du automatisch bereits die Ausgabe in der Sprache, welche auch fuer den Rest der Seite gilt.
Interessant wird es jedoch, wenn du keinen Eintrag in dieser Sprache auf Lager hast, was nimmst du als Sprachfallback?

Zitat:

---

Zitat von jared

Diese ganze Gefrickel macht mich sonst noch wahnsinnig. Kenne ich so einfach nicht von TYPOlight.

---

Nunja, der Katalog ist auch eine der maechtigsten Extensions fyr TYPOlight, welche obendrein hauptsaechlich auf Kundenwunsch weiterentwickelt wird, oder aber "wenn ich mal eben Zeit habe" (so gehen wir Catalogentwickler alle vor, da es nicht anders praktikabel ist).
Der Code ist recht gut strukturiert und es steht jedem frei patches einzureichen.
Dennoch benoetigt jeder eine vollkommen eigene Ausgabe und Behandlung der items, weshalb man an einigen Stellen eben trickst um zum gewynschten Ergebnis zu kommen.

Es steht dir jedoch jederzeit frei, die Entwicklung zu sponsoren oder aber selbst Hand anzulegen. :)

Gruss
Chris

Wie ich sehe bedarf es da noch einer etwas längeren Planung. Leider habe ich nicht soviel Zeit für das Projekt, mal schauen wieviel ich alles schaffe.

Ein kleines Problem habe ich aber leider damit wenn ich diese Änderungen auf Basis der aktuellen SVN Version (Catalog2) erstellen soll. Ich habe heute den halben Tag damit zugebracht meine Anforderungen mit der Catalog2 zu realisieren aber auch damit kläglich gescheitert.

Deswegen wollte ich die stabile Version als Basis nehmen. Da ist das Backend wenigestens komplett in Deutsch ;) ich beherrsche zwar die englische Sprache aber die Muttersprache ist doch immer besser!

Die deutsche Sprache ist leider noch nicht vorhanden (sogar die englische ist noch nicht komplett).
Jedoch kannst du aus der aktuellen stabilen Version das Sprachverzeichnis in die Version 2 uebernehmen, dann sind immerhin schon mal 70% in deutsch. :)

Aber generell koennte man mal einen Aufruf machen, den Katalog zu uebersetzen.

Ich werds mir morgen anschauen ;) und melde mich sobald ich mit der Entwicklung anfange.