Verbesserung der Suche

Diese Seite enthält die 1:1-Übersetzung der Originalseite, ungeachtet der "unordentlichen" Reihenfolge der Beiträge.

SaintMagoo 28 Dezember 2010, um 15:24: Danke, Peter. Im Moment würden wir es 'hassen', eine Datenbank einführen zu müssen. Einer der Gründe, warum wir PmWiki so lieben, ist, dass wir uns nicht damit herumschlagen müssen.

-Rn :)

Wenn Sie interessiert sind: ich habe einen guten Start in Richtung Ersetzen von .pageinfo durch eine SQLite-Datenbank. Das Problem, das ich dabei bekam, war nur eine Frage der Optimierung. Jede Suche, die ich anstieß, lief besser mit dem einfachen Durchsuchen der Textdatei (.pageindex) im Vergleich zu der indizierten Datenbank... Lassen Sie's mich wissen, wenn Sie an dem Code interessiert sind. Peter Bowers 26. Dezember 2010, um 16:38 Uhr

SaintMagoo 26. Dezember 2010, um 22:44 Uhr: Danke, Peter. Beeindruckend, äußerst beeindruckend :)

Idee für Weihnachten: Wie wäre es mit zwei weiteren Dateien wie .pageinfo. Eine, die indiziert ist: Sie enthält nur die Seitennamen, das kann ein Weg sein, eine Seite zu registrieren, die schon durchsucht wurde. Danach kann .pageinfo2 die Indexnummern der registrierten Seiten in einem sortierten Wortlistenverzeichnis benutzen. Natürlich sortiert und binär durchsucht, imo kann ein solches neues Suchsystem das aktuelle Suchsubsystem ersetzen und hyper-beschleunigen.

Der einzige Nachteil ist hier die relative Geschwindigkeit, in der die Verzeichnisdatei wächst: Einfügen neuer Wörter könnte langsam sein. Dennoch muss das Hauptverzeichnis nicht per se indiziert sein, wenn das Verzeichnis auch indiziert ist. Nur die Verzeichnis-Index-Datei muss sortiert sein. Danach würde das Einfügen einer bloßen Integerzahl + Offset in den Verzeichnis-Index — wenn eine neues Wort eingefügt wird — den Aufbau des Verzeichnissen ordentlich beschleunigen.

Ich erwäge das Biest zu schreiben. Sogar (im schlimmsten Fall) für den Gebrauch von Cron, wenn die mtime (Änderungszeit) einer Seitendatei größer ist als die der Registerdatei, ist das ein Zeichen dafür, dass eine Seite oder drei re-indiziert werden müssten. Sollte spaßig sein.

.02 ends

Versuchen Sie GoogleSearch. Peter Bowers 25. Dezember 2010, um 15:02 Uhr

SaintMagoo 24. Dezember 2010, um 21:30 Uhr: Wir haben gerade 200.000 Seiten in unser Wiki hochgeladen, nicht sehr überraschend, dass die Suche nicht eben sehr gut flutscht. Nach einem kurzen Blick auf .pageinfo konnten wir sehen, dass das eine Liste von Seiten ist mit Schlüsselwörtern. Sind schon Pläne im Gange, die Suche mehr google-like zu machen?

Gibt es in der Zwischenzeit, neben dem Löschen der .pageinfo, noch einen leichten Weg, die Suche abzuschalten? Hab's gefunden - man entfernt es einfach von den "z-forms" in der .tmpl. Man könnte auch $EnablePageIndex = 0; setzen.

Tanks,

-Rn

lordmundi 06. November 2007, um 22:54 Uhr: Um an die Diskussion unten anzuschließen: Ich glaube, ich setze mal einen Link auf ein Beispiel-Such-Ergebnis auf Renatos Site mit integriertem Sphider (der URL führt mittlerweile ins Leere):

• http://www.dicpedia.com.br/dicpedia.php?n=&action=search&q=steve

lordmundi 05. November 2007, um 21:05 Uhr: Wow... Ich finde die Sphider-Integration wirklich gut. Das sieht großartig aus. Mit Blick auf die Sphider-Site sieht das aus, als könnte es ein großartiges Kochbuchrezept für PmWiki werden. Ich wüsste gern, wie Sie oder jemand anders das folgende machen könnte:

