„Verwirrte“ Suchfunktion?

[mattsches]

Ich hatte mal in einem anderen Thread (Update: hier) angeregt, den Plaintext eines Entries zu extrahieren. Damals ging es um Abstracts, die z.B. Facebook, Twitter oder die Google-Suchergebnisse anzeigen könnten.

Damals wollte ich das über einen zusätzlichen Key im $eventData-Array zwischenspeichern, so dass es auch über mehrere Plugins hinweg funktionieren würde. Ich habe dafür auch irgendwo Code rumliegen, müsste ich auch erst wieder suchen.

Eventuell wäre die Suche ein weiterer Use-Case für Plaintext, und man könnte den tatsächlich beim Speichern eines Entries extrahieren und in die DB speichern. Das kann ja über ein Plugin realisiert werden, nur weiß ich nicht, ob wir die Suche auch über das Plugin umleiten können.

[Timbalu]

Das verstehe ich nicht ganz in diesem Zusammenhang. Hier würde es ja eventuell nur darum gehen, bei zwei bestimmten Key-Wörtern (Serendipity/S9y) die Query bei Mustern wie class/id und mdb nicht anschlagen zu lassen. Davon jedes Markup von vornherein auszusperren halte ich nichts, denn es gäbe sicher Umstände, wie links etc, die man doch gerne in der Suche enthalten haben würde. Es müsste, wenn man sich überhaupt daran setzt, höchst einfach und unaufwendig sein. [ä's sind bäh!]

[garvinhicking]

Hi!

Von der Ausschlussmethodik s9y/serendipity halte ich nichts, so verhindern wir ja auch dass unser keyword in jedem s9y blog gefunden würde. Zudem, wo hört man hier auf bzw müsste weiter machen? Auch div, class, style, article, section, script etc ausblenden? Nee, ich glaube das führt zu nix.

Der Ansatz eine Plaintextversion mit strip_tags herzustellen und die Suche umzuleiten klingt da am vielversprechendsten, das ist aber schon ein schmerzhafter Aufwand für eine Funktionalität die jetzt vielleicht nicht so total megarelevant ist. Letztlich hat man ja lieber zu viele SUchergebnisse als zu wenig.

Grüße,
Garvin

[Timbalu]

Stimmt! So gesehen ist bei if (strtolower($term) == 'serendipity' || strtolower($term) == 's9y*') eine gestrippte Version besser und einfacher. Leider würde strip_tags() aber keine <!-- S9ymdb:55 --> strippen, oder?

[garvinhicking]

Hi!

Doch, das ist ja ein HTML-Tag:

Code: Select all

garvin:templates garvin$ cat t.php
<?php
$string = 'bla davor <!-- s9ymdb:55 --> bla danach' . "\n";
echo strip_tags($string);

garvin:templates garvin$ php t.php
bla davor  bla danach

Grüße,
Garvin

[Timbalu]

Tatsächlich! Hätte ich so auf den ersten Blick nicht gedacht...
Allerdings kann man das ja erst anwenden, wenn die Query bereits gelaufen ist. Dann müsste im gestrippten Array noch einmal neu gesucht werden und alle Keys deren Values nun nicht mehr matchen aus dem Original Array herausgerechnet werden..., wenn ich das richtig sehe. Viel (zuviel) Aufwand, IMHO.
Da wäre es im Falle des Falles einfacher, in der "Sie haben gesucht ..." Konstante eine kleine Notiz unterzubringen, dass es auch versteckte Vorkommen des Suchstrings im Quelltext gibt.

[garvinhicking]

Hi!

Ja, daher war mattsches idee ja eine eigene datenbankspalte zu erstellen wo der plaintext abgelegt wird, auf den in der query direkt gematcht wird...

Grüße,
Garvin

[Timbalu]

Verstehe.
Trotzdem nicht so gut, meine ich, da ich die Suche gerne auch auf markup wie links anschlagen lassen würde.

[mattsches]

Turns out I already committed something similar to the Markdown plugin: see serendipity_event_markdown.php l.128.

Obviously, the plaintext is not (yet) saved to the DB but generated on the fly from the Markdown code; but it's already being evaluated in the Metadesc plugin, see serendipity_event_metadesc.php l.175.

An improved and expanded version of this method could be moved to a proper plugin (or even the core), where the plain text would be saved to the DB.

Edit: Oh, sorry, wir sind ja hier im deutschsprachigen Forenbereich

[Timbalu]

@mattsches und @garvinhicking

Sind wir da eigentlich schon weiter und ist das eventuell für die 2.0 schon umgesetzt? Wollten wir das (wirklich)?

[garvinhicking]

Keine Ahnung, gibt gerade dringendere Probleme