Interne Suche

webbird · 14.12.2016 11:25:29

Ich konnte mich nicht so richtig entscheiden, welches Forum das Richtige ist, also bitte ggfs. verschieben.

Bei BC denken wir gerade über die interne Suche nach. Da wir mit Version 2 sowieso alles auf Links krempeln, bleibt davon auch die Suche nicht verschont. Da die Community hier etwas größer ist, erlaube ich mir, auch hier mal die Frage(n) zu stellen.

https://forum.blackcat-cms.org/viewtopic.php?f=2&t=627
https://forum.blackcat-cms.org/viewtopic.php?f=6&t=628

Prinzipiell gibt es drei Möglichkeiten:

* Eine interne Suchfunktion wie in WB(CE) und BC1 implementiert.
* Eine externe Suchmaschine, die sozusagen parallel zum CMS installiert wird, aber auf eigenem Webspace. (z.B. Solr, Lucene, Sphinx)
* Eine externe Suchmaschine wie Google oder DuckDuckGo.

Alle Methoden haben ihre eigenen Vor- und Nachteile. Ich fange mal hinten an (nur die Nachteile und nur als Auszug zu verstehen):

* Externe Suchmaschinen wie Google und DuckDuckGo lassen sich Layoutmäßig nicht an die eigene Seite anpassen. Außerdem schalten sie ggfs. Werbung oder verfolgen die Suchaktivitäten (Google). Meist läßt sich auch nicht so ohne weiteres beeinflussen, wann (wie oft) der Index aktualisiert wird.

* Lokal installierte Suchmaschinen haben Systemvoraussetzungen, die bei gehostetem Webspace häufig nicht erfüllbar sind oder Extrakosten verursachen. (z.B. Java) Zudem funktioniert die Indexerstellung nur, indem sie die Webseiten scannen. (Genau wie Google & Co.) Das heißt das verursacht Last. Für regelmäßige Aktualisierungen braucht es Cronjobs.

* Eine interne Suche erfordert, daß die Modulautoren eine Suchfunktion zur Verfügung stellen. Das sollte normalerweise keine Hürde sein, ich kann mich aber gut daran erinnern, daß ich in meiner Anfangszeit nicht kapiert habe, was zu tun ist.

Für eigentlich alle Varianten gilt, daß der Inhalt der Seiten oft dynamisch ist und/oder von Benutzereingaben abhängt. Das betrifft z.B. auch die Droplets, für die es dank Ralfs DropletsExtension (in BC in den Core integriert) zwar eine Lösung gibt, so ganz perfekt ist das aber auch nicht.

Nachdem ich einige Stunden mit der Recherche befaßt habe, was geeignet sein könnte, bin ich ziemlich ernüchtert. Die für PHP verfügbaren Search Engines sind entweder hoffnungslos veraltet (Sphider), verfügen nur über sehr eingeschränkten und somit nicht ausreichenden Funktionsumfang, oder sind nicht in eigene Projekte integrierbar. Oder sie basieren auf Projekten wie Solr oder Lucene, was wieder zu dem Problem führt, daß der Provider das erst mal zur Verfügung stellen muß.

Das einzige Projekt, das zumindest einigermaßen brauchbar erscheint, ist TNTSearch.

http://tnt.studio/blog/solving-the-sear … -tntsearch
https://github.com/teamtnt/tntsearch

Ein paar Fragen an Euch:

* Nutzt Ihr die interne Suche überhaupt? (Bzw. Eure Kunden.)
* Welche Erfahrungen habt Ihr mit der internen Suchfunktion von WB(CE)? Sowohl als Benutzer als auch als Modulautor.
* Welche Rückmeldungen bekommt Ihr ggfs. von Euren Kunden bzw. deren Besuchern?
* Wo liegen Eurer Meinung nach die größten Schwächen?
* Habt Ihr Erfahrungen mit anderen CMS und deren Suchfunktionen? Wie sieht es dort aus?

Und, zuguterletzt: Besteht ggfs. Interesse an einer Kooperation bei der Implementierung einer neuen Suchfunktion? (Sofern möglich.)

stefanek

stefanek · 14.12.2016 12:12:13

Wichtiges Thema.
Ich bin bis heute nicht richtig durch die Suchfunktion gestiegen.
Eines der letzten Chaos-Elemente im CMS. roll

florian · 14.12.2016 12:37:16

