Suchindex löschen und neu aufbauen via Cronjob

Hallo zusammen,

hat jemand eine Idee wie ich den Contao Suchindex via z.B. Cronjob regelmäßig löschen und danach neu aufbauen kann.

Ich habe eine Installation die nach wenigen Wochen einen Suchindex von über 200 MB aufbaut. Das Webhosting Paket stürtzt dann leider beim Suchen über das Frontend ab. oder kann man auch deaktivieren, dass sich der Suchindex immer weiter aufbaut? Wenn ich diesen selber generiere, ist er nicht annähernd so groß....

Vielleicht hat ja jemand eine Idee oder sogar ein Script dafür?

Viele Grüße und schöne Weihnachtstage.

Hmm der über die Systemwartung dürfte aber keine unterschiedliche Größe zum "natürlich" erstellten haben...da ist doch was faul? Die Systemwartung ruft ja auch nur alle Seiten auf die man aufrufen kann. Wie ein User auch.

Hey,

ich glaube das der mit den vom user eingegebenen Suchanfragen wächst, oder?
Also bin mir sehr sicher, dass der bei allen Installationen wächst.

Suchanfragen werden imho nicht gespeichert. Nur vorhandene Texte (News, Artikel, Strukturen) werden in den Index aufgenommen. Korrigiert mich wenn ich falsch liege. Es macht eigentlich auch keinen Sinn Suchanfragen in den Index aufzunehmen...der Inhalt der Webseite ändert sich dadurch ja nicht.

Edit:
Also wie schon vermutet wächst der Index nicht durch Sucheingaben an (habs gerade bei 2 Installationen getestet). Das wäre auch sehr bedenklich...so könnte man ja quasi jede Contaoseite crashen :).

Dieser Crash ist ja mein Problem.

Ich habe eine Installation, die im Moment folgendes in der Systemwartung anzeigt:
Anhang 14974

Nach dem leeren und neuem Aufbau des Suchindexes habe ich folgendes Ergebniss:
Anhang 14975

Also irgendwas passiert doch da im Hintergrund. Der Suchindex wächst definitiv, dass sieht man ja an den Screenshots. Was kann denn dazu führen, dass so etwas passiert?
Und ich möchte halt, damit es keinen Crash gibt, den Suchindex regelmäßig leeren und neu generieren.

Strange..das Einzige was ich mir erklären kann ist das die Systemwartung weniger Seiten durchgeht als es gibt. Ruft jemand die Seite auf, wird es dem Index. Vielleicht ein Shopmodul deren Strukturen von der Suche ausgenommen sind? Vielleicht sind es auch doppelte Einträge? Dafür müsste man man in die Tabelle schauen. Über 1 Mio Einträge is heftig! :)

Da ist ein Contao Immomanager drin. Der wird in den Index aufgenommen. Meinste, dass hat evtl. was damit zu tun?
Aber grundsätzlich brauche ich eh erstmal nen Cronjob, geht sowas denn ;-)


EDIT: 1 Mio ist nichts. Habe den ltzte Woche noch geleert. Nach 4 Wochen gehts richtig rund :-)

Ja, ich tippe definitiv auf eine "Fehlfunktion" eines Moduls. Als würde er weiterhin unterschiedliche URLs erzeugen die dann auch indexiert werden. Nur so kann ich mir den Zuwachs erklären. Kenne aber den Immomanager nichts. Klingt aber nach einem Verdächtigen :D

Hast Du mal geprüft, ob viele Seiten bei der Suche angezeigt werden, die es bei Dir gar nicht gibt?

Leider nimmt Contao - vermutlich nur mit bestimmten Erweiterungen - im Suchindex irgendwie alles auf, was auf die Domain abgefragt wird. So wird dann der Suchindex immer größer durch Robots oder einfach falsche Eingaben.
Ich persönlich habe daher die automatische Indizierung ausgeschaltet und lösche regelmäßig den Index und baue ihn manuell wieder auf.

