Echten Cronjob erstellen

Guten Tag,

für ein Projekt brauche ich einen zuverlässigen Cronjob der zu einem bestimmten Zeitpunkt Mails versendet. Das Hosting ist Hostingwerk. Ich habe vom Betreiber folgende Info erhalten, dass ich auf der Kommandozeile mittels crontab -e beliebe Cronjobs anlegen kann.

Leider bin ich hier ABSOLUTER Neuling und weiss nicht mal welche Kommandozeile hier gemeint ist und wie ich hier anfangen würde.

Ich wäre sehr dankbar, wenn mir jemand auf die Sprünge helfen würde und mir mit Stichpunkten oder gar einer Anleitung, wie ich dies schritt für schritt angehe, weiterhelfen könnte.

Vielen Dank im Vorraus.

Zitat:

---

Zitat von Nacht69

Leider bin ich hier ABSOLUTER Neuling und weiss nicht mal welche Kommandozeile hier gemeint ist und wie ich hier anfangen würde.

---

Per SSH auf den Server verbinden, dann auf der Konsole crontab -e eingeben.

Zitat:

---

Zitat von Spooky

Per SSH auf den Server verbinden, dann auf der Konsole crontab -e eingeben.

---

Vielen Dank - das hilft mir schon mal weiter.

Noch eine generelle Frage: Wenn ich hier einen Cronjob einrichte der alle 5 Minuten das Frontend aufruft, sollte der Contao Cronjob auch alle 5 Minuten zuverlässig aufgerufen werden, oder? So könnte ich dann über das Contao backend die verschiedenen Funktionen steuern.

Nein, wenn du einen echten Cronjob einrichtest, dann fügst du

Code:

---

contao:
    localconfig:
        disableCron: true

---

in deiner config.yaml hinzu und lässt über den Cronjob contao:cron ausführen. Also zB:

Code:

---

* * * * * php /path/to/contao/vendor/bin/contao-console contao:cron

---

Siehe https://docs.contao.org/dev/framewor.../#command-line

Zitat:

---

Zitat von Spooky

Nein, wenn du einen echten Cronjob einrichtest, dann fügst du

Code:

---

contao:
    localconfig:
        disableCron: true

---

in deiner config.yaml hinzu und lässt über den Cronjob contao:cron ausführen. Also zB:

Code:

---

* * * * * php /path/to/contao/vendor/bin/contao-console contao:cron

---

Siehe https://docs.contao.org/dev/framewor.../#command-line

---

Ah verstehe! Vielen Dank!

dh. die cronjobs funktionieren alle genau so wie vorher nur dass der Auslöser nicht mehr das Aufrufen des Frontends ist, sondern der Cronjob vom Server?

Genau, ja

Zitat:

---

Zitat von Spooky

Genau, ja

---

Das mit dem Cronjob hat schon mal geklappt. Jetzt funktionieren die bestehenden Cronjobs leider aber nur noch zum Teil wie gehabt.

PHP-Code:

---

$serverurl = (empty($_SERVER['HTTPS'])) ? 'http' : 'https';
        $serverurl .='://'.$_SERVER['HTTP_HOST'];        
        
        $url=$serverurl."/bundles/ordner/ajax/ ....... ";
        $objects = fopen ($url, "r"); 


---

findet er nicht mehr (liegt wohl am $_SERVER der nicht mehr übergeben wird). In der Doc steht dass man dies in der Website Root hinterlegen soll. Das hätte ich gemacht (schon immer) - also unter Webseiten Startpunkt - Domain (oder ist hier was anderes gemeint?)

PHP-Code:

---

# config/parameters.yaml
parameters:
    router.request_context.host: 'example.org'
    router.request_context.scheme: 'https' 


---

das kann ich denke ich mal nicht machen, da auf der Installation verschiedene Domains verschiedener Kunden liegen. Hier muss ja die Sitemap auch für verschiedene Domains gelten.

PHP-Code:

---

$filenames[] = '../web/bundles/..........'; 