Ein paar Antworten

* Nutzt Ihr die interne Suche überhaupt? (Bzw. Eure Kunden.)
Ja. Oft wird auch explizit eine interne Suche gewünscht. Ich denke, dies sollte schon Bestandteil eines CMS sein, gerade wegen der unbefriedigenden Alternativen.

* Welche Erfahrungen habt Ihr mit der internen Suchfunktion von WB(CE)? Sowohl als Benutzer als auch als Modulautor.
Funktioniert i.d.R. recht gut.
Wunschzettel:
- Fehlertoleranz*
- Wichtung*
- Paginierung, d.h. nicht mehr immer alle Ergebnisse auf einer Seite
- ggf. auch ein einfacher Weg, Suchvorschläge zu generieren (einige Templates können das glaube ich bereits)
- Konfigurationsmodul, um z.B. Suchen einzurichten, die nur auf bestimmte Verzeichnisse, Sprachen und/oder Module zugreifen

(* naja, Semantische Suche wäre allerdings wohl doch etwas viel verlangt)

* Welche Rückmeldungen bekommt Ihr ggfs. von Euren Kunden bzw. deren Besuchern?
Kein Feedback ist gutes Feedback, weil keine Beschwerden ;-)

* Wo liegen Eurer Meinung nach die größten Schwächen?
Eine fehlerhafte Modul-search.php kann nicht nur die Suche, sondern die gesamte Website (Frontend und Backend) vorübergehend lahmlegen - das ist nicht so gut.

* Habt Ihr Erfahrungen mit anderen CMS und deren Suchfunktionen? Wie sieht es dort aus?
Ich habe (bis letzten Montag) 15 Jahre lang als Contentschrubber ein Intranet betreut, das mit einem High-End-CMS für einen fünfstelligen Eurobetrag auf Windows-Server/Oracle/Java/Resin-Basis betrieben wurde. Als Suche kam Lucene zum Einsatz. Zum Schluß hatte das Intranet so um die 100.000 Objekte. Die Suche brauchte ungefähr fünf Minuten, um eine Abfrage durchzuführen und ist hinterher abgestürzt, so dass der Suchserver ungefähr alle halbe Stunde neu gestartet werden musste. Mit einem Wort: es war so grauenhaft, dass zum Schluss niemand mehr die Suche benutzt hat.

Kooperation: immer, gerne, es ist sowieso schade, dass sich WBCE und BC in völlig unterschiedliche Richtungen entwickeln.

webbird

webbird · 14.12.2016 13:24:31

Danke für die ausführliche Antwort! Das hilft mir sehr weiter!

Ich beschreib mal kurz meine grobe Idee für BC2 (unabhängig von der letztlich eingesetzten Lösung):

Aus Performancesicht ist eine Indexsuche vermutlich die beste Lösung. Hierbei werden die möglichen Übereinstimmungen extrahiert und in die Datenbank geschrieben. Dort ist erfaßt, auf welchen Seiten das gesuchte Wort vorhanden ist. Die "Live-Suche" erfolgt nur noch gegen den Index, womit z.B. das Problem, daß eine kaputte search.php die Seite lahmlegt, gelöst ist.

Der Index wird beim Speichern erzeugt bzw. aktualisiert. Zum einen ist das normalerweise der einzige Zeitpunkt, zu dem sich Inhalte tatsächlich verändern, zum anderen sind die Daten eines einzelnen Blocks in der Regel nicht so riesig, daß ein Timeout zu befürchten ist. Es gibt natürlich immer Ausnahmen, etwa wenn ein Droplet wie "EveryNext" das Datum des nächsten 1. Dienstags im Monat berechnet und anzeigt. Hier müßte man dann innerhalb des Droplets entscheiden, ob diese Information wirklich so relevant ist, daß sie über die SuFu gefunden werden muß; wenn ja, kann das Droplet zur Not beim Aufruf selbst den Index aktualisieren.

Der Core bzw. die Suchbibliothek (in BC ist das ein Modul vom Typ "library") muß Methoden zur Verfügung stellen, die es Modulen und Droplets ermöglichen, den Index zu aktualisieren. Hier mal ein Ausschnitt von der TNTSearch Seite (seht es als Pseudocode):

[== PHP ==]
use TeamTNT\TNTSearch\TNTSearch;

$tnt = new TNTSearch;