• Wie Implementieren Sie Rechte in der Suche? Z. B. listet meine Suche keine Seiten, die zu lesen jemand nicht autorisiert ist. Das wäre sogar wichtiger, da die Suchergebnisse Text aus der Seite präsentieren. Ich vermute, jedes Suchergebnis müsste von einem (:if auth read:) eingeklammert werden oder etwas handlicheres. Machen Sie es so?
  • Ich habe die config.php-Datei bearbeitet, um gewisse Kategorien auszuschließen (mit Zeilen wie $SearchPatterns['default'][] = '!^Site\.!';), wie es in der PmWiki-Dokumentation steht. Auch kann Sphider URLs-alles-was-du-willst-enthaltend vermeiden und das habe ich auch genutzt.
  • lordmundi 06. November 2007, um 10:51 Uhr:Das ist cool. Das lässt einen bestimmte Bereiche ignorieren auf Basis deren Ortes. Aber was ich gern wüsste ist, wie Sie nur die Seiten auflisten, die der aktuell eingeloggte Benutzer lesen darf. Lassen Sie uns z. B. annehmen, PM fügt eine spezielle Seite in das Kochbuch ein, von der er nicht will, dass Benutzer sie lesen. Wenn ein anderer Benutzer sich einloggt und sucht, wie erscheint das Suchergebnis nur dann, wenn er auch autorisiert ist, die Seite zu lesen. Alles was dazu zu tun ist, ist einen Weg zu finden, User-Code um jedes Suchergebnis einzufügen. Wenn es dieses Feature gibt, dann können wir eine Vorlage erzeugen, die jedes Suchergebnis mit einem (:if auth read:) umklammert. Hoffentlich macht das Sinn.
• Beim Durchsuchen der Sphider-Dokumentation habe ich nicht herausgefunden, wie die Software die Site "re-crawled". Wird dafür ein Cron-Job vorgeschlagen oder etwas, dass den Roboter alle Seiten durchsuchen lässt? Oder haben Sie das in Ihr PmWiki-Rezept eingebaut, um nach einer gewissen Auszeit zu Durchsuchen, in etwa wie bei den Benachrichtigungs-E-Mails, die PmWiki nutzt.
  • Ich glaube, jemand könnte einen schnellen Roboter codieren, der Ihre Site nach einigen Stunden/Tagen/Monaten neu durchsucht, aber ich habe das nicht gemacht. Noch nicht, wenigstens bis jetzt, da ein Kollege einen Großteil meine Zeit beansprucht hat und ich mich auf andere Codierungen meiner Site konzentriere. Deshalb müssen Sie zunächst Ihre Site selbst erneut durchsuchen, was jedes Mal, wenn Sie es möchten, nur zwei oder drei Klicks beansprucht.
  • Um es ganz klar zu sagen, ich bin wirklich lahm, wenn ich meinen Wiki-Code behandle. Ich verstehe bis jetzt fast nichts, nur das Nötigste, um es ans Laufen zu kriegen. Ich habe das httpvariablen-Rezept benutzt, so dass ich den Abfragestring aus dem angegebenen URL herauslösen konnte. Wie ich unten angegeben habe (lol), KÖNNTE ich einige weitere Schritte unternommen haben, aber ich kann mich nicht mehr wirklich erinnern, welche. Ich habe das httpvariablen-Rezept, Sphider und ein wenig JavaScript benutzt (damit ich die Ergebnisseite (iframe) verkleinern kann, wenn es wenige Ergebnisse gibt). Ich bin sicher, es gibt Erfahrenere als mich, die diesen Job machen könnten, aber ich will alles dazu beitragen, was ich kann. :)

Alles in Allem sieht es wirklich gut aus. — FG
Danke! Und verzeihen Sie bitte, dass ich ihre Originalnachricht durcheinander gebracht habe, aber ich glaube, so ist es etwas klarer als wenn ich eine neue Nachricht über dieser aufgemacht hätte. Deshalb: meine Nachrichten sind in lila um nicht ALLES durcheinander zu bringen. lol Renato

31.08.07 - Renato - Okay, sechs Monate später, ich glaube ich habe eine Idee. Ich habe seit gestern mit Sphider herum gespielt. Ich konnte das Such-Feature in einer Nacht implementieren (Ich hatte ein paar Schwierigkeiten damit, die Suchergebnisse in das "Hauptfenster" von PmWiki zu bekommen, der meiste PmWiki-Code kommt mir spanisch vor)... Ich habe nur einen kleinen Fehler in dem "meinten Sie ..."-Feature (es verhält sich merkwürdig, wenn ich Großbuchstaben verwende), aber abgesehen davon (oder wenn man das deaktiviert), läuft die Suchmaschine gut. Ich werde heute Abend versuchen, das zu lösen, aber ich kann nichts versprechen. Und ich habe ein ziemliches Durcheinander in dem Code, also muss ich das erst mal alles untersuchen, um herauszufinden, was ich gemacht habe. :P (Jau, ich sollte beginnen, eine Änderungshistorie zu schreiben...)

