fullsizeoutput_e6

„Relevanssi“ – eine bessere Suche? – gen Plug-in Search Relevance

Der Website eigene Suchergebnisse lĂ€sst Programms WordPress etwas zu wĂŒnschen ĂŒbrig, insofern es nur Datums sortierte Ergebnisse anzeigt und des Gesuchten 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.

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 ⇔.

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 mit 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 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 …). Aber dieses als keine Lösung betrachtet werden kann:

Nur paar Suchergebnisse auf einer Seite

Eine Suche soll Artikel tatsĂ€chlichen Begriffs widerspiegeln. Ansonsten sind Inhaltsverzeichnis, Kategorien und die Tags vorteilhaft. Daher evtl. 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.

Mit dieser Änderung 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.

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
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, erfolgt Weiterleitung direkt an den Artikel */
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' );

Bemerkung Allgemein:

Nebenher erfolgen dem Widget 'Neue BeitrÀge' in den Suchergebnissen ebenso 'Relevante neue BeitrÀge'.

Plug-in
WP Ajax Search Widget

Interner Versuch die Suche von 'Seiten' und 'BeitrĂ€ge' zu sondieren. Der Beschreibung nach ist/war es funktionell, aber an und fĂŒr sich ist diese, naja, Technik zu umstĂ€ndlich – bleibt nur als Doku zum Versuch.

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, idealerweise 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. Darum habe ich mich mit Plug-in WP Ajax Search Widget befasst, um eine Zweite – wie voneinander getrennte Suchergebnisse fĂŒr BeitrĂ€ge und Seiten zu erreichen.

Beschreibungen

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, 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 Snippets zur functions.php im Plug-in Code Snippets abspeichern. Dazu ist das zur Verwaltung der Codes als auch der Schutz 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;
}

↑ TabmenĂŒÂ 

Der Beitrag ist so weit, so gut