$tnt->loadConfig([
    'driver'    => 'mysql',
    'host'      => 'localhost',
    'database'  => 'dbname',
    'username'  => 'user',
    'password'  => 'pass',
    'storage'   => '/var/www/tntsearch/examples/'
]);

$indexer = $tnt->createIndex('name.index');
$indexer->query('SELECT id, article FROM articles;');
//$indexer->setLanguage('german');
$indexer->run();

Der obere Teil gehört dann in den Core bzw. das Suchmodul, der untere (ab $indexer->query) in die save-Funktion des Moduls. (Der Aufruf von setLanguage() ist übrigens für die korrekte Behandlung von Umlauten relevant. Das ist ja auch immer ein Problem. Trotz utf-8.)

Ich denke, daß sich dadurch mehrere Fliegen mit einer Klappe schlagen lassen:

* Die Erzeugung und Aktualisierung des Index wird für den Modulautor sehr viel einfacher.
* Die Live-Suche wird (vermutlich sogar signifikant) schneller.
* Das Frontend wird durch defekte Modul-Suchfunktionen nicht beeinflußt. Die Daten fehlen lediglich im Index oder werden darin nicht gefunden.
* In BC bauen wir für sowas grundsätzlich Wrapper, so daß die tatsächlich genutzte Search Engine prinzipiell austauschbar ist. Die API bleibt stabil.
* Komplexe(re) Droplets können die Methoden bei Bedarf ebenso verwenden.

Natürlich gibt es auch diverse Nachteile, aber die gibt es schließlich immer.

florian

cwsoft · 14.12.2016 15:17:49

Würde auch auf interne Suche setzen. Habe allerdings bisher eigene Erfahrungen nur mit der MySQL fulltext search gemacht. Die lief bis zu einigen 100 Seiten stabil und zuverlässig. Das ganze war aber für eine Art Blogmodul.

Mit Lucene für das Intranet meiner alten Firma hatten wir keine Geschwindigkeitsprobleme, aber die Suchtreffer varierten stark und waren oft nicht zu gebrauchen. Hatte da aber keine Aktien drin, kann also durchaus auch an der Implementierung gelegen haben.

Last edited by cwsoft (14.12.2016 15:18:11)

evaki · 14.12.2016 15:40:58

Einer unserer Berater verwendet seit 2004 FDSE für eine seiner Sites (kein WBCE, sondern Apache SSI). Bei über 10000 Beträgen (Online-Zeitung) ist die SUMA äußerst schnell.
Befürchte aber, daß viele nicht wissen was Perl ist. "webbird" weiß es smile
MfG. EVaki

webbird · 14.12.2016 15:45:27

Ich glaube mittlerweile ist bei vielen Providern auch schon kein Perl mehr verfügbar. Oder nur gegen Aufpreis. Das wäre damit das gleiche Problem wie mit Lucene und Co.

Edit: Ganz taufrisch ist FDSE allerdings auch nicht mehr -> "Latest stable version 2.0.0.0073 released August 22, 2005" Was nichts darüber aussagt wie gut oder schlecht sie ist. Das Grundprinzip - die Algorithmen - ändert sich ja nicht so schnell wie andere Dinge (HTML-Markups etwa).

Last edited by webbird (14.12.2016 15:50:05)

florian

webbird · 14.12.2016 15:48:08

Das kam bei uns noch zum Punkt "Probleme mit der SuFu":

Diese einfach für den Modulautor zu halten, gleichzeitig aber so mächtig zu gestalten, dass sie (theoretisch) alle Bereiche abdeckt. D.h. ich habe oft Optionen (Titel für ein Box, ...) die nicht mit dem Hauptcontent gespeichert werden.

Das betrifft natürlich auch Texte in (Modul-)Templates und Sprachdateien. Wobei man sicherlich drüber streiten kann ob die indiziert gehören.

stefanek · 14.12.2016 16:35:59

Die Beispiel Such von TeamTNT sieht schon sehr imposant aus. thumb_up

grindmobil · 14.12.2016 19:14:17

Was mich eigentlich am meisten stört, ist dass die Ergebnisse völlig ungeordnet sind.

Das wäre wahrscheinlich sogar leicht zu zu beheben. Bei jedem Ergebnis ist wohl zumindest bekannt, wie viele Treffer es gab (Zahl der Auszüge)
Alle noch mal in ein Array, nach Zahl der Ergebnisse sortieren und dann erst ausgeben.
Dann hat man wenigsten ein bissel das Gefühl von "Relevanten Ergebnissen".

