Relevanssi – A Better Search

(Aufzeichnung intern) Bemerkung: Betreffs „Suche" mit Relevanssi waren 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:

Die folgenden Informationen sind als interne Aufzeichnung zu betrachten und geben wieder, wie es damals abgelaufen ist.

• 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 war "Suchbegriffe in aufgerufenen Dokumenten hervorheben" kein Häkchen zu 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.

• WP Ajax Search Widget: Dies hat nichts mit dem Plug-in 'Relevanssi Live Ajax Suche' zu tun.

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

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.

Snippets functions.php, CSS und JavaScript: das Child-Theme. Spezifisch, CSS+JS: das Plug-in Header Footer Code Manager. Zum Workflow und Browser Cache siehe das Plug-in reBusted!

!! 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öscht¹⁾ sein, weil ansonsten leitet die Schaltfläche²⁾ 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;
}