WP-Suchergebnisse

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. – so ist meist zu lesen. 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. Mit Vorbehalt deshalb, da für so Websites wie hier die WP-Suche genug des Guten ist. Daher ist hier auf Wegerl der Art kein Plug-in in Anwendung. Mithin zur Performanz von Suchergebnissen sind da so Snippets für die functions.php., die so-und-so von Vorteil sein können.

Snippets

So Snippet führt die Suche zu vernünftige Ergebnisse.

Beiträge die Suche auf Kategorie begrenzen

Und das „Nur im Frontend der Website ausführen“. Der PHP-Code wird im Adminbereich nicht ausgeführt. – und so soll es auch sein!

functions.php

/* Suche für Beiträge auf Kategorie begrenzen */
add_action( 'pre_get_posts', function( $query ) {
    if ( ! is_admin() && $query->is_search() ) {
        $query->set( 'cat','13,16' );
    }
});

Das funktioniert für die Kategorien mit den IDs 13 und 16, sofern es diese auch gibt.

Es ist aber auch Folgendes zu machen, da ist direkt im Code zu sehen, welche Kategorien das sind. Bspw ‚ewp‘ und ‚mac‘:

functions.php

/* Suchergebnisse für Beiträge der Kategorie */
add_action( 'pre_get_posts', function( $query ) {
if ( ! is_admin() && $query->is_search() ) {
$query->set( 'category_name', 'ewp,mac' );
}
});

Merkhilfe

is_admin() prüft ob der Code im Adminbereich ausgeführt wird. Mit dem Ausrufezeichen sagen wir IS NOT is_admin(). && bedeutet AND.

Also heißt es im Grunde: WENN ( IS NICHT is_admin() UND $query->is_search() ) also if ( ! is_admin() && $query->is_search() )

Mit $query->set können wir den globalen Query, hier dann der Suchquery manipulieren. Das sorgt dafür, dass die Suche nur innerhalb der Kategorien ‚ewp‘ und ‚mac‘ stattfindet.

Dadurch das wir das nicht im Adminbereich ausführen, funktioniert die Suche im Adminbereich.

[kevin.p]

Wenn die Suche nur 1 Post zurückgibt

… automatisch an die zurückgesandte Post weiterleiten.

functions.php

/* Die Suche nur 1 Post, weiterleiten */
add_action( 'template_redirect', function() {
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;
}
}
});

Beiträge / Seiten definit von der Suche ausschließen

functions.php

/* Artikel von der Suche ausschließen */
add_action( 'pre_get_posts', function( $query ) {
if ( $query->is_main_query() && is_search() ) {
$exclude_ids = array( 248, 396 ); // Array of the ID's to exclude
$query->set( 'post__not_in', $exclude_ids );
}
});

Der Suche Ausschluss sind hier die Artikel der ID 248 und 396.

[codesnippets]

Das im Folgenden Tab-Menü ist dem Erfahrungswert hier der Zeit des Anfangs mit WP. – und ist nicht mehr ganz up to date.

[tabby title=“Relevanssi“]

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.

[tabby title=“Search Relevance“]

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

Bemerkung Allgemein:

Nebenher erfolgen dem Widget ‚Neue Beiträge‘ in den Suchergebnissen ebenso ‚Relevante neue Beiträge‘.

[tabby title=“Ajax
Search Widget“]

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.
[codesnippets]
!! 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-dTH: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;
}

[tabbyending]

↑ Tabmenü