florian

stefanek · 15.12.2016 11:12:44

evaki wrote:

Wie ist es mit der Sphider?
MfG. Evaki

Sphider ist veraltet.

Dieses TNT sieht interessant aus.

@webbird
hast Du schon damit etwas mehr herumexperimentiert und siehst einen Weg, über kurz oder lang, wie es gut eingebaut werden könnte?

Das Szenario bei WBCE sieht so aus, dass wenn wir diese Lösung implementierten, die Module nach und nach schleichend nachrücken würden.
Es müßte also eine Möglichkeit her, wo vorübergehend beide Methoden funktionieren.

Darüberhinaus habe ich mich ehrlich gesagt kaum mit der Suche in WB/CE beschäftigt.
Will also nicht den Eindruck erwecken, ich wäre jetzt voll hinterher mich damit auseinander zu setzen ops
Aber sinnvoll wäre es schon, die Suche zu optimieren.
Mir graust es schon, wenn ich ein Modul mit der Suche koppeln soll. Und da bin ich nicht der Einzige.

Gruß,
Christian

florian

webbird · 15.12.2016 11:18:41

Die letzte Sphider-Version ist zwar offiziell von 2013, irgendwo hab ich aber gelesen, daß das Teil schon seit 2006 oder so nicht mehr wirklich weiter entwickelt wurde. Es gibt wohl zwei "Forks", wenn man es denn so nennen kann, Sphider Pro und Sphider Plus, aber auch die sehen mir nicht wirklich professionell aus.

Wir müssen hier auch die beiden Ansätze unterscheiden:

* Externe Suchmaschinen, die die gerenderten Seiten durchsuchen (so wie es Google und Co. tun)
* Interne Bibliotheken, die es erlauben, per API den Suchindex zu pflegen

Ich suche eher nach letzterem, da nur dann die Möglichkeit gegeben ist, beim _Speichern_ einer Änderung den Index anzupassen. Mit allen Haken und Ösen (z.B. daß hartcodierte Template-Teile, Sprachausgaben, Ausgaben von Droplets u.ä. nicht im Index stehen). Ich bin mittlerweile zu dem Schluß gekommen, daß es wohl am besten ist, wieder was eigenes zu schreiben - wobei man dann sicherlich von den Projekten anderer lernen kann.

webbird · 15.12.2016 11:23:05

stefanek wrote:

@webbird
hast Du schon damit etwas mehr herumexperimentiert und siehst einen Weg, über kurz oder lang, wie es gut eingebaut werden könnte?

Ich habe mir mal die Quellen angeschaut, der Punkt, der mich stört, ist, daß es SQLite verwendet. Es wäre vermutlich auch nicht ohne Anpassungen verwendbar, da man z.B. gar nicht die SeitenID speichern könnte.

Ich habe übrigens keinerlei Doku zur search.php gefunden. Wie soll da ein Modulentwickler in der Lage sein, die SuFu zu unterstützen?

stefanek · 15.12.2016 11:33:41

Verstehe mit TNT.

Und die search.php
ja, nun ja. Altes Teil, kaum einer je durchgestiegen, sodass es auch keine Doku gibt.
Sie stamm noch aus der Zeit, wo komplett auf OOP verzichtet werden wollte.
Welch'n Graus ...

webbird · 15.12.2016 11:45:06

Das hier ist noch ein Fundstück von gestern.

https://github.com/boyter/Phindex
Das ist das Ergebnis einer Blog-Serie zum Thema "wie baue ich meine eigene Search Engine". Möglicherweise brauchbar als Basis. Man sollte die Blog-Serie (5 Teile) lesen. Link im GitHub Repo.

Es ist ausdrücklich nicht dazu gedacht, in eigenen Projekten verwendet zu werden, aber in Kombination mit der Serie gut geeignet, ein paar Grundlagen zu lernen.

webbird · 15.12.2016 11:57:55

Selbst im Jahr 2008 gab es keine Doku zur search.php. Bisher fand ich im WB-Forum:

Basically you do not install anything in the search table anymore.
Create a function with the name your_module_search().
In there you can get info and variables from the search engine. Next you can decide what data will be available to be found by the search function, and you return that data in the defined array.

