memory_limit

Beschreibung: Dieser Wert legt fest, wie viel Arbeitsspeicher (RAM) ein PHP-Skript maximal verwenden darf. Wird dieser Wert überschritten, beendet PHP das Skript mit einem Fehler.
Beispiel: memory_limit = 512M bedeutet, dass ein Skript maximal 512 MB RAM verwenden darf.

Was dabei oft vergessen wird:
Ein typischer Webhosting Server hat bei uns 64 Gigabyte RAM und es sind niemals mehr als 200 Kund:innen auf einem Server. Da niemals alle Accounts den RAM gleichzeitig beanspruchen, ist das auch überhaupt kein Problem.
Das Erhöhen von memory_limit kann dazu führen, dass Skripte mehr RAM verbrauchen und unter Umständen andere Services
oder Websites auf dem gleichen Server negativ beeinflussen. Sie können das vergleichen mit einem Verkehrsteilnehmer auf einer Autobahn,
der die gesamte zur Verfügung stehende Breite aller Fahrspuren für sich beansprucht. Wie würden Sie sich fühlen, wenn Sie einen solchen
Verkehrsteilnehmer vor sich hätten?

max_execution_time

Beschreibung: Bestimmt die maximale Laufzeit eines PHP-Skripts in Sekunden. Nach Überschreiten dieses Limits wird das Skript abgebrochen.
Beispiel: max_execution_time = 30 bedeutet, dass ein Skript spätestens nach 30 Sekunden gestoppt wird.

Was dabei oft vergessen wird:
Eine Erhöhung von max_execution_time kann dazu führen, dass langfristig ausgeführte Skripte andere Prozesse blockieren
und die Performance für alle Nutzer beeinträchtigen. Die voreingestellten Werte sind ein Kompromiss zwischen Flexibilität und Stabilität.
Und es handelt sich hier schließlich um einen Webserver, dessen einzige Aufgabe es sein soll, Webseiten auszuliefern und nicht Radio Streams oder Wetterdaten zu berechnen. Ein höherer Wert ist auch wirklich nicht sinnvoll, denn Webseitenbesucher warten niemals so lange, sondern klicken nach spätestens fünf Sekunden auf „Reload“ oder woanders hin. Falls eine Webseite generell so langsam ist, sollte eher die Webseite überarbeitet werden.

max_input_time

Beschreibung: Gibt an, wie viele Sekunden PHP benötigt, um Eingabedaten (z.B. POST/GET-Daten, Datei-Uploads) einzulesen.
Nach Ablauf dieses Zeitraums wird das Einlesen abgebrochen.
Beispiel: max_input_time = 60 bedeutet, dass 60 Sekunden für das Einlesen von Daten zur Verfügung stehen.

Was dabei oft vergessen wird:
Wenn max_input_time zu hoch eingestellt wird, können langsame oder große Uploads lange Ressourcen binden,
bevor sie überhaupt verarbeitet werden. Dies kann die Verarbeitung anderer Anfragen verzögern. Ein sinnvoll gesetzter Wert schützt den Server vor zu langen „Hängeprozessen“ beim Dateneingang.

post_max_size

Beschreibung: Beschränkt die maximale Gesamtgröße der Daten, die per POST an den Server geschickt werden können.
Hierzu gehören beispielsweise Formulardaten und Upload-Dateien zusammen.
Beispiel: post_max_size = 20M bedeutet, dass die gesamten POST-Daten maximal 20 MB groß sein dürfen.

Was dabei oft vergessen wird:
Wenn post_max_size stark erhöht wird, besteht das Risiko, dass sehr große Dateien hochgeladen werden,
was nicht nur mehr Speicherplatz beansprucht, sondern auch die Bandbreite beim Upload blockieren kann.
Das bremst dann andere Websites aus. Sie sind schließlich nicht alleine auf dem Server. Nehmen Sie Rücksicht auf andere oder mieten Sie einen dedizierten Server, sprich einen Server, der nur Ihnen alleine gehört. Dort können Sie dann auch machen, was Sie wollen.
Die voreingestellten Limits sind ein Kompromiss, um Bandbreite und Speicherbedarf zu kontrollieren.

upload_max_filesize

Beschreibung: Legt die maximale Dateigröße für einen einzelnen Upload fest.
Beispiel: upload_max_filesize = 20M bedeutet, dass eine Datei beim Hochladen nicht größer als 20 MB sein darf.

Was dabei oft vergessen wird:
Ähnlich wie bei post_max_size kann eine Erhöhung von upload_max_filesize zu übermäßiger Serverauslastung führen.
Große Uploads brauchen mehr Zeit, mehr RAM und mehr Bandbreite. Wir als Anbieter müssen insbesondere auf Servern, auf welchen mehrere Accounts existieren, sicherstellen, dass die Ressourcen für andere Accounts nicht einschränkt werden, wenn einzelne Nutzer sehr große Dateien hochladen.

