PHP/MariaDB Basisparameter
Pragmatische Server-Basisparameter für stabile Moodle-Instanzen.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für PHP/MariaDB Basisparameter – mit Fokus auf konkrete Entscheidungen statt allgemeiner Leitlinien.
Zentral sind hier vor allem zielversion und upgradepfad und grenzwerte pro umgebung, damit Teams denselben Maßstab anwenden.
Nachvollziehbar wird der Standard erst durch verlinkte Nachweise wie php-konfig-snapshot und durch dokumentierte Grenzfälle/Ausnahmen.
Wann diese Seite hilft
Typische Situationen, in denen diese Seite als Arbeitsdokument Mehrwert bringt – und wo eine andere Doku passender ist.
Typische Einsätze
- wenn bei PHP/MariaDB Basisparameter technische Standards zu php-version und extensions verbindlich dokumentiert werden müssen
- wenn Teamwechsel/Vertretung denselben Ablauf für zielversion und upgradepfad sicher ausführen soll
- wenn Störungen oder Changes zeigen, dass Nachweise wie php-konfig-snapshot bisher fehlen
- wenn Konfig- oder Betriebsabweichungen (z. B. parameter werden aus defaults übernommen) wiederholt auftreten
Eher nicht passend bei
- wenn es bei PHP/MariaDB Basisparameter nur um einen einmaligen Einzelfall ohne Standardisierungsbedarf geht
- wenn ein detailliertes Projektticket oder eine technische Schritt-für-Schritt-Anleitung gepflegt werden soll
Empfohlener Ablauf
Pragmatische Reihenfolge, die in der Praxis funktioniert – vom Scope bis zum Review.
- Ist-Stand und Scope für PHP/MariaDB Basisparameter erfassen, inklusive php-version und extensions und kritischer Abhängigkeiten.
- Sollzustand / Standards festlegen; wichtig sind Entscheidungen zu zielversion und upgradepfad.
- Änderungen kontrolliert testen (Staging, Testsystem oder Checkliste) und Ergebnis dokumentieren.
- Produktiv umsetzen, Nachtests durchführen und php-konfig-snapshot + benchmark-/testwerte verlinken.
- Monitoring/Reviews auswerten und wiederkehrende Befunde wie „Parameter werden aus Defaults übernommen“ in den Standard einarbeiten.
Entscheidungsregeln
PHP/MariaDB Basisparameter ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Entscheidungsrahmen
Für PHP/MariaDB Basisparameter zuerst den Anwendungsbereich konkret machen: PHP-Version und Extensions.
Verantwortung
Entscheidungen zu zielversion und upgradepfad und grenzwerte pro umgebung nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Abweichungsregeln
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier ini-grenzwerte (memory, upload, timeouts).
Review-Auslöser
Prüfbar ist die Regel erst, wenn php-konfig-snapshot und benchmark-/testwerte sauber verlinkt sind.
Was dokumentiert werden soll
Hier nur die spezifischen Inhalte zu PHP/MariaDB Basisparameter pflegen; allgemeine Doku-Regeln bleiben in der zentralen Leitlinie. Zentrale Leitlinie.
Die Seite ist dann gut, wenn eine Vertretung den Standard anwenden oder prüfen kann, ohne erst Personenwissen einsammeln zu müssen.
Kontext
Begriffe, Scope und Grenzen zu PHP/MariaDB Basisparameter konkretisieren – inklusive php-version und extensions.
Umsetzungsvorgaben
Den Standard so notieren, dass zielversion und upgradepfad und änderungsfenster und tests eindeutig entschieden sind.
Prüfpfad
Artefakte direkt nennen und verlinken: PHP-Konfig-Snapshot, Benchmark-/Testwerte, Change-Nachweis.
Offene Punkte / Ausnahmen
Aktive Ausnahmen, letzte Änderung und nächster Review gehören auf die Seite – besonders bei Themen mit ini-grenzwerte (memory, upload, timeouts).
Typische Stolperfallen
Pflege hier echte Fallstricke aus der Praxis von PHP/MariaDB Basisparameter; allgemeine Hinweise gehören in die zentrale Leitlinie. Zentrale Leitlinie.
- Umfang driftet: Parameter werden aus Defaults übernommen.
- Regel bleibt abstrakt: Version driftet zwischen Staging und Prod.
- Nachweis fehlt: Extensions fehlen erst im Betrieb auf.
- Ausnahme entgleist: Parameteränderungen ohne Baseline-Vergleich.
Moodle-Referenz (offizielle Doku 5.1)
Kurze Verweise auf die offizielle Moodle-Dokumentation für PHP/MariaDB Basisparameter. So bleibt diese Seite AFANDI-spezifisch und vermeidet doppelte Grundlagen.
Offizielle Referenzen
Dokumentationsfokus
- Version-Baselines mit Quelle (Moodle-Version), Testdatum und Abweichungen dokumentieren.
- UI-Pfad, Rolle und Testfall explizit notieren (nicht nur den gewünschten Endzustand).
- Abweichungen von AFANDI-Standards separat markieren, damit Updates leichter reviewbar bleiben.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu PHP/MariaDB Basisparameter – nicht nur gegen den Wortlaut. Entscheidend ist, ob Standard, Ausnahmen und Nachweise im Alltag tragen.
- Ist Version in allen Umgebungen konsistent?
- Passen Limits zu realen Kurs-/Dateigrößen?
- Wurden Änderungen getestet?
- Passen DB-Parameter zur Last?
Prüf-Fokus für „PHP/MariaDB Basisparameter“: Moodle-Betrieb; prüfe dabei insbesondere php-version und extensions.
Sinnvolle Kennzahlen
Wenige Kennzahlen genügen – wichtig ist, dass sie Entscheidungen oder Verbesserungen auslösen.
Für „PHP/MariaDB Basisparameter“ Kennzahlen direkt an zielversion und upgradepfad und die häufigsten Praxisrisiken koppeln.
PHP-Konfig-Drift
Abweichungen zwischen Umgebungen
Intervall: monatlich
Timeout-Fälle
Anzahl requests mit PHP-/FastCGI-Timeout
Intervall: monatlich
Upgrade-Vorlauf
Zeit zwischen Support-Ende und Upgrade-Plan
Intervall: quartalsweise
Nächste Schritte
Ergänze jetzt die konkrete Entscheidung zu zielversion und upgradepfad inkl. Verantwortlichen, Datum und Verweis auf php-konfig-snapshot.
Auf „PHP/MariaDB Basisparameter“ als Nächstes besonders klar machen: welche php-version und extensions im Standardfall gelten und welche Ausnahmen befristet sind.