Die beiden Links müssten eigentlich zum Thema passen.
Sucherergebnisse in tl_search können manipuliert werden
Suchindex enthält ungültige Links

Hey,

also erstmal danke für Eure Anregungen. Es ist auf jeden Fall etwas, was durch das Modul erzeugt wird.

Aber erstmal würde ich gerne noch mal nachhaken ob es denn die Möglichkeit gibt von außerhalb (z.B. mit einem Script) den Suchindex zu leeren (das würde ja zur Not über einen Cronjob gehen der die Datenbanktabelle leert) und vor allem Dingen neu aufzubauen.

Ich wäre da wirklich dankbar, wenn jemand eine Idee hat, wie diese Systemfunktionen genutzt werden könnten.

Zitat:

---

Zitat von Kahmoon

Hmm der über die Systemwartung dürfte aber keine unterschiedliche Größe zum "natürlich" erstellten haben...da ist doch was faul? Die Systemwartung ruft ja auch nur alle Seiten auf die man aufrufen kann. Wie ein User auch.

---

Naja, es kann durchaus sein, dass es mehr im Frontend aufrufbare Seiten gibt, als über die Systemwartung ersichtlich ist. Ich bin mir zB nicht sicher, ob paginierte Seiten da immer komplett drin sind bspw. Und je nach Extension kann es vorkommen, dass auf einer Seite (mit irgendeinem Reader Modul bspw.) viele verschiedene Kombinationen von Variablen existieren können, die wohl kaum alle per getSearchablePages Hook abgedeckt sind.

Sieh' dir als einfaches Beispiel die Tags Extension an. Da kann auf jeder Seite noch zusätzliche eine Variante existieren mit .../tag/... Und die Tags Extension implementiert den getSearchablePages Hook gar nicht - daher werden alle per Tag gefilterten Seitenaufrufe auch nicht in den Index aufgenommen, wenn man den Index im Backend neu aufbaut.

Tags vergrößert bei mir aber den Suchindex nicht wenn ich Tagseiten im Frontend aufrufe.

Ich klinke mich hier mal in die Diskussion um den Suchindex ein, wenngleich ich etwas andere, größere Probleme mit dieser Funktion habe.

Ich habe vor ein paar Tagen ein Online-Branchenbuch gelaunched, das natürlich eine Volltextsuche beinhaltet. Organisiert ist das Ganze technisch wie folgt: Es gibt eine Seite, die für jedes Kundenprofil wiederum einen Artikel beinhaltet. Diese Seite wird über die Suche indiziert. Den Aufbau dex Suchindex kann man hier sehen: Systemwartung - Suchindex aufbauen.pdf.

Nach der Systemwartung wird alles perfekt gefunden, der Aufbau des Suchindex funktioniert offenbar einwandfrei.

ABER: Stück für Stück, ohne das irgendetwas am System gemacht wird, zerlegt sich der Suchindex selbst. Nach und nach wird immer weniger gefunden. Ich habe hier einmal zwei Dateien angehängt, die das zeigen:
1. Direkt nach dem Aufbau des Suchindex über die Systemwartung um 8:37 Uhr: Suchergebnisse-01.pdf
2. Bereits um 9:17 Uhr wird der erste Eintrag nicht mehr gefunden: Suchergebnisse-02.pdf

Ich weiß, dass irgendwo im Hintergrund Pseudo-Cronjobs laufen, die auch den Suchindex aktualisieren und aufbauen sollen. Offenbar wird der Suchindex aber abgebaut?!?!?!?! Wie ist das möglich?
Was ich auch feststellen konnte ist ebenso kurios. Direkt nach dem Aufbau des Suchindex werden z. B. bei Eingabe des Suchbegriffs "Marketing" verschiedene Kundenprofile gefunden. Nach einiger Zeit aber nicht mehr. Die Profile werden nur noch dann gefunden, wenn ich "marketing", also klein geschrieben eingebe. Das System hat sich selbständig auf case sensitive umgestellt?!?!??

