Anpasspare und "handlebare" Suche
Eingetragen von A. Winter (88)am 03.02.2015 - 12:53 Uhr in
Hallo zusammen,
aktuell bin ich gerade dabei, die momentan verwendete Suche (Core search module) an einigen Punkten zu verbessern.
Mir ist bereits aufgefallen, dass die Standard-Suche nur begrenzt konfigurierbar ist.
Folgende Punkte sind mir bei der Suchfunktion sehr wichtig:
- Verwendung sowohl auf einer Seite als auch mithilfe eines Blocks
- Festlegung, welche Bereiche durchsucht werden sollen
- Optimal auch für Seiten/Übersichten, die mittels View generiert werden
- Möglichkeit zur Anpassung (Templates)
- Anpassung des Suchpfades/der URL (statt node/search/begriff z. B. einfach suche/begriff)
- Schöne/aussagekräftige Breadcrumbs. Aktuell leider folgendes: Startseite / Suche / Inhalt / Inhalt (als Theme verwende ich Zen)
- Highlighting der Fundstellen
Wichtig, aber nicht zwingend erforderlich:
- Ausgabe der Anzahl der Treffer
- Highlighting der Fundstellen, sowohl im Title als auch im Body bzw. Teaser
- Feinere Einstellung, wie genau durchsucht werden soll. Z. B., ob Teilbegriffe gefunden werden sollen oder nicht.
- Verwendung von Placeholdern statt Labels
Mit der Standardsuche könnte ich fast leben, wenn es mir nur irgendwie möglich wäre, sowohl die URL als auch die Breadcrumbs anzupassen.
Ich habe bis jetzt schon folgende drei Möglichkeiten ausprobiert:
- Verwendung des Custom Search
- Erstellung einer Suchseite mit Views und dem Search API-Modul mit dieser Anleitung
- Anpassung der Core-Funktionalität über ein eigenes Modul, Anleitung gefunden auf dieser Seite
Custom Search: Damit hatte ich leider keinen Erfolg. Man konnte prinzipiell einige Einstellungen vornehmen, aber die Suche hat bei mir anschließend nicht mehr funktioniert (Die Seite "suche/suchbegriff" konnte nicht gefunden werden)
Views, Search API: Es sah anfangs ganz gut aus, aber mir war es ehrlich gesagt etwas zu "überdimensioniert" und kompliziert.
Eigenes Modul: Hiermit war es möglich, den Suchpfad/URL anzupassen und automatisch auch die Breadcrumbs, allerdings funktionierte die Suche auch nicht mehr, sobald ich den Pfad searchpath in suche geändert hatte.
Hier ist der Code, den ich innerhalb des Moduls verwende:
<?php
// Custom search path alias
function search_path_alias_form_search_form_alter(&$form, &$form_state, $form_id) {
$form['#action'] = 'searchpath';
$form_state['action'] = 'searchpath';
$form['#submit'][] = '_search_path_alias_search_form_submit';
}
function search_path_alias_form_search_block_form_alter(&$form, &$form_state, $form_id) {
$form['#submit'][] = '_search_path_alias_search_form_submit';
}
function _search_path_alias_search_form_submit(&$form, &$form_state) {
$form_state['redirect'] = 'searchpath/'.$form_state['values']['search_block_form'];
}
// Add searchpath to available paths
function search_path_alias_menu_alter(&$items) {
$path = 'searchpath';
$items[$path] = array(
'title' => t('Search'),
'page callback' => 'search_view',
'page arguments' => array('node', 1),
'access callback' => '_search_menu_access',
'access arguments' => array('node'),
'type' => MENU_LOCAL_TASK,
'file' => drupal_get_path('module', 'search') . '/search.pages.inc',
'weight' => -10, //Don't know what is it for
);
$items["$path/%menu_tail"] = array(
'title' => t('Search'),
'load arguments' => array('%map', '%index'),
'page callback' => 'search_view',
'page arguments' => array('node', 1),
'access callback' => '_search_menu_access',
'access arguments' => array('node'),
// The default local task points to its parent, but this item points to
// where it should so it should not be changed.
'type' => MENU_LOCAL_TASK,
'file' => drupal_get_path('module', 'search') . '/search.pages.inc',
'weight' => 0,
// These tabs are not subtabs.
'tab_root' => 'searchpath/%',
// These tabs need to display at the same level.
'tab_parent' => 'searchpath',
);
}Ist es denn bei Drupal so schwierig, eine vernünftige Suche zu realisieren, ohne immensen Mehraufwand in Kauf zu nehmen?
Ich habe leider auch auf drupalcenter noch keine gute passende Erklärung/Lösung gefunden.
Deshalb hoffe ich, dass mir jemand auf die Sprünge helfen kann :)
- Anmelden oder Registrieren um Kommentare zu schreiben
Search API ist definitiv empfehlenswert
am 03.02.2015 - 14:23 Uhr
Ich habe die Anforderungen nur kurz überflogen und sofort an Search API gedacht. Und dann das gelesen.
Views, Search API: Es sah anfangs ganz gut aus, aber mir war es ehrlich gesagt etwas zu "überdimensioniert" und kompliziert.
Das Argument wird dann auch gerne insgesamt eggen Drupal in Stellung gebracht. Flexibilität bringt aber logischerweise auch Komplexität mit.
Dazu kommt, daß die Core-Suche sehr rudimentär und nicht sehr performant ist. Langsamer ist dann nur eine Volltext-Suche direkt auf der SQL-Datenbank, wie man das mit Views alleine machen machen, obwohl man damit etwas Flexibilität bekommt. Die Search API-Lösung lässt sich dann auch mit Apache Solr erweitern, mit dem dann eine professionelle und äußerst performante Suche möglich wird.
# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: Full Maintenance Service Provider | Web Application & Server | Security & Availability
Danke Carsten für deinen
am 03.02.2015 - 18:30 Uhr
Danke Carsten für deinen Tipp.
Ich habe es mit hauptsächlich diesen beiden Anleitungen endlich geschafft, eine Suche zu bauen, so wie ich sie mir vorstelle und eigentlich auch so, wie man es gewohnt ist.
http://webwash.net/tutorials/add-keyword-highlighting-using-search-api-d...
http://webwash.net/tutorials/intro-search-api-part-1-how-create-search-p...
Sogar mit Highlighting und es wird nur in den "Bereichen" gesucht, die ich ausgewählt habe.
Jetzt bin ich nur noch EINEN Schritt davon entfernt, dass ich das Kapitel abhaken kann und glücklich bin.
Im Header soll es zusätzlich das Such-Eingabefeld geben, sodass man auf jeder Seite nach einem Begriff suchen kann - und nicht erst auf die spezielle Suchseite navigieren muss.
Eigentlich so, wie es auch bei der Core-Suche möglich ist, über einen Block, der auf die Suchergebnisse-Seite weiterleitet.
Also dachte ich, als Anzeige lediglich einen Block hinzufügen (alles außer des exposed Filters entfernen) und den Block wie gewohnt in eine Region schieben.
Aber wie ich feststellen musste, werden die Filter in einem "Views-Block" nicht angezeigt.
Also habe ich versucht, über die Better Exposed Filter den Filter "auszulagern", was prinzipiell auch funktioniert. Allerdings wird der Filterbereich dann NUR noch im entsprechenden Block
angezeigt und nicht mehr auf der eigentlichen "Views-Suche-Seite".
Ich brauche aber beides, die Suche-Seite MIT Eingabefeld (Filter) UND eben ein Suchfeld in einem Block, das ständig angezeigt wird.
Das muss doch irgendwie gehen.
BITTE BITTE helft mir bei diesem kleinen Schritt. Ich krieg' bald die Krise :)
"Hervorgehobenes Formular in Block"
am 04.02.2015 - 01:04 Uhr
Für eine Views-Page kann ein exposed Filter (der hier ja auf einen Search API index sucht) auch als Block bereit gestellt werden.
Edit: OK, das läuft schon, aber das Problem ist der "doppelte" Block dann auf der eigentlichen Suchseite. Da gibt es garantiert auch eine Lösung für, nur müsste ich da jetzt auch nach suchen. Aber diese Suche kann unabhängig von Search API erfolgen. Es geht nur darum Exposed Filter "doppelt" im Einsatz zu haben.
# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: Full Maintenance Service Provider | Web Application & Server | Security & Availability
Multiblock
am 04.02.2015 - 01:22 Uhr
Vllt. gibt es einen Views-Ansatz, der die Standard-Filter nicht komplett abschaltet, wenn sie in ein Block verschoben werden. Das würde mich auch interessieren.
Aber ohne so einen eleganteren Weg kann man das auch nur auf Block-Ebene betrachten, den wir wieder verwenden möchten. Da gibt es zwar ein paar Code-Snipits im Netz, weil das erstmal nicht vorgehen ist, zumindest noch in D7 (bei D8 weiß ich es nicht). Das Modul "Multiblock" macht dies auch mit dem Exposed-Filter Block, wie ich gerade mal rudimentär getestet habe.
# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: Full Maintenance Service Provider | Web Application & Server | Security & Availability
Nochmal danke für das Feedback
am 04.02.2015 - 10:29 Uhr
Okay, also wie ich sehe, ist die Verwendung sowohl einer globalen Suche, als auch einer Suchseite so nicht wirklich vorgesehen.
Wobei ich es irgendwie seltsam finde, dass es für dieses Szenario keinen Ansatz bzw. keine elegante Lösung gibt.
Es ist doch eigentlich "normal", dass es auf einer größeren Seite ein Suchfeld gibt, das in irgendeiner Sidebar, im Header oder
Footer fest vorhanden und ständig zu verwenden ist?
Mich würde wirklich interessieren, wie das auf anderen Drupal-Seiten umgesetzt ist.
Ich habe vorübergehend eine Lösung gefunden, die nicht wirklich elegant und professionell ist, aber funktioniert:
Alles, was ich getan habe, ist, den HTML-Code des Suchfelds einfach zu kopieren und ihn in einem Block zu speichern.
Natürlich habe ich nicht benötigte Tags und IDs entfernt. Anschließend den Block in den Header schieben, fertig!
Starte ich nun darüber eine Suche, werde ich mittels der korrekten URL auf die Views-Seite geleitet und die Ergebnisse
werden wie gewohnt dargestellt.
Ich denke, ich kann erst mal mit meiner "Lösung" leben, obwohl ich lieber eine "Block-Suche" hätte, die mit der eigentlichen
Suche verknüpft ist.
Ach und, falls es jemanden interessiert, um diese Seite geht es, damit man sich ein besseres Bild machen kann:
http://landfrauen-rheinhessen.de.dedi2168.your-server.de/