„Relevanssi“ – eine bessere Suche? – gen Plug-in Search Relevance und WP Ajax Search Widget

Der Website eigene Suchergebnisse lässt Programms WordPress etwas zu wünschen übrig, insofern es nur Datums sortierte Ergebnisse anzeigt und des Gesuchte darüber hinausgehend Ergebnisse auswirft, die wenig, bis nichts mit dem Gefragten verknüpft. Daher gibt es Plug-ins, welche die Sucherergebnisse in Algorithmen aufbereiten. Hierzu eignet sich mit Vorbehalt sehr gut das Plug-in Relevanssi – A Better Search, oder Plug-in Search Relevance darüber hinaus WP Ajax Search Widget.

Plug-in
Relevanssi

Im Vergleich zur WP-Suche ist mit Plug-in Relevanssi der „relevante Erfolg“ sichtbar, etwa 1/3 weniger Ergebnisse, welche spezifisch nicht fehlen. Zudem kann man die gesuchten Begriffe hervorheben lassen auch Aufrufs in betreffenden Artikel (aber s. hierzu ersten Punkt nächste Überschrift). Der „weiterlesen →“ Button ist bei den Suchergebnissen durch Plug-in Relevanssi nicht mehr eingeblendet (s. kl., interne  Aufzeichnung). Fast allesamt relevanten Eistellungen (fulminant! :-) sind ins Deutsche übersetzt und soweit bestens erklärt.

(Aufzeichnung) Bemerkung: Betreffs „Suche“ mit Relevanssi sind die Artikel ohne „weiterlesen →“ Button dargestellt. Dies ist gleich annehmbarer Nebeneffekt, da durch das Plug-in WP External Links dessen Anzeige der „Inernal Links“ Icons/Dashicons bei den Suchergebnissen doppelt angezeigt war. Plug-in WP External Links nunmehro nicht aktiviert, s Internal Links ⇔.

Meine Hinweise für Einstellungen:
  • Benutzerdefinierte Auszüge/Snippets „Neues Benutzerdefiniertes Suchergebnis-Snippet“ anhaken, somit sind in den Suchergebnissen die Suchbegriffe farblich hervor gehoben.
    • Das extra zu setzende Häkchen zur Hervorhebung von Suchbegriffen in aufgerufenen Dokumenten (also nicht nur Hervorhebung des Suchbegriffs in der Anzeige der Suchergebnisse), folgt, wenn der Besucher ein Dokument mit komplizierterem Inhalt (z. B. Snippetscodes) aus einem Suchergebnis öffnet: eine gestörte Wiedergabe. Also „Suchbegriffe in aufgerufenen Dokumenten hervorheben“ kein Häkchen setzen!
  • Die Sucherergebnisse sollten natürlich auch des Inhalts von Info-Button und Tabmenü resultieren, hierzu Funktion unter Indizierungs-Einstellungen die „Shortcodes im Beitrags-Inhalt ausführen“ anhaken.

Aber anders: also mein Argument wider Erweiterung „Relevanssi“ (mit Vorbehalt Zeitpunkts aktuellen Plug-in Version): In den Suchergebnissen spießen sich mithin oben beschriebener Umsicht (auch generell mit More-Tag vor Code-Snippets im pre-Tag), Beiträge, nach anklick „Weiter →“ Button, dessen Artikel Inhalts gewissen Coderates (Snippets) eine Störung der Website hervorrufen. Desselben Missfallens der Störung kommen weder noch in Weiterleitung von „WorPress Suchergebnissen“, „Kategorie-“ oder „Tags-Aufruf“ zustande.

Überlegung: Eine Suche soll Artikel konkreten Begriffs widerspiegeln. Ansonsten ist ja eh alles im Inhaltsverzeichnis, in Kategorien und den Tags auffindbar. Daher genügte, so wie hier meiner Website, die Anzeige von paar Artikel um zu gesuchten Begriffen zu finden (z. B. 6 Beiträge, gleich, wie hier die Einstellung für Beiträge pro Seite der „Beitrags- Blogseite“, s. nächsten Tab „Search Relevance“: Anzeigens von paar Suchergebnissen auf nur einer Seite …).