error_reporting

Beschreibung: Bestimmt, welche Arten von PHP-Fehlern gemeldet werden sollen (z.B. Warnungen, Hinweise, schwerwiegende Fehler).
Beispiel: error_reporting = E_ALL & ~E_NOTICE blendet Notices aus, meldet jedoch alle anderen Fehler.

Was dabei oft vergessen wird:
Zwar betrifft error_reporting weniger direkt die Ressourcen, aber für eine saubere Server- und Skriptverwaltung
empfiehlt es sich, ein sinnvolles Fehler-Reporting zu wählen. In der Produktion sollte man kritische Fehler aufzeichnen,
aber nicht unbedingt an Nutzer ausgeben, um Sicherheitslücken nicht offenzulegen.
Die Voreinstellungen stellen meist einen guten Mittelweg dar.

display_errors

Beschreibung: Steuert, ob Fehlermeldungen im Browser angezeigt werden sollen.
Empfehlung: In Entwicklungsumgebungen auf On, in Live-Umgebungen auf Off stellen und stattdessen Fehler in ein Log schreiben.

Was dabei oft vergessen wird:
display_errors ist weniger ein Ressourcen- als vielmehr ein Sicherheitsaspekt. In Live-Umgebungen sollte man
Fehlermeldungen nicht direkt an den Nutzer ausgeben. Die Standardeinstellungen sind häufig so gesetzt,
dass Fehlermeldungen nicht öffentlich einsehbar sind und stattdessen in eine Logdatei gehen.

log_errors und error_log

Beschreibung: log_errors aktiviert die Fehlerprotokollierung in einer Datei. Mit error_log
wird der Pfad/die Datei für die Protokollierung angegeben.
Empfehlung: In Live-Umgebungen sollten Fehlermeldungen nicht im Browser ausgegeben, sondern in eine Logdatei geschrieben werden.

Was dabei oft vergessen wird:
Eine saubere Fehlerprotokollierung ist wichtig, um Probleme zu erkennen und zu beheben, ohne sensible Informationen nach außen preiszugeben.
Der voreingestellte Pfad und das Logging-Verhalten sorgen in der Regel für eine gute Basis,
ohne zu viele Ressourcen (z.B. großen Festplattenplatz) zu beanspruchen.

date.timezone

Beschreibung: Legt die Standardzeitzone fest, die von PHP verwendet wird.
Beispiel: date.timezone = "Europe/Berlin" stellt sicher, dass Datums- und Zeitfunktionen die Mitteleuropäische Zeit nutzen.

Was dabei oft vergessen wird:
Voreingestellte Zeitzonen machen eine zentrale Administration einfacher. Verändert man diesen Wert individuell,
kann es zu Inkonsistenzen zwischen verschiedenen Skripten oder Anwendungen auf demselben Server kommen,
wenn diese unterschiedliche Zeitzonen erwarten.

max_input_vars

Beschreibung: Bestimmt die maximale Anzahl an Variablen, die über POST, GET oder Cookies akzeptiert werden.
Beispiel: max_input_vars = 1000. Bei sehr großen Formularen kann es sinnvoll sein, diesen Wert zu erhöhen.

Was dabei oft vergessen wird:
Eine zu hohe Einstellung kann dazu führen, dass sich Skripte mit extrem vielen Feldern (beispielsweise ein sehr großes Formular)
unkontrolliert ausbreiten und Speicherkapazitäten verbrauchen. Die Standardwerte bieten meist genügend Luft für typische Formulare,
ohne den Server zu überlasten.

session.gc_maxlifetime

Beschreibung: Bestimmt, wie lange Sitzungsdaten (Sessions) auf dem Server aufbewahrt werden (in Sekunden), bevor sie
der Garbage Collector löscht.
Beispiel: session.gc_maxlifetime = 1440 (24 Minuten). Erhöhen Sie diesen Wert, wenn Ihre Nutzer längere Sitzungen benötigen.

Was dabei oft vergessen wird:
Eine Verlängerung der Session-Lebenszeit erhöht den Platzbedarf für Session-Dateien und kann gleichzeitig ein Sicherheitsrisiko
durch veraltete, aber weiterhin gültige Session-Daten darstellen. Die Voreinstellungen sind meist so gewählt,
dass ein Kompromiss aus Nutzerfreundlichkeit und Server-Ressourcen entsteht.

session.save_path

Beschreibung: Definiert das Verzeichnis, in dem PHP die Sitzungsdateien ablegt.
Beispiel: session.save_path = "/var/lib/php/sessions".

Was dabei oft vergessen wird:
Server-Betreiber wählen meist ein Verzeichnis, das zentral überwacht, abgesichert und regelmäßig bereinigt wird.
Änderungen daran können die Zugriffs- und Rechteverwaltung sowie Cronjobs (z.B. für Session-Garbage-Collection) durcheinanderbringen.

