Ausführung externer WB-Scripts (Bspl.: croncheck)

[hillschmidt]

Liebe Mit-User,

bei der Ausführung von croncheck von Dev4Me taucht seit dem neuesten Release eine Fehlermeldung auf.
Dieses Script ist für WB geschrieben. Die php Datei ist im Root einer WB Installation (siehe https://dev4me.com/modules-snippets/opensource/croncheck/.

Ich nutze sowohl  die aktuelle croncheck Version als auch die WB-Version 2.13.3 r166

Die Fehlermeldung:

Code: [Select]

PHP Warning: Undefined array key "SCRIPT_NAME" in /mnt/web220/b2/93/536293/htdocs/wb/framework/CoreAutoloader.php on line 95
PHP Warning: Undefined array key "SCRIPT_NAME" in /mnt/web220/b2/93/536293/htdocs/wb/framework/CoreAutoloader.php on line 146
There was an uncatched exception<br />
strtolower(): Argument #1 ($string) must be of type string, null given<br />
in line (72) of (/framework/HttpRequester.php):<br />
Der Entwickler schrieb mir dazu:

The error is generated by the WB framework, before the croncheck is actually executed.

I guess you are calling the croncheck script directly in php, and not as http request (like wget / curl).
This WB version checks the request method ( in line (72) of (/framework/HttpRequester.php) ), but that is not existing.
Secondly, PHP8 is strict and does not allow string operations on non-existing-string (null). This is actually generating the error.

Gibt es dafür eine Lösung? Denn mit wget/curl kenne ich mich nicht aus ... Ich starte das Script über den cron Service des Providers strato.

Danke für Hinweise im Voraus, es grüßt Andreas

[dbs]

Hallo, bei meinem Provider kann ich den cron Service auf verschiedene Arten ausführen lassen.
Eine davon ist die Datei per URL aufrufen, also http Request. Vielleicht hilft das ja schon (so wie Ruud vermutet)

[hillschmidt]

Danke für den Tipp; bei Strato mit meinem Paket geht nur das:

In die Kommandozeile werden grundsätzlich Unix-Kommandos eingetragen, d. h. alle Kommandos und Skripte, die auch manuell aus einer SSH-Session heraus aufgerufen werden, können hier ausgeführt werden. Grundkenntnisse im Umgang mit einem Unix-System sind also zwingend erforderlich, damit Cron-Jobs einwandfrei funktionieren.

Und da bin ich nun unsicher/nicht wissend, welches Kommando außer

Code: [Select]

php -f <scriptname> ich nutzen könnte ...

[LudwigSt]

Und da bin ich nun unsicher/nicht wissend, welches Kommando außer

Code: [Select]

php -f <scriptname> ich nutzen könnte ...

Versuche es mal mit

Code: [Select]

/bin/php -f ./PFADzurDATEI/croncheck.php
Den Pfad zu deiner Datei mußt du entsprechend setzen.

Edit: Siehe auch https://www.strato.de/faq/hosting/so-einfach-richten-sie-ihre-cron-jobs-ein/

[hillschmidt]

genauso so nutze ich es - ich habe das Kommando im Post auf das Wesentliche verkürzt ...

[LudwigSt]

Dann ist doch alles ok, oder gibt es damit ein Problem?

[hillschmidt]

s.o.
Genau bei diesem Aufruf aus der Shell über Cron gibt es die oben beschriebene Fehlermeldung ... also weiterhin nicht alles ok

[DarkViper]

Ich glaub, ich muss da kurz mal aufklären...   

Es besteht ein großer Unterschied zwischen den Aufrufen

Code: [Select]

https://example.com/croncheck.php und

Code: [Select]

php -f path/to/script/croncheck.phpIm ersten Fall wird der Webserver (z.B. Apache) aufgerufen, der das Environment aufbaut und die Request Variablen (GET/POST/etc.) einrichtet und dann z.B. über fpm-fastcgi  den PHP-Interpreter startet und diesem das Script plus das Environment übergibt. So wäre alles im grünen Bereich.

Im zweiten Fall wird per Shell direkt die ComandLineInterface-Version von PHP gestartet und die Aufrufparameter als simples Array ($args[]) übergeben. In diesem Fall fehlen z.B. das gesamte $_SERVER[] - Array und natürlich auch $_GET[] und $_POST[]. Unter diesen Bedingungen ist es WB (das auf HTTP-Requests ausgelegt ist) schlicht unmöglich, korrekt zu starten.

Lösungsmöglichkeit:  Es bräuchte einen Wrapper, der den CLI-Aufruf in einen HTTP-Request umsetzt. (also ein Script, das einen CLI-Aufruf verarbeiten und mit den Daten einen HTTP-Request auslöst.
Leider hebe ich selbst gerade null Zeit, sowas zu tippern. Aber evt. kennt sich da ja noch jemand anderes gut genug aus, und kann das übernehmen.

Manuela

[hgs]

Frage an hillschmidt, was hindert dich daran es so wie im Beispiel zu machen?

Code: [Select]

https://example.com/croncheck.php
Ich mache das seit Jahre bei all-inkl.com genau so, wobei croncheck.php im DocRoot bei mir steht.

[DarkViper]

Frage an hillschmidt, was hindert dich daran es so wie im Beispiel zu machen?

eventuell das Cron-Management  Der Standard-Cron, der normalerweise installiert ist, kann keine HTTP-Requests absenden, sondern nur shell scripte oder Programme aufrufen. Er kann auch mit den HTML-Antworten eines PHP-Programmes nichts anfangen.
Das Thema ist deutlich komplexer, als es auf den ersten Blick erscheint.

[LudwigSt]

Vermutlich macht er das so, weil Ruud das so empfohlen hat. Anderenfalls muss man ja immer selber dran denken und die Datei jede Viertelstunde einmal aufrufen.

Das einzige, was das Script hindert als Cronjob zu laufen, denke ich, ist das

Code: [Select]

include('config.php'); Wenn man das entfernt und den Inhalt der config.php direkt dort rein schreibt, müsste eigentlich alles laufen. "Eigentlich", deshalb, weil ich es nicht ausprobiert habe. Ich nutze aber mehrere ähnliche PHP-Skripte, die ich via Cronjob jede Nacht laufen lasse, und alles klappt wunderbar. $_GET oder $_POST kommen im Skript nicht vor.

Mag sein, daß das nur bei Strato so geht, aber es geht.

[hillschmidt]

Wird nicht funktionieren ... ohne

Code: [Select]

require __DIR__.'/framework/initialize.php'; läuft es nicht ... und da wird der Fehler schon generiert, wie Ruud gesagt hat.

Ansonsten nutze ich cron, um ein regelmäßiges manuelles Aufrufen des Scriptes über http zu vermeiden (wegen des Vergessens/Aufwand ... ich liebe Automatism!).

[hillschmidt]

Leider kamen keine anderen Vorschläge - das Problem ist immer noch offen

[dbs]

Nur ein Vorschlag: https://www.cronjob.de/
Zwar extern, aber man kann eine URL angeben.

[hillschmidt]

scheitert genauso ... das Problem ist nicht cron an sich, sondern das auszuführende Script mit seinen WB Aufrufen ohne Wrapper

der den CLI-Aufruf in einen HTTP-Request umsetzt. (also ein Script, das einen CLI-Aufruf verarbeiten und mit den Daten einen HTTP-Request auslöst.

wie DarkViper schon geschrieben hat.