config.example: Cron-Doku auf den echten Stand

Zwei Korrekturen an Stellen, die beim Anlegen der Cronjobs in die Irre geführt
hätten: (1) der Abschnitt behauptete noch, der Tarif habe keine Cronjobs —
seit 31.07.2026 ist Weg A unser Weg, cron.key ist leer und public/cron.php
stillgelegt. (2) Die Cron-Zeilen leiteten die Fehlerausgabe in die Kanal-Logs,
deren Format `[Zeit] LEVEL Meldung` eine rohe PHP-Warnung bricht (bin/logs.php
wertet Kanäle nach Level aus). Sie geht jetzt nach php-errors.log, das
bin/logs.php bereits als "eigenes Format" behandelt. Dazu die echten Pfade
dieses Webspace statt Platzhalter.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NzeVVgMCrzCDJAKeLEdKr7

config/config.example.php

@@ -11,8 +11,11 @@
  * ---------------------------------------------------------------------------
  * A) Der Tarif hat Cronjobs → Shell-Cronjobs unten verwenden. Sauberster Weg,
  *    kein Endpoint, kein Dritter im Spiel.
- * B) Der Tarif hat KEINE Cronjobs (Stand 27.07.2026 bei uns der Fall, KAS meldet
+ *    ►►► DAS IST SEIT 31.07.2026 UNSER WEG: der Tarif hat SSH und Shell-Cronjobs.
+ *    Deshalb steht `cron.key` unten leer und public/cron.php ist stillgelegt.
+ * B) Der Tarif hat KEINE Cronjobs (so war es bis 30.07.2026, das KAS meldete
  *    „in deinem Tarif nicht verfügbar“) → public/cron.php + externer Cron-Dienst.
+ *    Nur noch als Rückweg dokumentiert, falls der Shell-Cron ausfällt.
  *    Dann `cron.key` unten setzen und beim Dienst diese URLs im gewünschten Takt
  *    aufrufen lassen (Schlüssel besser als Header X-Cron-Key als in der URL):
  *
@@ -28,18 +31,26 @@
  * ---------------------------------------------------------------------------
  * CRONJOBS (im KAS anlegen, Typ „eigener Cronjob“ / Shell) — nur Weg A
  * ---------------------------------------------------------------------------
- * SITE=/www/htdocs/<KAS-User>/tsv08kulmbach   (echten Pfad einsetzen: pwd auf dem Server)
- * PHP=/usr/bin/php                            (All-Inkl ggf. /usr/local/bin/php8.2 — `which php8.2` prüft es)
+ * SITE=/www/htdocs/w01ca75d/tsv08kulmbach-website   (echter Pfad, ermittelt 31.07.2026)
+ * PHP=/usr/bin/php                                 (8.3.29; mit `which php` gegenprüfen)
+ *
+ * Die Fehlerausgabe geht bewusst nach php-errors.log und NICHT in die Kanal-Logs:
+ * die Skripte schreiben ihren Verlauf selbst über log_write() im Format
+ * `[Zeit] LEVEL Meldung`, und bin/logs.php wertet Kanäle nach Level aus. Eine rohe
+ * PHP-Warnung dazwischen bricht das Format. php-errors.log ist die Datei für PHPs
+ * eigene Ausgabe, und bin/logs.php behandelt sie schon als "eigenes Format".
+ * Nach /dev/null darf nur log-rotate: ein Fatal dort ist harmlos, ein Fatal in einem
+ * Sync (etwa fehlendes vendor/ nach einem halben Deploy) soll auffallen.
  *
  * # Instagram-Feed: 2×/Tag (versetzte Minuten, damit die Läufe sich nicht überlappen)
- * 17 6,18 * * *   cd $SITE && $PHP bin/instagram-sync.php >> storage/logs/instagram.log 2>&1
+ * 17 6,18 * * *   cd $SITE && $PHP bin/instagram-sync.php >> storage/logs/php-errors.log 2>&1
  *
  * # Matchcenter: 2×/Tag als Grundtakt
- * 37 7,19 * * *   cd $SITE && $PHP bin/matchcenter-sync.php >> storage/logs/matchcenter.log 2>&1
+ * 37 7,19 * * *   cd $SITE && $PHP bin/matchcenter-sync.php >> storage/logs/php-errors.log 2>&1
  *
  * # Matchcenter am Spieltag-Nachmittag/Abend ½-stündlich (Sa+So 13–21 Uhr),
  * # damit Ergebnisse und Tabelle zeitnah stehen.
- * 7,37 13-21 * * 6,0   cd $SITE && $PHP bin/matchcenter-sync.php >> storage/logs/matchcenter.log 2>&1
+ * 7,37 13-21 * * 6,0   cd $SITE && $PHP bin/matchcenter-sync.php >> storage/logs/php-errors.log 2>&1
  *
  * # Logpflege: sonntags nachts. Rotiert Dateien über 2 MB und löscht Einträge älter als 90 Tage.
  * 23 3 * * 0   cd $SITE && $PHP bin/log-rotate.php > /dev/null 2>&1