Oh, wer möchte kann einen Blick darauf werfen auf meiner Site, wenn es ihm nichts ausmacht, Portugiesisch zu lesen. :P Gute Stichwörter sind "guitarra elétrica", "symphony x", "steve howe". Es wird Ihnen eine Idee vermitteln. Wenn Sie den Fehler sehen möchten, suchen Sie nach "Stevee". Ich habe den Code so geändert, dass Alles in Kleinbuchstaben umgewandelt wird. Wenn sich das mit PmWiki verträgt, ist es eine Option. :)

Henning 18. Juli 2007, 12:38 Uhr: Mir kam der Gedanke, dass es doch schön sein könnte, eine Suchmaschine zu haben, die auf Verlangen bestimmte Seiten ausschließt, die ein gewisses Alter überschritten haben (um die Konzentration auf jüngere Inhalte zu lenken). Nur ein Brainstorming ...

• Es könnte auch wertvoll sein auf die auf Lucene basierende PHP-Implementatierung von Zend search zu sehen, auch auf Zend Lucene

Henning 22. Februar 2007, um 10:40 Uhr: Ich wäre auch an einer Lösung für Mehrfachschaltflächen interessiert. Ich habe sie in einem Nicht-Wiki-CMS gesehen und es sah nach einer effizienten Benutzerschnittstelle aus, die ich gern kopieren würde.

07.02.07 - Renato - Die Tipps in diesem Thread (PmWikiUsers:2006-October/034807.html) sind klasse für alle, die nur nach den Seitentiteln suchen wollen. Wäre es möglich, zwei Schaltflächen zu haben (Go/Search, wie z. B. in MediaWiki)? Eine für die Suche nach Titeln und die andere für die Suche nach Stichwörtern im Inhalt?

14.12.06 - (:searchresults:) kann angepasst werden durch Bearbeiten der Seite Site.Search, siehe auch Suche nach Seiten.

05.06.06 Ich kann die Frustration mit PmWikis Suchergebnissen total verstehen..., aber vielleicht ist das Thema jetzt weit genug in den Köpfen, dass es Zeit für mich ist, voran zu gehen und einen gültigen Weg zu implementieren, Suchergebnisse zu extrahieren (und möglicherweise zu gewichten), obwohl es in einigen Aspekten suboptimal ist. Am bemerkenswertesten ist, dass es in Sachen Geschwindigkeit suboptimal ist - jede Aufgabe und jede Option, die wir zum Suchen und zu Seitenlisten hinzufügen, machen dies noch langsamer als es ohnehin schon ist.

Ich meine, ich muss die Gruppe daran erinnern, dass PmWiki keine Suchmaschine ist, dafür nie entworfen wurde und dass ich nicht vorhabe, es zu einer zu machen. Ich bleibe bei meiner Haltung, dass wer auf seiner Site eine schnelle Suche mit relevanten Gewichtungen und Auszügen aus dem Text haben möchte, eine "richtige" Suchmaschine einsetzen sollte, die für solche Aufgaben geschaffen wurde, und diese die Site indizieren lassen sollte. (Bonus: solch eine Maschine kann Sachen suchen und indizieren, die nicht Wikiseiten sind wie Anhänge oder andere statische Seiten auf der Site.)

Ich sollte auch hervorheben, dass jeder Autor eine angepasste Suchseite auf pmwiki.org erstellen kann, es braucht mich nicht dazu. Um z. B. eine Suchseite zu haben, die standardmäßig fmt=#title für ihre Ausgabe annimmt, erstellt man eine Seite die etwa so aussieht:

(:searchbox:)

(:searchresults fmt=#title order=title:)

Siehe z. B. http://www.pmwiki.org/wiki/Test/SearchByTitle . Man benutzt dann die angepasste Seite für die Suche anstelle von PmWikis Standardsuchseite.

Ich kann mal sehen, ob ich eine {$Excerpt}-Seitenvariable sowie eine Order=rank-Option einbauen kann.

Pm

Siehe auch Search für eine dokumentierte angepasste Suchseite.

01.02.06 - Eine Menge Leute fragen weiterhin nach Verbesserungen von PmWikis Suchfähigkeiten. In der Vergangenheit habe ich den Standpunkt vertreten, dass "PmWiki keine Suchmaschine ist", und dass der Gebrauch eines anderen Suchmaschinenpakets (eines, das auf die Durchführung einer Suche optimiert ist) besser ist als eine solche selbst zu machen.

Die pmwiki.org-Site beginnt so stark benutzt zu werden, dass ich möglicherweise dort eine Suchmaschine aufsetzen muss, um die Server-Beanspruchung niedrig zu halten. Hat irgendjemand einen Vorschlag für ein gutes, leicht zu installierendes Suchmaschinenpaket?

Die zwei, die ich detailiert betrachtet habe, schließen die folgenden ein:

Ich habe auch kurz auf mnoGoSearch gesehen, aber aus einigen Gründen glaube ich nicht, dass das gut zu dem passt, was ich möchte.

Irgendwelche Vorschläge?

13.06.05 - PmWikis Suchmaschine scannt den Quelltext direkt, nicht die erzeugte HTML-Seite.

Nichtsdestotrotz habe ich mit einer Idee zum Zwischenspeichern des Inhalts herumgespielt, die es möglich machte, dass die Suchmaschine auch die ausgegebene Version des Textes durchsuchen kann, vielleicht können wir diesen Weg gehen... :-)

