Files
tsv08kulmbach-website/public/cron.php
fs a101b0c3ec Stadionzeitung, Veranstaltungen, News-Artikel, Lightbox und Anzeigen-Verteilung
Stadionzeitung: Live-Seiten (Tabellen, Ergebnisse, Vorschau, Termine, News,
Kontakt, Historie, Sportheim, Partner, Momente, Impressum), automatisches Cover,
Swipe-Viewer mit Vollbildmodus und die Druckfassung als Falt-Heft. Anzeigen
kommen jetzt aus dem Bestand und werden gleichmäßig verteilt, nie mehr als zwei
hintereinander (vorher vier Blöcke à fünf). Die Doppelseiten-Regel rechnet das
Skript selbst, statt sie von Hand zu prüfen.

Veranstaltungen: Bereich /veranstaltungen mit Detailseite pro Fest, Lebenszyklus
über das Datum (Ankündigung vor dem Fest, Rückblick danach), Galerie mit
Lightbox. veranstaltungen.json ist dritte Termin-Quelle, damit ein Fest nie
doppelt gepflegt wird.

News-Artikel als dritte dynamische Prefix-Route, gemeinsamer detail-head.

Behobene Fehler:
- Wappen-Kontexte setzten Zeilen-Layout auf .crest statt auf die Zeile; das
  Wappen wurde zum Grid, Vereinsname und Tore rutschten darunter zusammen
  (Ergebnis-Rückblick, Vorschau, Cover).
- --header-h (60px) unterschätzt die Kopfleiste um 32px (Logo 72px + 20px
  Versatz): neues abgeleitetes --header-space, sonst klebten Zurück-Links
  unter dem Logo.
- base_url in der Produktions-Config ohne www, während .htaccess auf www
  umleitet; preflight prüft das jetzt.
- .lightbox brauchte display:none mit (0,2,0), sonst lag das Overlay offen.

Neue Werkzeuge: bin/anzeige-add.php (Anzeigen-Bestand), bin/veranstaltung-bilder.php
(Plakate und Galerien, Alt-Texte folgen der Quelldatei), bin/qr.php (Druck-QR mit
Warnung, wenn base_url nicht auf die echte Domain zeigt).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NzeVVgMCrzCDJAKeLEdKr7
2026-07-31 14:55:27 +02:00

105 lines
4.3 KiB
PHP

<?php
declare(strict_types=1);
/**
* Cron-Endpoint — die ZWEITE benannte Ausnahme zu Regel 3 (siehe CLAUDE.md).
*
* Warum es ihn gibt: der All-Inkl-Tarif kennt keine zeitgesteuerten Aufgaben, weder
* Shell- noch URL-Cronjobs ("in deinem Tarif nicht verfügbar"). Die Sync-Skripte müssen
* aber regelmäßig laufen, also muss der Takt von außen kommen. Ein externer Dienst
* (cron-job.org o. ä.) ruft diese Datei auf, sie startet das Skript serverseitig.
*
* Warum nicht der Weg über GitHub Actions mit FTP-Upload: dort müsste ein Dritter
* Schreibzugang zum ganzen Webspace kennen. Hier kennt er einen Schlüssel, der
* ausschließlich "starte einen der beiden Syncs" kann — deutlich kleinerer Radius.
*
* Aufruf: https://www.tsv08kulmbach.de/cron.php?job=matchcenter&key=<cron.key>
* Schlüssel alternativ als Header X-Cron-Key (bevorzugt, landet nicht im Log
* des aufrufenden Dienstes) — die Datei akzeptiert beides.
*
* Grenzen, die den Endpoint harmlos halten:
* - Job-Whitelist, keine freien Skriptnamen aus der URL
* - Schlüssel aus config.php, Vergleich mit hash_equals; ohne echten Schlüssel ist zu
* - Mindestabstand zwischen zwei Läufen (cron.min_interval) — ein geleakter Link kann
* damit nicht dauerfeuern und uns die Server-IP bei BFV/Instagram sperren lassen
* - flock in den Skripten selbst: parallele Aufrufe überspringen sich
* - Antwort ist immer leer. 403 nur bei falschem Schlüssel/Job, damit ein falsch
* eingerichteter Cron-Dienst überhaupt auffällt (sonst syncte wochenlang nichts,
* ohne dass es jemand merkt). Der Schlüssel ist lang genug, dass das kein Orakel ist.
*
* Erreichbar ohne Rewrite-Anpassung: public/.htaccess leitet nur nicht-existierende
* Pfade auf index.php (RewriteCond %{REQUEST_FILENAME} !-f).
*/
require dirname(__DIR__) . '/app/bootstrap.php';
header('X-Robots-Tag: noindex, nofollow');
header('Cache-Control: no-store');
$jobs = [
'matchcenter' => 'bin/matchcenter-sync.php',
'instagram' => 'bin/instagram-sync.php',
];
$job = (string) ($_GET['job'] ?? '');
$key = (string) config('cron.key', '');
$given = (string) ($_SERVER['HTTP_X_CRON_KEY'] ?? $_GET['key'] ?? '');
$deny = static function (string $reason): never {
// Kein Detail in der Antwort, der Grund steht im Log. IP nur als gesalzener Hash.
log_spam('cron', $reason);
http_response_code(403);
exit;
};
// Not-Aus wie in den Formular-Actions: ohne echte config.php liefe die Seite auf der
// Vorlage, deren Werte öffentlich im Repo stehen — der Endpoint wäre dann offen.
if ($key === '' || $key === 'CHANGE_ME' || strlen($key) < 24) {
$deny('kein brauchbarer cron.key konfiguriert');
}
// Ein gemeinsamer Grund für beide Fälle: verrät nicht, ob Job oder Schlüssel falsch war.
if (!isset($jobs[$job]) || !hash_equals($key, $given)) {
$deny('job oder key ungueltig');
}
// --- Mindestabstand ---
// Marker wird bei JEDEM angenommenen Versuch gesetzt, nicht erst bei Erfolg: sonst
// dürfte ein dauerhaft fehlschlagender Sync beliebig oft neu angestoßen werden.
$minInterval = max(60, (int) config('cron.min_interval', 240));
$marker = STORAGE_PATH . '/cache/cron-' . $job . '.last';
clearstatcache(true, $marker);
if (is_file($marker) && filemtime($marker) > time() - $minInterval) {
log_write($job, 'WARN', "Cron-Trigger übersprungen — letzter Lauf vor weniger als {$minInterval} s.");
http_response_code(204);
exit;
}
touch($marker);
// --- Lauf ---
// Status steht fest, BEVOR das Skript startet: es beendet sich per exit(), unser Code
// nach dem require läuft also nicht mehr zuverlässig.
http_response_code(204);
// Was die Skripte auf stdout schreiben (Debug-Ausgaben, PHP-Warnungen), darf nie im
// HTTP-Body landen. Der Shutdown-Handler greift auch bei exit() mitten im Skript.
ob_start();
register_shutdown_function(static function (): void {
while (ob_get_level() > 0) {
ob_end_clean();
}
});
set_time_limit(180); // Steady State ~2,5 s; Luft nur für den Erstlauf mit allen Bildern
ignore_user_abort(true); // Timeout beim aufrufenden Dienst darf den Sync nicht zerreißen
// Hebt den CLI-Riegel in den Sync-Skripten auf — nur hier, nach der Prüfung oben.
define('CRON_HTTP', true);
// Die Skripte lesen ihre Schalter aus $argv; im Web-SAPI existiert das nicht.
$argv = [$jobs[$job]];
$argc = 1;
require ROOT_PATH . '/' . $jobs[$job];