Montag, 23. Dezember 2019
"Suche" auf statischer Seite
Gestern hatte ich (in meinen Augen) eine ziemlich gute Idee: Wenn ich die "Suche" aus dem Banner entfernen und in einen eigenen Menüpunkt einbinden könnte, dann würde die mobile Ansicht des Banners um einiges besser aussehen.
Das Entfernen der "Suche" aus dem Banner ist einfach. Dafür muss ich nur den entsprechenden Code aus der index.tpl löschen.
Schwieriger wird es, die "Suche" in einer statischen Seite unterzubringen. Als erstes erstellte ich mal eine leere statische Seite mit dem Namen Suche und der URL /pages/suche.html. Dann begann das üben und pröbeln...
Die jeweilige Schritte habe ich auf der statischen Seite dokumentiert. Bis jetzt konnte ich noch kein brauchbares Resultat erzielen. Das braucht wohl noch ein paar Stunden...
Einen sehr guten Hinweis/Tipp erhielt ich in diesem Kommentar. Das war super! ? Die Suche ist jetzt im entsprechenden Menü. Nun muss ich nur noch herausfinden, wie ich das Wort (label) "Suche" davor wegkriege und das Suchfeld in der Breite dynamisch hinkriege.
Trackbacks
Trackback-URL für diesen EintragDieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2600-Suche-auf-statischer-Seite.html«
-
| Weiter: "Paragraph"
Solange ich nur einen Absatz schreibe, fügt der Editor keine <p>-Tags an und dadurch wird der Abstand oben zum Titel und unten zu der Fusszeile kleiner als mit <p>-Tags. Sobald ich "Return" betätige, für einen neuen Absatz, werden <p> […]
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Beat am :
Ian Styx am :
Grundsätzlich ist quicksearch ja ein Seitenleisten Plugin und wurde "früher" auch grundsätzlich dort angezeigt. Da neuere Templates das dann oft in die Navigation verlegten, wurde es dort einfachst und kurzerhand deaktiviert. Siehe sidebar.tpl deines Themes.
Du müsstest also nur das "$item.class != "serendipity_plugin_quicksearch" AND " Teil wegnehmen, damit sie wieder angezeigt wird.
Beat am :
Beat am :
Probleme mit der Suche
Ich weiss, dass es mindestens 5 Blogeinträge gibt, in denen ich Mountainbiketouren mit *Peter* auf den Berg *Hörnli* unternommen habe. Ich suche also alle Beiträge, in denen die Worte *Hörnli* und *Peter* gemeinsam vorkommen. Meine Versuche:
was mache ich falsch?
Ian Styx am :
Ich kann mir kaum vorstellen dass es zwei unterschiedliche Suchpatterns beherrscht und würde daher nur matchen, wenn "Hörnli Peter" tatsächlich zwei aufeinanderfolgende Worte wären.
Das du also meinst, dass das auf bbbeat ginge, ist wohl eher auf eine Missinterpretation zurückzuführen. Und vielleicht sind die quicksearch Plugins hier und da noch unterschiedlich eingestellt.
Beat am :
Styx Handbuch 3.7 Suche, 3. Abschnitt:
... Hier können Sie Wörter mit einem Anführungszeichen einschließen und ein + oder - vorstellen, um Teilwörter ein- oder auszuschließen. Auch kann das Zeichen * als Platzhalter für beliebige Zeichen verwendet werden.
Meine Eingabe im Suchfeld: *+Hörnli +Peter*. Hier erhalte ich 0 Treffer und im Live-Blog 7 Treffer. Alle anderen Wortkombinationen habe ich hier nur zu Testzwecken ausprobiert und dienen als Info.
Irritierend ist, dass z.B. die Abfrage *+Bikerunde +Pistenende* 4 Treffer anzeigt (auf beiden Blogs). Es macht den Eindruck, als ob es ein Problem mit der Kombination *+* mit Umlaut *ö* in *+Hörnli* gibt. (*Hörnli* = 10 Treffer, *+Hörnli* = 0 Treffer). Suche ich z.B. *+Genua +Peter*, werden auf beiden Blogs 5 Treffer angezeigt.
Ian Styx am :
Hast du einen entries table Fulltext Index ?
entry_idxFULLTEXTNeinNeintitle20 Ja body20 Jaextended20 Ja
Deine Interpretation dieses Satzes entspricht nicht unbedingt dem was da steht.... Mich irritiert inbesondere "Anführungszeichen" und "Teilwörter" im Zusammenhang mit dem Plus/Minus.
Und was sagt dir das hier?
https://bbbeat.ch/search/H%C3%B6rnli/Peter
Suchbegriff(e): Die Suche nach "Hörnli Peter" ergab 125 Treffer:
Bedenken muss man jetzt außerdem, dass durch die utf8mb4 Verkürzung der Index (varchar) Längen die beiden Indizes nicht mehr absolut vergleichbar sind. Denn das alte Serendipity normal utf8 hatte bis zu 64 Zeichen mehr zum durchsuchen, nicht wahr?!
Beat am :
Und was sagt dir das hier?
https://bbbeat.ch/search/H%C3%B6rnli/Peter
Suchbegriff(e): Die Suche nach "Hörnli Peter" ergab 125 Treffer:
Das sagt mir folgendes:
macht netto 125 Treffer (richtig). Also Einträge, in denen entweder das Wort *Hörnli* oder *Peter* vorkommt.
Ian Styx am :
https://www.blog.dokumenzi.ch/search/H%C3%B6rnli/
Suche: Die Suche nach "Hörnli" ergab 10 Treffer:
Wiewiele davon sind identisch mit dem +Hörnli +Peter result auf bbb?
Ian Styx am :
Ups, ich glaube mehrere müssten hier richtig umgehangen werden...(erledigt)Hast du die anderen Sachen auch schon bedacht?
Ian Styx am :
während es bei der genannten Kurzvaiante nur 8 sind. (2. Zeile war falsch von mir kopiert).
Beat am :
Wir können es auch reduzieren auf die Frage weshalb liefert Hörnli 10 Treffer (richtig) und +Hörnli 0 Treffer (falsch)?
Ian Styx am :
Weil + impliziert, dass es zu etwas Gesuchtem hinzugesucht werden soll (IMHO).
Beat am :
Beat am :
3x Beiträge Hörnli ohne Peter
Beat am :
Ich habe mich nocheinmal intensiv mit der Suche beschäftigt und dabei mit der Original-S9Y-Suche verglichen. Die Suche in der Styx-Edition hat ein Problem mit +/- und Umlaute wie ä, ö oder ü.
Beispiel "Zürich" = 280 Treffer "+Zürich" = 0 Treffer (bei S9Y ist die Trefferanzahl identisch). Selbiges trifft natürlich auf das oben genannte Beispiel mit "+Hörnli" zu.
Sobald nach einem Wort ohne Umlaut gesucht wird, sind die Treffer mit oder ohne + oder - identisch (und richtig).
Ian Styx am :
Es gibt sogar noch mehr "Suchoperatoren". Ich musste es neulich gerade mal raussuchen und schrieb es jemanden.
The MySQL Fulltext search, because it relies on Indizes hold in cache. (A real search would too easily bring down a server system quickly.)
Full-text Searches Using the Boolean Mode
The boolean mode is perhaps one of the most interesting things that MySQL full-text search has to offer. This mode has many caveats unique to it because it allows you to expand the search capabilities using boolean operators. When the boolean mode is in use, certain characters can have special meaning at the beginning or end of words. For example:
“+” means AND;
“-” means NOT;
The “(“ and “)” operators allows to create subexpressions;
“<” and “>” operators change the rank of the search value lower or higher;
“~” lowers the value’s contribution to the search results;
Double quotes (“”) only match literal values;
“*” is a wildcard operator (refer to the explanation above).
These operators allow you to expand the functionality of the search: for example, if you would want to retrieve all rows that contain the word “Demo”, but not “Demo2”, you could use a query like so:
SELECT * FROM table WHERE MATCH(column) AGAINST (“+Demo -Demo2” IN BOOLEAN MODE);
You can also use double quotes together with single quotes like so:
SELECT * FROM table WHERE MATCH(column) AGAINST(‘“search string”’ IN BOOLEAN MODE);
Full-Text Search Gotchas are certain stopwords not being allowed to use.
So after having said this. Did you ever tried that?
Ian Styx am :
Sind wir damit eigentlich je damit fertig geworden?
Ich habe gerade (noch) eine Variante gefunden, die "besser" (und überhaupt) als jene über das Suchfeld funktioniert.
https://www.blog.dokumenzi.ch/search/H%C3%B6rnli%20(%22+Peter%22)/
= abgezeigt:
/search/Hörnli ("+Peter")/
Ich würde fast schätzen, dass dies das richtige Ergebnis anzeigt, d.h. alle Hörnli die auch Peter enthalten (hier 8 im LIVE 9).
Ian Styx am :
Diese Hörnli und Peter Geschichte hat mich jetzt ganz schön lange umhergetrieben. Aber HEUREKA ich habe es nun endlich gefunden, warum +29er -Peter richtig arbeitete (siehe Resultate von 29er Suche), aber eben nicht +Hörnli -Peter.
Schönes Neues Jahr! 🎇
Falls du bis zu einem nächsten realen Styx Update selber damit herumspielen möchtest musst du dir im Styx tree die allerletzte include/function_entries.inc im RAW modus angeln (und für das Backend die include/admin/entries.inc). Aber, nicht so sehr über die zugehörigen Commits, da ich hier und da noch etwas and den zugehörigen Notes herumgedoktert habe.
Beat am :
Auf den Kommentar vom 23.12.2022 habe ich nicht reagiert, weil mir die Suchvariante zu kryptisch war 😏.
Habe vorhin hier und im Live-Blog die zwei neuen Files aufgespielt und bin begeistert. YES! Nun stimmen die Suchergebnisse! Klasse!
Beim Rumspielen ist mir aufgefallen, dass das searchhighlight-Plugin Mühe bekundet, wenn man Doppel-Suchen wie z.B. "+Hörnli + Peter" durchführt. Peter wird gehighlightet, Hörnli nicht. Wenn ich "+Zürich +Matthias" suche, wird Matthias gehighlightet, Zürich jedoch nicht. Es scheint irgendwie mit Umlauten zusammenzuhängen, denn wenn ich "+Peter +Matthias" suche, werden beide Namen gehighlightet. (Alles jeweils im Live-Blog durchgeführt).
Interessant ist, wenn ich nur "Zürich" oder "Hörnli" suche, wird das Wort richtig gehighlightet. Hmmm... es scheint am Operator zu liegen. Bei "+Zürich" wird das Wort nicht gehighlightet.
Es ist also irgendwie die Kombination aus Operator und Umlaut. Denn die Suche "+Peter +Matthias +Remi" highlightet alle Namen korrekt. Bei der Suche nach "+Peter +Matthias +Jürg" wir Jürg nicht gehighlightet.
Ian Styx am :
Also diese /search/... Kurzform ist ja eigentlich nur die mode_rewrite Entsprechung der langen GET queries wie
und wird zb auch bei den Seite 2 +/- Seiten als URI benutzt. Die URL_encodeten %5D Zeichen (etc) sind nur die umgewandelten Sonderzeichen [, ], ü, ä, ö, + für Leerzeichen, das MYSQL FULLTEXT Sonderzeichen + als %2B usw, die in der ursprünglichen Auslegung von URIs immer encoded werden mussten damit sie am anderen Ende richtig ausgelesen werden konnten und nicht etwa unterwegs verloren gingen. Heute helfen die Browser mit (-meine ich-) und so ist das nicht mehr wirklich immer vonnöten.
Diese Geschichte mit den searchhighlight Auszeichnungen ist verzwickt.... zB auch klappte es gar nicht auf result Seiten die durch das Seitenpaging weitergegeben wurden, wenn es multi-byte Zeichen darin gab.
Ich meine jetzt aber eine Lösung dafür gefunden zu haben (die komischerweise aber gar nicht direkt irgendwelche Besonderheiten für multi-byte Chars vornimmt und trotzdem das Problem löst) und werde das Update des Plugins gleich mal commiten.
Beat am :
Perfetto! 👍
Ian Styx am :
Vedo che durante le vacanze di Natale hai fatto pratica con l'italiano. Bravo Beato! 😄
Beat am :
Si, certo! 😁
Kannst Du Italienisch oder war das Google Translate?
Ian Styx am :
😶 ... ☕🥛💦 o un bel latte macciato ... 😄