Interne Suche

grindbatzn · 16.12.2016 15:06:08

Ich betreue jetzt keine Site mit _wirklich_ vielen unterseiten.
Auf beesign.com hab ich beim Suchbegriff "der" (kommt praktisch auf jeder Seite vor) ca 180 Ergebnisse. Die Site liegt auf einem älteren Server, die Suchzeit ist praktisch null.

Ja, es gab schon mal Websites, wo die Suche nicht mehr fertig wurde, aber die Server werden ja auch immer schneller, mit immer mehr Speicher.

webbird · 16.12.2016 15:06:30

Zu den DropletsExtensions fällt mir noch ein: Das Modul müßte eigentlich nach wie vor funktionieren.

http://www.phpmanufaktur.info/de/addons … ension.php

evaki · 17.12.2016 20:22:32

Wer Sphider unter php5.x ausprobieren möchte, dem empfehle ich Sphider-plus v2.9! zu testen.
Hab' nun eine anscheinend funktionierende Testinstallation unter php5.4 gesehen.
Eine kleine Korrektur "InnoDB statt MyISAM" hatte man vor der Installation, aus welchem Grund auch immer, vorgenommen. Vor dem Einsatz unter php7 wären 'ne Menge DB-Aufrufe auf mysqli oder PDO zu ändern, sonst geht NIX. Ist also nur sinnvoll bei weiterer Verwendung.
MfG. Evaki

Beitrag geändert von evaki (18.12.2016 04:49:17)

stefanek

norhei · 17.12.2016 20:39:04

Habe mir mal die DropletsExtenseions grade ein wenig Angeschaut

Nichts von dem, was ein Droplet berechnet, bei einer Datenbank abfragt und anzeigt wird von der WebsiteBaker oder LEPTON CMS Suchfunktion berücksichtigt - Droplets werden vollständig und sehr konsequent ignoriert.
Droplets haben keinen Einfluss auf den Seitentitel sowie auf die im Dateiheader enthaltene Kurzbeschreibung ( description ) und die aufgelisteten Schlüsselwörter ( keywords ), selbst dann nicht, wenn Sie den Inhalt einer Seite vollständig bestimmen.
Droplets können im Unterschied zu Seitenmodulen Cascading Stylesheets (CSS) nicht automatisch laden, der verantwortliche Webmaster muss den erforderlichen CSS Code von Hand im Stylesheet der Website einbinden.

Punkt 2 und 3 sind mit der neuen Class Insert(I) eigentlich schon gedeckelt
Machen also nicht unbedingt mehr viel Sinn. bei Punkt 1 gehe ich grade noch den lösungsweg nach.

stefanek

norhei · 17.12.2016 21:21:30

Zu 1.
Ui Ui ... man markt deutlich, das viele von Ralfs Module mitunter darunter litten, das die Coreentwickler stur dicht gemacht haben.

Also die Suche wird über eine Versteckte FrontendSeite in die Core Suche integriert.
Das Droplet muss sich erst einen Interface Datei includieren.
Dann registriert es sich bei jedem Aufruf mit seiner aktuellen Page ID dem Modulnamen des Moduls das dieses Droplet benutzt mithilfe einer Registrierfunktion
Bei der Suche wird dann die Versteckte Seite durchsucht.
Dies hat eine Liste/Index der Seiten und der Droplets die sich dort registriert haben.
Sie ruft nun in den Genutzen Modulen eine hoffentlich vorhandene droplet.extension.php auf.
Diese gibt genauso wie die search.php die relevanten Inhalte zurück.
Die search.php der versteckten Seite gibt dann das alles gesammelt an die Suchfunktion zurück.

Ich hoffe , ich habe es richtig wiedergegeben?

Ich sehe da folgende Probleme :

Es muss ziemlich fiel Zeugs in den Droplets Code (Nicht einsteiger Freundlich )
Funktioniert nur wenn das Droplet ein Modul aufruft und nicht wenn es die Inhalte Selber generiert .
Das Modul muss extra dafür gemacht sein und eine droplet.extension.php haben.
Seite die nicht aufgerufen wurden , sind nicht registriert.
Ich konnte nichts finden um alte Einträge wieder aus der Registrierung zu löschen (z.B. wenn Seite gelöscht wird )