mit file_exists findet er ebenfalls nicht mehr .... ist hier nun von einen anderen Ordner auszugehen? Wenn ja von welchem? 


---

Vielen Dank schon mal.

Also dein Cronjob scheint einen HTTP Context zu brauchen? Was genau macht dein Cronjob?

Zitat:

---

Zitat von Spooky

Also dein Cronjob scheint einen HTTP Context zu brauchen? Was genau macht dein Cronjob?

---

der Cronjob selber ruft verschiedene php Dateien auf die dann weiteres machen. zB Webcam Bild holen und verarbeiten, Buchungsdaten vom Hotelprogramm per json holen und verarbeiten usw usw usw.

laut doku ist das ja auch wichtig für die Erstellung der Sitemap oder?

Zitat:

---

Zitat von Nacht69

der Cronjob selber ruft verschiedene php Dateien auf die dann weiteres machen. zB Webcam Bild holen und verarbeiten, Buchungsdaten vom Hotelprogramm per json holen und verarbeiten usw usw usw.

---

Hört sich so an, wie wenn du das generall mal runderneuern solltest ;). Jeder Job sein eigener Service. Und du solltest die ganzen Dinge auch nochmal dahin gehend prüfen warum du einen HTTP Context brauchst bzw. ob das überhaupt wirklich notwendig ist.

Zitat:

---

Zitat von Nacht69

laut doku ist das ja auch wichtig für die Erstellung der Sitemap oder?

---

Die Generierung der Sitemap (in Contao 4.9) braucht keinen HTTP Context.

Zitat:

---

Zitat von Spooky

Hört sich so an, wie wenn du das generall mal runderneuern solltest ;). Jeder Job sein eigener Service. Und du solltest die ganzen Dinge auch nochmal dahin gehend prüfen warum du einen HTTP Context brauchst bzw. ob das überhaupt wirklich notwendig ist.

Die Generierung der Sitemap (in Contao 4.9) braucht keinen HTTP Context.

---

jo natürlich aber das ist ein zu groß um es nochmal neu aufzubauen (zumindest zur Zeit)

Da wären noch zwei fragen:

1. brauche ich für relative Pfade ebenfalls einen Http Context? Wenn nein wieso funktioniert folgendes nicht mehr?

Code:

---

'../web/bundles/..........';

---

gehe ich nun von einen anderen Ordner aus? Wenn ja welchen?

2. Wenn ich

PHP-Code:

---

# config/parameters.yaml
parameters:
    router.request_context.host: 'example.org'
    router.request_context.scheme: 'https' 


---

eintrage - hätte dies auf die anderen Domains generelle Auswirkungen und würde das evtl einen HTTP context herstellen?

Danke

Zitat:

---

Zitat von Nacht69

1. brauche ich für relative Pfade ebenfalls einen Http Context? Wenn nein wieso funktioniert folgendes nicht mehr?

Code:

---

'../web/bundles/..........';

---

gehe ich nun von einen anderen Ordner aus? Wenn ja welchen?

---

Was genau willst du denn machen?

Zitat:

---

Zitat von Spooky

Was genau willst du denn machen?

---

statt:

PHP-Code:

---

    $url="https://domain.de/bundles/modulordner/ajax/new/datei.php";
        $objects = fopen ($url, "r"); 


---

etwas wie:

PHP-Code:

---

    $url="../web/bundles/modulordner/ajax/new/datei.php";
        $objects = fopen ($url, "r"); 


---

Uff, ich verstehe leider nicht was du da machst, das sieht jedenfalls nicht gut aus. Warum machst du ein fopen auf eine PHP Datei?

Zitat:

---

Zitat von Spooky

Uff, ich verstehe leider nicht was du da machst, das sieht jedenfalls nicht gut aus. Warum machst du ein fopen auf eine PHP Datei?

---