Dank archive.org findet man eine alte Abhandlung von thorn zu dem Thema:

https://web.archive.org/web/20080407185 … is-aus.php

norhei · 15.12.2016 22:49:13

Also...

@webbird
Deine Analyse im ersten Post ist wirklich extrem treffend !!

Zur Nutzung
Grade Shop Seiten brauchen die Suche unbedingt .
Seiten mit größeren Artikelsammlungen genauso.

Zur WB Suche:
Meine Erfahrung ist , das die Einzelwortsuche ganz gut funktioniert, alles Weitere .. vergessen wir das ...

Zu TNT Search:
Sqlite , da ist die Frage wieder ob das auf dem Webspace aktiviert ist ...

Es gibt wohl Probleme mit Umlauten :
https://github.com/teamtnt/tntsearch/issues/54

Php 5.5.

Ich das Gefühl man hat sich da schon eine Menge Gedanken gemacht um eine gute Indexierte Suche zu machen.

Phindex:
Solide Grundlage wenn wir uns entscheiden sollten, das Selberbauen eine gute Idee ist.
Einige Teile bräuchten wir nicht in der Form wie sie dort gemacht sind (z.b. brauchen wir nicht Crawlen, wir haben alles schon in der DB )
Aber Ansich ist das schon einen nette Bauanleitung .

Es ist die einzige Möglichkeit wo man Techniken wie Redbean, Doctrine Oder die WB eingene Datenbankklasse einsetzen könnte .

Andere such Engines:
Die einen brauchen Perl oder Java , benötigen Cronjobs , oder Schell Zugriff ... Alles was bei einem einfachen System wie WBCE nicht vorrausgesetzt werden darf .

Alte WB Suche:
Habe ich das richtig gesehen? Die Suchfunktion gibt praktisch das/die Suchwort/e an das Modul weiter , und das gibt dann Informationen zurück ?

Fazit: Vielleicht Modular ?
Intern hatte ich schon mal überlegt die Suchfunktionalität vor allem in ein Modul auszulagern.
Dort hätte man eine Klasse in der all die Sachen enthalten sind wie :

Seiteninhalte Holen(crawlen/Db)
Zum index hinzufügen
Aus dem Index entfernen
Neuen Index erstellen.
Suchresultate als Array zurückgeben.
Eine richtige HTML Suchausgabe .
Bestimmte Einstellungen ....

Als erstes hatte ich dann an eine wirklich primitive Datenbanksuche gedacht. Aber es wäre ja kein Problem das Modul/Library zu tauschen und dann komplexere Suchsysteme dort einzuklinken die dann aber auch Ansprüche wie SQLITE, Java oder Perl stellen dürften.

Was auch ein Gedanke war , war erst einmal in den Modulen in der info.php die relevanten Tabellen und Felder anzugeben, um das Holen der Daten zu erleichtern . Ein externer Crawl ist eigentlich totaler Unsinn wenn man direkten Zugriff auf die Daten hat.

Ein primitiver Indexer könnte dann einfach hingehen und beim Speichern der Seite deren Inhalte in etwas modifizierter Form abspeichern.
Umgekehrte Indexe wären erstmal noch nicht Pflicht .
Sprich beim Speichern der Seite würde immer die Suchmethode mit bestimmten Parametern aufgerufen .

Bei WBCE könnte man diese Grundklasse auch im Core installieren , und dann per Modul Override gegebenenfalls ersetzen wenn man eine Komplexe SuMa nutzen möchte.

Also eine simple Lösung als Grundlage, mit der Option beliebig zu erweitern.

Leider bin ich grade ein wenig gehetzt.
Aber ich finde die Diskussion wirklich toll !!!

stefanek · 16.12.2016 00:02:11

Im Prinzip, wie ich das sehe, was "unsere" Suche macht:
jedes Modul stellt über die search.php bereit, welche DB-Felder des jeweiligen Moduls von der Suchfunktion berücksichtigt werden sollen.
Das ist erstmal soweit in Ordnung.
Nur, dass die Art und Weise, wie man in der search.php die DB-Felder zuweist ist nicht ganz einfach verständlich.
Wenn wir hier bereits eine Klasse hätten, die dann als Vorgabe dient und dann mit Klassen Extends gearbeitet werden könnte, in der Form von:

class wysiwyg_search extends ModSearch{
     . . . 
}