Fazit: Somit die relativ große, aber gefällige Erweiterung mit Relavanssi hier nichtig ist. Die WordPress-Suche habe ich dennoch ergänzt, mit dem schlanken Plug-in Search Relevance, s. n. Tab.

Plug-in
Search Relevance

Search Relevance, welche Suchergebnisse, ja, der Relevanz entsprechen und diese sind mit diversen Snippets in der functions.php einzustellen.

Snippets:

WordPress-Suchergebnisse einschränken
WordPress Search Results Page Modifications
10 Useful Snippets for Improving WordPress Search
Useful WordPress Code Snippets to Improve Search
Limit Your WordPress Search Results
Hacks and snippets to enhance WordPress search engine

Zugabe:

limit search results
Limit Number of Posts Returned in WP Quer
Sort WordPress Search by Relevance

Beispiel
Snippets für die Suchergebnisse:

// Wenn das Suchergebnis nur 1 Post zurückgibt, wird es automatisch an den Artikel weiterleiten
function wpc_redirect_single_post() { 
 if (is_search()) { 
 global $wp_query; 
 if ($wp_query->post_count == 1 && $wp_query->max_num_pages == 1) { 
 wp_redirect( get_permalink( $wp_query->posts['0']->ID ) ); 
 exit; 
 } 
 } 
} 
add_action('template_redirect', 'wpc_redirect_single_post');

// Beiträge Suchergebnisse einschränken auf Kategorie
function SearchFilter($query) {
 if ($query->is_search) {
 $query->set('cat','35');
 }
 return $query;
}
 
add_filter('pre_get_posts','SearchFilter');

// Einzelne Beiträge / Seiten aus der Suche ausschließen
function exclude_pages_from_search($query) {
 if ( $query->is_main_query() && is_search() ) {
 $exclude_ids = array( 822, 630 );
 $query->set( 'post__not_in', $exclude_ids );
 }
 return $query;
}
add_filter( 'pre_get_posts','exclude_pages_from_search' );
Nur paar Suchergebnisse auf einer Seite

… also wie die Überlegung im Tab „Relevanssi“: Eine Suche soll Artikel tatsächlichen Begriffs widerspiegeln. Ansonsten sind Inhaltsverzeichnis, Kategorien und die Tags vorteilhaft. Daher die Anzeige von paar Artikel passend, um zu gesuchten Begriffen zu finden (z. B. 6 Beiträge, gleich, wie hier die Einstellung für Beiträge pro Seite der „Beitrags- Blogseite“.

Hierzu kann man in der search.php des Themes auskommentieren:

// Previous/next post navigation.
 /* twentyfourteen_paging_nav(); */

… hiermit ist „Weiter →“ Button der Seite von Suchergebnissen nicht vorhanden und im Gesamten dieselbe Anzahl angezeigt, wie für „Beitrags- Blogseite“ der Einstellung (Dashboard/Einstellungen /Lesen) „Blogseiten zeigen maximal“ per Seite definiert sind.

Anmerkung: Mit dieser Änderung auch die beschriebene Störung der Avis gewissen Beiträgen durch Relevanssi hinfällig wären, weil hier die Störung ja erst nach betätigen des „Weiter→“ Button zustande kommt.

Für „Beiträge“ und „Seiten“ jeweils eigene Suchergebnisse?

Meine Website bedient sich des Plug-in Search Relevance und die Suchergebnisse – durch Snippets modifiziert – sind auf Kategorie beschränkt. Es wäre ein Snippet-Code gefragt, welches die Suchergebnisse von Beiträgen und Seiten trennen kann, also eine Suche, welche von „Beitrag“ gestartet, idalerweise nur von „Beiträgen gleicher Kategorie(n)“ anzeigt und ebd. von „Seite“ nur Ergebnisse von „Seiten“, oder – einfach, wie hier – eine zweite, definierte Suche mit jeweils individuellen Suchergebnissen.

Hierzu bliebe zur Idee ein eigenes, feines Plug-in, welches die Suche in Relevanz und selbständig bewerkstelligt: WP Ajax Search Widget. Siehe bitte nächsten Tab.

Plug-in
WP Ajax Search Widget

Das Widget vom Plug-in WP Ajax Search Widget bewerkstelligt zunächst einfache Auflistung des Titels. In Seitenleiste eingefügt, wird durch das Ausklappen der Anzeige des Suchergebnis, das bestehende Inhaltsverzeichnis nach unten verschoben und evtl. abgeschnitten oder umgekehrter Reihenfolge zum Inhaltsverzeichnis, sich über den Footer-Widget-Bereich legt.

Besser geeignet scheint einbringen des Widgets in den Footer-Widget-Bereich, wo es sich aufrufs der Suchergebnisse nach unten darstellt. Dieser Modifikation ist hier diesen Themes aber die obere Linie der Fußzeile störend und kann visuell entfernt werden.

Wer für die Fußzeile ohnehin keine Verwendung (Stolz präsentiert von WordPress), kann in der footer.php die Fußzeile entfernen, s. auch Fußzeile Textfarbe und Text.

Oder, erweiterter Hinsicht jeweiligen Themes kann man die footer.php aber mit entsprechendem Inhalt belassen und für den Erfolg barrierefreie Darstellung der Suchergebnisse – wie hier meiner Website für „Seiten“ (.page) – über CSS ansprechen:

.page #supplementary + .site-info {
 border-top: 0px;
}