Sagen wir mal so , alles in allem ist das mit der Suche in Droplets mit so einigen Schwierigkeiten versehen.

Seitentitel , Metas , CSS , JS und auch HTML ins Template zu packen geht um längen einfacher mit Insert (1 Zeiler)
Was einfach daran liegt das ich das im Core einfach nach den Droplets einhängen konnte und nicht um den Core drumrum arbeiten musste. Ralf hatte das damals viel schwerer.

norhei · 18.12.2016 13:46:53

Nur ein paar Merknotitzen.

Also meiner Meinung nach sollte es auf jeden Fall einfacher sein eine halbwegs funktionierende Suche für Module zu erstellen.
Eine Fehlerfreie Anzeige der Suchergebnisse bei der keine Boxen rumspinnen wäre auch nicht schlecht.
Schön wäre auch sie Suche ans Template anpassen zu können.
Anzeige der Suchergebnisse an beliebiger Stelle würde mir gefallen.
Würde mir Wünschen nicht mehr auf den Search Ordner angewiesen zu sein.
Mehrsprachigkeit wäre noch recht wichtig oder ?

Der Ablauf nach Thorn ist ja:

Der Benutzer stellt eine Suchanfrage.
WB lädt die von den Modulen bereitgestellte Funktionen, z.B. auch moduleX_search().
WB ermittelt bei welchen Abschnitten (section_ids) das Modul moduleX verwendet wird.
WB ruft die Funktion moduleX_search() auf, mit der nächsten section_id als Parameter.
Die Funktion moduleX_search() sammelt alle Daten die zu diesem Abschnitt gehören und durchsucht werden sollen, und übergibt sie an die eigentliche Suchfunktion, zusammen mit Angaben zur Herkunft dieser Daten (Seitentitel, Beschreibung, Link zu diesem Abschnitt, ggf. Link zu einem Thumbnail, ...).
Die Suchfunktion ermittelt mögliche Übereinstimmungen mit den Suchbegriffen, und erzeugt ggf. den Link für die Ergebnisliste, inklusive Textauszügen und Thumbnail-Darstellung.
Zurück zu Punkt 4 bis alle Abschnitte dieses Modules abgearbeitet sind. Wiederholung für andere Module. Nach Abarbeitung aller Module weiter zu Punkt 8.
Für Seiten, die noch nicht in der Ergebnisliste auftauchen werden auch Seitentitel, Menutitel, Beschreibung und Schlüsselwörter durchsucht.
Ausgabe der Ergebnisliste.
Für Module ohne eigene _search()-Funktion wird stattdessen die alte Suchfunktion benutzt.

stefanek · 18.12.2016 14:15:48

Wie könnte man es jetzt hinbekommen, dass auch Droplets und Snippets die Inhalte ausgeben, so präpariert werden, dass deren Ausgabe irgendwo für die Suche festgehalten wird. Inklusive Position der Ausgabe (auf welcher seite? section? template? global? relevant?).
Den Inhalt der Ausgabe irgendwie abzufangen sollte nicht all zu schwierig sein, position und relevant allerdings schon.
Denn der Inhalt der Augabe -- vor allem bei Droplets -- wird ja durch den output-buffer gejagt, bevor er ausgegeben wird. Da könnte man zwischen schalten und die Ausgabe vorher irgendwo für die Suche cachen.

Christian

norhei · 18.12.2016 15:04:49

Droplets werden ja an eine Funktion gegeben , die die dann ausführt und code zurückgibt .. ist sozusagen schon alles da.

Wobei sich die Frage stellt ob dann ein teilweise externer Spider tatsächlich nicht besser ist. Der gesammt Aufwand alles von Innen zu holen ist schon beträchtlich.

stefanek · 18.12.2016 15:25:09

Rein theoretisch könnte man einen Cache aller Seiten anlegen, indem man sie von Außen einliest. Etwa wie mit CURL, nur gibt es bessere Methoden dafür.
Die interne Suche würde dann dieses durchsuchen.
Jedes mal, wenn man an irgendeiner Seite Änderungen vorgenommen hat, würde man das Skript veranlassen, von dieser Seite eine neue Copy zu machen.
Auf Knopfdruck könnte man auch sagen: refresh Search Cache.