Ich muss sagen, ich habe schon echt eine Menge an Kuriositäten im Bereich Programmierung erlebt. Welcher Entwickler kennt das nicht. Aber hier bin ich wirklich absolut ratlos und sprachlos, wie so etwas möglich ist.

Ich habe im Backend übrigens den Command Scheduler schon deaktiviert, hat aber nichts geholfen. Das System ist aktuell Contao 3.5.2.

Ganz offenbar liegt hier ein ganz massiver Bug vor. Es wäre mir schon geholfen, wenn ich wüsste, wie ich diese versteckten Automatismen nachhaltig abschalten kann.

Würde mich extrem freuen, wenn mir irgend jemand hier weiterhelfen könnte. Denn die Suchfunktion in einem Branchenbuch ist ja nicht irgendwie eine Kleinigkeit, sondern eher von sehr zentraler Bedeutung.

Grüße und Dank im Voraus
Sitting Bull

Validiere deine Installation mit dem Contao Check und poste alle Extensions die du installiert hast.

Zitat:

---

Zitat von Spooky

Validiere deine Installation mit dem Contao Check und poste alle Extensions die du installiert hast.

---

Hi Spooky,

danke erst mal für Dein superschnelles Feedback!

Habe den Check gemacht. Sagt mir folgendes:

Version: Found a Contao 3.4.5 installation (hatte ich im Post vorhin falsch angegeben, sorry)
Corrupt files: robots.txt
Your installation is not up to date.

Ich weiß natürlich nicht, inwieweit sich da was auf den Suchindex auswirken kann. Was bedeutet genau "Your installation is not up to date."? Ich könnte natürlich auf 3.5.2 updaten. Aber das ist im Prinzip ja nicht generell nötig?!

Corrupt robots.txt sagt mir allerdings auch nicht viel?! Habe ich selbst nicht angelegt.

Installierte Extensions:

• ce-access
• dma_elementgenerator
• efg
• galerie
• mod_articlefilter
• page_images
• randomarticle
• rocksolid-columns
• rocksolid-slider
• sharebuttons
• superfish
• xls_export

Grüße
Sitting Bull

Ich hab noch was zu dem Thema ausgegraben ...

Ein sehr alter Thread von 2010, der belegt, vergleichbare Probs gabs auch da schon mit dem Suchindex und könnten tatsächlich mit von Erweiterungen gesetzten URL-Parametern verursacht werden:
https://community.contao.org/de/show...puliert-werden

Und einer, der bis 2014 reicht - somit noch recht aktuell, aber auch viel früher begann - ein Beispiel für Datenbankmanipulation mittels cron.php und was dabei speziell zu beachten ist:
https://community.contao.org/de/show...ob-anlegen-wie

Zitat:

---

Zitat von Spooky

Validiere deine Installation mit dem Contao Check und poste alle Extensions die du installiert hast.

---

Hi Spooky,

habe in einem anderen Post gelesen, dass das mit der "Installation not up to date" mit der robots.txt zusammenhängt. Habe daher die Original robots.txt noch mal eingespielt. Nun zeigt der Check auch:

Version: Found a Contao 3.4.5 installation.

Your installation is up to date.

Hier kann also der Fehler offenbar nicht liegen.

Zitat:

---

Zitat von Sitting Bull

Corrupt files: robots.txt

---

Die robots.txt verbietet bloß den Bot-Zugriff auf einige Systemordner u. -dateien, u. a. auch auf cron.php. Und hat normalerweise nur wenige Zeilen Inhalt, da reicht ein Blick zum Vergleich mit der Core-Version. Glaub eher nicht, dass die was damit zu tun hat.

Von den Extensions scheinen mir dma_elementgenerator, efg und mod_articlefilter am ehesten verdächtige Kandidaten. Letztere nur, weil ich die selber noch nie verwendete. Mit efg hatte ich noch nie Probleme, doch man hört ja, soll für Cto 3 nicht mehr so das Wahre sein.

Edit: Ups, zu spät. An der robots.txt lags also wirklich nicht.

Zitat:

---

Zitat von soweit_ok

