CMS Made Simple Forums

Im ersten Moment überraschend fix, für mich in der Praxis nicht zu gebrauchen.

Das Module verwendet einen eigenen Suchindex über eine DB Tabelle.
Die hat bereits bei der Erstinstallation 1900 Datensätze.

Wörter die in der Stopfunktion enthalten sind, werden ignoriert , also weder im Suchindex gespeichert noch gefunden.

and navigation areas
z.B. in der Suche enthält für die Seite in der diese Wörter sogar in exakt der Folge enthalten sind eine Trefferqoute von 11%, für eine andere Seite in der diese Worte wuer im Inhalt verteilt sind, aber ohne and sogar 100%.

Es wird kein Textauszug mit den Suchbegriffen im Ergebnis geliefert.

Die Stopworte sind nur in englisch und damit für andere Sprachen nicht zu gebrauchen.

Bei Webs mit einer Seitenanzahl von ca: 100 muss man eigentlich garnicht mehr suchen, da man u.U. eine solche Trefferqoute erhält mit irrelevanten % Angaben, dass man nichts mehr findet.

Deinstalliert man ein Module wie News suicht aber nach einem Text der in News gespeichert ist, wird einem freundlicherweise sogar ein Treffer angezeigt, weil es keinen Rückbezug zu Änderungen , Streichungen von Moduleinhalten oder garnichts mitbekommt.

Das bedeutet, es werden Treffer signalisiert zu Inhalten die nicht mehr vorhanden sind oder wo es die Module dazu nicht mehr gibt.

Fazit beim aktuellen Stand für mich - in der Form absolut unbrauchbar und das schlimmste ist, jeder der das mal selbst testet, wird das nach wenigen Minuten selbst feststellen.

Piratos wrote: Das Module verwendet einen eigenen Suchindex über eine DB Tabelle.

Ted war schon immer von phpdig begeistert.

Die Stopworte sind nur in englisch und damit für andere Sprachen nicht zu gebrauchen.

... sehr wahrscheinlich will auch jeder andere Stopwörter. Außerdem lassen die sich IMHO nicht mehrsprachig importieren (kommen nicht aus dem language file).

Das für die Bequemen  :

ich, mir, mein, meine, mich, meinen, wir, unser, unsere, unseres, unserer, unseren, du, dein, deine, deinen, deines, er, sein, seine, seines, seinen, sie, ihr, ihre, ihres, ihren, es, deren, dessen, ihnen, eure, euren, eures, eurer, welche, welcher, wer, wessen, dies, das, jenes, bin, bist, ist, sind, war, waren, warst, sein, gewesen, habe, haben, hat, hatte, hatten, tun, tut, tat, ein, eine, einer, eines, die, der, das, des, und, aber, wenn, oder, weil, als, während, auf, bei, für, mit, über, unter, gegen, zwischen, in, im, durch, während, bevor, nach, oberhalb, unterhalb, bis, von, hoch, runter, in, aus, an, über, unter, ferner, dann, mal, hier, dort, was, wo, wann, warum, wie, alle, irgend, jemand, beide, jeder, mehr, meisten, andere, anderen, anderes, einige, einigen, einiger, solche, solcher, solchen, ja, nein, nicht, nur, selbst, selbe, selben, selber, so, dann, danach, auch, sehr, doch, weil, da

Das bedeutet, es werden Treffer signalisiert zu Inhalten die nicht mehr vorhanden sind oder wo es die Module dazu nicht mehr gibt.

So wie bei Google  ... ist wohl bei einem phpdig-Ableger auch nicht anders zu erwarten; nur dass es sich bei CMSms mit einem Klick wesentlich schneller neu indizieren lässt.

Tja, es gibt noch 'ne Menge zu tun ...

Klick wesentlich schneller

Na das täuscht ungemein - ich kann das nur mit 3 Usern gleichzeitig testen, die alle etwas in den Inhalten rum rühren, aber die CPU Belastung allein bei der Aufbereitung des Search Indexes steigt enorm.

Bei einem Seitenbestand von rund 200 wird das bei der Bearbeitung schon recht gemütlich.

Der Autor von Search muss nicht nur den Webbetrachter im Auge haben sondern auch die Seite hinter der Bühne.

Jedenfalls ist das so billig gemacht, dass man eigentlich mit einer Mysql Volltextsuche besser klar kommen würde obwohl auch da von der Besucherseite bei reichlicher Nutzung eine CPU ganz schön in die Knie geht.