Theme Twenty Fourteen

… und die Linie ist hiermit den „Seiten“ entfernt wie sie für „Beiträge“ in normaler Darstellung ist, wo ja WP Ajax Search Widget nicht in Verwendung ist.

Ausschluss-filter für Plug-in WP Ajax Search Widget

Den Code für Suchergebnisse von „Beiträgen“ v. v. „Seiten“ oder Ausschluss Kategorie usw., dessen für WP Ajax Search Widget die Snippets etwas anders sind.

Filter Kategorie

Nach Schablone und Tipp vom Plug-in Autor Scott, functions.php:

// Ajax Search Widget. Kategorien ausschließen
function my_wp_query_array( $query, $s, $search ) {
 return array( 's' => $s, 'category__not_in' => array( 1, 35, 36 ) );
}
add_filter('wpasw_query', 'my_wp_query_array', 10, 3);
Filter einzelne Seiten/Beiträge

Möchte man mit den „Kategorien“ auch ein paar einzelne „Beiträge“ anderer Kategorie bzw. „Seiten“, bspw. das Impressum, aus der Suche ausschließen:

// Ajax Search Widget. Kategorien ausschließen; Einzelne Beiträge / Seiten aus der Suche ausschließen
function my_wp_query_array( $query, $s, $search ) {
 return array( 's' => $s, 'category__not_in' => array( 1, 35, 36, 37, 41 ), 'post__not_in' => array( 46, 381, 782 ) );
}
add_filter('wpasw_query', 'my_wp_query_array', 10, 3);
Anzahl Suchergebnisse:

Separate Anzahl der Suchergebnisse, Anfügung, zum obigen Code der Ausschluss-filter, also der Code mit beiden vorhergehenden Snippets zusammen:

// Ajax Search Widget. Kategorien ausschließen; Einzelne Beiträge / Seiten aus der Suche ausschließen und Suchergebnisse einschränken
function my_wp_query_array( $query, $s, $search ) {
 return array( 's' => $s, 'category__not_in' => array( 1, 35, 36, 37, 41 ), 'post__not_in' => array( 46, 381, 782 ), 'post_status' => 'publish', 'posts_per_page' => 4 );
}
add_filter('wpasw_query', 'my_wp_query_array', 10, 3);

…. für unbegrenzte Anzeige der Suchergebnisse:

anstatt: => 4
dieses: => $limit
Anmerkung: Mit den Filtern ist die im „Widget“ von WP Ajax Search Widget zu definierende Anzahl der Suchergebnisse durch die normale Suche (für Plug-in Search Relevance bestimmte Suchergebnisse, s. dessen Tab) nicht mehr funktionell und jene Grundeinstellung von (Dashboard/Einstellungen/Lesen) kommt zum Tragen und wird daher für WP Ajax Search Widget mit obigem Code eigens festgelegt.

