Druckbare Version
Hab jetzt vieles dazu gelesen, aber als Anwender komme ich nicht weiter. Wie richtet man den Cronjob ein, damit Backend-Suche funktioniert.
Meine Installation liegt auf einen gehosteten Webplatz, da habe ich kein Einfluß auf PHP Einstellungen.
Kann aber Cronjobs über die Oberfläche als Pfad (https://) anlegen. Würde das funktionieren, wenn ja welchen Pfad gibt man da ein?
Ich habe es damit versucht, klappt aber nicht:
Code:domain.at/vendor/bin/contao-console contao:cron
Webcron reicht nicht, du musst einen echten Cronjob anlegen.
In der Doku gibt es einen Abschnitt, der die Routeangibt, siehe https://docs.contao.org/dev/framewor...x.html#web-urlCode:https://www.domain.de/_contao/cron
Ich stehe vor einem ähnlichen Problem und versuche das Cronjob Framework über die Admin-Oberfläche von all-inkl zum Laufen zu bekommen. Gibt es dafür keine Lösung?
Bei all-inkl gibt es leider kein Crontab. Daher muss man den Cronjob per PHP und Shell-Skript anstoßen.
Exec ist schon sehr mächtig, daher habe ich das Skript in einen Unter-Ordner von /public gepackt.PHP-Code:<?php
exec("/usr/bin/php82 /www/htdocs/DEINE-W-NUMMERR/DEIN-CONTAO-ORDNER/vendor/bin/contao-console contao:cron");
echo "1"; // das kann nach erfolgreichem Test auch raus
?>
Bei mir sieht das dann so aus: contao/public/cron/contao-cron.php
Diesen Ordner habe ich mit einer htaccess/ Verzeichnisschutz abgesichert.
Benutzer und Passwort der htaccess übergebe ich beim Aufruf des Cronjobs über das all-inkl-Backend.
Man kann die Datei auch anders absichern. Z. B. mit einem GET-Parameter.
Dann legst du im Backend von all-inkl einen Cronjob an und befüllst ihn mit
Protokoll / Pfad: dem Pfad zum Skript
Beschreibung: frei wählbar
Ausführungsintervall
minütlich alle 1 Minuten
HTTP Benutzer: Benutzer des htaccess Schutzes
HTTP Passwort: Passwort des htaccess Schutzes
E-Mail-Adresse: deiner E-Mail-Adresse
Beschreibung als E-Mail-Betreff: ja
Cronjob ist aktiv: ja
Speichern.
Jetzt solltest du eine Minute später das, was bei echo oben im Skript steht, als E-Mail bekommen. Eventuell auch eine Fehlermeldung.
Wenn alles funktioniert, kannnst du das echo aus dem Skript nehmen und im Cronjob deine E-Mailadresse rausnehmen.
Wie verhält es sich mit dem Ausführungsintervall? Auf kleineren Seiten, auf denen nicht ständig im Backend gearbeitet wird, in welchem Abstand empfiehlt es sich, diesen laufen zu lassen? Ich habe bemerkt, dass der Index bei zu langem Intervall wieder verschwindet; allerdings konnte ich noch nicht feststellen, nach welcher Zeit dies geschieht.
Oder gibt es ein Argument, ihn in sehr kurzen Abständen auszuführen?
Der Cronjob muss minütlich ausgeführt werden.
Servus zusammen,
vielen Dank Malle für deine Ausführliche Beschreibung. Ich habe mich bis jetzt noch nie mit cronjobs auseinandergesetzt. Bin auch bei All-Inkl und hab alles gemacht und auch eine E-Mail erhalten. In der Mail steht dann nur eine Zeile mit den ***** wie es auch bei dem Beschreibungs-Link "Contao Cronjob-Framework" steht. Sonst steht bei mir nix in der Mail. Muß ich noch irgendwas anderes machen? Der Button "Suchindex aufbauen" ist bei mir immer noch inaktiv. Zeitintervall ist alle 1 Minute.
Danke für kurze Info.
Gruß Torsten
Deaktiviere und aktiviere den Cronjob, vielleicht stoßt er ihn dann an.
Hallo zusammen,
wollte die Backendsuche auch einmal testen, habe das bei allinkl so wie beschrieben angelegt.
Ich bekomme die Mails jede Minute mit Status 404.
Wo hab ich den Knoten produziert?
Stimmen die Zugangsdaten des pasßwortgeschützen Ordners?
Ich habs bisher ohne Passwortschutz versucht.
Sprich da muss ein Passwortschutz hin?
Beschreibe nochmal genau was du gemacht hast. Zeigt dazu evt. Screenshots.Zitat:
Zitat von planepix
Kenne mich da nicht aus, aber ich denke die Datei zu Schützen hat Sinn.
Die PHP-Version und den Pfad im Code vielleicht nochmals auf Richtigkeit überprüfen.
Wobei es am Pfad zur Datei selber liegen könnte, wenn es ein 404 ist, der muß sein:
Code:Domain.de/ortner/datei.php
Nach dem Post von Markus die Datei cron.php mit diesem Inhalt angelegt:Zitat:
Zitat von Spooky
Diese Datei dann unter „rc54.domain.com/public/cron/cron.php” abgelegt.PHP-Code:<?php
exec("/usr/bin/php83 /www/htdocs/wxxxxxx/rc54.domain.com/vendor/bin/contao-console contao:cron");
echo "1"; // das kann nach erfolgreichem Test auch raus
?>
Und diesen Pfad auch in den Cron-Settings bei allinkl eingetragen.
Anhang 27735
Der Pfad, den du bei All-Inkl. eingetragen hast ist falsch. public/ ist ja vermutlich dein DocumentRoot, oder nicht?
Ja genau.
Das wars. Danke!!
Ich bin zu blöd.
Ich benutze Hetzner als Server und würde gerne meine Suchfunktion aktivieren und brauche dazu anscheinend ein Studium...
Wer kann mir sagen was ich wo eintragen muss? Anhang 27956
Ich werde da echt nicht schlau draus.
Vielen lieben Dank.
Zitat:
Zitat von flensburger-stadtanzeig
- Interpreter: die PHP Version der Contao Installation
- Skript (absoluter Pfad): der absolute Pfad zur bin/console Datei der Contao Installation am Server + contao:cron, z.B.: /usr/home/foobar/public_html/example.com/bin/contao-console contao:cron
- Ausführungszeiten: Manuell: - oder Freitext mit * * * * *
- Minuten: Jede Minute
- Stunden: Jede Stunde
- Tage: Jeden Tag
- Monate: Jeden Monat
- Wochentage: N/A
- Exklusive Ausführung: Aktiv
- Zusammenfassung: * * * * * /usr/bin/php83 /usr/home/foobar/public_html/example.com/bin/contao-console contao:cron
https://community.contao.org/de/atta...1&d=1751799929
In der Übersicht bei E-Mail-Benachrichtigung an: dann noch deine E-Mail Adresse eintragen (oder wer auch immer technisch verantwortlich ist).
Wir haben gestern Abend beim Berliner Stammtisch darüber gesprochen, wie man den minütlichen Cron bei All-Inkl aufsetzen kann.
Ich habe das heute noch einmal in meiner Installation (PHP 8.4, Contao 5.6.4 mit der Demoseite) probiert, aber die Backendsuche ist nicht sichtbar.
Im Cron habe ich einen minütlichen Aufruf einer start.php:
Dieses PHP ruft dann ein Shellscript auf test.sh:PHP-Code:<?php
exec("/bin/bash /www/htdocs/wxxx/test.sh 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
was wiederum den Contao:cron triggert.Code:#!/bin/bash
cd /www/htdocs/wxxx/contao56/
/bin/php84 /www/htdocs/wxxx/contao56/vendor/bin/contao-console contao:cron
Der normale Aufruf des Shell-Scripts liefert ein leeres Array zurück (das kann ja Ok sein).
Ich habe dann in vendor/bin/contao-console eine Textausgabe eingefügt, diese kommt dann auch als Ergebnis zurück.
Dann habe ich diese Ausgabe in vendor/contao/manager-bundle/bin/contao-console eingefügt, auch hier kommt der Text dann als Ergebnis zurück.
Dann habe ich die Übergabeparameter überprüft, die console wird auch mit contao:cron als Parameter aufgerufen.
Ich denke, das ist der Beweis, dass der Aufruf soweit stimmt, er erfolgt auch jede Minute, trotzdem ist keine Spur von der Backensuche zu finden.
Woran kann es noch liegen, dass die Suche fehlt?
Soweit ich weiß funktioniert bei All-Inkl. die Backend Suche generell nicht, da All-Inkl. die Einsicht der Prozesse mit ps nicht erlaubt. Du könntest dich gemeinsam mit Christian Feneberg bei All-Inkl. diesbezüglich beschweren ;)
Spannend.
Das ging bei einer 5.5 Installation noch bei allinkl, in 5.6 wie beschrieben nicht mehr.
Count me in, um bei allinkl nachzuhaken.
Ok, das ps-Kommando im SSH-Terminal funktiniert hier nicht, das kann ein Grund sein.
Aber in der 5.4 und 5.5 ging es ja wohl, ist die Nutzung des ps jetzt ab 5.6 neu hinzugekommen?
Nein, es ist etwas weggefallen: https://github.com/Toflar/cronjob-supervisor/pull/6
Ich habe das im Ticket hinzugefügt:
https://github.com/Toflar/cronjob-su...ent-3501839489
Du musst dich bei All-Inkl. beschweren (siehe oben).Zitat:
Zitat von do_while
Ich habe gerade mal nett bei All-Inkl angefragt, ob sie dazu eine Lösung finden können.
Du kannst ihnen auch gleich die richtige Lösung sagen. /proc mit hidepid=2 mounten, damit jeder User nur die eigenen Prozesse sehen kann (so wie es bspw. bei Hostingwerk und Hetzner bereits gemacht wird). Siehe auch https://github.com/Toflar/cronjob-su...ent-3501915494
Vielleicht könnt ihr mir auch weiterhelfen. Ich wollte ebenfalls die Backend-Suche aktivieren und habe dafür erfolgreich den Cronjob aktiviert. Der wird ausgeführt und läuft auch durch. Noch bevor ich aber die Backend-Suche in der config.yaml aktiviert habe, erhalte ich folgende Meldungen im Log:
Ich hätte erwartet, dass es gar nicht so weit kommt, da die Backend-Suche ja per Default inaktiv ist. Gleichzeitig frage ich mich, welche database locked sein sollte?!Code:[2025-11-10T11:56:40.019794+00:00] contao.error.ERROR: Message "Contao\CoreBundle\Messenger\Message\BackendSearch\ReindexMessage" failed: "Handling "Contao\CoreBundle\Messenger\Message\BackendSearch\ReindexMessage" failed: An exception occurred while executing a query: Unable to execute statement: database is locked" {"exception":"[object] (Symfony\\Component\\Messenger\\Exception\\HandlerFailedException(code: 0): Handling \"Contao\\CoreBundle\\Messenger\\Message\\BackendSearch\\ReindexMessage\" failed: An exception occurred while executing a query: Unable to execute statement: database is locked at /var/customers/webs/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php:124)\n[previous exception] [object] (Loupe\\Loupe\\Exception\\IndexException(code: 0): An exception occurred while executing a query: Unable to execute statement: database is locked at /var/customers/webs/vendor/loupe/loupe/src/Internal/Index/Indexer.php:115)\n[previous exception] [object] (Doctrine\\DBAL\\Exception\\LockWaitTimeoutException(code: 5): An exception occurred while executing a query: Unable to execute statement: database is locked at /var/customers/webs/vendor/doctrine/dbal/src/Driver/API/SQLite/ExceptionConverter.php:32)\n[previous exception] [object] (Doctrine\\DBAL\\Driver\\SQLite3\\Exception(code: 5): Unable to execute statement: database is locked at /var/customers/webs/vendor/doctrine/dbal/src/Driver/SQLite3/Exception.php:12)\n[previous exception] [object] (SQLite3Exception(code: 5): Unable to execute statement: database is locked at /var/customers/webs/vendor/doctrine/dbal/src/Driver/SQLite3/Statement.php:113)","contao":{"Contao\\CoreBundle\\Monolog\\ContaoContext":"{\"func\":\"Contao\\\\CoreBundle\\\\Messenger\\\\EventListener\\\\MessageListener::onWorkerMessageFailed\",\"action\":\"ERROR\",\"username\":\"N\\/A\",\"browser\":\"N\\/A\",\"uri\":null,\"pageId\":null}"}} {"contao":{"Contao\\CoreBundle\\Monolog\\ContaoContext":"{\"func\":\"Contao\\\\CoreBundle\\\\Messenger\\\\EventListener\\\\MessageListener::onWorkerMessageFailed\",\"action\":\"ERROR\",\"username\":\"N\\/A\",\"browser\":\"N\\/A\",\"uri\":null,\"pageId\":null}"}}
[2025-11-10T11:56:40.022491+00:00] messenger.INFO: Rejected message Contao\CoreBundle\Messenger\Message\BackendSearch\ReindexMessage will be sent to the failure transport Symfony\Component\Messenger\Bridge\Doctrine\Transport\DoctrineTransport. {"class":"Contao\\CoreBundle\\Messenger\\Message\\BackendSearch\\ReindexMessage","transport":"Symfony\\Component\\Messenger\\Bridge\\Doctrine\\Transport\\DoctrineTransport"} []
Und das beste ist: die Backend-Suche funktioniert.
Was mache ich hier falsch?
Die Backend Suche ist in der Contao Managed Edition von Haus as aktiviert.
Wenn ichausführe, erhalte ich:Code:vendor/bin/contao-console config:dump-reference contao
Müsste dort dann nicht true stehen?Code:backend_search:
enabled: false
# The DSN of the search adapter.
dsn: ~
# The name of the search index
index_name: contao_backend
Aber auch wenn sie standardmäßig aktiv ist: Wieso erhalte ich die Fehlermeldung? Und warum funktioniert die Suche dann trotzdem?
Mit config:dump-reference lässt du dir nur die Referenz ausgeben. Den tatsächlichen Stand siehst du mit debug:config. z.B.:Zitat:
Zitat von witschi87
Code:$ bin/console debug:config contao backend_search
Current configuration for "contao.backend_search"
=================================================
enabled: true
dsn: 'loupe://…/var/loupe'
index_name: contao_backend
Ich habe Heute eine Antwort von All-Inkl bekommen, nachdem ich bei der ersten Ablehnung dann Yannicks Beitrag gepostet habe.
Hier nun die finale Antwort von Heute:
Dann ist es jetzt offenbar so.Code:... vielen Dank für Ihre Anfrage.
Unsere Techniker haben dazu noch einmal Rücksprache gehalten. Jedoch bleibt, auch mit der Verwendung des Mounts durch die Option "hidepids",
ein Zugriff auf Shared-Servern auf das Kommando "ps" nicht gestattet.
Bei weiteren Fragen stehen wir Ihnen gern zur Verfügung.
Mit freundlichen Grüßen
Supportteam
Ich würde weiter nachhaken, mit welcher Begründung das so bleibt.