Ich hab noch was zu dem Thema ausgegraben ...

Ein sehr alter Thread von 2010, der belegt, vergleichbare Probs gabs auch da schon mit dem Suchindex und könnten tatsächlich mit von Erweiterungen gesetzten URL-Parametern verursacht werden:
https://community.contao.org/de/show...puliert-werden

Und einer, der bis 2014 reicht - somit noch recht aktuell, aber auch viel früher begann - ein Beispiel für Datenbankmanipulation mittels cron.php und was dabei speziell zu beachten ist:
https://community.contao.org/de/show...ob-anlegen-wie

---

Schau ich mal in Ruhe an, ob das was mit dem Problem zu tun haben könnte und noch aktuell ist. Danke erst mal.

Niemand mehr eine Idee zu diesem Problem?

Ich denke, die Suchmaschine ist ja ein ziemlich zentrales Core-Element von Contao. Wäre also schon schön, wenn man das auch nutzen könnte. Es würde mir ja auch schon sehr helfen, einfach diese ganzen Indiziereungmechnismen, die da offenbar im Hintergrund laufen, komplett totzuschalten. Denn ein unkontrollierbarer Cron-Job, der den Index langsam auslöscht, ist absolut unbrauchbar. Bin also für jeden Hinweis dankbar. Man traut sich sonst ja gar nicht mehr, eine Website mit Suchfunktion anzubieten. Bei Wordpress hat man gleich eine ganze Flotte an Such-Extensions aller Art. Aber hier gibt es ja leider bisher nur das Core-System.

Ich kann gern auch für Interessierte, bzw. Core-Entwickler, das Gesamtsystem zum Testen zur Verfügung stellen, damit dieses kuriose Verhalten überhaupt einmal nachvollziehbar wird.

Das Problem ist ja, dass man solche Bugs manchmal gar nicht bemerkt. Suche wird implementiert. Index wird übers Backend aufgebaut. Man testet diverse Begriffe. Alles funktioniert reibungslos. Ich bin nie im Leben auf die Idee gekommen, dass sich das System quasi im Alleingang selbst zerlegen könnte, bis mich der Kunde darauf aufmerksam gemacht hat, dass die Treffer immer weniger werden?!

Ich denke, ich werde hier mal ein Ticket aufmachen müssen.

Danke für alle kommenden Ideen und Grüße
Sitting Bull

Zitat:

---

Zitat von Sitting Bull

Es würde mir ja auch schon sehr helfen, einfach diese ganzen Indiziereungmechnismen, die da offenbar im Hintergrund laufen, komplett totzuschalten. Denn ein unkontrollierbarer Cron-Job, der den Index langsam auslöscht, ist absolut unbrauchbar.

---

Du hast den Frontend Cron ja deaktiviert, oder? Wenn du die cron.php nun nicht selbst aufrufst, wird nie ein CronJob gestartet.

Seiten kommen allerdings auch einfach durch den Aufruf im Frontend in den Index.

Zitat:

---

Zitat von Sitting Bull

Aber hier gibt es ja leider bisher nur das Core-System.

---

Es gibt zB [CearchPro] (wobei dies unter Umständen sowieso den normalen Suchindex benutzt, bin mir jetzt nicht sicher) und irgendeine Kostenpflichtige Search Extension, deren Name mir gerade entfallen ist.

Zitat:

---

Zitat von Sitting Bull

Ich kann gern auch für Interessierte, bzw. Core-Entwickler, das Gesamtsystem zum Testen zur Verfügung stellen, damit dieses kuriose Verhalten überhaupt einmal nachvollziehbar wird.

---

Wird wohl nötig sein, andernfalls wird man den Fehler nicht finden können, denke ich.

Hi Spooky,

ja, der Cron-Job ist über "Command Scheduler deaktivieren" eigentlich totgeschaltet. Ob man diesen Frontentindizierer auch irgendwie abmurksen kann, weiß ich leider nicht. Das wäre aber mehr als hilfreich. Ist mir eh nicht klar, was der soll?!