Schau Dir die Wirkungsweise von z.B. Snoopy an
https://github.com/endroy/Snoopy

Der holt Dir alles was öffentlich auf Deiner / irgendeiner Seite zugänglich ist, auch wenn CURL und andere Methoden aussetzen.
PHP Requirements sind gering.

Der Aufwand allgemein dürfte gering sein.

Christian

norhei · 18.12.2016 16:48:26

Ich weiss, Snoopy kommt mit PHP Bordmitteln aus , CURL ist nicht immer verfügbar.

Bedingung ist, das URL fopen aktiviert ist , sonst wird das generell nichts . So ettliche Hoster von kleinen Spaces haben das deaktiviert.
Was sich als Quelle für die URLs anbietet wäre übrigens die Google Sitemap. Die Haben wir ja schon.

Deswegen sagte ich irgendwann hier im Verlauf schon , das Modular schön wäre . Basissuche so lassen(leicht pimpen) , und wenn der Webspace das hergibt kann man was besseres einfach einklinken.

Am besten wäre es in Modulen wie Topics , oder Foldergallery statt Pseudoseiten wirklich echte Seiten zu nutzen. Aber das ist eher Wunschkonzert für die Zukunft.

grindbatzn · 19.12.2016 11:13:27

Die Foldergallery und rFG nutzen Parameter.
"Pseudoseiten" hat Topics, Bakery, OneForAll und News+Forks davon. (was mir spontan einfällt)

MIt den Pseudoseiten wirst du wenig Probleme haben, deren Zahl ist immer endlich.

Schwieriger sind die Seiten mit Parametern, die können unendlich viel werden.
Alles was zb mit Kalendern und Datum zu tun hat, geht in alle Ewigkeit weiter (und in die Vergangenheit). Dazu noch Wochenansicht, Monatansicht, Filter...
Und noch "Verdreher": ?a=1&b=2&c=3 vs ?b=2&c=3a=1....

Wenn du das nicht ausfilterst, hast du am Ende 30000 Suchergebnisse. Um das auszufiltern, müsstest du aber die Parameter sortieren. Google machte das mit bis zu 7 Parametern, bis man irgendwann das Duplicate Content Problem generell in den Griff bekam.

Du kannst auch sagen: Maximal 1 Parameter, dann hast du bei Kalendermodulen "nur mehr" Max-Integer / 3600 / 24 wink

Kleiner Nachtrag:
Google hat ja das PageRank-Verfahren, das - immer noch! - auch dazu dient, den Index sauber zu halten:

Bei Kalendermodulen hast du in der Regel einen oder mehrere Links zum vorigen/nächsten Tag. Und von dort wieder weiter. Das selbe mit Woche, Monat, Detail....
Bei der Berechnung des PageRank (der innerhalb von Websites in einer verkürzten Form angewendet wird) gibt es den Dämpfungsfaktor (ca 0.85)
Dadurch werden Seiten, die immer nur in einer Linie über andere erreichbar sind, stark abgewertet und irgendwann gar nicht mehr indexiert, wodurch der Kreislauf unterbrochen wird. Sonst würde der Index überlaufen.

Das PageRank-Verfahren ist öffentlich bekannt, ich habe es seinerzeit in WebEye implementiert. Bis ca 1000 Seiten, wenn du vorher das Menü rausfilterst, schaffst du das noch unter einer Minute auf einem Server.

Beitrag geändert von grindbatzn (19.12.2016 11:46:00)

webbird · 19.12.2016 14:46:20

Gehen wir mal einen Schritt zurück.

Punkt 1: Die Suche wird IMMER irgendwie eingeschränkt sein.

Inhalte, die sich täglich oder gar stündlich ändern, können nicht vernünftig erfaßt werden. Ist eben so. Braucht man also auch nicht viel Hirnschmalz für verwenden.

Punkt 2: Droplets sind ein Problem.