short_open_tag

Beschreibung: Erlaubt die Verwendung von <? statt <?php.
Hinweis: Moderne Anwendungen verwenden in der Regel <?php, daher ist dieser Wert oft deaktiviert.

Was dabei oft vergessen wird:
Bei kurzfristiger Deaktivierung von short_open_tag kann es in älteren Skripten zu Problemen kommen,
während neuere Skripte kaum davon betroffen sind. Die Standardeinstellungen (in den meisten Fällen: deaktiviert)
verhindern Versionskonflikte und stellen eine bessere Kompatibilität sicher.

allow_url_fopen und allow_url_include

Beschreibung: Erlauben das Öffnen bzw. Einbinden externer Dateien via HTTP/FTP, z.B. mit file_get_contents().
Hinweis: Häufig aus Sicherheitsgründen deaktiviert, insbesondere allow_url_include.

Was dabei oft vergessen wird:
Das Aktivieren dieser Optionen kann zu Sicherheitsrisiken führen, wenn Skripte externe Inhalte unkontrolliert laden.
Server-Betreiber setzen diese Werte daher häufig auf Off, um Missbrauch (z.B. durch Remote-Code-Ausführung) zu verhindern und die Server-Integrität zu schützen. Dies ist also im Sinne aller User.

open_basedir

Beschreibung: Beschränkt den Zugriff von PHP auf bestimmte Verzeichnisse, um unerwünschtes Lesen oder Schreiben
außerhalb dieser Verzeichnisse zu verhindern.
Beispiel: open_basedir = "/var/www/html:/tmp" erlaubt nur den Zugriff auf diese Verzeichnisse und deren Unterverzeichnisse.

Was dabei oft vergessen wird:
Diese Einstellung schützt vor ungewolltem Zugriff auf andere Bereiche des Servers.
Standardwerte sind meist so gesetzt, dass Webprojekte nur in ihrem eigenen Verzeichnis agieren können.
Eine Lockerung dieser Einschränkung kann aus Sicherheitssicht problematisch sein.

Historische Einstellungen (in modernen PHP-Versionen nicht mehr verfügbar)

safe_mode

Beschreibung: Ehemals ein Sicherheitskonzept, das Dateizugriffe und Skriptberechtigungen einschränken sollte,
besonders in Shared-Hosting-Umgebungen.
Warum entfernt? Das Konzept war fehleranfällig und konnte leicht umgangen werden. Ab PHP 5.4 nicht mehr verfügbar.

register_globals

Beschreibung: Aktivierte das automatische Überführen von Variablen aus GET, POST und Cookies in den globalen Namensraum
(z.B. $user statt $_GET['user']).
Warum entfernt? Führte häufig zu Sicherheitslücken, weil Variablen leicht überschrieben werden konnten. Ab PHP 5.4 entfernt.

magic_quotes_gpc und magic_quotes_runtime

Beschreibung: Sollten Sonderzeichen (z.B. Anführungszeichen) in eingehenden Daten (GET/POST/Cookie) automatisch maskieren,
um SQL-Injection zu verhindern.
Warum entfernt? Das Feature war unflexibel und führte zu unerwartetem Verhalten. Stattdessen sollte man
prepared Statements und Escape-Funktionen nutzen. Ab PHP 5.4 entfernt.

register_long_arrays

Beschreibung: Erlaubte die Nutzung älterer, langer Array-Variablennamen wie $HTTP_GET_VARS anstelle von $_GET.
Warum entfernt? War veraltet und wurde daher entfernt. Moderne PHP-Versionen verwenden nur die Superglobals.

Aktuelle Best Practices und Empfehlungen

• OPcache-Einstellungen: opcache.enable, opcache.memory_consumption,
  opcache.validate_timestamps usw. sorgen für Performance-Gewinne durch Caching des PHP-Bytecodes.
• Sichere Datenbankzugriffe: Immer prepared Statements (z.B. mit PDO oder MySQLi) statt veralteter Magic Quotes nutzen.
• Fehlerbehandlung: Fehler und Warnungen in Logs schreiben (Stichwort log_errors), statt sie im Browser auszugeben.
• Session-Sicherheit: Session-Einstellungen anpassen (z.B. session.gc_maxlifetime) und bei Bedarf
  sichere Session-Cookies (HTTPS) verwenden.
• upload_max_filesize und post_max_size: Diese Werte aufeinander abstimmen, damit größere Uploads nicht ungewollt
  abgelehnt werden.
• Aktuelle PHP-Version: Verwenden Sie möglichst eine aktuelle PHP-Version (8.x oder neuer),
  um von Sicherheits- und Performance-Verbesserungen zu profitieren.