Ich schreib dann morgen mal ein Ticket.

Danke
Sitting Bull

Zitat:

---

Zitat von Sitting Bull

Ist mir eh nicht klar, was der soll?!

---

Äh, du willst ja, dass die Contao Suche funktioniert, oder? ;) Wenn keine Seiten in den Suchindex aufgenommen werden, werden auch keine Seiten mehr gefunden.

Zitat:

---

Zitat von Spooky

Äh, du willst ja, dass die Contao Suche funktioniert, oder? ;) Wenn keine Seiten in den Suchindex aufgenommen werden, werden auch keine Seiten mehr gefunden.

---

Ich baue den Index lieber selbst über das Backend auf. Ist ja kein Problem und funktioniert einwandfrei.

Wenn ich die andere Automatik verstanden habe, werden nur Seiten indiziert, die zuvor bereits besucht wurden. D. h. doch im Prinzip. Eine Seite, die besucht wurde, wird auch nie über die Suche gefunden werden können. Wenn das tatsächlich so sein sollte, fände ich das mehr als komisch ;)

Aber, wie gesagt. Leider funktioniert der Mechanismus ja auch irgendwie nicht. Ich habe gestern am späten Abend den Suchindex über das Backend komplett aufgebaut. Alles wurde perfekt gefunden. Die Systemwartungt zeigte 234 Einträge (Kundenprofile) an. Heute morgen um 6:55 Uhr habe ich getestet. Nichts wurde mehr gefunden. Laut Systemwartung war der Index won 234 auf 38 Einträge geschrumpft!!!

Automatismen sind sehr gut, wenn sie funktionieren. Aber hier handelt es sich offenbar eher um eine Art Selbstzerstörung :eek:

Zitat:

---

Zitat von Sitting Bull

Wenn ich die andere Automatik verstanden habe, werden nur Seiten indiziert, die zuvor bereits besucht wurden. D. h. doch im Prinzip. Eine Seite, die besucht wurde, wird auch nie über die Suche gefunden werden können.

---

? Nein, das hast du falsch verstanden. Seiten kommen in den Suchindex entweder, wenn du im Backend den Suchindex neu aufbauen lässt, oder wenn die Seite im Frontend aufgerufen wird.

Zitat:

---

Zitat von Sitting Bull

Aber, wie gesagt. Leider funktioniert der Mechanismus ja auch irgendwie nicht. Ich habe gestern am späten Abend den Suchindex über das Backend komplett aufgebaut. Alles wurde perfekt gefunden. Die Systemwartungt zeigte 234 Einträge (Kundenprofile) an. Heute morgen um 6:55 Uhr habe ich getestet. Nichts wurde mehr gefunden. Laut Systemwartung war der Index won 234 auf 38 Einträge geschrumpft!!!

---

Wie gesagt, hier liegt bei deiner Installation irgendein Problem vor. Von alleine verschwinden Seiten normalerweise nicht aus dem Suchindex.

Zitat:

---

Zitat von Spooky

? Nein, das hast du falsch verstanden. Seiten kommen in den Suchindex entweder, wenn du im Backend den Suchindex neu aufbauen lässt, oder wenn die Seite im Frontend aufgerufen wird.

---

Dann habe ich das doch völlig richtig verstanden ... "wenn die Seite im Frontend aufgerufen wird". Wenn sie aber nicht aufgerufen wird, kommt sie auch nicht in den Index?! Sie muss also erst einmal aufgerufen werden, damit man sie später über die Suche finden kann?!?!

Den Backend-Mechanismus habe ich ja, wie gesagt, abgeschaltet. Muss also irgendwie noch was anderes laufen?! Das würde ich sehr gern auch abschalten, weiß aber nicht wie.

Zitat:

---

Zitat von Sitting Bull

Dann habe ich das doch völlig richtig verstanden ... "wenn die Seite im Frontend aufgerufen wird". Wenn sie aber nicht aufgerufen wird, kommt sie auch nicht in den Index?

---