Okay, kann man nicht widersprechen. Ich persönlich würde mich zwar auf den Standpunkt stellen, daß komplexe/umfangreiche Dinge nicht in ein Droplet gehören (dafür gibt's Page-Module), aber das ist eben eine persönliche Meinung.

Punkt 3: Das ist aber eigentlich egal.

Nämlich dann, wenn man eine brauchbare API zur Verfügung stellt, die einfach zu benutzen ist. Die kann sowohl jede Art von Modul, als auch jede Art von Droplet verwenden. Und selbst ein Template kann sie benutzen!

Im BC-Forum hab ich dazu in etwa geschrieben, daß für das Erzeugen des Index (beim Speichern der Seite) zwei Methoden gebraucht werden, denen ich als Parameter eins von beidem gebe:

* Volltext / String
* Datenbanktabelle / -query

Plus natürlich Metadaten wie SeitenID, SectionID, Position auf der Seite etc.

Was bleibt und bei diesem Verfahren einfach nicht lösbar ist, ist, daß der Modul-/Droplet-/Templateautor wissen muß, was sinnvoll zu indizieren ist. Es stellt sich z.B. die Frage, ob ich AnyTopics indizieren muß, da es ja nur Daten von Topics aufbereitet. Warum soll ich den BeSUCHer da nicht gleich auf die Topics-Seite leiten? Manchmal muß so ein Mensch auch einfach mal selber nachdenken. devil

Beitrag geändert von webbird (19.12.2016 14:47:24)

webbird · 19.12.2016 20:02:56

Beispielhaft:

[== PHP ==]
        $indexer = new Indexer();
        $indexer->indextable(1,'mod_wysiwyg','text');

public static function indextable($section_id, $table, $fields=array('*'))

Letztlich wird aus den Daten lediglich ein Statement wie

SELECT `text` FROM `<prefix>mod_wysiwyg` WHERE `section_id`=1

generiert, das Ergebnis ausgelesen, in Tokens (=Worte) gewandelt, und die Worte in eine Index-Tabelle eingetragen.

Das sollte doch für einen Modulautor nicht sooo schwierig zu verwenden sein, oder?

Man kann das auch noch weiter automatisieren, z.B. indem man die Tabelle mit SHOW COLUMNS analysiert und Spalten vom Typ *text und varchar indiziert. Dann müßte das Modul nur noch z.B. in der info.php angeben, welcher seiner Tabellen für den Index berücksichtigt werden müssen.

stefanek

stefanek · 19.12.2016 21:02:25

webbird schrieb:

Was bleibt und bei diesem Verfahren einfach nicht lösbar ist, ist, daß der Modul-/Droplet-/Templateautor wissen muß, was sinnvoll zu indizieren ist. Es stellt sich z.B. die Frage, ob ich AnyTopics indizieren muß, da es ja nur Daten von Topics aufbereitet. Warum soll ich den BeSUCHer da nicht gleich auf die Topics-Seite leiten? Manchmal muß so ein Mensch auch einfach mal selber nachdenken.

Es könnte ein folgendes Szenario geben:
ich verwende das Modul "itemz" mit dem ich auf einer versteckten Seite Inhalte einpflege.
Die ist versteckt.
Um die darin enthaltenen Daten den Besuchern zu veröffentlichen, verwende ich ein Droplet bzw. eine Funktion (gutes altes Snippet).

Die Inhalte sind keine verlinkungen zu einer festen physischen Seite wie im Falle von News/Topics... sondern es sind schon die Inhalte.
Nichts davon landet je wirklich im Suchindex -- nehm ich an, oder werden Inhalte von versteckten Seiten indiziert? (schon möglich?)
Aber nehmen wir dann als nächstes an, dass ich die ursprüngliche Section aus der ich die Inhalte über eine Funktion/Droplet ziehe ausgeblendet habe (Veröffentlichungszeitraum überschritten).

Es gibt sehr viele unterschiedliche Szenarien die suboptimale Ergenbisse zurückliefern.
Ich sprech sie nur an. Ich mache mir selbst momentan nicht wirklich Kopf darum.

Christian

norhei · 19.12.2016 21:50:30

Inhalte, die sich täglich oder gar stündlich ändern, können nicht vernünftig erfaßt werden. Ist eben so. Braucht man also auch nicht viel Hirnschmalz für verwenden.

Lustigerweise macht die jetzige Suche das, es wird immer der aktuelllste Seitenzustand gegeben.

Wegen dem Indexer

 $indexer = new Indexer();
 $indexer->indextable(1,'mod_wysiwyg','text');

Könnte man auch einfach in die info.php schreiben

$module_indextable= array ('mod_wysiwyg2' => "text");

Nochwas zur jetzigen Search Funktion. Die gibt z.B. einem Kalendermodul die angenehme Möglichkeit einfach nur Aktive Termine an die Suche weiterzugeben, was auch nicht allzu schlecht ist. Und diese sind obendrein auch noch stets aktuell.

stefanek

stefanek · 19.12.2016 21:58:35

Gute Info.

Wer hat die damals geschrieben die Suchfunktion?
War das nicht Thomas (Thorn)?
Er hatte schon geniale Einfälle, auch wenn das alles nicht OOP sondern prozedural geschrieben wurde.
Ich habe mal mit ihm darüber kommuniziert, warum er so reluctant ist OOP zu schreiben. Er meinte etwas in der Art, dass viele Leute (er meinte nicht alle) die mit OOP arbeiten die Grundlagen von PHP nicht verstehen.

Dennoch, es war gut über 5 Jahre her und vielleicht könnte man die Suche so abändern, dass tatsächlich weniger Angaben vom Modulentwickler abverlangt werden?

Das obige Objekt und die Klasse würde ich aber nicht platt indexer nennen, schon eher SearchIndexer, damit es nicht viel Erklärung braucht, was der "idexer" macht. Ich bin dafür das Funktionsnamen so kurz wie möglich aber so lang wie nötig sind; hauptsache deren Namen machen Sinn.
;-)