Die functions.php betreffende Codeschnipsel vornehmlich im Plug-in Code Snippets ⇔ abspeichern: Sowohl Protektion und Verwaltung als auch Erhaltung der Codes bei Theme-Update.

!! Wichtig:
  • Die Filter-Codes für WP Ajax Search Widget unter Verwendung des Plug-in Code Snippets: dessen im Code-Editor in Einstellungen/Bereich: „Snippet überall ausführen“ oder „Nur im Administrationsbereich ausführen“ – beides funktionell.
  • Die Snippets zur normalen Suche (über Plug-in Search Relevance) auf „Nur im Frontend der Website ausführen“ gesetzt sein will, weil es ansonsten in Anwendung beider Suchmöglichkeiten unterschiedlicher Suchergebnissen nicht funktioniert (betrifft eigentlich den Filter für „Beiträge Suchergebnisse einschränken auf Kategorie“).

Kuriosität der Erstellung, kleine Erinnerung: Das Plug-in WP Ajax Search Widget mitsamt Code funktionierte im Frontend der Website nur vom Backend. Also war ich der Annahme, dass es mit dem Ajax, Javascript zusammenhängt, und habe mit dem Code dieser Website (Einfügen von JavaScripts in Head oder Footer) Erfolg. Fast gleichzeitig stand ein Update für das Plug-in Code Snippets an, und wurde sogleich durchgeführt – wie dieses Zusammenhangs Folgendem sein könnte?  Kl. Irrtum? – Ja.
 

Der Tüftelei um die Einstellung habe ich nämlich den besagten Code (Einbinden mit der WP-Funktion wp_enqueue_scripts) auch deaktiviert – und, die Funktion von WP Ajax Search Widget war gegensätzlich eingangs dennoch vorhanden –. Aber …

Merke: Solcherart Ungereimtheiten können neben dem Browser Cache auch durch Plug-in Cache Enablers Cache und Löschen dessen aufgehoben werden. Gleich, wie wenn mal unzureichende Ladung eines Bildes, bei erneutem Aufruf immer dessen gecoachte Seite aufgerufen wird, also das Bild trotz Neuladung der betreffenden Seite nicht aufscheint. Diese Frage ist auf der Startseite durch in der Headerleiste befindenden Schaltfläche „Url Cache Löschen“ zu beantworten.

Plug-in WP Ajax Search Widget, Suchergebnisse ohne Datum anzeigen

Die Suchergebnisse ohne Datum anzeigen geht über Plugin-Editor, Datei wp-ajax-search-widget/wp-ajax-search-widget.php, durch löschen des Codes farbig hervorgehobenen Bereichs:

<li <?php post_class(); ?>>
 <h5 class="entry-title"><a href="<?php the_permalink() ?>" rel="bookmark" title="<?php the_title_attribute(); ?>"><?php the_title(); ?></a></h5>
 <div class="entry-date"><time class="published" datetime="<?php the_time( 'Y-m-d\TH:i:s' ) ?>"><?php the_date(); ?></time></div>
 </li>
Die Schaltfläche „View all search results?“

Die Schaltfläche für „View all search results?“ sollte ebenso gelöscht1) sein, weil ansonsten leitet die Schaltfläche2) zu den Suchergebnissen der Einstellung für Plug-in „Search Relevance“.

1)   ;-) Jojo – das Snippet zur richtigen Weiterleitung konnte ich nämlich nicht herausfinden …
2)  … ebd. durch die Codes-Filter, s. o., !! Wichtig.

Also, Plugin-Editor, selbige Datei w. o. und Löschung der Codes orange farbigen Bereichs:

 // link to more?
 if ( $search->max_num_pages > 1 ) {

 if ( locate_template( 'parts/widget-ajax-search-more.php' ) != '' ) {
 get_template_part( 'parts/widget-ajax-search-more' );
 } else {
 ?>
 <li class="wpasw-more-link"><a href="<?php echo esc_url( add_query_arg( array( 's' => $s ) , home_url() ) ); ?>"><?php _e( 'View all search results &hellip;', 'wpasw' ); ?></a></li>
 <?php
 }
 }

 ?><br></br></ul><?php

 else:

 // no results