Nicht umsonst haben Google und Co tausende von Servern um das zu managen.

Der Autor wird schnell dahinter kommen, das es so auf Dauer nicht läuft - denn die Anwender haben keine Rechnerkapzitäten a la Google.

Und - was nützt mir ein schnelles Ergebniss, das ungehemmt in allen Inhalten sucht (wenn es denn für Modulschreiber auch mal eine API Beschreibung gibt), wenn man den Wald vor lauter Bäumen nicht mehr sehen kann.

Hat der Autor schon mal etwas von Synchronisation gehört ?

Da bedeutet hier, dass jede Inhaltsänderung eines bewirken muss - vollständige Löschung des Searchindexex für diesen Inhalt plus Neueinspielung für den aktualisierten Inhalt , wenn noch einer vorhanden ist.

Das Ding ist uralt und führt bei grossen Foren zu enormen Resourcenverbrauch (ich denke da z.B. an PHPBB Deutschland).

Also der normale CMS Anwender hat vielleicht max. 100 Seiten und da ist diese Technik gelinde gesagt Müll.

Und eines wird bei Search überhaupt nicht berücksichtig - wenn Inhalte z.B, aus Plugins oder Modulen stammen und somit ein Bestandteil der Seite selbst sind -  jeder Treffer bei einer Direktsuche verliert damit den Zusammenhang mit der Seite, in der sie dargestellt wird.

Und - beziehen Plugins oder Module ihre Inhalte nicht aus einer Datenbank (daran hat der Autor auch nicht gedacht), dann gibt es auch 0 Ergebnisse.

Piratos wrote:

Klick wesentlich schneller

Na das täuscht ungemein - ich kann das nur mit 3 Usern gleichzeitig testen, die alle etwas in den Inhalten rum rühren, aber die CPU Belastung allein bei der Aufbereitung des Search Indexes steigt enorm.

Zumindest dürfte es schneller sein als der monatliche Google Dance  .

Hat der Autor schon mal etwas von Synchronisation gehört ?

Und dabei wäre es so einfach gewesen, Pisearch in die Distri reinzupacken und die Energie für andere Sachen zu nutzen ...

Piratos wrote: aber die CPU Belastung allein bei der Aufbereitung des Search Indexes steigt enorm.

Wäre eigentlich mit der neuen Ereignisverwaltung auch ein CMS-internes Cronjob-Modul möglich (z.Bsp. für eine Neuindizierung in lastarmen Zeiten)?

Neuindizierung

Wenn ich Gelegenheit habe einen Cronjob laufen lassen zu können, gibt es systemeigene Möglichkeiten die weitaus besser sind als eine solche Funktion, die in einem Module abgelegt sind - für Datenpflege und - Sicherung wwird dann 0 Module benötigt, da man das mit Systemwerkzeugen machen würde.

Bedingt in der Regel einen Server mit vollem Root Zugriff.

Piratos wrote: gibt es systemeigene Möglichkeiten die weitaus besser sind als eine solche Funktion, die in einem Module abgelegt sind

Ist mir schon klar, aber ...

Bedingt in der Regel einen Server mit vollem Root Zugriff.

... genau das ist das Problem und war der Anlass für meine Überlegungen  .

Anlass für meine Überlegungen

Ist schon klar aber Cronjob bedeutet ja immer rootzugriffsmöglichkeit.

Gemeint ist hier wahrscheinlich eher eine einfache Zeitsteuerung als Auslöser, das Problem ist dann die automaische Triggerung.

Piratos wrote: Gemeint ist hier wahrscheinlich eher eine einfache Zeitsteuerung als Auslöser,

... deswegen die Idee mit der neuen Ereignisverwaltung  .

Ja gut und schön, aber man müsste dann ein Script endlos im Hintergrund laufen haben (was bekannterweise so nicht mit PHP  geht, also im Vordergrund) und dann müsste das Script in einer Schleife Datum Zeit abfragen und dann beim erreichen des gewünschten Timestamps eine Aktion auslösen.

Bloss wenn ich den Browser schliesse bzw. auch die Verbindung kappe hat sich das mit dem Script bereits erledigt - der Job wird nie ausgeführt.

(Deswegen gibt es ja Cronjobs).

Also ein ganz schlechter Ansatz, da er nicht funktionieren wird.

Klingt logisch  ...