Schönen Gruß
Christian

norhei · 19.12.2016 22:57:41

Vermutlich möchte webbird die inhalte auch indexieren und ablegen, statt jedes mal neu zu schauen. Vor Allem klang das so das jede Seite gleich wenn sie gespeichert wird mit in den Index soll.

stefanek · 19.12.2016 23:09:11

Gut,
Brainstorming ist gut.

florian · 20.12.2016 08:51:48

Nicht-zielführende Haarspaltereien entfernt. Bitte konstruktiv bleiben.

stefanek

webbird · 20.12.2016 12:36:01

norhei schrieb:

Vermutlich möchte webbird die inhalte auch indexieren und ablegen, statt jedes mal neu zu schauen. Vor Allem klang das so das jede Seite gleich wenn sie gespeichert wird mit in den Index soll.

Korrekt.

Ich setze das jetzt mal testweise für BC1 um. Ich mag nicht so viel theoretisieren, ich muß "anfassen". big_smile Dann merkt man nämlich auch viel schneller, ob man sich vergaloppiert. cool Das fängt nämlich schon bei eigentlich total simpel erscheinenden Punkten an: Worterkennung. str_word_count will bei mir um's Verrecken nicht "don't" als einzelnes Wort erkennen, obwohl es das laut Doku sollte. Liegt vermutlich am UTF-8. Und dann gibt's Sprachen, da gibt's gar keine Leerzeichen zwischen einzelnen Worten... Gut, bei der Zielgruppe für BC sollte das kein Problem sein, aber nichtsdestotrotz sind das alles Stolpersteine, die man bedenken muß.

florian

webbird · 20.12.2016 18:49:47

Mein bisheriges Ergebnis:

Indexerstellung

* Es existieren diverse Problematiken mit Umlauten, Sonderzeichen, allgemein mit UTF-8 (str_word_count() kann damit nicht umgehen). Daher habe ich eine auf preg_split() basierende Funktion eingebaut. Die ist langsamer als str_word_count(), dafür kann sie mit HTML-Entities und UTF-8 umgehen.
* Der Indexer befüllt derzeit zwei Tabellen, 'words' und 'index'. Erstere beinhaltet alle gefundenen Worte, letztere die SectionID, die WordID und die Position des Wortes innerhalb des Gesamtstrings.
* Ich habe Stopwords für Englisch, Deutsch und Niederländisch, die nicht in der Tabelle "words" gespeichert werden. (Sowas wie "und", "oder", "uns", etc.)

Suche

* Der Searcher durchsucht den Index, sondert Seiten aus, die der Benutzer nicht sehen darf, sowie Sektionen, die aufgrund des Publikationsdatums aktuell nicht sichtbar sind, und zeigt das Ergebnis an.
* Das Suchergebnis wird derzeit nach Anzahl der Vorkommen im Gesamtstring sortiert; je öfter, desto weiter oben.