Anmerkung: Mit den Tags <br></br> habe ich mir am Ende der Liste des Suchergebnis etwas mehr Abstand erlaubt. Die Auszeichnung <br /> (einfach mit Leerzeichen vor dem Slash) funktioniert diesen Codes nicht. Für erweiterten Abstand können mehrere <br></br> eingesetz werden, auch das &nbsp;, aber mehrere &nbsp; sprechen nicht an.

Zwischenräume in der Auflistung des Suchergebnis

Die Zwischenräume sind hier bezüglich, zu weit dargestellt, daher CSS Auszeichnung im CSS-Editor:

.wpasw-result-list li {
/* margin-top: 0px; */
margin-bottom: -13px;
}

… dieser Auszeichnungen sind die vertikalen Abstände pixelgenau einzuzellen. Das margin-top: 0px; für evtl. Gebrauch.

Im Suchfeld die Textfarbe für eingaben Suchbegriffs(!) anpassen

Dieser Hinsicht wird wohl nur gelegentlich Verwendung finden oder individuell erwünscht ist. Beispiels Website mit verlauf hellblauen Hintergrund, schaltet die Textfarbe im Suchfeld auf Weiß um und ist somit kaum sichtbar.

Nach Suche in der style.css des Themes kann man im (Stylesheed) CSS-Editor dem Missfallen entgegenwirken bzw. dem Gefallen einwirken. Hier mit spezifischer Auszeichnung für Seiten (page) und Portfolio (single-portfolio), funktionierend durch „input“ und „textarea“:

/* Ajax-Search-Widget, Texteingabe für Suche andere Farbe */
.page input, textarea::-webkit-input-placeholder {
 color: #a17e4f !important;
}

.single-portfolio input, textarea::-webkit-input-placeholder {
 color: #a17e4f !important;
}

.page input, textarea:-moz-placeholder {
 color: #a17e4f !important;
}

.single-portfolio input, textarea:-moz-placeholder {
 color: #a17e4f !important;
}

.page input, textarea::-moz-placeholder {
 color: #a17e4f !important;
}

.single-portfolio input, textarea::-moz-placeholder {
 color: #a17e4f !important;
}

.page input, textarea:-ms-input-placeholder {
 color: #a17e4f !important;
}

.single-portfolio input, textarea:-ms-input-placeholder {
 color: #a17e4f !important;
}

Wie aus dem Beispiel zu erkennen ist, sind unterschiedliche Custom Post Types eigens auszuzeichen, eine Aneinanderreihung wie:

.page input, textarea:-ms-input-placeholder, .single-portfolio input, textarea:-ms-input-placeholder {
color: #a17e4f !important;
}

… nicht funktionell ist bzw. nur das Erstere übertragen wird.

Code 4 Mal  für jeden Browser-Präfix … ebenso-gut könnte der Platzhalter im Suchfeld (Suche…) erwünschter Farbe folgen: Wie man die Farbe des Textplatzhalters in Formularfeldern ändert Kompliment und Danksagung der Website! – solcherart diffizile Infos für Verständnis Anfänger sind nicht einfach zu finden …

Beifügung – nur Merkzettel (OT) evtl. Gebrauchs:

input Code ändert die Farbe des Text-Platzhalters für Eingabefeld: Text, Suche, Link, Telefonnummer, E-Mail-Adresse, und Passwort.

textarea Code ändert die Farbe des Text-Platzhalters für den Textbereich (text area), wo der Nachrichtentext des Kontaktformulars angezeigt wird.

Die Farbe des Text-Platzhalters für bestimmten Eingabetyp, Beispiels die E-Mail-Adresse (email):

input[type="email"]::-webkit-input-placeholder {
color: blue !important;
}

Aktualisiert am 07.09.2017

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.