15.04.05 - Ich habe immer vertreten, dass PmWiki *keine* Suchmaschine ist und für erweiterte Suche eine Site besser daran ist mit der Integration einer vorhandene Lösung als mit der Wiedererfindung dieses speziellen Rades.

Dennoch gibt es Zeiten, in denen es nützlich ist, Teasers für etwas anzubieten, das nicht "Suche" ist. Die meisten Suchmaschinen haben von PmWikis Strukturen wie Gruppen, Trails oder Kategorien keine Ahnung, dabei wäre es sehr sinnvoll Teaser-Informationen im Zusammenhang mit jenen Strukturen anzubieten.

13.06.04 Aber Ihr Punkt ist gut gewählt. Ich hatte nie vor nach Markup-Sequenzen zu suchen. :-)

 > 
 > Ich mache das hin und wieder, also müssen wir wohl unsere
 > eigene Suchmaschine implementieren.

Nun, ich hatte auch nicht vor, die Suchmaschine ganz zu eliminieren. Ich hatte nur das Gefühl, dass, wenn eine Suchmöglichkeit besteht, dies das Verlangen der meisten Wikibenutzer befriedigt. Meine Zeit und meine Anstrengung ist auf anderen Feldern des Wiki besser eingesetzt und nicht für die Wiedererfindung einer Suchmaschine, die es schon gibt.

(Alter Inhalt, hinzugefügt zu dieser Seite, bevor Pm jemals eine Chance hatte, irgendetwas zu schreiben.)

Nachdem Pm diese leere Seite erzeugt hat, habe ich den Titel schamlos gekapert, um laut nachzudenken und eventuell Ideen in Anderen zu zünden :) Ich habe dies Geschreibsel in PITS-Einträge verlagert.

• Wenn es nicht zentral geschieht, könnten wir vielleicht wenigstens ein Rezept haben, dass die aktuelle Seite von der Suche (und ggf. Seitenlisten) ausschließt.

Ich habe (erfolglos) versucht

   $SearchPatterns['normal'][] = "!\.$Name$!";

einzufügen.

versuchen Sie

   $SearchPatterns['normal'][] = "!^$FullName\$!";

• fügen Sie (davon verschiedene) Formatargumente hinzu, die
  • Sortierung der Suchergebnisse und Seitenlisten hinzufügen (nach Dateidatum oder sogar anderes Definierbares in local/config.php; etwas wie die Felder in PITS, Feld: Wert, ein Feld pro Zeile, irgendwo in der Datei)
    Das ist schon im Designbuch vermerkt — hab's aber noch nicht implementiert. — Pm
  • die Ausgabe des Suchreports am Anfang der Seite unterdrückt, z. B. 'Ergebnis der Suche nach group=GName fmt=simple list=normal :'
    Benutze hierfür (:pagelist:) statt (:searchresults:).
  • die Ausgabe des Suchreports am Ende der Seite unterdrückt, z. B. '12 Treffer auf insgesamt 127 durchsuchten Seiten.'
    Benutze hierfür (:pagelist:) statt (:searchresults:).

-Radu 11 März 2005, um 13:43 Uhr

Radu 14. März 2005, um 23:25 Uhr
Aber (:pagelist:) erlaubt keinen Suchstring ... oder doch? Es ist jedenfalls nicht unter Seitendirektiven dokumentiert.

Pico 27 März 2006, um 15:51 Uhr
Augenscheinlich tut's es. Siehe Seitenlisten wegen weiterer Angaben zu Seitenlisten (und Suchergebnisse). Was Seitendirektiven angeht, das muss bearbeitet werden und ist für die Dokumentation kategorisiert.

Category: PmWiki Design DocumentationToDo

Originalseite auf PmWikiDe.SearchImprovements - Rückverweise
Zuletzt geändert:
PmWikiDe.SearchImprovements am 10.07.2012