Ja das wär sicher anders um einiges besser. Das Modul wurde schon vor längerer Zeit und nicht von mir programmiert. Es gibt hald ca 20 php Dateien die im public Ordner einer eigenen Erweiterung liegen die alle unterschiedliche Aufgaben ausführen (Meistens json dateien holen diese verarbeiten und eine eigene Json Datei auf dem Server speichern. (wie zB belegungen bzw freie Zeiträumen Preisdaten usw vom Hotelprogramm) und diese müssen je nach Fall jede Minute, Stunde oder täglich ausgeführt werden.

Warscheinlich wurde diese herangehensweise verwendet weil mit fopen und fwrite die json dateien erstellet werden und das funktioniert hat.

Du würdest dies mit Funktionen im contao Ordner der Erweiterung machen oder? Dafür ist das ganze aber JETZT zu umfangreich. (eine neu Programmierung von mir ist eh in ein paar Monaten eingeplant). Ausserdem müsste ich mir erst ansehen, wie ich aus dem Cronjob auf diese Funktionen dann zugreifen kann.

Da die Erweiterung nur für einen bestimmten Kunden ist, kann ich in diesem Fall die Domain hardcoden - ich denke das wird funktionieren oder?

Relative Pfade kann ich dann gar nicht angeben? Also befindet sich der Cronjob in keinen Ordner? (ich wills nur verstehen). Also wenn ich ZUM BEISPIEL auf ein bild in /files per Pfad zugreifen will.

vorher wäre ich dann mit ../ einen Ordner zurück gegangen und dann in files also ../files/bild.jpg

Achso, also diese PHP Dateien können einfach im Frontend aufgerufen werden? Also mit https://domain.de/bundles/modulordne.../new/datei.php bspw.


Dann wäre es vielleicht besser, wenn du dir für jede dieser Dateien einen crontab Eintrag machst, wo die Datei mit wget aufgerufen wird (da die ja offensichtlich nur über einen HTTP Request funktionieren). Also zB:

Code:

---

* * * * * wget -q -O /dev/null https://domain.de/bundles/modulordner/ajax/new/datei1.php
* * * * * wget -q -O /dev/null https://domain.de/bundles/modulordner/ajax/new/datei2.php
* * * * * wget -q -O /dev/null https://domain.de/bundles/modulordner/ajax/new/datei3.php

---

etc.


Besser wäre es natürlich das alles komplett neu zu schreiben, damit es nicht mehr so haarsträubend ist ;)

Zitat:

---

Zitat von Spooky

Achso, also diese PHP Dateien können einfach im Frontend aufgerufen werden? Also mit https://domain.de/bundles/modulordne.../new/datei.php bspw.


Dann wäre es vielleicht besser, wenn du dir für jede dieser Dateien einen crontab Eintrag machst, wo die Datei mit wget aufgerufen wird (da die ja offensichtlich nur über einen HTTP Request funktionieren). Also zB:

Code:

---

* * * * * wget -q -O /dev/null https://domain.de/bundles/modulordner/ajax/new/datei1.php
* * * * * wget -q -O /dev/null https://domain.de/bundles/modulordner/ajax/new/datei2.php
* * * * * wget -q -O /dev/null https://domain.de/bundles/modulordner/ajax/new/datei3.php

---

etc.


Besser wäre es natürlich das alles komplett neu zu schreiben, damit es nicht mehr so haarsträubend ist ;)

---

ja genau :) So ist es mir aber lieber, da ich dann einfach wie gewohnt in die Cronjob Datei schreiben kann wenn was dazu kommt. Neu programmieren werde ich es sowieso. Dies sollte ich dann mit Klassen und Funktionen machen, um nach der Contao Logik zu gehen oder? Also im Cronjob eine Funktion aufrufen die unter eigenesmodul/contao/ liegt oder?

Das mit den relativen Pfaden kannst du mir auch nicht sagen oder?

Zitat:

---

Zitat von Nacht69

Also im Cronjob eine Funktion aufrufen die unter eigenesmodul/contao/ liegt oder?

---

Nein, entweder setzt der Cronjob die jeweilige Funktionalität um - oder du lässt dir im Cronjob einen entsprechenden Service injecten, der die Funktionalität umsetzt.