Bei Listingmodulen wie OFA, Itemz, News und Ähnlichen, wo man sowohl die Loops hat wie aber auch die Detail-Ansicht, könnte man eine Funktionalität einbauen, mit der man die view_overview.php mit einem übergeordneten (Systemweit einsetzbaren) DB-Caching System bedient und die Ausgabe der Loops in der DB cached, die dann als ganzes von der DB mit durchgeforstet wird.
Gleiches gilt dann für die Detail-Ansicht Seiten, die sich auch oftmals aus vielen Feldern zusammensetzen.
Die Layouts dieser Ansichten wären dann auch gleich im Cache, bereit um durchsucht zu werden.

Persönlich sehe ich das größte Problem bei den dynamischen Inhalten, die aus Droplets, Funkionen etc. kommen.

Ebenfalls, ich kann z.B. eine Itemz Seite haben die unsichtbar ist, die Inhalte werden über ein eigens für diesen Zweck geschriebenes Droplet ganz woanders ausgegeben. Wo führt micht die Suche hin?

Ich suche noch ... nach Eingebung. big_smile

Chris

norhei · 16.12.2016 08:33:37

Habe das grade mal gründlicher gelesen ... Die Sufu holt sich jedes mal(bei jeder Suche) von allen Sections die Seiteninhalte ?

Und danach werde Diese durchsucht ? PageId und der ganze Sermon werden komplett mitgeschleift ? Und alles wird bei jeder neuen Suche wiederholt ?

Leider exitiert die Seite mit der Schnittstellen Definition nicht mehr ..... Alle enderen existieren noch
https://web.archive.org/web/20080405070 … hp?lang=EN

Thorn hat sich da schon eine Menge Gedanken gemacht, auch die Seiten davor und dahinter sind informativ. Was ich mir vorstellen könnte ist das diese Suche sehr langsam wird bei wirklich großen Seiten , Auch zeigt es das das Prinzip, Seiten mit mehreren Unterseiten, die aber keine wirklichen Seiten sind
immer wieder Probleme bereitet.

Was ich persönlich finde, ist das Pagekeywords und Description wieder stärker in die Suche eingebunden werden sollten. Seit den Letzten paar Google Updates macht es dort auch nur noch Sinn was einzutragen wenn es den Inhalt der Seite entspricht. Keywordstuffing usw. haben sich alle erledigt.

Was mir auch erst mal problematisch erscheint ist, die Kompatibilität zu alten Modulen , wobei, wenn die Suchfunktion des moduls so Vollständige Informationen auswirft hätte man natürlich auch gleich die richtigen Daten, die man zum indexieren braucht ... . Sprich beim erstellen des Suchindizes einmal alle Seiten abfragen und dann beim speichern einer Seite einmal diese Seite erneuern . Zieht die Seite um und die URLs ändern sich , einmal komplett neu indexieren .. fertig ...

grindbatzn · 16.12.2016 11:02:13

Der Suchindex lässt sich theoretisch ja relativ leicht erstellen:
einfach bei jeder Seite die page_content(alle blöcke) durchlaufen, html raus, noch nachbehandeln und ab in die DB.
Welche Blöcke es gibt? - dazu muss man das Template der Seite abfragen, das sollte noch gehen.

Schwieriger: Was ist mit Parametern? Oder Modulen, die selbst Seiten erzeugen? (Topics, Bakery, One4All..)
Wie kommt man zu all diesen Seiten? DIe kennt nur das jeweilige Modul.

Spider: Es gibt Module, die 30000 "Seiten" (=URLs) erzeugen - ich glaub Bookings gehört da dazu. Da kannst du einen (nur mittelintelligenten) Spider vergessen.

Ich denke, das ist auch der Grund, warum all diese Fertig-Lösungen nicht mehr gepflegt werden.
Ich hab ja (ewig her) mal das SEO-Tool Webeye entwickelt, im Kern ein Spider + Indexer. Hab ich auch einstellen müssen; die Art wie heute Websites gemacht sind, hat das Tool hoffnungslos überfordert; es hat sich oft verlaufen.
Bei Google arbeiten ja 1000 Entwickler laufend dran - und wenn es ein Problem gibt, kommt es einfach nicht in den index. Erfährst du ja nicht.
Bei WBCE entwickelt eine Handvoll nebenher, und wenn eine Seite mal nicht gleich sofort im Suchindex ist, gibt es Beschwerden.