Ok, du hattest geschrieben:

Zitat:

---

Zitat von Sitting Bull

D. h. doch im Prinzip. eine Seite, die besucht wurde, wird auch nie über die Suche gefunden werden können.

---

;)

Zitat:

---

Zitat von Sitting Bull

Wenn sie aber nicht aufgerufen wird, kommt sie auch nicht in den Index?! Sie muss also erst einmal aufgerufen werden, damit man sie später über die Suche finden kann?!?!

---

Nein, wie gesagt, entweder durch das Aufrufen der Seite im Frontend oder über "Suchindex neu aufbauen" im Backend.

Zitat:

---

Zitat von Sitting Bull

Muss also irgendwie noch was anderes laufen?! Das würde ich sehr gern auch abschalten, weiß aber nicht wie.

---

Irgendwas, was nur bei deiner Installation so passiert. Wie gesagt, normalerweise wird nichts aus dem Suchindex einfach so gelöscht.

Ja, wie gesagt, ich würde sehr gern auf alle Automatismen verzichten, solange sie nicht 100% funktionieren. Leider habe ich keinen Hinweis gefunden, wie man das anstellen kann?!

Ich glaube du verstehst es noch falsch: irgendwas bei deiner Installation läuft nicht normal. Du musst das Problem genauer analysieren. Denn es gibt keinen Automatismus von Contao, der Seiten aus dem Suchindex löscht, so wie du es beschreibst. Contao löscht nie Seiten aus dem Suchindex von selbst. Über TL_CRON wird nur der Such-Cache gelöscht, nicht der Suchindex selbst.

Zitat:

---

Zitat von Spooky

Ich glaube du verstehst es noch falsch: irgendwas bei deiner Installation läuft nicht normal. Du musst das Problem genauer analysieren. Denn es gibt keinen Automatismus von Contao, der Seiten aus dem Suchindex löscht, so wie du es beschreibst. Contao löscht nie Seiten aus dem Suchindex von selbst. Über TL_CRON wird nur der Such-Cache gelöscht, nicht der Suchindex selbst.

---

Ok, das werde ich mal checken.

Contao löscht übrigens doch Seiten aus dem Index, wenn für die aufgerufene URL keine Seite gefunden wurde - also jedesmal wenn die 404 Seite von Contao generiert wird, wird die entsprechende URL auch aus dem Suchindex gelöscht. Ansonsten werden nur Einträge aus tl_search_index gelöscht, wenn ein neuer Eintrag für die selbe URL hinzukommt.

Zitat:

---

Zitat von Spooky

Contao löscht übrigens doch Seiten aus dem Index, wenn für die aufgerufene URL keine Seite gefunden wurde - also jedesmal wenn die 404 Seite von Contao generiert wird, wird die entsprechende URL auch aus dem Suchindex gelöscht. Ansonsten werden nur Einträge aus tl_search_index gelöscht, wenn ein neuer Eintrag für die selbe URL hinzukommt.

---

Aber die Seiten sind alle zugreifbar. Kann es sein, dass versehentlich irgendwo eine 404 generiert wird? Und wenn ja, wie oder wo kann man das sehen?

Nur am Rande:
Das erstellen des Suchindexes im Backend macht nichts anderes wie die Seite "Durchklicken" via Ajax. Somit kommt das erstellen des Index im CMS dem durchklicken im FE gleich.
Via Ajax wird jede einzelne URL aufgerufen und somit der Index erstellt. Wahlweise mit angemeldetem Mitglied.

Zitat:

---

Zitat von Sitting Bull

Aber die Seiten sind alle zugreifbar.

---

Ich habe gerade festgestellt, dass z. B. bei Eingabe einer unbekannten Unterseite, z. B. www.beispiel.de/aslfkdfl eine leere Seite angezeigt wird. bei Eingabe von www.beispiel.de/aslfkdfl.html hingegen kommt, wie eingestellt die 404-Weiterleitung auf die Startseite zum tragen.

Diese leere Seite enthält folgende Quellcode:

HTML-Code:

---

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <style type="text/css">
            html, body, #partner, iframe {
                height:100%;
                width:100%;
                margin:0;
                padding:0;
                border:0;
                outline:0;
                font-size:100%;
                vertical-align:baseline;
                background:transparent;
            }
            body {
                overflow:hidden;
            }
        </style>
        <meta content="NOW" name="expires">
        <meta content="index, follow, all" name="GOOGLEBOT">
        <meta content="index, follow, all" name="robots">
        <!-- Following Meta-Tag fixes scaling-issues on mobile devices -->
        <meta content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" name="viewport">
    </head>
    <body>
        <div id="partner"></div>
        <script type="text/javascript">
            document.write(
                    '<script type="text/javascript" language="JavaScript"'
                            + 'src="//sedoparking.com/frmpark/'
                            + window.location.host + '/'
                            + '1und1parking6'
                            + '/park.js">'
                    + '<\/script>'
            );
        </script>
    </body>
</html>

---

Das System liegt auf einem 1&1-Server. Wie kommt diese Seite zustande, und warum wird hier nicht umgeleitet? Bzw. kennt jemand einen htaccess-Eintrag, der auch diese Seiten umleiten kann?

Zitat:

---

Zitat von Zero

Nur am Rande:
Das erstellen des Suchindexes im Backend macht nichts anderes wie die Seite "Durchklicken" via Ajax. Somit kommt das erstellen des Index im CMS dem durchklicken im FE gleich.
Via Ajax wird jede einzelne URL aufgerufen und somit der Index erstellt. Wahlweise mit angemeldetem Mitglied.

---

Ist das definitiv so? Oder kommen hier vielleicht doch andere Skripten zum Tragen, die vielleicht nicht alles korrekt erfassen?

Ein Sache, die ich mir zumindest theoretisch noch vorstellen könnte, ist der Einsatz der dma_elementgenerator Extension. Denn die Kundenprofile sind hiermit angelegt, um eine einfache Verwaltung im Backend zu gewährleisten. Ist es möglich, dass diese von den Crons nicht erfasst werden oder zu Fehlern führen?

Im Prinzip wird der Such-Index der Website nur aus einer einzigen Unterseite aufgebaut, die für jeden Kunden einen eigenen Artikel enthält mit dem Kunden-Profil drin, das wiederum mit Hilfe der dma_elementgenerator Extension erstellt wurde. Wäre so etwas denkbar, oder ist das Quatsch?!?

Siehe z.B. hier: https://community.contao.org/de/show...nicht-gefunden

Zitat:

---

Zitat von Sitting Bull

Bzw. kennt jemand einen htaccess-Eintrag, der auch diese Seiten umleiten kann?

---

Ja, einfach

Code:

---

ErrorDocument 404 /index.php

---

eintragen :).

Zitat:

---

Zitat von Sitting Bull

Ein Sache, die ich mir zumindest theoretisch noch vorstellen könnte, ist der Einsatz der dma_elementgenerator Extension. Denn die Kundenprofile sind hiermit angelegt, um eine einfache Verwaltung im Backend zu gewährleisten. Ist es möglich, dass diese von den Crons nicht erfasst werden oder zu Fehlern führen?

Im Prinzip wird der Such-Index der Website nur aus einer einzigen Unterseite aufgebaut, die für jeden Kunden einen eigenen Artikel enthält mit dem Kunden-Profil drin, das wiederum mit Hilfe der dma_elementgenerator Extension erstellt wurde. Wäre so etwas denkbar, oder ist das Quatsch?!?

---

Sollte keinen Unterschied machen. Solange keine 404 Seite für eine URL generiert wird, sollte diese URL im Suchindex bleiben.

Zitat:

---

Zitat von Spooky

Ja, einfach

Code:

---

ErrorDocument 404 /index.php

---

eintragen :).


Sollte keinen Unterschied machen. Solange keine 404 Seite für eine URL generiert wird, sollte diese URL im Suchindex bleiben.

---