Das SQL-Statement ist recht komplex:

[== Undefiniert ==]
SELECT count(`t3`.`section_id`) as `occurences`, `t3`.`section_id`, `t3`.`modified_when`, `t3`.`page_id`, `t4`.`menu_title`, `t5`.`display_name`
FROM `cat_ri_word` AS `t1`
JOIN `cat_ri_index` AS `t2`
ON `t1`.`word_id`=`t2`.`word_id`
JOIN `cat_sections` AS `t3`
ON `t2`.`section_id`=`t3`.`section_id`
JOIN `cat_pages` AS `t4`
ON `t3`.`page_id`=`t4`.`page_id`
LEFT OUTER JOIN `cat_users` AS `t5`
ON `t3`.`modified_by`=`t5`.`user_id`
WHERE `t1`.`string` LIKE "deutsch"
GROUP BY `t2`.`section_id`

Offen

Jede Menge, daher nur beispielhaft:

* Inhalte von Templates
* Indexer derzeit nur Tabellenbasiert (kein Parser)
* Gewichtung nach Position des Wortes innerhalb der Seite, der Sektion, nach Vorkommen in Überschrift(en) etc.
* Keine und/oder-Verknüpfungen, keine Phrasensuche

Lessons learned

* Das Programmiererleben könnte so einfach sein, wenn PHP tatsächlich überall UTF-8 könnte...
* Ich hasse Umlaute!
* Ich hasse Sonderzeichen!
* Ich liebe die vielen Hilfsfunktionen, die BC hat... devil

webbird · 20.12.2016 18:52:07

Ausschnitt aus der words-Tabelle:

attachment.php?item=606&download=1

Ausschnitt aus der index-Tabelle:

attachment.php?item=607&download=1

Darstellung des Suchergebnisses in BC1 (Default FE Template):

attachment.php?item=608&download=1

Beitrag geändert von webbird (20.12.2016 18:54:35)

cwsoft · 20.12.2016 19:30:51

webbird schrieb:

Ich setze das jetzt mal testweise für BC1 um. Ich mag nicht so viel theoretisieren, ich muß "anfassen". Dann merkt man nämlich auch viel schneller, ob man sich vergaloppiert. Das fängt nämlich schon bei eigentlich total simpel erscheinenden Punkten an ...

thumb_up

Ist in der Tat so. Nachdem man sich ein paar grundlegende Gedanken gemacht hat, hilft die Umsetzung eines Prototypens oft die "versteckten" Knackpunkte aufzudecken und evtl. Probleme frühzeitig zu erkennen.

Gruss

stefanek

WBCE CMS Forum

#26 16.12.2016 15:06:08

Re: Interne Suche

#27 16.12.2016 15:06:30

Re: Interne Suche

#28 17.12.2016 20:22:32

Re: Interne Suche

#29 17.12.2016 20:39:04

Re: Interne Suche

#30 17.12.2016 21:21:30

Re: Interne Suche

#31 18.12.2016 13:46:53

Re: Interne Suche

#32 18.12.2016 14:15:48

Re: Interne Suche

#33 18.12.2016 15:04:49

Re: Interne Suche

#34 18.12.2016 15:25:09

Re: Interne Suche

#35 18.12.2016 16:48:26

Re: Interne Suche

#36 19.12.2016 11:13:27

Re: Interne Suche

#37 19.12.2016 14:46:20

Re: Interne Suche

#38 19.12.2016 20:02:56

Re: Interne Suche

#39 19.12.2016 21:02:25

Re: Interne Suche

#40 19.12.2016 21:50:30

Re: Interne Suche

#41 19.12.2016 21:58:35

Re: Interne Suche

#42 19.12.2016 22:57:41

Re: Interne Suche

#43 19.12.2016 23:09:11

Re: Interne Suche

#44 20.12.2016 08:51:48

Re: Interne Suche

#45 20.12.2016 12:36:01

Re: Interne Suche

#46 20.12.2016 18:49:47

Re: Interne Suche

#47 20.12.2016 18:52:07

Re: Interne Suche

#48 20.12.2016 19:30:51

Re: Interne Suche

Fußzeile des Forums