Ein möglicher Ansatz wäre vielleicht, dass ein Modul eine Datei pagelist.php enthalten kann, in der steht, welche urls es gibt und wann diese das letzte Mal geändert wurden. Und: ob diese Aktiv sind.
Bei WB selbst wäre das der PageTree.
DIese URLs werden dann zyklisch abgeklappert und im Suchindex erneuert.

Ein weiteres Problem sehe ich bei den Berechtigungen.
Und: Wie man mit Leichen im Index umgeht. Man müsste bei jeder Suche alle pagelist.php neu abfragen, ob sich was geändert hat.

Aber nicht zuletzt muss man sagen:
Wieviele Seiten hat denn eine durchschnittliche WBCE-Website? Und wie sind die so gestrickt?
In aller Regel reicht die derzeitige Funktion aus.

norhei · 16.12.2016 12:29:40

Hmmm, Berechtigungen sind ein übles Problem ... , deswegen wirds wohl auch jedes mal neu erstellt.
Mit ner Spider kommt man da aber auch ins stocken(bei Berechtigungen).

An der Derzeitigen Funktion stört halt, das sie für Modulbauer so undurchsichtig ist.... und vermutlich bei großen Seiten nicht mehr klarkommt.
Wir sammeln ja Grade erst mal gedanken.

Diese Pageid 0 Seiten auf denen das derzeit angezeigt wird Stinken auch gewaltig . Besser fände ich als Versteckte Seite einrichten , Searchmodul drauf.
Dann könnte man auch verschiedene Sprachen besser behandeln.

ISt mehrsprachigkeit eigentlich im Moment ingendwo in der Suchfunktion irgendwo bedacht ?

@webbird
Gibts eigentlich irgendwo Infos dazu, wie Ralf das mit den Droplets geregelt hat ?

grindbatzn · 16.12.2016 13:20:28

>>ISt mehrsprachigkeit eigentlich im Moment ingendwo in der Suchfunktion irgendwo bedacht ?

Ja, da wird unterschieden. Auf englischen Seiten werden nur englische Seiten durchsucht, auf deutschen nur deutsche.

Wäre für mich aber jetzt nicht so wichtig, weil es in der Praxis wohl nur wenige Suchbegriffe gibt, die in allen Sprachen gleich sind (Namen zb), aber es schadet ja nicht, wenn die Suchergebnisse den Hauch von Internationalität haben.

grindbatzn · 16.12.2016 13:49:02

norhei wrote:

Diese Pageid 0 Seiten auf denen das derzeit angezeigt wird Stinken auch gewaltig . Besser fände ich als Versteckte Seite einrichten , Searchmodul drauf.

Dann müsstest du aber die Suchfunktion in jedem Template individuell anpassen, nix mehr Standard. Was hast du denn genau gegen das, was jetzt ist? Ich sehe da kein Problem.

Berechtigungen:
In der Praxis kannst du nur mal alles indexieren, und dann rausfiltern, was nicht sichtbar sein soll.
Allerdings können auch Module selbst wiederum einzelne Berechtigungen haben - zb Topics. (aktiv nur für angemeldete Besucher, wobei aber nicht nach der Art der Berechtigung gefragt wird.). In der Suche sind bei Topics aber nur aktiv=öffentlich zu sehen.

norhei wrote:

An der Derzeitigen Funktion stört halt, das sie für Modulbauer so undurchsichtig ist.... und vermutlich bei großen Seiten nicht mehr klarkommt.

Ja. Da ist Wissen verloren gegangen. Aber das kann man ja wieder gewinnen.

So insgesamt: Ich hab über das Thema schon öfter mal nachgedacht, bin aber auf keinen grüneren Zweig gekommen.