Danke, das hat schon mal geklappt, auch wenn es das Problem mit dem Suchindex vermutlich nicht löst. Warum aber schlägt denn hier nicht die Backend-Einstellung für 404 zu? Wieso muss man hier zusätzlich noch die htaccess anfassen? Ist das nur bei 1&1 so?

Nein, wird wahrscheinlich überall so sein. Für URLs mit Suffix greift das URL Rewriting der .htaccess.default von Contao. Für nicht existente Ordernamen sagt dir der Webserver, dass dieser Ordner nicht existiert. Mit

Code:

---

ErrorDocument 404 /index.php

---

legst du eine selbst definierte Fehlerseite für solche Fälle fest.

Sind auf den Seiten die indiziert werden die Erweiterungen efg, mod_article_filter, dma_elementgenerator aktiv?
Da der Abbau deiner Suchindexe ja recht schnell geht, würde ich die Erweiterungen einfach mal deaktivieren, einzeln, und schauen ob sich was ändert.

Zitat:

---

Zitat von Spooky

Contao löscht übrigens doch Seiten aus dem Index, wenn für die aufgerufene URL keine Seite gefunden wurde - also jedesmal wenn die 404 Seite von Contao generiert wird, wird die entsprechende URL auch aus dem Suchindex gelöscht. Ansonsten werden nur Einträge aus tl_search_index gelöscht, wenn ein neuer Eintrag für die selbe URL hinzukommt.

---

Wenn im Backend unter System-Log keine 404 Meldungen zu finden sind, normalerweise werden die dort ja protokolliert, dann bliebe ja nur die zweite Möglichkeit.
Quasi ein Löschen durch leeren Neueintrag oder so.

Hallo, ich habe das gleiche Problem mit der Suche.
Wörter die gestern noch funktioniert haben und einen Treffer geliefert hatten, werden heute nicht mehr gefunden, obwohl der Eintrag, der das Wort enthält schon älter ist und zwischendurch das hier durchgeführt wurde.

Leert die Tabellen tl_search und tl_search_index. Anschließend muss der Suchindex neu aufgebaut werden (siehe oben).

Nach Neuaufbau gibt es diese Werte: tl_search_index: 40192 Einträge, 2 MiB
Einen Tag später sieht es so aus: tl_search_index: 7000 Einträge, 1 MiB
Wo sind die ganzen Indizierungswerte hin?

Ich kann doch nicht jeden Tag den Index neu aufbauen lassen...nerv!

Zitat:

---

Zitat von jgrotstabel

Hallo zusammen,

hat jemand eine Idee wie ich den Contao Suchindex via z.B. Cronjob regelmäßig löschen [...] kann.

---

Da die Frage noch nicht beantwortet war und ich gerade selbst gesucht habe, hier ein externes PHP-Skript. Der Pfad zu initialize.php muß angepaßt werden:

PHP-Code:

---

<?php

// Contao einbinden
define('TL_MODE', 'FE');
require('../system/initialize.php');

class PurgeIndex extends Backend
{

    public function __construct()
    {
        parent::__construct();
    } // __construct

    public function run()
    {
        // Suchindex löschen
        \Automator::purgeSearchTables();
    
        echo "Suchindex geloescht";
    }
 
}

$objPurge = new PurgeIndex();
$objPurge->run();

---

Hallo Frank,

da dein Beitrag relativ aktuell ist, nehme ich an, dieses Script funktioniert auch in Contao 3.5.28?
Wenn ich das richtig sehe, wird hier der Suchindex nur gelöscht.
Hättest du eine Idee, wie man das Script so erweitert, dass der Index dann gleich wieder neu aufgebaut wird?

Gruß,
Ignatz

Von trilobit gibt es dazu ein Skript, das – z. B. per Cronjob ausgeführt – den Contao Suchindex automatisch neu aufbaut: https://www.trilobit.de/trilobits/de...suchindex.html

Hat jemand eine Ahnung, wie ich dieses Script erweitere, so dass auch geschützte Inhalte indexiert werden?