PHP/MariaDB Basisparameter
Pragmatic Server-Basisparameter for stabile Moodle-Instanzen.
Quick overview
This page describes the working standard for PHP/MariaDB Basisparameter – with a focus on concrete decisions rather than general guidance.
The main focus here is zielversion and upgradepfad and grenzwerte pro umgebung so that teams apply the same standard.
The standard only becomes traceable through linked evidence such as php-konfig-snapshot and through documented edge cases/exceptions.
When this page helps
Typical situations in which this page adds value as a working document, and where another document is more appropriate.
Typical use cases
- when for PHP/MariaDB Basisparameter technical standards about php-version and extensions must be documented in a binding way
- when team handovers or temporary cover the same process for zielversion and upgradepfad should be able to execute safely
- when incidents or Changes show that evidence such as php-konfig-snapshot are still missing
- when configuration or operational deviations (e.g. parameter be aus defaults übernommen) occur repeatedly
Less suitable when
- when PHP/MariaDB Basisparameter only about a one-off individual case without need for standardization applies
- when a detailed project ticket or a technical step-by-step guide is the better fit
Recommended process
A pragmatic sequence that works in practice, from scope to review.
- capture the current state and scope for PHP/MariaDB Basisparameter capture, including php-version and extensions and critical dependencies.
- define the target state and standards; key decisions include zielversion and upgradepfad.
- test changes in a controlled way (Staging, Testsystem or Checklist) and Ergebnis document.
- implement in production, run follow-up checks, and php-konfig-snapshot + benchmark-/testwerte link.
- Monitoring/Reviews auswerten and recurring Befunde such as „Parameter be aus Defaults übernommen“ in the standard einarbeiten.
Decision rules
PHP/MariaDB Basisparameter is well documented, when rules, Edge cases and Evidence so clearly are, dass teams so that without additional coordination work can.
Entscheidungsrahmen
For PHP/MariaDB Basisparameter first define the scope clearly: PHP-Version and Extensions.
responsibility
decisions about zielversion and upgradepfad and grenzwerte pro umgebung not implizit lassen, sondern roles and approvals explicitly benennen.
Abweichungsregeln
Allow exceptions only if they do not dilute the standard; especially relevant here are ini-grenzwerte (memory, upload, timeouts).
review triggers
Verifiable is the rule only, when php-konfig-snapshot and benchmark-/testwerte cleanly verlinkt are.
What should be documented
Here only the spezifischen Inhalte about PHP/MariaDB Basisparameter maintain; general documentation rules remain in the centraln guideline. Central guideline.
The page is good when a substitute can apply or review the standard without first collecting tribal knowledge.
Kontext
terms, scope and boundaries about PHP/MariaDB Basisparameter specify in concrete terms, including php-version and extensions.
Umsetzungsvorgaben
Den standard so record, dass zielversion and upgradepfad and änderungsfenster and tests eindeutig entschieden are.
review path
Name and link evidence directly: PHP-Konfig-Snapshot, Benchmark-/Testwerte, Change-evidence.
Offene Punkte / Exceptions
Aktive Exceptions, the latest change and the next review belong on the page—especially for topics with ini-grenzwerte (memory, upload, timeouts).
Common pitfalls
This section captures real-world pitfalls from PHP/MariaDB Basisparameter; general guidance belongs in the central guideline. Central guideline.
- scope driftet: Parameter be aus Defaults übernommen.
- the rule is too abstract: Version driftet between Staging and Prod.
- evidence is missing: Extensions fehlen only in the Operations on.
- the exception gets out of control: Parameteränderungen without Baseline-Vergleich.
Moodle reference (official docs 5.1)
Kurze Verweise on the offizielle Moodle documentation for PHP/MariaDB Basisparameter. So remains this Page AFANDI-spezifisch and vermeidet doppelte Grundlagen.
Official references
Documentation focus
- Version-Baselines with Quelle (Moodle-Version), Testdatum and deviations document.
- UI path, role and test case record explicitly (not only the desired target state).
- Mark deviations from AFANDI standards separatelyely so that updates remain easier to review.
Review & maintenance
Check this Page gegen reale processes about PHP/MariaDB Basisparameter – not only gegen the Wortlaut. Entscheidend is, ob standard, Exceptions and Evidence in the Alltag contribute.
- Ist Version in allen Umgebungen consistently?
- Passen Limits about real course-/file sizen?
- Were changes getestet?
- Passen DB-Parameter to the Last?
Review focus for „PHP/MariaDB Basisparameter“: Moodle-Operations; check especially php-version and extensions.
Useful metrics
A few metrics are enough – what matters is that they trigger decisions or improvements.
For „PHP/MariaDB Basisparameter“ Kennzahlen directly an zielversion and upgradepfad and the most frequent Praxisrisiken koppeln.
PHP-Konfig-Drift
deviations between Umgebungen
Interval: monthly
Timeout-cases
Anzahl requests with PHP-/FastCGI-Timeout
Interval: monthly
Upgrade-Vorlauf
time between Support-Ende and Upgrade-Plan
Interval: quarterly
Next steps
Add jetzt the concrete Entscheidung about zielversion and upgradepfad incl. Verantwortlichen, Datum and Verweis on php-konfig-snapshot.
On „PHP/MariaDB Basisparameter“ make especially clear as the next step: which php-version and extensions apply in the standard case and which exceptions are time-limited.