News 
- mod_menu goes PHP 7.3 (07.01.2019)
- Das Menü-Modul wurde für PHP 7.3 fit gemacht
- mod_track - File Injection Detection (03.01.2019)
- mod_track jetzt für PHP 7.2 mit Update-Link im Mail
- Wie man ein Modul updatet (18.12.2018)
- Einfach nur Dateien hochladen ist meist zu wenig
- mod_maintenance (21.03.2015)
- Neue Version 4.1 mit direkter Erstellung einer Wartungsseite
- mod_gallery wird 10 Jahre alt (23.01.2014)
- Daher gibt es eine neue Version 4.3b
- mod_database 4.1b (18.01.2014)
- aktualisiert auf Adminer 4.0.2
- mod_newsletter 4.3e (03.01.2014)
- eine komplett überarbeitete und durchgetestete Version. Ein Update wird dringend empfohlen!
- mod_backup 4.1a (22.10.2013)
- Set it and forget it - Der Retter im Hintergrund.
- Kennzeichnungspflicht (22.10.2013)
- Die früher erforderliche Kennzeichnung mit dem ratsnappers-Logo per eingebundenem Code entfällt.
- mod_gallery 4.3a (20.09.2013)
- Bei Einsatz unter CPO 4.1.6 können bei bestimmten Arbeitsabfolgen Probleme mit der Bildumrechnung auftreten. Dieses Upgrade von 4.3 auf 4.3a löst diese Probleme
feature_search
professionelle Filter
Diese Idee stammt aus dem Februar 2006
Das im Hinterkopf habe ich einen Auftrag mit entsprechender Anforderung angenommen und das Modul inzwischen mehrfach sehr erfolgreich eingesetzt.
Dabei dient das Modul "Suche" als Grundlage (zumindest in der von mir vorgelegten Version, die seit Januar von balu weiterentwickelt wird).
Der Unterschied zum Modul Suche eine Original-ConPresso-Installation ist, daß nicht alle Felder durchsucht werden, sondern nur bestimmte.
Wenn also die Artikeldaten konsequent in verschiedene Eingabefelder verteilt werden, dann kann auch konsequent gezielt gesucht werden.
Der eigentliche Witz ist, daß die gesamte Definition über den HTML-Code des Formulares vorgenommen wird, also welche Felder durchsucht werden, wie sie durchsucht werden und dies beliebig erweiterbar ist. Durch Select-Felder kann sogar eine Auswahl von Feldern angeboten werden oder auch eine Reihe vorgefertigter Suchen angeboten werden.
Das ganze ist schwer zu beschreiben, wird aber sicher von allen, denen die Volltextsuche zu ungenau ist, schnell eingesetzt werden. Im Grunde ist es das Pendent zum neuen Platzhaltersystem, nur eben als Suchfunktion.
| Zitat: |
| Bisher fiel mir irgendwie noch kein anderer Name dafür ein, aber es wird ein rein kommerzielles Modul, das es erlauben wird, in bestimmten Feldern nach bestimmten Inhalten zu suchen. Dies wird durch die Möglichkeit beliebige Platzhalter zu definieren ermöglicht. Beispiel: Immobilienmarkler - Suche nach Immobilien mit Preis von/bis - Suche nach Quadratmeter- oder Zimmerzahl - Suche nach bestimmten Typen |
Das im Hinterkopf habe ich einen Auftrag mit entsprechender Anforderung angenommen und das Modul inzwischen mehrfach sehr erfolgreich eingesetzt.
Dabei dient das Modul "Suche" als Grundlage (zumindest in der von mir vorgelegten Version, die seit Januar von balu weiterentwickelt wird).
Der Unterschied zum Modul Suche eine Original-ConPresso-Installation ist, daß nicht alle Felder durchsucht werden, sondern nur bestimmte.
Wenn also die Artikeldaten konsequent in verschiedene Eingabefelder verteilt werden, dann kann auch konsequent gezielt gesucht werden.
Der eigentliche Witz ist, daß die gesamte Definition über den HTML-Code des Formulares vorgenommen wird, also welche Felder durchsucht werden, wie sie durchsucht werden und dies beliebig erweiterbar ist. Durch Select-Felder kann sogar eine Auswahl von Feldern angeboten werden oder auch eine Reihe vorgefertigter Suchen angeboten werden.
| Code: |
| <form name="suchergebnisse" class="result" method="get" action="index.php" style="display: inline;"> <input type="hidden" name="action" value="feature_search" /> <input type="hidden" name="rubric" value="### SEARCH_NAV ###" /> <input type="hidden" name="results" value="AND" /> <table border="0"> <tr> <td><label for="p1">PLZ</label></td> <td> <input type="text" name="p1" id="p1" value="### SEARCH_PHRASE_1 ###" /> <input type="hidden" name="sf1" value="PLZ" /> <input type="hidden" name="sm1" value="b" /> </td> </tr> <tr> <td><label for="p2">Nachname</label></td> <td> <input type="text" name="p2" id="p2" value="### SEARCH_PHRASE_2 ###" /> <input type="hidden" name="sf2" value="Nachname" /> <input type="hidden" name="sm2" value="b" /> </td> </tr> <tr> <td><label for="p3">Ort</label></td> <td> <input type="text" name="p3" id="p3" value="### SEARCH_PHRASE_3 ###" /> <input type="hidden" name="sf3" value="Ort" /> <input type="hidden" name="sm3" value="b" /> </td> </tr> <tr> <td><label for="sp4">Rasse</label></td> <td> <select name="sp4" id="sp4"> <option value=''>-- Bitte wählen --</option> <option value='Airedale Terrier'>Airedale Terrier</option> <option value='Australian Terrier'>Australian Terrier</option> <option value='Australian Silky Terrier'>Australian Silky Terrier</option> <option value='Bedlington Terrier'>Bedlington Terrier</option> <option value='Border Terrier'>Border Terrier</option> etc... |
Das ganze ist schwer zu beschreiben, wird aber sicher von allen, denen die Volltextsuche zu ungenau ist, schnell eingesetzt werden. Im Grunde ist es das Pendent zum neuen Platzhaltersystem, nur eben als Suchfunktion.
Das Formular
Hier jetzt mal eine kleine Anleitung:
Das wichtigste für das ganze Modul ist das Formular, über das fast alles gesteuert wird.
Fangen wir mal vorne an:
Hierbei ist folgendes wichtig bzw. einstellbar:
- method="get" muss eingestellt sein, weil dadurch Suchen als Link vordefiniert werden können
- Das hidden-Field action muß den Wert feature_search haben
- In das Hidden-Field rubric trägt das Modul automatisch die per URL übergebene Rubrik ein, wenn dort ### SEARCH_NAV ### eingetragen ist. Das ist wichtig für die richtige Anzeige der Navigation
- results kann den Wert "AND" annehmen. Dadurch müssen alle Angaben erfüllt werden. Wird nichts angegeben gilt automatisch "OR"
Anschließend folgen die Suchbegriffe.
Wichtig: Diese müssen durchgehend von 1 an nummeriert sein, aber nicht zwingend in dieser Reihenfolge im Formular vorkommen.
# steht im folgenden(!) für die durchgehende Nummerierung!
Zuerst das eigentliche Eingabefeld für den Suchbegriff p# (also p1, p2, p3...) mit dem Wert ### SEARCH_PHRASE_# ###, der nach Durchführung der Suche als Vorgabe eingetragen wird.
sf# ist das Suchfeld, in dem gesucht werden soll.
sm# ist die Suchmaske, mit der die Abfrage laufen soll. Die Suchmasken werden in den Moduleinstellungen definiert
Zum Absenden natürlich noch am Ende ein
Das wichtigste für das ganze Modul ist das Formular, über das fast alles gesteuert wird.
Fangen wir mal vorne an:
| Code: |
| <form name="suchergebnisse" class="result" method="get" action="index.php" style="display: inline;"> <input type="hidden" name="action" value="feature_search" /> <input type="hidden" name="rubric" value="### SEARCH_NAV ###" /> <input type="hidden" name="results" value="AND" /> |
Hierbei ist folgendes wichtig bzw. einstellbar:
- method="get" muss eingestellt sein, weil dadurch Suchen als Link vordefiniert werden können
- Das hidden-Field action muß den Wert feature_search haben
- In das Hidden-Field rubric trägt das Modul automatisch die per URL übergebene Rubrik ein, wenn dort ### SEARCH_NAV ### eingetragen ist. Das ist wichtig für die richtige Anzeige der Navigation
- results kann den Wert "AND" annehmen. Dadurch müssen alle Angaben erfüllt werden. Wird nichts angegeben gilt automatisch "OR"
Anschließend folgen die Suchbegriffe.
Wichtig: Diese müssen durchgehend von 1 an nummeriert sein, aber nicht zwingend in dieser Reihenfolge im Formular vorkommen.
| Code: |
| PLZ:<input type="text" name="p1" id="p1" value="### SEARCH_PHRASE_1 ###" /> <input type="hidden" name="sf1" value="PLZ" /><input type="hidden" name="sm1" value="a" /><br /> Nachname:<input type="text" name="p2" id="p2" value="### SEARCH_PHRASE_2 ###" /> <input type="hidden" name="sf2" value="Nachname" /><input type="hidden" name="sm2" value="b" /><br /> ... |
# steht im folgenden(!) für die durchgehende Nummerierung!
Zuerst das eigentliche Eingabefeld für den Suchbegriff p# (also p1, p2, p3...) mit dem Wert ### SEARCH_PHRASE_# ###, der nach Durchführung der Suche als Vorgabe eingetragen wird.
sf# ist das Suchfeld, in dem gesucht werden soll.
sm# ist die Suchmaske, mit der die Abfrage laufen soll. Die Suchmasken werden in den Moduleinstellungen definiert
Zum Absenden natürlich noch am Ende ein
| Code: |
| <input type="submit" value="Suche"></form> |
Das Ergebnis
Der Ergebnisbereich ist grundsätzlich so definiert wie beim Such-Modul
### SEARCH_MESSAGE ### gibt Meldungen aus
### SEARCH_MATCHES ### gibt die Anzahl der gefundenen Treffer aus
### SEARCH_NUM ### ist eine durchgehende Nummerierung
### SEARCH_TITLE ### ist der Artikeltitel
### SEARCH_PAGES ### ist die ggf. notwendige Paginierung
aber nun kommts:
die restlichen Platzhalter im Format ### SEARCH_Platzhaltername ### stehen eben für die Platzhalter, die abgebildet werden sollen, die ja nicht unbedingt der eigentliche Suchbegriff sein müssen.
| Code: |
| ### SEARCH_MESSAGE ### <br /> <br /> ### SEARCH_MATCHES ### <!-- START_SEARCH_MATCH --> <div class="morelink">### SEARCH_NUM ###.) <a href="../_rubric/detail.php?nr=### SEARCH_ARTICLE_ID ###&rubric=Z%FCchter">### SEARCH_TITLE ###</a></div> <div class="externallink">### SEARCH_Vorname ### ### SEARCH_Nachname ###<br /> ### SEARCH_PLZ ### ### SEARCH_Ort ###<br /> <a href="### SEARCH_Homepage ###" rel="external">### SEARCH_Homepage ###</a></div> <hr /> <!-- ENDE_SEARCH_MATCH --> <br /> <br /> ### SEARCH_PAGES ### <br /> <br /> <a href="../_rubric/index.php?rubric=Z%FCchter">Alle Züchter anzeigen</a> <!-- ENDE_MOD_SEARCH --> |
### SEARCH_MESSAGE ### gibt Meldungen aus
### SEARCH_MATCHES ### gibt die Anzahl der gefundenen Treffer aus
### SEARCH_NUM ### ist eine durchgehende Nummerierung
### SEARCH_TITLE ### ist der Artikeltitel
### SEARCH_PAGES ### ist die ggf. notwendige Paginierung
aber nun kommts:
die restlichen Platzhalter im Format ### SEARCH_Platzhaltername ### stehen eben für die Platzhalter, die abgebildet werden sollen, die ja nicht unbedingt der eigentliche Suchbegriff sein müssen.
Select-Felder
Nun ein "Goodie":
Jede Benutzereingabe kann Fehlerhaft sein, daher ist eine Auswahl ggf. besser. Diese kann man vordefinieren:
sp1 steht für "select phrase". Der gewählte Wert wird automatisch als p1 ausgewertet.
Ist sf1 mit einem Feldnamen versehen, wird dies als zu durchsuchendes Feld benutzt. Ist der Wert leer (wi im Beispiel) wird der Wert von sp1 auch als Feldname verwendet! Wozu das? Die von mir eingeführten Checkboxen können so mittels Select-Feld problemlos angeboten werden. Es werden also viele verschiedene Felder mit gleichen aber auch mit unterschiedlichen Werten durchsucht. Und das nur mit einem(!) select-Feld!
Hierbei wird als Suchmaske sm1 der Wert "a" (entspricht ='###') benutzt, weil es ja durch die Vorgabe eine exakte Übereinstimmung sein kann... muss aber nicht, auch hier ist die Suchmaske freigestellt.
Und was heißt ### S1_Airedale Terrier ### ???
S1_ steht für das Select-Feld 1 und anschließend steht ein möglicher Auswahlwert.
Wird nun ein Wert gewählt, wird der entsprechende Platzhalter durch selected="selected" ersetzt. Die anderen bleiben stehen, werden aber durch den Browser ignoriert.
Solche umfangreichen Optionslisten lassen sich aus einer einfachen Textliste wunderbar mittels Excel oder auch Access mit allen notwendigen HTML-Tags versehen.
Jede Benutzereingabe kann Fehlerhaft sein, daher ist eine Auswahl ggf. besser. Diese kann man vordefinieren:
| Code: |
| <select name="sp1" id="sp1"> <option value=''>-- Bitte wählen --</option> <option value='Airedale Terrier' ### S1_Airedale Terrier ###>Airedale Terrier</option> <option value='Australian Terrier' ### S1_Australian Terrier ###>Australian Terrier</option> <option value='Australian Silky Terrier' ### S1_Australian Silky Terrier ###>Australian Silky Terrier</option> ... <option value='Skye Terrier' ### S1_Skye Terrier ###>Skye Terrier</option> <option value='Welsh Terrier' ### S1_Welsh Terrier ###>Welsh Terrier</option> <option value='West Highland White Terrier' ### S1_West Highland White Terrier ###>West Highland White Terrier</option> <option value='Yorkshire Terrier' ### S1_Yorkshire Terrier ###>Yorkshire Terrier</option> </select> <input type="hidden" name="sf1" value="" /> <input type="hidden" name="sm1" value="a" /> |
sp1 steht für "select phrase". Der gewählte Wert wird automatisch als p1 ausgewertet.
Ist sf1 mit einem Feldnamen versehen, wird dies als zu durchsuchendes Feld benutzt. Ist der Wert leer (wi im Beispiel) wird der Wert von sp1 auch als Feldname verwendet! Wozu das? Die von mir eingeführten Checkboxen können so mittels Select-Feld problemlos angeboten werden. Es werden also viele verschiedene Felder mit gleichen aber auch mit unterschiedlichen Werten durchsucht. Und das nur mit einem(!) select-Feld!
Hierbei wird als Suchmaske sm1 der Wert "a" (entspricht ='###') benutzt, weil es ja durch die Vorgabe eine exakte Übereinstimmung sein kann... muss aber nicht, auch hier ist die Suchmaske freigestellt.
Und was heißt ### S1_Airedale Terrier ### ???
S1_ steht für das Select-Feld 1 und anschließend steht ein möglicher Auswahlwert.
Wird nun ein Wert gewählt, wird der entsprechende Platzhalter durch selected="selected" ersetzt. Die anderen bleiben stehen, werden aber durch den Browser ignoriert.
Solche umfangreichen Optionslisten lassen sich aus einer einfachen Textliste wunderbar mittels Excel oder auch Access mit allen notwendigen HTML-Tags versehen.
Diese Dokumentation ist urheberrechtlich geschützt. Alle Rechte, auch die der Modifikation, der Übersetzung, des Nachdrucks und der Vervielfältigung, im Ganzen oder in Teilen, bedürfen der vorherigen schriftlichen Genehmigung von Markus Rösel. Dies gilt unabhängig davon, auf welche Art und Weise, für welche Zwecke und mit welchen Mitteln dies geschieht.