Was ich für realistisch halte, ist eine bessere Vor- und Nachbehandlung.
1) Suche zuerst mal alle, die die Begriffe im Titel und in der Meta-Description oder in den Keywords haben.
Diese Seiten werden vorgereiht und müssen dann gar nicht mehr erneut durchsucht werden.
2) sortiere alle Ergebnisse nach Relevanz (Punktesystem: im Titel = 10 Punkte, in der Desc = 5 Punkte, Keyw = 5 Punkte, Zahl der Excerpts. = je 1

Dann wäre schon mal allerhand gewonnen.

Last edited by grindbatzn (16.12.2016 13:50:43)

norhei · 16.12.2016 14:00:09

Dann müsstest du aber die Suchfunktion in jedem Template individuell anpassen, nix mehr Standard.

Nene , es würde dann heissen man kanndie Suchfunktion in jedem Template anpassen. Nucht muss.

Die Pageid 0 Seiten machen im Core jede Menge Ärger und brauchen bei jeder Kleinigkeit ne Extra Wurst.
Mit Login und globalen Boxen harmonieren die wenn ich mich recht erinner auch nicht besonders. Sprich Suche nur für Mitglieder , geht das ?

Ein weiterer Vorteil wäre eben die austauschbarkeit , mann könnte relativ leicht eine andere Suche implementieren.

stefanek

webbird · 16.12.2016 14:02:03

Puh, ich such mal zusammen, worauf ich was sagen will, ohne die Namen der Betreffenden mühsam dazuzufrickeln. wink

Spider: Es gibt Module, die 30000 "Seiten" (=URLs) erzeugen - ich glaub Bookings gehört da dazu. Da kannst du einen (nur mittelintelligenten) Spider vergessen.

Das meinte ich mit Aufrufparametern und Abhängigkeit von Benutzereingaben. Ich kann ja nicht für jeden Monat/Woche/Tag usw. eigene Unterseiten anlegen. Wenn ein Benutzer von einer Quartalsübersicht in eine Tagesansicht wechselt, geht das halt nur über Aufrufparameter. Wobei gerade in diesem konkreten Beispiel - also Bookings - das Auftauchen in der SuFu sowieso nicht so wichtig ist.

Gibts eigentlich irgendwo Infos dazu, wie Ralf das mit den Droplets geregelt hat ?

Puh, ich glaube nicht. Da wirst Du wohl Quellcode lesen müssen.
https://github.com/phpManufaktur/DropletsExtension

Oder bei BC im Droplets Helper.

Ich habe gestern noch einen ziemlich coolen Ansatz gefunden, die ganze Indizierung und Suche allein über die DB zu machen. Also mit Hilfe von Triggern und Stored Procedures. Das hat den Charme, daß man auf Scriptseite gar nichts nichts machen muß und es zudem sehr performant ist. Allerdings gibt's auch da ein paar Probleme - was z.B. wenn ich den Suchindex aus irgendeinem Grund leeren muß? Dann isser erst mal weg... denn die Arbeit mit Triggern bedeutet ja auch: Es muß auf DB-Seite eine Änderung stattfinden, damit der Trigger ausgelöst wird. Zudem geht sie Suche konkret auf bestimmte Tabellen und nicht auf alle Inhalte. Von den Rechten ganz zu schweigen.

Dennoch etwas, das ich nochmal gründlicher beleuchten möchte.

WBCE CMS Forum

#1 14.12.2016 11:25:29

Interne Suche

#2 14.12.2016 12:12:13

Re: Interne Suche

#3 14.12.2016 12:37:16

Re: Interne Suche

#4 14.12.2016 13:24:31

Re: Interne Suche

#5 14.12.2016 15:17:49

Re: Interne Suche

#6 14.12.2016 15:40:58

Re: Interne Suche

#7 14.12.2016 15:45:27

Re: Interne Suche

#8 14.12.2016 15:48:08

Re: Interne Suche

#9 14.12.2016 16:35:59

Re: Interne Suche

#10 14.12.2016 19:14:17

Re: Interne Suche

#11 15.12.2016 11:12:44

Re: Interne Suche

#12 15.12.2016 11:18:41

Re: Interne Suche

#13 15.12.2016 11:23:05

Re: Interne Suche

#14 15.12.2016 11:33:41

Re: Interne Suche

#15 15.12.2016 11:45:06

Re: Interne Suche

#16 15.12.2016 11:57:55

Re: Interne Suche

#17 15.12.2016 22:49:13

Re: Interne Suche

#18 16.12.2016 00:02:11

Re: Interne Suche

#19 16.12.2016 08:33:37

Re: Interne Suche

#20 16.12.2016 11:02:13

Re: Interne Suche

#21 16.12.2016 12:29:40

Re: Interne Suche

#22 16.12.2016 13:20:28

Re: Interne Suche

#23 16.12.2016 13:49:02

Re: Interne Suche

#24 16.12.2016 14:00:09

Re: Interne Suche

#25 16.12.2016 14:02:03

Re: Interne Suche

Board footer