Die Bedingung stand doppelt als Closure in sportsmanager.php und ein drittes
und viertes Mal punktebasiert in den Ansichten, wo eine Begegnung mit
ausschliesslich unentschiedenen Saetzen als "_:_" erschien, obwohl die
Tabelle sie zaehlt.
Meldung von Sven (DTFB-IT): "Im Live-Ticker werden Tore nicht gezeigt."
Dazu gemessen: view_ticker.php enthielt keinen einzigen Zugriff auf die
Tore-Spalten, und die Spielzeile blendete das Ergebnis aus, sobald der
Satzstand 0:0 war ("5:5 5:5" -> leere Zelle, obwohl eingetragen).
- Spielzeile im Matchdetail: das Ergebnis erscheint auch bei Satzstand 0:0,
sofern ein Satzergebnis vorliegt (ergebnis_detailliert); darunter stehen
die Tore des Spiels aus teamspiel_heim_tore/teamspiel_gast_tore, klein und
nur, wenn sie bekannt sind und nicht ohnehin dem Punktestand entsprechen
(bei punktetyp 0 sind Punkte = Tore, dort bleibt die Zeile unveraendert).
- Matchdetail-Kopf: die Gesamttore der Begegnung stehen in der Datumszeile
("... - Tore 47:42"), gleiche Bekanntheits-Regel; der feste 78px-Zaehler
(resultat_holder) bleibt unangetastet und zeigt statt "--|--" den Stand,
sobald ein Ergebnis vorliegt (heim_tore bekannt), auch bei Spielpunkten 0:0
(Wertung "je Satz, Sieg 1": alle Spiele remis).
- Status einer Begegnung (finished/upcoming) in Liste und Turnierbaum:
bekannte Tore zaehlen als beendet, nicht nur Spielpunkte != 0.
- Die Ticker-Abfragen (Liste und Timestamp-Erkennung) behandeln eine
Begegnung mit Punkten 0:0, aber bekannten Toren als ausgetragen -- sie
erscheint unter den beendeten Spielen und sortiert sich dort ein, statt
als "anstehend" zu gelten. Fuer Bestandsdaten ohne Tore-Spaltenwerte
(NULL) aendert sich an Filterung und Sortierung nichts.
Meldung von Sven (DTFB-IT): "In der Tabelle sind Saetze falsch." Die
Satz-Spalte der Tabelle summiert teamspiel_*_punkte, und die zaehlen nur
ENTSCHIEDENE Saetze -- unentschiedene Saetze verschwanden spurlos. Aus
"6:4 5:5 2:6 6:3" wurden 2:2 Saetze, das 5:5 fehlte in jeder Summe.
Vorbild ist die Spielerstatistik, die mit saetze_unentschieden genau dieses
Feld schon fuehrt. Neue NULL-bare Spalten, NULL heisst unbekannt (Bestand vor
der Erfassung von Satzergebnissen), nie wird 0 unterstellt:
- teamspiel.teamspiel_saetze_remis: unentschiedene Saetze des Spiels, eine
Zahl, fuer beide Seiten gleich
- begegnung.saetze_remis: Summe ueber die Spiele; NULL, sobald ein Spiel
unbekannt ist (gleiche Regel wie bei den Toren)
- team.saetze_remis: Summe ueber die ausgetragenen Begegnungen, in
teamstatistikAktualisieren mitberechnet
Berechnet wird der Wert in tools.php (saetzeRemisFuerSpiel, analog zu
toreFuerSpiel: nur bei punktetyp 1 mit Satzergebnissen bekannt, sonst NULL)
und an denselben beiden Stellen geschrieben wie die Tore: Speicherschleife
adminSaveBegegnungSpielplan() und begegnungenAktualisieren().
Migration: #306 ist nicht ausgeliefert, Datenbankversion 123 gehoert bereits
zu diesem Zweig -- die neuen Spalten erweitern deshalb den bestehenden
<123-Block in database/update.php (mit eigenen Spalten-Guards, damit eine
Instanz, die den bisherigen 123er-Stand schon traegt, nur das Fehlende
nachzieht) und die CREATEs in script.php.
Anzeige: im Je-Satz-Modus weist die Satz-Spalte der Tabelle die Remis-Saetze
kompakt mit aus ("6:5 (4)"), mit erklaerendem title (neuer Sprachschluessel
COM_SPORTSMANAGER_SETS_DRAWN); die Spaltenzahl waechst nicht. Ausserhalb des
Je-Satz-Modus bleibt team.saetze_remis NULL und die Anzeige unveraendert.
getTabelleSpieltag liefert den Wert je Spieltag ueber ein Subselect, das nur
im Je-Satz-Zweig erzeugt wird; die JSON-Ansicht reicht die Teamobjekte
unveraendert durch und traegt den Wert damit automatisch.
Meldung von Sven (DTFB-IT): "Ist irgendwo zwischendurch ein 5:5 werden alle
Ergebnisse und Paarungen beim Speichern ab dort geloescht." Seine Vermutung
traf zu: teamspiel_*_punkte zaehlt nur ENTSCHIEDENE Saetze, und punkte == 0:0
gilt an mehreren Stellen als "nichts eingetragen". Wo Unentschieden normal
sind (Je-Satz-Modus, Satzergebnis-Erfassung), kollidiert das.
Gemessen an PRUEF Liga G (Modus 21, je Satz): eingetragen Spiel 1
"6:4 5:5 2:6 6:3", Spiel 2 "5:5 5:5", Spiel 3 "4:4 6:2 5:5 2:6" -- gespeichert
wurde nur Spiel 1. Spiel 2 ergibt Punkte 0:0, damit war die Behalte-Bedingung
(admin.php) und die do-while-Bedingung falsch, die Schleife endete, und
DELETE ... WHERE teamspiel_nummer >= $spiel_nr nahm Spiel 2 UND Spiel 3 mit.
Die falschen Gesamttore aus der Meldung sind eine Folge derselben Loeschung;
ohne komplett unentschiedenes Spiel stimmen sie exakt (47:42 = Handrechnung).
Ausserdem gemessen: eine Begegnung, deren Spiele ALLE unentschieden enden
(Begegnungspunkte 0:0), verschwand komplett aus der Tabelle -- die Mannschaft
zeigte danach "0 Siege, 0 Unentschieden, 1 Niederlage", Spielpunkte und Tore
der Begegnung fehlten. Grund: die Tabellenabfragen filtern Begegnungen mit
(heim_punkte != 0 OR gast_punkte != 0).
Behebung: ueberall dort, wo punkte != 0 als "es liegt ein Ergebnis vor"
dient, gilt zusaetzlich "ein Satzergebnis liegt vor" -- das Kriterium wird
erweitert, nie verengt:
- Speicherschleife adminSaveBegegnungSpielplan(): Behalte-Bedingung und
do-while zusaetzlich !empty($ergebnis_detailliert). Auf teamspiel-Ebene ist
ergebnis_detailliert das unmittelbare Zeugnis der Eingabe; es ist genau dann
gefuellt, wenn Satzergebnisse eingetragen wurden.
- Wiederherstellungs-Block fuer Zwischenergebnisse: Punkte werden nur noch
zurueckgeholt, wenn NEBEN 0:0 auch kein Satzergebnis gesendet wurde -- ein
live eingetragenes "5:5 5:5" ist eine Eingabe, keine Luecke.
- Tabellenabfragen (getTabelleSpieltag, teamstatistikAktualisieren samt
Buchholz-Paarungen): ausgetragen ist eine Begegnung mit punkte != 0 ODER
heim_tore IS NOT NULL. Auf Begegnungsebene gibt es kein ergebnis_detailliert;
heim_tore (Datenbankversion 123) wird beim Speichern genau dann gesetzt, wenn
Satzergebnisse vorliegen, und ist damit dort das eindeutige Signal.
- Spieltag-Ermittlung (tabelle(), teamstatistikAktualisieren): ein Spieltag
mit heim_spielpunkte 0:0 (Wertung "je Satz, Sieg 1": alle Spiele remis)
zaehlt ueber NOT ISNULL(heim_tore) trotzdem als ausgetragen.
Bestandsmodi aendern sich nicht: ausserhalb der Satzergebnis-Erfassung ist
bei "nicht eingetragen" auch kein Satzergebnis vorhanden (ergebnis_detailliert
leer, heim_tore NULL), das erweiterte Kriterium bleibt dort wirkungslos. Die
SQL-Zusaetze sind an $je_satz gebunden bzw. haengen an Spalten, die in
Bestandsdaten NULL sind; die von getTabelleSpieltag erzeugten Abfragen bleiben
fuer Nicht-Je-Satz-Modi byteidentisch (Query-Log-Vergleich wie bei 49ce079).
Sven 2026-09-09 mit Bildschirmfoto des Begegnungsformulars: „Bei dem Modus ‚für
jeden Satz einzeln' erscheint mir die Anzeige der Satzergebnisse bei den Spielen
nicht sinnvoll beim Bearbeiten der Begegnung. Zeige diese da nicht an."
Zu Recht: die Zeile „Saetze: 2:1" unter einem Spiel beantwortet dort eine Frage,
die in diesem Modus niemand stellt. Gewertet wird jeder Satz einzeln — der
Satzstand des Spiels entscheidet nichts mehr, und daneben steht bereits der
Gesamtstand, der die tatsaechlich vergebenen Spielpunkte zeigt.
Die Zeile entfaellt deshalb je Spiel, dessen Wertung „je Satz" ist (Einzel und
Doppel getrennt betrachtet, weil beide eine eigene Wertung haben koennen).
Die beiden VERBORGENEN Felder darunter bleiben in jedem Fall stehen: sie tragen
`spiel_N_heim_punkte`/`_gast_punkte` zum Server, und das Satz-JavaScript
beschreibt sie weiter. Nur die sichtbare Zeile faellt weg; das JS, das sie
fuellt, prueft ohnehin auf Vorhandensein (`if (anzeige != null)`) und laeuft
unveraendert.
Gemessen am Testserver:
Liga G (je Satz): 0 Satzstand-Anzeigen, 6 verborgene Punktefelder
Liga F (Satzdetail, aber
Wertung je Spiel): 3 Anzeigen, 3 span-Elemente, 6 Punktefelder
Sven 2026-09-09: „Bei ‚Spielpunkt' ‚Für jeden Satz einzeln': hier wuerde ich
analog zu den Auswahlen oben ergaenzend noch ‚Sieg: 1 Punkt' und ‚Sieg: 3 Punkte,
Unentschieden: 1 Punkt' noch mit vorsehen wollen in geeigneter Reihenfolge." Und:
„solange es kompatibel zu dem Stand vor #304/#306 ist" — der Wert des Modus war
also frei gestaltbar.
Statt weitere Einzelwerte anzuhaengen (4, dann 5, dann 6) traegt der Wert die
Bedeutung jetzt selbst:
Wert % 10 = die Punkteskala (0 = Sieg 2/Remis 1, 1 = Sieg 3/Remis 1,
2 = ohne Umrechnung, 3 = Sieg 1)
Wert >= 10 = je SATZ statt je Spiel
je Spiel: 3 0 1 2 je Satz: 13 10 11
^^ ^^ ^^ dieselbe Skala, +10
Die ueberlieferten Werte 0 bis 3 behalten damit ihre Bedeutung unveraendert —
das ist die geforderte Kompatibilitaet zum Stand vor #304. Und jede der drei
Rechenstellen leitet Siegwert und Remiswert aus demselben Grundwert ab, statt
einen Sonderfall je Wert zu fuehren: aus einer Fallunterscheidung mit vier
Zweigen wurden zwei Zeilen.
Der Entwicklungswert 4 (nur in #306, nie ausgeliefert) entfaellt ersatzlos; er
existierte allein auf dem Testserver und ist dort auf 10 gesetzt. Deshalb auch
keine Migration dafuer — in keiner Installation steht er.
Der Server nimmt nur noch die sieben gueltigen Werte an; alles andere faellt auf
0 zurueck. Fehlt die Satzerfassung, faellt eine Je-Satz-Wertung auf IHRE EIGENE
Skala je Spiel zurueck (13 -> 3, nicht mehr pauschal auf 0): die gewaehlte
Punkteskala ist eine andere Aussage als die Bezugsebene und bleibt erhalten.
VERIFIZIERT, alles gemessen statt angenommen:
1. Bestand unveraendert: Ausgangsstand gesichert, alle sieben Pruefmodi ueber die
echten Formulare neu gespeichert, 784-Zeilen-Dump aller wertungsrelevanten
Tabellen — IDENTISCH. Am Ende, nach dem Durchlauf aller drei neuen Skalen und
Ruecksetzen auf 10, erneut identisch.
2. Spielpunkte je Skala gegen eine UNABHAENGIGE Nachrechnung in Python (parst
ergebnis_detailliert selbst, kein PHP beteiligt): 8 Spiele + 3 Begegnungen,
je Skala 0 Abweichungen. Darunter der Faelligkeitsfall, dass „Sieg 1 Punkt"
fuer Unentschieden NICHTS gibt (Spiel mit 1 Sieg, 1 Niederlage, 2 Remis:
1:1 statt 2:2) und der Rueckfall ohne Satzdetails (Skala x Satzsiege).
3. Spielerstatistik je Skala gegen dieselbe Art Nachrechnung: 7 Spieler, je
Skala 0 Abweichungen. Siege/Unentschieden/Niederlagen sind ueber alle Skalen
gleich (die Skala aendert nur Spielpunkte, nicht wer einen Satz gewann), die
Spielpunkte skalieren mit 1/2/3.
4. Das erzeugte JavaScript traegt je Skala die passenden Faktoren
(1*/0*, 2*/1*, 3*/1*) — aus der gerenderten Seite gelesen.
5. Die Auswahl zeigt drei Je-Satz-Eintraege in derselben Reihenfolge wie oben
(Sieg 1, Sieg 2/Remis 1, Sieg 3/Remis 1); ohne Satzerfassung bleibt die ganze
Gruppe verborgen.
Der Warnhinweis spricht nicht mehr von „2 Punkten je gewonnenem Satz", sondern
vom vollen Siegwert — mit drei Skalen waere die Zahl falsch gewesen.
Sven 2026-09-09 mit zwei Bildschirmfotos: „Benenne die Optionen geeignet,
geeignet angeordnet und gut unterscheidbar." Und: „Und brich die Beschreibungen
geeignet um."
1. DIE BESCHREIBUNGEN — ein Schaden, den 7f1bedc (Kommentare entfernen)
angerichtet hat. Der Kommentar ueber der CSS-Regel .sm_hinweis war
mehrzeilig; entfernt wurde nur seine ERSTE Zeile, weil nur die mit „/*"
begann. Zurueck blieben vier Prosazeilen und ein verwaistes „*/" direkt hinter
<style>. Der Browser liest das als Selektor und verwirft die ganze Regel — also
fehlten `white-space: normal` und `max-width: 42em`, und jede Beschreibung lief
in einer Zeile aus dem Bild. Genau das zeigt Svens Bildschirmfoto.
Der Rest ist entfernt, die Regel gilt wieder. Gegengeprueft: im ganzen Zweig
gibt es kein zweites unbalanciertes Kommentarzeichen (Klammerbilanz ueber alle
sechs geaenderten Dateien; die uebrigen Treffer sind einzeilige Kommentare).
2. DIE AUSWAHL. Die neue Wertung stand am Ende und las sich fast wortgleich wie
die zweite („Sieg: 2 Punkte, Unentschieden: 1 Punkt – je Satz" gegen „Sieg: 2
Punkte, Unentschieden: 1 Punkt"). Jetzt zwei Gruppen:
Fuer das ganze Spiel
Sieg: 1 Punkt
Sieg: 2 Punkte, Unentschieden: 1 Punkt
Sieg: 3 Punkte, Unentschieden: 1 Punkt
Ohne Umrechnung – Saetze sind die Spielpunkte
Fuer jeden Satz einzeln
Je Satz: Sieg 2 Punkte, Unentschieden 1 Punkt
Das Unterscheidende steht ZUSAETZLICH im Eintrag selbst („Je Satz:" vorn), weil
eine Gruppenueberschrift nur im aufgeklappten Zustand sichtbar ist — zugeklappt
zeigt das Feld allein den Eintrag, und der muss fuer sich sprechen.
Das Feld heisst nicht mehr „Spielpunkte pro Spiel", sondern „Spielpunkte": mit
einer Wertung je Satz war die alte Beschriftung ihrem eigenen Inhalt
widersprochen.
3. Beide Auswahlfelder (Einzel und Doppel) entstehen jetzt aus EINER Funktion.
Vorher stand die Schleife zweimal da — dieselbe Bauart, die beim Remis-Vorfall
auseinandergelaufen ist.
Gemessen am Testserver: Modus 21 (je Satz) zeigt beide Gruppen mit dem richtigen
gewaehlten Eintrag; Modus 15 („Mehrere" ohne Satzerfassung) und 16 („Einer")
zeigen die Je-Satz-Gruppe VERBORGEN. Die .sm_hinweis-Regel kommt wieder
unversehrt im Quelltext der Seite an.
Der STFV will in der Spielerstatistik jeden Satz als Spiel gezaehlt sehen.
spielerstatistikAktualisieren() holt dafuer im Veranstaltungs-Zweig
zusaetzlich ergebnis_detailliert und die beiden Wertungs-Spalten (der Join
auf teamspiel_modus existiert schon), bestimmt je Zeile Einzel oder Doppel
wie begegnungenAktualisieren ueber ISNULL(spieler_2_id) und zaehlt bei
Wertung 4 Siege/Unentschieden/Niederlagen und die Satz-Spalten je SATZ aus
runden_detailliert_auswertung — die angezeigte Spielezahl ist s+u+n und
wird damit von selbst zur Satzzahl. spg/spv bleiben die (im 4er-Modus
bereits satzbasierten) Spielpunkte; pg/pv bleiben die Punktesummen, also
Saetze — ihre Einheiten-Beschriftung haengt an punktetyp und bliebe bei
einer Tore-Umwidmung falsch. Ohne gespeicherte Satzergebnisse (App-Meldung
nur mit Satzstand) zaehlt das Spiel wie bisher als EIN Spiel aus dem
Punktevergleich — deterministisch, keine erfundenen Saetze.
Die S/U/N-Zaehlung und die Satz-Spalten laufen jetzt ueber dieselben drei
Zaehler (heim/unentschieden/gast je Zeile): fuer jede Wertung ausser 4
tragen sie exakt die alten 1-aus-3-Werte, das Ergebnis ist wertgleich zum
bisherigen if/else — bewiesen ueber die Messlatte, nicht nur hergeleitet:
11 Modi + 11 Begegnungen unveraendert gespeichert, voller Datenbank-Dump
(784 Zeilen) und Frontend-Dump (26987 Zeilen) vor/nach dem Wechsel — die
EINZIGEN Unterschiede sind die 7 bestenliste_punkte-Zeilen der
Je-Satz-Prueflige G, und dort nur s/u/n und sg/su/sv; spg/spv und pg/pv
jeder Zeile sind unveraendert. Alle sieben Bestands-Bestenlisten
(einschliesslich der Liga 'Mehrere mit Ergebnis je Satz' bei Wertung
Sieg 2/Remis 1, die weiter je SPIEL zaehlt) sind identisch.
Handrechnung dokumentiert an Spieler 115 der Prueflige G: Einzel
'6:4 4:4 2:6 6:3' (2/1/1), Doppel '4:4 4:4 6:2 2:6' (1/2/1), Doppel
'6:4 6:4 0:6 4:6' als Gast (2/0/2), dazu die Fallback-Begegnung ohne
Satzdetails als eine Niederlage (0/0/1): zusammen 5 Siege, 3 Unentschieden,
5 Niederlagen = 13 'Spiele' (Saetze), Spielpunkte 15:15, Punkte 6:6 —
exakt die gespeicherte Zeile.
Im Je-Satz-Modus ist die Satzdifferenz nach der Spielpunkte-Differenz
vollstaendig redundant (Spielpunkte-Differenz = 2 x Satzdifferenz) — die
naechste Stufe, die wirklich trennt, sind die Tore (#306-Konzept, Abschnitt
0 und 3). Die Sortierung haengt am MODUS, nicht an neuen tabellenwertung-
Werten: so wirkt die Tore-Stufe automatisch in Differenz-, Quotienten-,
Buchholz- und Direktvergleichs-Varianten, ohne die Auswahlliste zu
verdoppeln. getTabelleSpieltag(), teamstatistikAktualisieren() und
getTabelleDirekterVergleich() ermitteln die Wertung des Modus jeweils per
eigenem kleinen SELECT und schieben bei Wertung 4 die Stufe tore_differenz
DESC (bzw. tore_quotient) ZWISCHEN Spielpunkte und Punkte; die Satz-Stufe
bleibt als letzter Tie-Break dahinter — sie schadet nie, und solange Tore
noch NULL sind, ordnet die Tabelle exakt wie bisher. Die Summen entstehen
als SUM ueber CASE je Begegnung ohne COALESCE: NULL traegt nichts bei,
unbekannt wird niemals 0:0. Die Platzvergabe (geteilte Plaetze) beachtet
die Tore an beiden Stellen (teamstatistik und HTML-Tabelle) mit — ohne das
teilten sich zwei nur durch Tore getrennte Teams Platz 1, gemessen am
Zwischenstand dieses Schrittes.
Die HTML-Tabelle zeigt die neue Stufe: im Je-Satz-Modus steht zwischen der
Saetze- und der Spiele-Spalte eine Tore-Spalte (Differenz bzw. Quotient,
absolut als Tooltip/Beiwert, "-" wo Tore unbekannt sind). Die JSON-Ansicht
bekommt die tore_*-Felder additiv ueber die ohnehin rohen Team-Zeilen.
Fuer alle anderen Modi entsteht BYTEIDENTISCHES SQL — nicht behauptet,
sondern geloggt: beide Fassungen im Testserver mit einem Query-Log
instrumentiert, 18 getTabelleSpieltag-Aufrufe (9 Ligen x 2 Spieltage) und
19 teamstatistik-Laeufe verglichen. Saemtliche Unterschiede betreffen
ausschliesslich die Je-Satz-Liga (2 Zusatzspalten, 2 Subselects, eine
ORDER-Stufe); jede Query einer Nicht-4-Liga ist Byte fuer Byte gleich.
Dazu dieselbe Messlatte wie bisher: 11 Modi + 11 Begegnungen unveraendert
gespeichert, Datenbank-Dump (778 Zeilen): 0 Unterschiede; Frontend-Dump
(9 Ligen x 3 Ansichten + 8 Statistiken): jede Abweichung ist eine
HINZUGEKOMMENE Zeile der Tore-Spalte der Je-Satz-Liga, keine einzige
bestehende Zeile geaendert oder entfernt.
Und der Fall, fuer den die Stufe da ist, ist konstruiert und gemessen
(Prueflige H): eine Remis-Begegnung, beide Teams mit Begegnungspunkten 1,
Spielpunkte-Differenz 0 und Satz-Differenz 0, aber Toren 35:34 gegen 34:35.
Alte Kette: beide Platz 1, alphabetisch sortiert (Adler vor Zebras). Neue
Kette: Zebras (+1 Tore) Platz 1, Adler (-1) Platz 2 — in team.platz wie in
der angezeigten Tabelle.
Der STFV wertet jeden gewonnenen Satz mit 2 Spielpunkten und jedes
Satz-Unentschieden mit 1 Punkt je Seite. Das ist ein neuer Wert der
bestehenden Stellschraube spielpunkte_wertung_* (tinyint, Wert 4), keine
neue Spalte und keine Kombinatorik (#306-Konzept, Abschnitt 1). Nach aussen
bleibt der Modus punktetyp 1 + satzergebnisse 1 — die Punkte eines Spiels
SIND weiter die gewonnenen Saetze, punktetyp behaelt seine zwei Werte.
Die Regel sitzt in spielpunkteFuerSpiel(): 2·gewonnene + 1·unentschiedene
Saetze je Seite aus ergebnis_detailliert; ohne Detail (App-Meldung nur mit
Satzstand) deterministisch 2·punkte — Satzsiege sind bekannt, Remis nicht.
Beide PHP-Rechenwege bekommen dadurch denselben neuen Fall geschenkt.
Das Formular bietet die Option nur an, wo sie rechenbar ist: sichtbar
allein bei "Mehrere - mit Ergebnis je Satz" (data-satzdetails-Option,
zeilen_anzeigen() blendet sie sonst aus und stellt die Auswahl zurueck).
Der Server verlaesst sich darauf nicht: kommt Wertung 4 ohne punktetyp 1 +
satzergebnisse 1 an, faellt sie auf 0 zurueck (Sieg 2/Remis 1 je Spiel, die
naechstliegende Je-Spiel-Regel) — die Spielform dominiert, wie im
Bestandscode. Race schliesst 4 automatisch aus, weil Race Wertung 2
erzwingt. Gemessen an drei ueber das echte Formular geposteten Modi:
Einer+4 -> 0, Mehrere-ohne-Satzerfassung+4 -> 0, Race+4 -> 2. Und der
Warnhinweis beim Speichern mit Bestandsergebnissen nennt jetzt auch den
STFV-Altbestandsfall: wo unter "Mehrere" in Wahrheit Tore in den
Punkte-Feldern stehen, zaehlt nach dem Wechsel jedes Tor wie ein gewonnener
Satz doppelt — umgerechnet wird nichts.
Die DRITTE Rechenstelle rechnet mit — die Lehre aus dem Remis-Vorfall
(Formular 7:3, Server 6:2): das erzeugte Formular-JavaScript bekommt EINE
gemeinsame Satzsummen-Hilfsfunktion (satz_summen liest die
_punkte_detailliert-Felder und ueberspringt 0:0-Saetze wie die
Satz-Zaehlschleife des Servers), und BEIDE Verbraucher benutzen sie:
gesamtstand_aktualisieren() und spielpunkte_bedingung(). Aus den
spiel_N_*_punkte-Feldern duerfen beide im 4er-Modus nicht mehr rechnen —
dort stehen Saetze, eine Je-Spiel-Wertung waere falsch.
End-to-end gemessen an der neuen Prueflige G (Modus ueber das echte
Formular angelegt: 3 Spiele E/E/D, 4 feste Saetze, Wertung je Satz;
punkte_sieg wird -3 gespiegelt):
- Begegnung 117 mit Satz-Remis in allen drei Spielen ("6:4 4:4 2:6 6:3",
"1:6 2:6 6:6 0:6", "4:4 4:4 6:2 2:6"): gespeichert 5:3, 1:7, 4:4 —
Begegnung 10:14 Spielpunkte, 3:5 Saetze, 43:57 Tore. Handrechnung
identisch.
- JS-Paritaet nicht nur gelesen, sondern gerechnet: das vom PHP erzeugte
JavaScript aus der gerenderten Seite in node gegen dieselben Feldwerte
laufen lassen — gesamtstand_aktualisieren liefert 10:14,
spielpunkte_bedingung summiert 10/14, satz_summen je Spiel
[2,1,1] [0,1,3] [1,2,1]; die Datenbank derselben Begegnung sagt 10:14.
- Fallback gemessen (Begegnung 119, Meldung wie ein Altclient nur mit
Satzstand 2:1 und 1:1): Spielpunkte 4:2 und 2:2 (= 2·punkte),
ergebnis_detailliert bleibt leer, Tore bleiben NULL.
- Bestandsmodi unveraendert: dieselbe Messlatte wie bei den beiden
Schritten zuvor (10 Modi + 10 Begegnungen unveraendert gespeichert,
756 Zeilen Datenbank-Dump, 30995 Zeilen Frontend-HTML): VOLLSTAENDIG
identisch.
Neue Sprachschluessel DE/EN: die Option ("Sieg: 2 Punkte, Unentschieden:
1 Punkt - je Satz") und der erweiterte Warnhinweis.
Die STFV-Tabellensortierung braucht als letzte inhaltliche Stufe die Tore — und
die stehen bisher ausschliesslich im tinytext ergebnis_detailliert, wo kein SQL
sie lesen kann (#306-Konzept, Abschnitt 2). Also neue, durchweg NULL-bare
Spalten: teamspiel_heim_tore/gast_tore, begegnung.heim_tore/gast_tore und
team.tore_gewonnen/verloren/differenz/quotient (Typen nach punkte_*-Vorbild).
toreFuerSpiel() in tools.php ist die einzige Rechenstelle: bei punktetyp 0 sind
die Punkte die Tore; wo Satzergebnisse gefuehrt werden (satzergebnisse 1),
werden sie aus ergebnis_detailliert summiert (runden_detailliert_auswertung);
sonst NULL — unter "Mehrere" ohne Satzerfassung spiegelt das Detail nur den
Satzstand, eine Torzahl steht dort nicht und stand dort nie. Geschrieben wird
an denselben zwei Stellen wie die Spielpunkte (Spielbericht speichern und
begegnungenAktualisieren), immer paarweise gesetzt oder paarweise NULL; das
Loeschen des Spielberichts nullt die Begegnungssummen mit. team.tore_* rechnet
teamstatistikAktualisieren immer mit — als SUM ueber CASE je Begegnung, OHNE
COALESCE: eine Begegnung mit unbekannten Toren traegt nichts bei, unbekannt
wird niemals als 0:0 gewertet. Gemessen an Prueflige F: ein geleertes
ergebnis_detailliert macht Spiel, Begegnung und die Differenz beider Teams
NULL (135/147 -> 85/98), die Wiederherstellung stellt exakt den alten Stand her.
KEIN Backfill in der Migration: updateDatabase() ruft begegnungenAktualisieren()
nicht auf, und ein Update soll gespeicherte Werte nicht anfassen. Gemessen: nach
Einspielen und einem Seitenaufruf steht die Version auf 123, alle 455 + 116 + 32
Tore-Felder sind NULL. Befuellt wird beim naechsten Speichern eines Berichts
bzw. komplett beim Speichern des Modus — gemessen ueber alle acht Ligen:
Einer/Race tragen Tore = Punkte (Damenbundesliga 42:31 -> 42:31), Satzerfassung
summiert die Saetze ("5:3 4:4 2:6 6:1" -> 17:14, Begegnung 50:49), "Mehrere"
ohne Satzerfassung bleibt ehrlich NULL (PRUEF Liga A, 30 Spiele, 0 Tore-Werte).
Beide Pflegeorte: Migration <123 in database/update.php (getTableColumns-Guard
je Tabelle, Versionsschreiben am Ende) UND die CREATEs in script.php samt
datenbank_version 123. Gemessen per probe_-Tabellen aus den Neuinstallations-
CREATEs gegen die migrierten Tabellen (information_schema: Name, Position, Typ,
Nullable, Default): alle drei Tabellen spaltenidentisch.
Bestand unberuehrt, gemessen mit derselben Messlatte wie beim Refactoring:
alle zehn Modi und dieselben zehn Begegnungen unveraendert erneut gespeichert,
danach Datenbank-Dump der Bestandsspalten (756 Zeilen) und Frontend-Dump
(30995 Zeilen HTML) gegen den Lauf mit dem alten Code verglichen:
VOLLSTAENDIG identisch.
Vorarbeit fuer die STFV-Satzwertung (#304/#306-Konzept, Abschnitt 6): die
Spielpunkte-Kaskade stand woertlich doppelt im PHP — einmal beim Speichern des
Spielberichts (admin.php, Rechenweg A), einmal in begegnungenAktualisieren()
(sportsmanager.php, Rechenweg B). Der Remis-Vorfall (35384a5, 5d1df85) ist genau
aus dieser Doppelung entstanden. Bevor eine vierte Wertung dazukommt, wird die
Regel EINE Funktion: spielpunkteFuerSpiel(wertung, heim, gast) in tools.php,
beide Wege rufen sie nur noch auf. Reine Umformung, keine Verhaltensaenderung;
die dritte Rechenstelle (das erzeugte Formular-JavaScript) bleibt in diesem
Schritt unangetastet.
Gemessen, nicht nur begruendet — vorab wurden vier weitere Prueflige angelegt,
damit ALLE Wertungen und Spielformen unter der Messlatte liegen (C = Sieg 3/
Remis 1, D = Sieg 1, E = Race mit 9:9-Abbruch, F = Mehrere mit Ergebnis je Satz
samt Satz-Remis; dazu die bestehenden A = Gewinnsaetze, B = Einer sowie
Damenbundesliga und Testliga). Ablauf identisch vor und nach der Umformung:
alle zehn Modi unveraendert durchs Formular gespeichert (Rechenweg B ueber alle
116 Begegnungen), dazu zehn Begegnungen quer durch alle Ligen unveraendert
durchs Spielbericht-Formular (Rechenweg A). Danach verglichen:
- Datenbank-Dump (116 Begegnungen, 455 teamspiel-Zeilen, 32 Team-Zeilen,
138 bestenliste_punkte-Zeilen, 756 Zeilen gesamt): VOLLSTAENDIG identisch.
- Frontend-Dump (8 Ligen je 3 Spieltagsansichten + 7 Spielerstatistiken,
30995 Zeilen HTML): VOLLSTAENDIG identisch.
Sven beim Testen von Begegnung 93 (2:2 im Doppel, Modus 3 Gewinnsaetze,
Wertung Sieg 2/Remis 1): das Formular rechnete 7:3 vor, gespeichert wurde 6:2.
„Und das ist meinem Verstaendnis nach doch auch das richtige Ergebnis?" — ja.
Zwei Fehler in einem:
1. Die Spielpunkte werden an DREI Stellen berechnet, nicht an zweien: zusaetzlich
zu admin.php und begegnungenAktualisieren() rechnet das Formular selbst per
JavaScript mit (view_admin.php, spielpunkte_bedingung()). 554ad25/35384a5
hatten die Remis-Sonderregel in die ersten beiden eingebaut, die dritte lief
nach der alten Regel weiter — daher 7:3 gegen 6:2.
2. Die Sonderregel selbst war falsch. „Unentschieden nur, wo der Satzmodus es
zulaesst" war eine Ableitung aus 554ad25, keine Anforderung. Die Wertung
sagt ausdruecklich „Sieg 2 Punkte, Unentschieden 1 Punkt" — das ist eine
Anweisung fuer den gleichen Stand, und eine Zahl von Gewinnsaetzen sagt nur,
WANN ein Spiel endet, nicht dass ein gleicher Stand wertlos ist. Spiele
enden faktisch gleich (Abbruch, Zeitlimit, Absprache); ein 0:0 an der Stelle
verliert dieselbe Information, die es schuetzen wollte.
Also: remisMoeglich() samt beiden Verwendungen entfernt, alle drei Wege rechnen
wieder die langjaehrige Regel. Gemessen auf zwei Pruefligen (je 6 Begegnungen,
30 Spiele, 4 Gleichstaende ungleich 0:0): die auf demselben Datenbestand neu
berechneten Tabellen sind zwischen dem Stand vor diesem PR und danach
VOLLSTAENDIG identisch — keine einzige Zahl weicht ab. Begegnung 93 zeigt im
Formular, auf der Seite und in der Datenbank uebereinstimmend 7:3.
Aus dem Review: „Der Quelltext ist absolut ueberkommentiert." Nach dem Kuerzen
in 554ad25 jetzt vollstaendig — 294 Kommentarzeilen aus fuenf Dateien.
Nachgewiesen unveraendert: der Diff ohne Kommentar- und Leerzeilen gegen
5aee028 ist vor und nach dieser Aenderung derselbe (gleiche Pruefsumme). Es ist
also ausschliesslich Kommentar entfernt worden, keine Zeile Programmtext.
Entfernt wurden nur die von diesem Zweig HINZUGEFUEGTEN Kommentare; jeder
Kommentar, der im alten Stand schon stand, bleibt unangetastet (auch dort, wo
Formularzeilen verschoben wurden).
Sven 2026-09-08: „Teste fuer alle Modus, ob Siege, Unentschieden und
Niederlagen weiter korrekt berechnet werden pro Spiel fuer saemtliche
Modusszenarien."
Beim Testen ueber die volle Matrix (4 Spielpunkte-Wertungen x 7 Satzmodi x 4
Spielstaende = 112 Szenarien) kam ein Fehler DIESES Zweigs heraus: die
Spielpunkte werden an ZWEI Stellen berechnet, und 09ae1c1/554ad25 hatte die
Remis-Pruefung nur in eine davon eingebaut.
Weg A admin.php, Spielbericht speichern — MIT Pruefung
Weg B sportsmanager.php, begegnungenAktualisieren() bei Modus-/
Wettbewerbsaenderung — OHNE Pruefung
Dasselbe Spiel bekam damit verschiedene Spielpunkte, je nachdem, welcher Weg es
zuletzt angefasst hatte: Speichern ergab 0:0, ein Moduswechsel schrieb 1:1
zurueck. Betroffen sind Gleichstaende ungleich 0:0 in Wettbewerben, deren
Satzmodus kein Remis zulaesst (ein fester Satz, ungerade Satzzahl,
Gewinnsaetze) bei Wertung „Sieg 2/Remis 1" oder „Sieg 3/Remis 1" — 8 der 112
Szenarien. Gemessen, nicht geschaetzt.
Die Regel steht jetzt als remisMoeglich() auf Dateiebene und wird von beiden
Wegen aufgerufen, statt als Closure in einem der beiden Loops zu leben.
Matrix danach: 0 Widersprueche.
NICHT betroffen und mitgeprueft:
- Siege/Unentschieden/Niederlagen je Spiel sind in ALLEN 112 Szenarien
unveraendert. Sie kommen in der Spielerstatistik aus dem Vergleich der
PUNKTE (sportsmanager.php:6338), nicht aus den Spielpunkten, und an den
Punkten aendert dieser Zweig nichts.
- Race bleibt unberuehrt: die Race-Normalisierung setzt die Wertung auf 2
(„ohne Umrechnung"), und dort gibt es keinen Remis-Zweig.
- spielerstatistikAktualisieren() selbst ist unveraendert (nur die
Einheiten-Beschriftung kam hinzu).
Sven 2026-09-08: „hier wuerde ich die Option direkt unter ‚Saetze pro Spiel'
ziehen und abhaengig von der Einstellung bei ‚Saetze pro Spiel' benennen".
Die vierte Wertung („ohne Umrechnung") uebernimmt das Spielergebnis als
Spielpunkte — welche Zahl das ist, sagt aber ein ANDERES Feld: Tore bei
„Einer", Saetze bei „Mehrere". Sie stand bisher zwei Gruppen weiter oben unter
„Begegnung", also getrennt von der Angabe, die ihre Bedeutung festlegt.
- „Spielpunkte pro Spiel" (Einzel + Doppel) sitzt jetzt direkt unter „Saetze
pro Spiel" in der Gruppe „Spiel" — wo sie hingehoert: es ist eine Angabe zum
einzelnen Spiel, nicht zur Begegnung. „Begegnung abgeschlossen bei" bleibt in
der Gruppe „Begegnung".
- Der Eintrag heisst jetzt nach der gewaehlten Einheit: „Ohne Umrechnung –
Saetze sind die Spielpunkte" bzw. „… Tore sind die Spielpunkte". Ueber
dasselbe data-tore/data-saetze-Verfahren, das die Siegbedingungen schon
benutzen; umgeschaltet in zeilen_anzeigen(), also auch beim Wechseln ohne
Neuladen. Der alte Sammeltext bleibt als Rueckfall stehen.
- Am lokalen Testserver gerendert und geprueft: Reihenfolge stimmt, beide
Texte kommen uebersetzt an.
- Nebenbei: der Kommentar nannte Datenbankversion 126, tatsaechlich ist es 122.
Drei weitere Punkte aus dem Review.
1. ERGEBNISANZEIGE BEI SAETZEN. Im Spielbericht stand je Spiel NUR ergebnis_detailliert. Bei
reinem „Mehrere" ist das derselbe Satzstand — bei Erfassung je Satz sind es die Saetze, und
dann fehlte, wer das Spiel gewonnen hat. Gemessen: die Zeilen lasen „6:3 | 3:6" ohne jede
Angabe des Standes. Jetzt steht der Stand davor und die Saetze in Klammern dahinter:
„1:1 (6:3 | 3:6)", „2:1 (6:3 | 3:6 | 6:4)". Wo beides dasselbe ist („Einer", oder „Mehrere"
ohne Satzerfassung), bleibt es einzeilig — gegengeprueft an einer Begegnung aus der
Einer-Zeit: unveraendert „6:3", nichts doppelt. Ein nicht gespieltes Spiel bleibt leer und
zeigt kein „0:0".
2. SPIELERSTATISTIK. Die Spalten „T +/-" summieren teamspiel_*_punkte, zaehlen also je
punktetyp Tore oder gewonnene Saetze — hiessen aber immer „Tore". Anders als in der Tabelle
gibt es hier nicht einen Modus: eine Bestenliste kann mehrere Wettbewerbe umfassen, sogar
Individualwettbewerbe. spielerstatistikEinheit() liest deshalb den punktetyp der speisenden
Wettbewerbe; sind sie einig, steht die richtige Einheit, sonst „Punkte" — statt eine zu
behaupten, die nicht fuer alle Zeilen gilt. Neuer Schluessel COM_SPORTSMANAGER_SETS_SHORTCUT
in beiden Sprachen. Alle drei Faelle gemessen: nur „Mehrere" -> „S +/-" mit „Saetze",
gemischt -> „P +/-" mit „Punkte", zurueck -> wieder „S".
Und der Tooltip der Tabellenspalte hiess COM_SPORTSMANAGER_DIFFERENCE = „Differenz Tore",
widersprach also der neuen Beschriftung „Saetze". Er nennt jetzt nur die Rechenart
(„Differenz"), wie sein Geschwister „Verhaeltnis" schon immer; die Einheit steht in der
Spalte. Einzige Verwendungsstelle.
3. SPIELFOLGE. Die sechs Auswahlfelder der Spielfolge und der Verknuepfungen stehen wieder
auf medium — sie tragen kurze Werte und sollten nicht mitwachsen. Breit bleiben nur die 33
Felder der Einstellungen, wo die langen Beschriftungen stehen.
Aus dem Review: „Die Summe der Tore ist auch falsch." Sie ist es nicht — sie ist falsch
BESCHRIFTET. Unter punktetyp „Mehrere" ist begegnung.heim_punkte seit immer die Summe der
Satzstaende, und die Tabellenspalte heisst „Tore". Bisher fiel das nicht auf, weil die Tore
gar nicht bekannt waren; mit der Erfassung je Satz sind sie es, und die Spalte behauptet
etwas, was sie nicht zeigt.
Die Absicht war schon da: tabelleAnzeigen() fragt `punktetyp != 2 ? Tore : Saetze` — nur
kennt punktetyp ausschliesslich 0 und 1, die Bedingung war also nie wahr. Jetzt
`punktetyp == 0 ? Tore : Saetze`, an beiden Spaltenkoepfen (Absolut und Differenz/Verhaeltnis).
Gemessen an zwei Wettbewerben derselben Installation: bei punktetyp 1 stehen jetzt „Saetze
Absolut" und „Saetze", bei punktetyp 0 unveraendert dreimal „Tore". Keine Zahl aendert
sich, kein Sortierschluessel, keine Bestandsdaten.
Die Alternative — die echten Tore summieren, wo Satzergebnisse geführt werden — waere ein
Eingriff in Bestandsstaende und in die Tabellensortierung und gehoert in einen eigenen PR
mit Migration (Sven 2026-09-07).
Drei Punkte aus dem Review.
1. UNENTSCHIEDEN, WO ES KEINES GIBT. Gemeldet: „2 Punkte pro Spiel und 1 Punkt
unentschieden ausgewaehlt, es kommt aber nur 1 Punkt pro Spiel." Nachgestellt an einer
Begegnung mit vier Spielen (Modus: Mehrere, Ergebnis je Satz, 3 Gewinnsaetze, Wertung
„Sieg 2, Remis 1"): Spiel 1 mit 6:3 3:6 steht 1:1 nach Saetzen und bekam 1:1 Spielpunkte.
Bei einer Zahl von GEWINNSAETZEN ist ein gleicher Satzstand aber kein Unentschieden,
sondern ein unfertiges Spiel — dafuer gibt es keinen Punkt. Die Rechnung fragt jetzt, ob
der Modus ueberhaupt ein Remis zulaesst: bei Gewinnsaetzen nein, bei fester Satzzahl nur
bei gerader Zahl, ohne Angabe wie bisher. Gemessen an derselben Meldung: Spiel 1 jetzt
0:0, die Begegnung 6:0 statt 7:1; die Spiele 2 bis 4 unveraendert 2:0.
Die Rechnung selbst ist Altbestand und von diesem PR nicht angefasst — erst die neue
Satzzahl liefert die Information, mit der sie unterscheiden kann.
2. KOMMENTARE. Zu Recht beanstandet. Was Sprachmechanik erklaert oder den Code
nacherzaehlt, ist raus; was eine Entscheidung oder einen Messwert festhaelt, bleibt in
hoechstens drei Zeilen. Die Herleitung gehoert in den PR-Text, nicht in die Datei.
update.php von 87 auf 22 Kommentarzeilen (57 % auf 25 % der Aenderung), ueber alle Dateien
von 459 auf 267.
3. AUSWAHLFELDER. Die 39 Auswahlfelder des Modus-Formulars stehen von medium (200 px) auf
large (500 px). Bei 200 px brach eine Beschriftung wie „Ohne Umrechnung - Tore bzw. Saetze
sind die Spielpunkte" ab. Nur dieses Formular, keine andere Ansicht.
Danach geprueft: sechs Ansichten HTTP 200 ohne PHP-Meldung, php -l sauber, dieselbe Meldung
mit dem erwarteten Ergebnis.
Vorsprung und Deckelung je Spiel, dieselbe Regel eine Ebene tiefer fuer den
einzelnen Satz, eine Auswahl der Satzzahl (feste Zahl oder Gewinnsaetze) samt
optional abweichender Regel fuer den Entscheidungssatz, eine Auswahl
"Mehrere - mit Ergebnis je Satz" mit Satzzeilen im Begegnungsformular — und
eine Zaehlweise "Race-Modus", in der der Stand ueber die ganze Begegnung
durchlaeuft.
Die Regel beschreibt den Wettbewerb, sie lehnt keine Eingabe ab: ein 8:6 dort,
wo ein Spiel bei 6 endet, hat oft einen Grund, den keine Regel kennt, und ueber
die Richtigkeit wachen beide Mannschaften. Ihr Nutzen liegt darin, dass eine
auswertende Anwendung endlich erkennen kann, ob ein Spiel entschieden ist.
RACE-MODUS. Das Spiel N endet, wenn der LAUFENDE Stand einer Seite N mal den
Schritt erreicht; eingetragen wird wie bisher die DIFFERENZ dieses Spiels, und
der Begegnungsstand bleibt ihre Summe. Gemessen an 91 Bundesliga-Begegnungen:
6:5 5:7 7:5 4:7 8:2 6:9 6:5 summiert sich auf 42:40, und laufend gelesen trifft
jedes Spiel seine Etappe (6, 12, 18, 24, 30, 36, 42). Die Ergaenzung im Formular
rechnet deshalb mit laufenden Staenden und zieht ab, was schon auf dem Konto
steht.
Im Formular steht statt des gespeicherten "Zwischenergebnis" jetzt der
GESAMTSTAND, gross und in Echtzeit: die Spielpunkte, gerechnet aus den
eingetragenen Spielen mit derselben Arithmetik, die der Server beim Speichern
anwendet. Es ist DIE Zahl, die die Begegnung nach aussen hat — Liste,
Mannschaftsseite und die Kopfzeile der Begegnungsdetails zeigen alle
heim_spielpunkte:gast_spielpunkte. Gemessen an einem 5er-Spielplan mit "Sieg: 1
Punkt": ein eingetragenes 6:4 ergibt "1:0", genau wie die Details. Die Torsumme
gehoert dagegen in die Tabellenspalte "Tore" und nicht in den Kopf einer
Begegnung. Die Zeile steht als letzte des Kopfes, unter dem Kommentar, mit
demselben senkrechten Abstand, den die Spiele untereinander haben — und ohne
erklaerenden Zusatz: "Gesamtstand" samt Zahl sagt es selbst.
Das Ziel wird nicht eingegeben, sondern folgt aus der Spielfolge. Dort steht
deshalb die Rechenvorschrift ("Anzahl der Spiele aus der Spielfolge x Schritt je
Spiel") und die konkrete Zahl erst ab zwei Spielen ("derzeit 7 Spiele x 6 = 42
Tore"): bei einem einzigen — dem Anfangszustand — waere "1 Spiele x 6 = 6 Tore"
nicht nur ungrammatisch, sondern eine Auskunft ueber einen Zustand, den niemand
gemeint hat. Mindestvorsprung, Grenze und ein moegliches
Unentschieden gelten nur fuer das letzte Spiel. Die Zaehlweise setzt
"Spielergebnis als Spielpunkte" und einen Satz je Spiel voraus und setzt beides
mit; das Ziel wird zusaetzlich nach punkte_sieg_* gespiegelt (mit Vorzeichen
fuer das Unentschieden), damit eine aeltere Programmfassung dieselbe wahre
Aussage liest. Vorrunde und Hauptrunde sind zwei Mannschaftsspielplaene. Die Zaehlweise steht als
erste Zeile ihrer Gruppe: was sie ausblendet, liegt darunter — Felder ueber einer
Auswahl verschwinden zu lassen, liest sich als Fehler.
Damit die Einstellungen ueberhaupt auseinanderzuhalten sind, steht dem Editor
eine kurze Begriffsleiter voran: Begegnung, Spiel, Satz, Tor. Sie stecken
ineinander, und die Gruppen darunter folgen genau dieser Reihenfolge. Drei
weitere Hinweiszeilen sagen, was "Ergebnis je Satz" bedeutet, wozu die Angaben
gut sind und wie der Race-Modus zaehlt.
Die vierte Spielpunkte-Wertung hiess "Keine" und sagte damit das Gegenteil
dessen, was sie tut: gewertet wird alles, nur ohne Umrechnung — das Ergebnis
des Spiels IST sein Spielpunktestand. Sie heisst jetzt "Ohne Umrechnung - Tore
bzw. Saetze sind die Spielpunkte"; die drei uebrigen beginnen mit "Sieg:", also
sagt schon der Satzanfang, dass es hier nicht um einen Sieg-Wert geht.
Die Hinweiszeilen brechen ausdruecklich um und haben ein Mass (max-width): die
Zellen dieses Formulars tragen alle `nowrap`, was fuer Beschriftungen und
Auswahlfelder richtig ist und fuer Prosa falsch — die Hinweise zogen die Tabelle
sonst beliebig breit. Wo ein Hinweis steht, ist die Beschriftung oben
ausgerichtet: sonst stand sie auf halber Hoehe des Absatzes statt neben dem
Auswahlfeld, zu dem sie gehoert.
Die Satzebene fuehrt dasselbe Vorzeichen wie die Spielebene: der Betrag ist der
Siegwert, ein negatives Vorzeichen erlaubt zusaetzlich ein Unentschieden ein Tor
darunter. Ohne diese Faelle waere ein Satz, der remis endet, gar nicht
hinterlegbar gewesen.
Bestehende "Mehrere"-Modi werden in die Satzzahl UEBERFUEHRT, und zwar restlos: 1 wird ein fester Satz, ein positiver Wert N werden N
Gewinnsaetze, ein negativer wird die feste Satzzahl 2(|N|-1) — denn ein Remis
setzt voraus, dass alle Saetze gespielt werden. Auch Werte jenseits der neuen
Auswahl werden ueberfuehrt statt als "Beliebig" liegen zu bleiben, denn sie sind
nicht unsinnig, nur ungewoehnlich: ein gespeichertes "Spiel gewonnen bei 42
Saetzen" bleibt nach der Ueberfuehrung dieselbe wahre Aussage, nur an der
richtigen Stelle. Das Formular zeigt einen solchen Wert als EIGENEN,
vorgewaehlten Eintrag der Auswahl ("42 Gewinnsaetze"), speichert ihn unveraendert
wieder und bietet ihn, einmal weggestellt, nicht mehr an. Sonst haette dort eine
Zeile ohne Auswahlfeld gestanden — die Beschriftung "Spiel abgeschlossen bei:"
und rechts daneben nichts — oder die Zahl waere beim ersten Speichern
verschwunden. Gemessen an drei Bestandswerten: 42 wird -42 und uebersteht Anzeige
und Speichern unveraendert, -9 wird die feste Satzzahl 16, und nach dem Wechsel
auf "3 Gewinnsaetze" hat die Auswahl 18 statt 19 Eintraege. Der Race-Modus wird
NICHT automatisch erkannt; er ist aus Bestandsdaten nicht sicher abzuleiten und
wird einmal von Hand gewaehlt.
Dass die Ueberfuehrung nichts verschiebt, ist gemessen und nicht bloss
begruendet: dieselbe Datenbank einmal unter der alten Fassung mit altem Schema
und einmal unter dieser, je sieben Begegnungen unveraendert neu gespeichert und
dann Tabellen, Uebersicht, Spielerstatistik und drei Begegnungsdetails
verglichen — 7942 Zeilen HTML und 436 Datenzeilen aus begegnung und teamspiel,
kein einziger Unterschied. Darunter der Bestandsmodus mit punkte_sieg 42, den
die Ueberfuehrung anfasst.
Umgekehrt spiegelt der Editor die Satzzahl VOLLSTAENDIG nach punkte_sieg_*
zurueck, nicht nur bei Gewinnsaetzen: eine feste Satzzahl sagt genau, welche
Endstaende es gibt, und damit auch, bei welchem Stand das Spiel entschieden ist —
4 feste Saetze heissen "gewonnen bei 3, Unentschieden bei 2:2" (-3), 3 feste
Saetze "gewonnen bei 2" (2). Das ist die Umkehrung der Ueberfuehrung und deshalb
verlustfrei. Zuvor blieb punkte_sieg_* bei fester Satzzahl leer, mit der
Begruendung, sie sei keine Siegbedingung — richtig gedacht, aber praktisch falsch:
ein Client, der nur die alten Felder kennt, haette nach einmaligem Oeffnen und
Speichern eines Bestandsmodus "Beliebig" gelesen, wo vorher eine Zahl stand. Und
es gibt einen solchen Client, den wir nicht mitziehen koennen (Kickern). Gemessen:
feste Satzzahl 4 -> -3, 3 -> 2, 6 -> -4, 1 -> 1, und Gewinnsaetze unveraendert
3 -> 3, 2 -> 2.
Die Einheit der Spielebene folgt punktetyp: Tore bei "Einer", Saetze bei
"Mehrere". Bisher stand dort in beiden Faellen "Punkte" — und genau daran war
eine Fehlkonfiguration nicht zu erkennen. Am echten TFVB-Spielplan 2026 sah man
es doppelt: "Spiel abgeschlossen bei 5 Punkte" direkt ueber "Mindestvorsprung 2
Tore", dieselbe Einheit in zwei Woertern. Innerhalb eines Satzes wird ohnehin
durchgaengig von Toren gesprochen.
Und "Spiele in Spielerstatistik" waehlt "Alle Spiele" jetzt ausdruecklich vor,
statt sich darauf zu verlassen, dass es die erste Option ist. Aus "Vorsprung" wird "Mindestvorsprung" (und
der Wert 1 heisst "Keiner"), aus "Deckelung" wird "Spaetestens gewonnen bei".
Die Einstellungen sind in fuenf Gruppen geordnet, vom Grossen ins Kleine:
Allgemein, Begegnung, Spiel, Satz, Spieler und Statistik. Dafuer wechseln drei
bestehende Zeilen den Platz — "Aktiv" nach oben zu "Bezeichnung",
"Spielernamen" hinunter zu "Spiele in Spielerstatistik", und die Gruppe
"Begegnung" vor die Gruppe "Spiel"; sonst ist nichts verschoben. Der Knopf
"Doppel getrennt einstellen" bekommt eine eigene Zeile, weil er auch die
Satzregel schaltet. Eine Gruppe ohne sichtbare Zeile zeigt keine Ueberschrift.
Die Spielfolge zeigt nur noch die Zeilen, die es gibt: Spiel 1 steht fest, weitere
kommen ueber "Spiel hinzufuegen", jede weitere traegt ein Kreuz zum Entfernen — ohne
Rueckfrage, denn gespeichert ist bis zum Speichern nichts. Verknuepfungen fangen bei
null an. Alle Zeilen bleiben im Dokument und werden beim Entfernen nach oben geschoben,
weil das Speichern spiel_1, spiel_2 … der Reihe nach liest und beim ersten leeren Paar
abbricht. Das Ziel des Race-Modus rechnet dabei mit: es haengt an der Zahl der Spiele,
und die aendert sich hier.
Bei "Mehrere" beantwortet die Satzzahl die Frage vollstaendig — "Spiel abgeschlossen
bei" wird dort deshalb gar nicht mehr angeboten. Es geht dabei nichts verloren, weil
jeder Bestandswert in die Satzzahl uebergeht (siehe oben) und ein Wert jenseits der
Auswahl dort als eigener Eintrag steht.
Ohne geforderten Mindestvorsprung endet ein Spiel exakt beim Siegwert — eine Grenze
kann dann nie greifen. "Spaetestens gewonnen bei" wird deshalb ueberall nur noch
angeboten, wo ein Vorsprung verlangt ist, und beim Speichern auf null gesetzt.
Die Spielfolge steht schon in derselben Spalte unter den Einstellungen und bekommt
deshalb nur ihre Ueberschrift — als sechste Gruppe. Und "Spiele in Spielerstatistik"
stellte nackte Zahlen neben "Alle Spiele"; sie sagen jetzt, was sie zaehlen ("nur die
ersten 3 Spiele").
Beim WECHSEL der Satzart wird nichts umgerechnet — aus sechs Toren wuerden sechs
Saetze, und umgekehrt; aus "drei gewonnene Saetze" folgt keine Torzahl, es ist also gar
nicht rekonstruierbar. Stattdessen zwei Massnahmen. Erstens fragt der Editor nach, wenn
"Saetze pro Spiel" geaendert wird und unter dem Spielplan schon Ergebnisse stehen.
Zweitens ueberleben echte Satzergebnisse den Weg zurueck von "mit Ergebnis je Satz" auf
"nur der Satzstand": bringt ein Aufruf keine Satzfelder mit, bleibt der Stand
unveraendert und stehen im Bestand mehr als ein Paar, bleibt ergebnis_detailliert, wie
es ist — sonst haette blosses Oeffnen und Speichern "6:3 3:6 6:3 3:6 8:6" durch "3:2"
ersetzt. Wird der Stand geaendert, wird der Detailtext wie bisher neu geschrieben.
RUECKWAERTSKOMPATIBEL, und zwar geprueft und nicht bloss behauptet.
EINE Datenbankversion, 122, nicht sechs (Sven 2026-09-03): alle Spalten in einem
ALTER, die Ueberfuehrung dahinter, ein Zaehler hoch. 121 gehoert dem
Hall-of-Fame-Zweig (PR #303 / Issue #300), auf dem dieser Stand aufsetzt; dieser
Block muss deshalb der LETZTE der Kette bleiben — $datenbank_version wird einmal
gelesen, beide Bloecke laufen also im selben Aufruf, aber die Nummer des zuletzt
gelaufenen bleibt stehen. Gemessen gegen eine Datenbank, die #303 schon hinter sich
hat: 121 -> 122, unsere 24 Spalten dazu, die drei Hall-of-Fame-Spalten unberuehrt,
der Bestandsmodus mit punkte_sieg 42 als saetze_modus -42 ueberfuehrt. Die Zwischenstufen waren nur
die Reihenfolge, in der ich gebaut habe — kein Bestand hat sie je gesehen, und
sechs Schritte, die immer zusammen laufen, sind sechs Gelegenheiten, auf halbem
Weg stehenzubleiben. Gemessen an einer Datenbank auf Stand 120: ein Aufruf, 120
-> 122, 13 Spalten -> 37, der Bestandsmodus mit punkte_sieg 42 als saetze_modus
-42 ueberfuehrt; ein zweiter Lauf tut nichts (die Spaltenpruefung und das WHERE
der Ueberfuehrung sehen beide, dass es schon geschehen ist).
Ein Client, der nur die ueberlieferten Felder liest, soll weiterarbeiten wie
bisher — es gibt mindestens einen, den wir von hier aus nicht mitziehen koennen
(Kickern). Dafuer zaehlt nicht, was hinzukommt, sondern was sich an dem aendert,
was er schon liest. Neue Spalten sind harmlos: die Modus-Zeile geht als ganzes
Objekt in die JSON-Ansicht, unbekannte Schluessel ignoriert jeder Client. Die
Ueberfuehrung selbst fasst kein altes Feld an. Bleiben zwei Stellen, und beide
sind versorgt.
Erstens der Wertebereich von punktetyp. "Mehrere - mit Ergebnis je Satz" war
zuerst ein dritter Wert 2 — und punktetyp ist genau das Feld, an dem eine fremde
Anwendung ablesen muss, ob die Punkte eines Spiels Tore oder gewonnene Saetze
sind. Wer "1 = Saetze, sonst Tore" schreibt statt "0 = Tore, sonst Saetze",
haette bei einem Satzstand 3:2 "3:2 Tore" gelesen; beide Fassungen stehen im
Sports Manager selbst. Die Angabe bekommt deshalb eine EIGENE Spalte
(satzergebnisse), punktetyp behaelt seine zwei Werte und seine Bedeutung. Ein
Altclient liest weiter "Mehrere" und rechnet richtig — die Punkte SIND die
gewonnenen Saetze, daran aendert die feinere Erfassung nichts; er verpasst nur
das Zusaetzliche. Die Auswahl im Editor hat weiter drei Eintraege, der dritte
schreibt punktetyp 1 samt satzergebnisse 1.
Zweitens: der Server verlangt die Satzergebnisse NICHT, auch wo sie eingestellt
sind. Er fragt beim Speichern ueberhaupt nicht nach dem Modus — kommt kein
Satzfeld mit, gilt der Summenwert, wie immer. Gemessen an einem Spielplan mit
"3 Gewinnsaetze" und Satzerfassung, gemeldet wie ein Altclient nach
SetsMode.setsOnly (nur spiel_N_*_punkte, keine Satzfelder): Spiel 1 als 3:1
gespeichert, Spielpunkte 1:0, ergebnis_detailliert "3:1" — genau die Zeile, die
das eigene Formular unter "Mehrere" auch schreibt. Dieselbe Begegnung nimmt
gemischt beides auf: Spiel 1 als Satzstand, Spiel 2 als "6:3 3:6 6:4". Meldet der
Altclient danach beide Spiele erneut als Satzstand, ueberleben die Satzergebnisse
von Spiel 2 unveraendert; dasselbe beim Oeffnen und Speichern im Verbandsformular,
das fuer diesen Modus nur Satzzeilen zeigt — es belegt sie fuer Spiel 1 bewusst
nicht vor (aus "3:1" folgt kein erster Satz) und schickt den gespeicherten Stand
im versteckten Summenfeld mit. Nur wenn der Altclient das Spiel AENDERT, weicht
der Detailtext dem neuen Stand ("2:0") — er beschrieb dann ein anderes Ergebnis.
Und wo Satzergebnisse gefuehrt werden, bleibt ergebnis_detailliert bei einer Meldung
ohne Satzfelder LEER, statt wie sonst den Stand zu spiegeln. Dieses eine Paar bedeutet
dort naemlich etwas anderes als sonst: das Feld fuehrt Saetze, also liest man „3:1" als
einen Satz mit drei Toren und rechnet daraus 1:0 statt 3:1 — in unserer eigenen App
steckte genau dieser Fehler. Leer ist die Wahrheit: der Satzstand steht in
teamspiel_*_punkte, die Tore darin sind nicht bekannt, und die Anzeige laesst die
Detailspalte dann weg statt denselben Wert zweimal zu zeigen. Erfundene Platzhalter
(„1:0" je gewonnenen Satz) waeren die Alternative und sind verworfen: gespeichert liesse
sie niemand mehr von einer echten Meldung unterscheiden (Sven 2026-09-03). Es ist die
einzige Stelle, an der das Speichern nach dem Modus fragt. Gemessen: dieselbe
Altclient-Meldung schreibt unter „Mehrere" weiter „4:2" und unter „Mehrere - mit
Ergebnis je Satz" nichts; echte Satzergebnisse daneben bleiben unberuehrt, auch nach
erneuter Summenmeldung und nach Oeffnen und Speichern im Formular.
Der Race-Modus braucht dafuer nichts: fuer einen Altclient sieht ein
Race-Spielplan aus wie punktetyp 0, "Ergebnis als Spielpunkte" und punkte_sieg =
Ziel — also genau so, wie ein solcher Spielplan heute schon eingestellt ist. Er
verliert nichts und gewinnt nichts.
Die Spielerauswahl erscheint nur noch fuer eine Mannschaft, die auch Spieler
hinterlegt hat — sonst stand dort ein Feld mit nichts als dem Leereintrag und
behauptete eine Wahl, die es nicht gibt. Gespeichert wird dann genau wie bei
einer leeren Auswahl: der Server liest die fehlenden Felder mit Vorgabe 0, also
"kein Spieler". Die Absende-Pruefung wird SEITENWEISE erzeugt und liest nur, was
es gibt; ohne Kader auf beiden Seiten bleibt von ihr "return true" uebrig. Sonst
haette eine Forderung nach Namen, die niemand erfuellen kann, das Melden
verhindert statt es zu ordnen. Gemessen an drei Faellen: beide Kader (12 Felder
je Seite), nur der Heimkader (12 zu 0, und die Pruefung liest nur heim), keiner
(0 Felder, Pruefung ohne Feldzugriff, ein 5:3 speichert mit vier Spieler-IDs 0
und Begegnungsstand 5:3 bei Spielpunkten 1:0) — der letzte Fall ausdruecklich
mit "Spielernamen: Pflicht".
Nebenbei behoben:
- Durchweg leere Satzfelder gewannen gegen ein vorhandenes Summenergebnis; das
blosse Oeffnen und Speichern loeschte damit Altbestand (gemessen: von sieben
gespeicherten Spielen blieb eines uebrig).
- "Doppel separat" wurde allein aus punkte_sieg_* abgeleitet; abweichende
Doppelwerte in den neuen Feldern waeren verborgen und beim naechsten
Speichern ueberschrieben worden.
- Zwei hartkodierte deutsche Zeichenketten im uebersetzten Formular nutzen
jetzt ihre vorhandenen Sprachschluessel.
- COM_SPORTSMANAGER_SETS fuehrte den Umlaut als HTML-Entitaet und wurde in zwei
Auswahlfeldern erneut maskiert ("S&auml;tze"); jetzt literal.
- halloffame_id: Bereichssuche (z.B. "1-5") ist nicht mehr möglich, nur noch einzelne Werte.
- jahr: Bereichs- und Einzelwerte werden auf 1900..aktuelles Jahr+5 begrenzt; liegt bei einem Bereich der 2. Wert unter dem 1., werden die Werte vertauscht statt den Bereich zu verwerfen.
- halloffameNameLink verlinkt bei Vereinen jetzt nur noch, wenn der Verein nicht ausgetreten ist (analog zur bestehenden Spieler-Aktiv-Prüfung).
## Neue Frontend-Darstellungen (gruppierung)
- gruppierung=jahr - Jahresrückblick: eine Tabelle je Jahr mit allen Disziplinen, inkl. mehrerer Plätze, Team-Mitspielern und Spalten-/Zeilen-Layout wie auf der Detailseite.
- gruppierung=summe - Ranking über alle Disziplinen hinweg: ein Eintrag je Spieler/Team mit mindestens einem 1. Platz, inkl. Titelanzahl und Auflistung aller Titel (Disziplin, Jahre).
- gruppierung=summedisziplin - wie summe, aber eine eigene Rangliste je Disziplin.
## Neue/erweiterte Steuerungsparameter
- platzierung (inspalten/inzeilen), plaetzezeigen, sortierung (kontextabhängig: Jahresreihenfolge oder anzahl/name in den Summen-Ansichten).
- anzahltitel - Mindestanzahl an Titeln für die Summen-Ansichten.
- halloffame_id und jahr als Filter für alle Hall-of-Fame-Seiten, mit Komma- und Bereichs-Syntax (2006-2010,2015).
- Titel fällt auf den Joomla-Menütitel zurück, wenn kein eigener Titel im Menüpunkt gesetzt ist.
- Überschrift semantisch als h1 statt div.
## Mannschaftsspieler-Feld
- Neues Datenbankfeld teamspieler (TEXT) an #__sportsmanager_mitglied_von_halloffame, Eingabe im Backend als Textarea (nur bei Mannschaftsdisziplinen).
- Anzeige im Frontend bei platzierung=inzeilen oder wenn nur ein Platz gezeigt wird, sofern mindestens ein Eintrag >= 3 Zeichen vorhanden ist.
## Verlinkung & Bilder
- Spieler-, Vereins- und Mannschaftsnamen sind jetzt überall anklickbar (Detailseite, Jahresübersicht, Summen-Ansichten) und führen zur jeweiligen Profilseite - inaktive Spieler (ohne aktuellen Verein) bleiben unverlinkt.
- Dummybilder: neues geschlechtsneutrales Bild (spieler-n.png) für Spieler ohne Datenbank-ID; deren Geschlecht wird zusätzlich anhand der übrigen Spieler mit ID derselben Disziplin geschätzt, bevor auf das neutrale Bild zurückgefallen wird.
- Fehlt der Name zu einer Platzierung, wird in der Spaltenansicht nur das Bild weggelassen, in der Zeilenansicht die komplette Zeile.
## Neues Feld "nicht_ausgespielt"
- Neue Spalte nicht_ausgespielt (BOOL) hinter jahr an #__sportsmanager_mitglied_von_halloffame (Teil von Datenbank-Version 121).
- Admin-Formular: Checkbox neben dem Jahr-Feld; bei Aktivierung werden alle anderen Felder deaktiviert, beim Speichern werden Platz 2/3 gelöscht und Platz 1 auf reines nicht_ausgespielt=1 ohne Team-/Spielerdaten gesetzt.
- Frontend-Detailseite und Backend-Jahresliste zeigen bei solchen Einträgen "Nicht ausgespielt" statt Team-/Spielername an.
- Jahresübersicht und beide Summen-Ansichten überspringen solche Einträge vollständig.
## Vereins-Dropdown im Backend gruppiert
- Die Vereinsliste im Auswahlfeld (Plätze 1-3) ist jetzt in zwei optgroup-Blöcke aufgeteilt: "Aktive Vereine" / "Inaktive Vereine" (neue Sprachkonstanten COM_SPORTSMANAGER_ACTIVE_CLUBS / COM_SPORTSMANAGER_INACTIVE_CLUBS). Innerhalb jeder Gruppe bleibt die alphabetische Sortierung erhalten.
## Routing-Fix
- task=team_details und task=verein_details funktionierten nur, wenn der aktuelle Menüpunkt bereits auf content=teams bzw. content=vereine stand (z. B. beim Verlinken von der Hall-of-Fame-Seite aus nicht). Beide Tasks laufen jetzt wie spieler_details über eine content-unabhängige Route.
## Performance
- Options-Liste für Vereins-/Spieler-Dropdowns im Backend-Formular wurde bis zu 6x komplett neu gerendert (3 Plätze x 2 Spieler bzw. 3x Vereinsliste). Jetzt wird sie nur noch 1x aufgebaut, in einem <template>-Element abgelegt und per JavaScript in die <select>-Felder befüllt.
- Team-ID-Auflösung für Mannschaften ohne Vereinszuordnung läuft jetzt über eine einmalig geladene Liste statt einer Datenbankabfrage pro Zeile.
## Bugfixes
- halloffameTeamIdFuerTeamname() erwartete einen nicht-nullbaren string und stürzte bei nicht_ausgespielt-Einträgen (teamname = NULL) mit einem TypeError ab. Parameter ist jetzt nullable, leerer/NULL-Teamname liefert direkt null zurück.
- Bei Einzel-Disziplinen wurden Jahre in den Summen-Ansichten doppelt gezählt, wenn in der Datenbank (z. B. aus Altdaten) noch ein spieler2_id hinterlegt war; wird jetzt nur noch bei echten Doppel-Disziplinen berücksichtigt.
## Migration
- Datenbank-Version 121: neues Feld teamspieler, neue Spalte nicht_ausgespielt, Bereitstellung des neutralen Dummybilds für Bestandsinstallationen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Season filter dropdowns in all frontend views (Mannschaftswettbewerbe,
Turniere, Teams, Spielerstatistiken, Individualwettbewerbe, Ranglisten)
now navigate via JS URL update (window.location with searchParams) instead
of submitting a POST form. This puts filter_saison_id in the URL, making
season-filtered views bookmarkable and shareable.
The PHP backend already reads filter_saison_id from $_REQUEST (covers GET),
and the cookie is still set as fallback for links that don't carry the param.
For veranstaltungHeaderAlone (single competition detail view), the JS also
resets task=veranstaltungen and removes veranstaltungid on season change,
matching the previous form-based behaviour of navigating back to the list.
https://claude.ai/code/session_01VyKCAgyEfixxR6RhAkBSEL
- mark teams which have requested a game shift
- display amount of time that a game has been shifted
- display time that has passed between game and result proposal, and result proposal and result validation
- mark games with incomplete player data
@@ -40,5 +49,59 @@ joomla specific database prefixes like #__
To set it up, insert into the configuration popup which follows after you enable the framework support:
Joomla install path: `./data/joomla_data`
JConfig: `./data/joomla_data/configuration.php`
> This works only with mounted volumes. However, mounted volumes will slow down the joomla instance significantly.
> The current setup does not use mounted volumes.
> An alternative would be to download joomla and use that installation
### Debugging (with Docker/Intellij)
1. Start Docker Container (see above)
2. Create a terminal for that container
```shell
docker exec -it <container_name> bash
```
3. install xdebug within the container since joomla does not come with xdebug preinstalled
```shell
pecl install xdebug
```
4. restart the container
5. In Intellij Go to [File | Settings | Languages & Frameworks | PHP | Servers](jetbrains://idea/settings?name=Languages+%26+Frameworks--PHP--Servers) and setup your server
| | |
|----------|-----------|
| name | anything |
| host | localhost |
| port | 8080 |
| debugger | xdebug |
use the path mapping and map the repo structure to the container content
Hint: for technical details regarding the release process have a look into .github/...
To create a release these steps need to be followed
1. make sure all needed code changes are merged from dev -> stage -> prod, since releases may only be build on prod branch
2. give pull requests meaningful names and label them enhancement/bug/chore since labels and names are used for release note generation
Hint: if a specific pull request should be ignored, add the label changelog-ignore
3. tag a commit (recommended is the latest merge on prod). The pipeline is listening for any tag fitting `v[0-9]+.[0-9]+.[0-9]+`
```shell
git tag -a v1.2.3 1a2b3c4 -m "Release version 1.2.3"
```
4. push the tag
```shell
git push origin --tags
```
5. the tag push will trigger the pipeline, and it will create the release and store in GitHub
A release can be created again anytime by deleting the release from GitHub, deleting the tag (from GitHub and additionally from git)
and repeating step 3 and 4
Further: merges from dev to stage and from stage to prod can only be done by creating pull requests. These pull requests will be automatically labeled as changelog-ignore
COM_SPORTSMANAGER_LAYOUT_GENERAL_CONTENT_OPTION_DESCRIPTION_DESC="Beschreibung, die unterhalb des Titels angezeigt wird (WICHTIG: Werden HTML-Tags verwendet, müssen auch Umlaute in HTML-Code angeben werden)"
COM_SPORTSMANAGER_LAYOUT_GENERAL_CONTENT_OPTION_CATEGORIES_DESC="Eine optionale Auswahl an durch Kommata getrennte Kategorienummern"
COM_SPORTSMANAGER_LAYOUT_GENERAL_CONTENT_OPTION_CATEGORIES_DESC="Eine optionale Auswahl von Kategorienummern durch Kommata oder Spiegelstrich getrennt"
COM_SPORTSMANAGER_LAYOUT_GENERAL_CONTENT_OPTION_EXTRA_PARAMS_DESC="Optionale zusätzliche Parameter für den Link in der Form Name1=Wert1&Name2=Wert2, die bei Aufruf dieses Menüpunkts wie GET-Parameter zur Verfügung stehen"
COM_SPORTSMANAGER_LAYOUT_GENERAL_CONTENT_OPTION_DESCRIPTION_DESC="Description that will be shows below the titel (IMPORTANT: if html tags are used, special characters must be maskeraded)"
COM_SPORTSMANAGER_LAYOUT_GENERAL_CONTENT_OPTION_EXTRA_PARAMS_DESC="Optional additional parameters for the link in the form name1=value1&name2=value2, made available as GET parameters whenever this menu item is called"
COM_SPORTSMANAGER_LAYOUT_ELO_RANKING_TITLE="Layout: elo ranking"
COM_SPORTSMANAGER_LAYOUT_ELO_RANKING_DESC="Listing of players sorted by elo rating"
return"".$prefix." (SELECT berechtigt_turnier_id FROM #__sportsmanager_berechtigt_fuer_turnier WHERE berechtigt_user_id = $user_id AND DATEDIFF(letzter_tag, NOW()) >= -14) ";
return"".$prefix." (SELECT berechtigt_turnier_id FROM #__sportsmanager_berechtigt_fuer_turnier WHERE berechtigt_user_id = $user_id AND DATEDIFF(letzter_tag, NOW()) >= -21) ";
}
functionvereinFilter($prefix):string
@@ -220,7 +464,7 @@ function veranstalterFilter($prefix): string
Log::add('can\'t sent '.$currentReminder.'. email reminder for tournament '.$row->turnierbezeichnung.': no recipient set',Log::WARNING,'com_sportsmanager');
continue;
}
$now=newDateTime();
$last_day=newDateTime($row->letzter_tag);
$last_day->modify('+1 day');// start to count at the end of the day, not at the beginning
."\n\nLaut Turnierordnung müssen die Ergebnisse spätestens 24 Stunden nach Turnierende eingetragen werden. Bitte reich die Ergebnisse umgehend nach."
."\n\nDu erhältst diese Mail, weil du als Berechtigter für das Turnier eingetragen wurdest. Falls du nicht der Veranstalter bist, leite diese Email bitte entsprechend weiter."
."\n\nHochladen der Ergebnisse über ".SportsManagerURL('&task=admin_turnierdisziplinen&turnierid='.$row->turnier_id,-1).".";
COM_SPORTSMANAGER_IMPORT_MESSAGE="Im Import sind ausschließlich Spielerdaten zum Verein %s enthalten. Soll ausschließlich der Spielerbestand des einen Vereins aktualisiert werden, muss der zugehörige Verein unten ausgewählt werden. Beinhaltet der Import den gesamten Spielerbestand einer Organisation, muss die zugehörige Organisation gewählt werden."
COM_SPORTSMANAGER_IMPORT_MESSAGE="Im Import sind ausschließlich Spielerdaten zum Verein %s enthalten. Soll ausschließlich der Spielerbestand des einen Vereins aktualisiert werden, muss der zugehörige Verein unten ausgewählt werden. Beinhaltet der Import den gesamten Spielerbestand einer Organisation, muss die zugehörige Organisation gewählt werden.<br />Bei schon vorhandener Lizenznummer wird die Lizenznummer und das Geburtsjahr nicht überschrieben!"
COM_SPORTSMANAGER_CHECK="Prüfen"
COM_SPORTSMANAGER_IMPORT_CONFLICTS_MESSAGE="Im Import sind Konflikte enthalten, die im Vorfeld manuell beseitigt werden müssen."
COM_SPORTSMANAGER_IMPORT_CONFLICTS_MESSAGE="Im Import sind Fehler oder Konflikte enthalten, die im Vorfeld manuell beseitigt werden müssen."
COM_SPORTSMANAGER_IMPORT_DUPLICATE_MESSAGE="Versuch, Spielernr. auf eine bereits für einen anderen Spieler vergebene Spielernr. zu ändern"
COM_SPORTSMANAGER_IMPORT_WRONG_FORMAT_PLAYERNUMBER="Eine oder mehrere Spielernummer enthalten ein ungültiges Format"
COM_SPORTSMANAGER_NAME2="Name"
COM_SPORTSMANAGER_DATA_IMPORT_ABORT_MESSAGE="Der Import wird abgebrochen, da Konflikte bei den zu importierenden Spielerdaten bestehen. Bitte kontaktiere einen Moderator und sende dabei die Importdatei mit!"
COM_SPORTSMANAGER_DATA_IMPORT_NO_CONFLICTS="Es bestehen keine Konflikte bei den zu importierenden Spielerdaten."
COM_SPORTSMANAGER_EXPLICIT_PENALTIES_EMAIL_BODY="%s wurden %f Strafpunkte zugeteilt mit der Begründung: %s"
COM_SPORTSMANAGER_EMAIL_SHIFT_GAME_APPOINTMENT_SUBJECT="%s vs %s: Spieltermin verlegen"
COM_SPORTSMANAGER_EMAIL_SHIFT_GAME_APPOINTMENT_BODY="Zur Begegnung %s gegen %s am %s in %s wird von %s der Spieltermin verschoben.\n\nAlternative Termine:\n\n"
COM_SPORTSMANAGER_EMAIL_SHIFT_GAME_APPOINTMENT_REQUESTED_BODY="Zur Begegnung %s gegen %s am %s in %s wird von %s der Spieltermin verschoben.\n\nBitte alternative Termine vorschlagen unter %s"
COM_SPORTSMANAGER_REALLY_REMOVE_ASSOCIATION_BODY="Willst Du dieses Verbandsorgan wirklich entfernen?"
COM_SPORTSMANAGER_INVALID_ASSOCIATION_BODY_NAME="Ungültiger Name für Verbandsorgan!"
COM_SPORTSMANAGER_NAME_NOT_COMPLETE="Der Name ist nicht komplett ausgefüllt"
COM_SPORTSMANAGER_ADDITIONAL_INFO="Zusatzinfo"
COM_SPORTSMANAGER_USE_HTML="Hier sollte HTML-formatierter Text verwendet werden"
COM_SPORTSMANAGER_REALLY_REMOVE_ASSOCIATION_BODY_MEMBER="Möchtest du dieses Mitglied des Verbandsorgans wirklich entfernen?"
COM_SPORTSMANAGER_HELP_EDIT_ASSOCIATION_BODY_MEMBER="Wird ein Name aus der Spielerliste ausgewählt, werden Nachname und Vorname übernommen.<br>Telefon, Mobil, E-Mail werden aus der Spielerliste übernommen, wenn sie hier nicht ausgefüllt sind."
COM_SPORTSMANAGER_HALL_OF_FAME="Hall of Fame"
COM_SPORTSMANAGER_ADD_HALL_OF_FAME="Hall of Fame hinzufügen"
COM_SPORTSMANAGER_INVALID_HALL_OF_FAME_NAME="Invalider Name für Hall of Fame"
COM_SPORTSMANAGER_REALLY_REMOVE_HALL_OF_FAME="Willst Du wirklich diese Hall of Fame mit allen Mitgliedern löschen?"
COM_SPORTSMANAGER_MATCH_TYPE="Spielform"
COM_SPORTSMANAGER_REALLY_REMOVE_HALL_OF_FAME_YEAR="Willst Du wirklich dieses Hall of Fame Jahr löschen?"
COM_SPORTSMANAGER_YEARS="Jahre"
COM_SPORTSMANAGER_ADD_HALL_OF_FAME_YEAR="Hall of Fame Jahr hinzufügen"
COM_SPORTSMANAGER_REALLY_SWAP_MATCH="Willst Du wirklich das Heimrecht tauschen?"
COM_SPORTSMANAGER_SWAP_MATCH="Heimrechttausch"
COM_SPORTSMANAGER_REALLY_DELETE_MATCH_REPORT="Der Spielbericht wird zusammen mit allen historischen Einträgen gelöscht. Willst du den Spielbericht wirklich löschen?"
COM_SPORTSMANAGER_DECIDING_SET_SAME="Wie die übrigen Sätze"
COM_SPORTSMANAGER_SETS_PER_GAME_HELP="Mit „Ergebnis je Satz" werden die Tore der einzelnen Sätze mit erfasst und stehen im Spielbericht; ohne bleibt nur der Satzstand."
COM_SPORTSMANAGER_SET_COUNT_HELP="Die Angaben beschreiben den Wettbewerb; sie lehnen keine Eingabe ab. Auswertungen und Apps erkennen daran, ob ein Spiel noch läuft oder schon entschieden ist."
COM_SPORTSMANAGER_MODE_GLOSSARY="Eine <strong>Begegnung</strong> ist die Partie zweier Mannschaften. Sie besteht aus mehreren <strong>Spielen</strong>: Einzel und Doppel, in der Reihenfolge der Spielfolge. Jedes Spiel bringt Spielpunkte für die Begegnung. Ein <strong>Spiel</strong> besteht aus einem Satz („Einer") oder aus mehreren. In einem <strong>Satz</strong> fallen <strong>Tore</strong>. Die Einstellungen unten sind in dieser Reihenfolge geordnet: von der Begegnung über das Spiel zum Satz."
COM_SPORTSMANAGER_RESULT_AS_GAME_POINTS="Ohne Umrechnung – Tore bzw. Sätze sind die Spielpunkte"
COM_SPORTSMANAGER_RESULT_AS_GAME_POINTS_GOALS="Ohne Umrechnung – Tore sind die Spielpunkte"
COM_SPORTSMANAGER_RESULT_AS_GAME_POINTS_SETS="Ohne Umrechnung – Sätze sind die Spielpunkte"
COM_SPORTSMANAGER_COUNTING="Zählweise"
COM_SPORTSMANAGER_COUNTING_PER_GAME="Je Spiel – jedes Spiel beginnt bei 0:0"
COM_SPORTSMANAGER_COUNTING_RACE="Race-Modus – die Tore addieren sich über alle Spiele"
COM_SPORTSMANAGER_RACE_STEP="Schritt je Spiel"
COM_SPORTSMANAGER_RACE_TARGET="Ziel"
COM_SPORTSMANAGER_RACE_TARGET_FORMULA="Anzahl der Spiele aus der Spielfolge × Schritt je Spiel"
COM_SPORTSMANAGER_RACE_DRAW="Unentschieden am Ziel"
COM_SPORTSMANAGER_RACE_DRAW_NO="Nein"
COM_SPORTSMANAGER_RACE_DRAW_YES="Ja – bei einem Tor unter dem Ziel"
COM_SPORTSMANAGER_RACE_HELP="Der Stand läuft über die ganze Begegnung durch: Spiel 1 endet beim Schritt, Spiel 2 beim doppelten Schritt, und so fort bis zum Ziel. Mindestvorsprung und Grenze gelten nur für das letzte Spiel. Der Race-Modus setzt „Spielergebnis als Spielpunkte" und einen Satz je Spiel voraus – beides wird mitgesetzt."
COM_SPORTSMANAGER_LINK_NUMBER="Verknüpfung Nr. %d"
COM_SPORTSMANAGER_GROUP_SEQUENCE="Spielfolge"
COM_SPORTSMANAGER_GAMES_IN_STATISTIK_FIRST_ONE="nur das erste Spiel"
COM_SPORTSMANAGER_GAMES_IN_STATISTIK_FIRST="nur die ersten %d Spiele"
COM_SPORTSMANAGER_POINT_TYPE_CHANGED_WARNING="Für diesen Mannschaftsspielplan sind bereits Ergebnisse eingetragen. Die gespeicherten Zahlen werden NICHT umgerechnet – sie bedeuten danach etwas anderes (Tore statt Sätze bzw. umgekehrt). Trotzdem speichern?"
COM_SPORTSMANAGER_PER_SET_VALUATION_CHANGED_WARNING="Für diesen Mannschaftsspielplan sind bereits Ergebnisse eingetragen. Beim Wechsel der Wertung „je Satz" wird nichts umgerechnet: Spiele ohne gespeicherte Satzergebnisse werden mit dem vollen Siegwert je gewonnenem Satz gewertet, ihre Satz-Unentschieden gehen verloren. Und wo unter „Mehrere" in Wahrheit Tore in den Punkte-Feldern stehen (statt Sätzen), zählt ab jetzt jedes Tor wie ein gewonnener Satz doppelt. Trotzdem speichern?"
COM_SPORTSMANAGER_IMPORT_MESSAGE="In the import there are only player information about club %s present. Shall only the members of that one club be updated, the associated club has to be selected down here. If the import contains all members of the organisation then the organisation must be selected."
COM_SPORTSMANAGER_IMPORT_MESSAGE="In the import there are only player information about club %s present. Shall only the members of that one club be updated, the associated club has to be selected down here. If the import contains all members of the organisation then the organisation must be selected.<br />If a license number already exists, the license number and the year of birth will not be overwritten."
COM_SPORTSMANAGER_CHECK="Check"
COM_SPORTSMANAGER_IMPORT_CONFLICTS_MESSAGE="There are conflicts in the import which have to be fixed manually first."
COM_SPORTSMANAGER_IMPORT_CONFLICTS_MESSAGE="There are faults or conflicts in the import which have to be fixed manually first."
COM_SPORTSMANAGER_IMPORT_DUPLICATE_MESSAGE="Attempt to change player number into one that is already assigned to another player."
COM_SPORTSMANAGER_IMPORT_WRONG_FORMAT_PLAYERNUMBER="One or more player numbers contain an invalid format"
COM_SPORTSMANAGER_NAME2="Name"
COM_SPORTSMANAGER_DATA_IMPORT_ABORT_MESSAGE="The import has been aborted because there are conflicts in the containing player information. Please contact a moderator and attach the import!"
COM_SPORTSMANAGER_DATA_IMPORT_NO_CONFLICTS="There are conflicts in the containing player information."
COM_SPORTSMANAGER_EXPLICIT_PENALTIES_EMAIL_SUBJECT="%s: received penalty"
COM_SPORTSMANAGER_EXPLICIT_PENALTIES_EMAIL_BODY="%s received a penalty of %f points based on the following justification: %s"
COM_SPORTSMANAGER_EMAIL_SHIFT_GAME_APPOINTMENT_SUBJECT="%s vs %s: Shift game appointment"
COM_SPORTSMANAGER_EMAIL_SHIFT_GAME_APPOINTMENT_BODY="For match %s versus %s on %s in %s the game appointment is shifted by %s.\n\nAlternative appointments:\n\n"
COM_SPORTSMANAGER_EMAIL_SHIFT_GAME_APPOINTMENT_REQUESTED_BODY="For match %s on %s in %s the game appointment is shifted by %s.\n\nPlease propose alternative appointments under %s"
COM_SPORTSMANAGER_FUNCTION_DESCRIPTION="Variables: n = number of participants, p = place, m = multiplier of rating and in doubles possibly additionally reduced rating<br />Functions: +, -, *, /, round(x), pow(x), if(a > b, x, y), min(x, y), max(x, y), log(x), ln(x), logn(b, x)<br />VerteilungR(r, p, n, m) := max(round((((m * r - 1) * (-log(p / n) * (1 - (p / n)))) / (-log(1 / n) * (1 - (1 / n)))) + 1), 1)<br />Verteilung(r, p, n, m) := max(round(m * round((((r - 1) * (-log(p / n) * (1 - (p / n)))) / (-log(1 / n) * (1 - (1 / n)))) + 1)), 1)<br /><br />The functions VerteilungR() and Verteilung() distribute points for place 1 (r) descending to the individual places (p) of the number of participants (n).<br />VerteilungR() applies the multiplier (m) to the points for 1st place and then distributes down to 1 point for the last place.<br />Verteilung() applies the multiplier (m) to the points after the calculation, i.e. the last place receives 1 * m points."
COM_SPORTSMANAGER_LIZENZ="License"
COM_SPORTSMANAGER_RANK="Rank"
; Edit Player
COM_SPORTSMANAGER_LIZENZ="License"
COM_SPORTSMANAGER_ARIA_LABEL_MATCHDAY_SELECT="Choose a match day"
COM_SPORTSMANAGER_ARIA_LABEL_PROPOSAL_DAY="Choose the day of the match proposal"
COM_SPORTSMANAGER_ARIA_LABEL_PROPOSAL_MONTH="Choose the month of the match proposal"
COM_SPORTSMANAGER_USE_HTML="HTML-formatted text should be used here."
COM_SPORTSMANAGER_REALLY_REMOVE_ASSOCIATION_BODY_MEMBER="Do you really want to remove this association body member?"
COM_SPORTSMANAGER_HELP_EDIT_ASSOCIATION_BODY_MEMBER="Selecting a name from the player list will fill in the first and last name.<br>Phone, mobile, and email are filled from the player list if left blank here."
COM_SPORTSMANAGER_HALL_OF_FAME="Hall of Fame"
COM_SPORTSMANAGER_ADD_HALL_OF_FAME="Add Hall of Fame"
COM_SPORTSMANAGER_INVALID_HALL_OF_FAME_NAME="Invalid Hall of Fame name"
COM_SPORTSMANAGER_REALLY_REMOVE_HALL_OF_FAME="Are you sure you want to delete this Hall of Fame including all its members?"
COM_SPORTSMANAGER_MATCH_TYPE="Game Type"
COM_SPORTSMANAGER_REALLY_REMOVE_HALL_OF_FAME_YEAR="Are you sure you want to delete this Hall of Fame year?"
COM_SPORTSMANAGER_YEARS="Years"
COM_SPORTSMANAGER_ADD_HALL_OF_FAME_YEAR="Add Hall of Fame Year"
COM_SPORTSMANAGER_ONE_FIXED_SET="1 set (played out)"
COM_SPORTSMANAGER_NUMBER_FIXED_SETS="%d sets (all played out)"
COM_SPORTSMANAGER_NUMBER_WINNING_SETS="Best of %d wins"
COM_SPORTSMANAGER_DECIDING_SET="Deciding set"
COM_SPORTSMANAGER_DECIDING_SET_SAME="As the other sets"
COM_SPORTSMANAGER_SETS_PER_GAME_HELP="With “each set’s result” the goals of the individual sets are recorded too and appear in the match report; without it only the set score remains."
COM_SPORTSMANAGER_SET_COUNT_HELP="These settings describe the competition; they never reject an entry. Evaluations and apps use them to tell a game still running from one already decided."
COM_SPORTSMANAGER_MODE_GLOSSARY="A <strong>match</strong> is the fixture between two teams. It consists of several <strong>games</strong> – singles and doubles in the order of the game sequence – and each game yields game points for the match. A <strong>game</strong> consists of one set (“One”) or of several. Within a <strong>set</strong>, <strong>goals</strong> are scored. The settings below follow that order: from the match through the game down to the set."
COM_SPORTSMANAGER_RESULT_AS_GAME_POINTS="Without conversion – goals or sets are the game points"
COM_SPORTSMANAGER_RESULT_AS_GAME_POINTS_GOALS="Without conversion – goals are the game points"
COM_SPORTSMANAGER_RESULT_AS_GAME_POINTS_SETS="Without conversion – sets are the game points"
COM_SPORTSMANAGER_COUNTING="Counting"
COM_SPORTSMANAGER_COUNTING_PER_GAME="Per game – every game starts at 0:0"
COM_SPORTSMANAGER_COUNTING_RACE="Race – goals add up across all games"
COM_SPORTSMANAGER_RACE_STEP="Step per game"
COM_SPORTSMANAGER_RACE_TARGET="Target"
COM_SPORTSMANAGER_RACE_TARGET_FORMULA="Number of games in the sequence × step per game"
COM_SPORTSMANAGER_RACE_TARGET_CURRENT="currently %1$d games × %2$d = %3$d goals"
COM_SPORTSMANAGER_RACE_MARGIN="Minimum margin at the target"
COM_SPORTSMANAGER_RACE_CAP="Won at the latest at"
COM_SPORTSMANAGER_RACE_DRAW="Draw at the target"
COM_SPORTSMANAGER_RACE_DRAW_NO="No"
COM_SPORTSMANAGER_RACE_DRAW_YES="Yes – one goal below the target"
COM_SPORTSMANAGER_RACE_HELP="The score runs through the whole match: game 1 ends at the step, game 2 at twice the step, and so on up to the target. Minimum margin and limit apply to the last game only. Race requires “game result as game points” and one set per game – both are set along with it."
COM_SPORTSMANAGER_ADD_GAME="Add a game"
COM_SPORTSMANAGER_ADD_LINK="Add a link"
COM_SPORTSMANAGER_REMOVE_GAME="Remove this game"
COM_SPORTSMANAGER_REMOVE_LINK="Remove this link"
COM_SPORTSMANAGER_LINK_NUMBER="Link no. %d"
COM_SPORTSMANAGER_GROUP_SEQUENCE="Game sequence"
COM_SPORTSMANAGER_GAMES_IN_STATISTIK_FIRST_ONE="the first game only"
COM_SPORTSMANAGER_GAMES_IN_STATISTIK_FIRST="the first %d games only"
COM_SPORTSMANAGER_POINT_TYPE_CHANGED_WARNING="Results have already been entered for this team schedule. The stored numbers are NOT converted – afterwards they mean something else (goals instead of sets, or the other way round). Save anyway?"
COM_SPORTSMANAGER_PER_SET_VALUATION_CHANGED_WARNING="Results have already been entered for this team schedule. Switching the per-set valuation converts nothing: games without stored set results are valued at the full win value per set won, and their drawn sets are lost. And where a 'multiple sets' schedule in fact holds goals in its points fields (instead of sets), every goal will from now on count double, like a set won. Save anyway?"
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
svennickel
svennickel
Jürgen MeyerandClaude Sonnet 5
MarvinF
Marvin Flock
Wieland Hagen
Tim
DTFB-PaulF
