DE
Jetzt starten

Hilfe · Website

PHP und der Datenbereich

Mit dem Zusatzpaket «PHP» läuft auf deiner Website serverseitiger Code. Er sieht zwei Verzeichnisse: deine veröffentlichten Dateien unter /var/www/html – nur lesbar und bei jedem Veröffentlichen ersetzt – und den Datenbereich unter /var/www/storage, in den dein Code schreibt und den kein Veröffentlichen anfasst. Den Pfad liest du mit getenv('PUBLISHING_STORAGE'). Dateien wie eine Konfiguration mit API-Schlüssel legst du im Portal ab, im Reiter «Daten» – nie im Chat.

Auf einen Blick

Ort Was dort liegt Dein Code darf
/var/www/html Deine veröffentlichten Dateien nur lesen
/var/www/storage Der Datenbereich: Konfiguration, Bestellungen, Uploads lesen und schreiben
/var/www/storage/sessions Die Sitzungen deiner Besucher – PHP verwaltet sie selbst nicht anfassen
/var/www/tmp Uploads, solange die Anfrage läuft nichts Eigenes ablegen
/tmp Zwischenablage, 64 MB, verschwindet bei jeder Pause nur Kurzlebiges

Ein Pfad ausserhalb dieser vier bricht mit einer Meldung über open_basedir ab. Das ist kein Fehler in deinem Code, sondern die Grenze.

In der Vorschau läuft PHP für alle. Veröffentlichen lässt es sich nur mit dem Paket.

Zwei Verzeichnisse – und warum

Deine Dateien – alles, was dein Assistent baut – sind der ausgelieferte Stand. Sie werden bei jedem Veröffentlichen vollständig ersetzt, und solange die Website läuft, kann sie sie nicht ändern. Das ist Absicht: Was ausgeliefert wird, soll sich nicht selbst umschreiben können. Genau daran scheitert die häufigste Einnistung nach einer Sicherheitslücke – wer eine Lücke findet, kann keine Datei hinterlassen, die beim nächsten Besucher mitläuft.

Der Datenbereich liegt daneben. Dort schreibt dein PHP hin, und ein Veröffentlichen fasst ihn nie an. Aus dem Web ist er nicht abrufbar: Was dort liegt, liefert deine Website selbst aus – mit ihrer eigenen Prüfung, wer es sehen darf. Ein hochgeladenes .php wird dort auch nie ausgeführt.

Den Datenbereich in PHP ansprechen

Der Pfad steht in der Umgebungsvariablen PUBLISHING_STORAGE. Nimm ihn von dort, statt ihn fest hinzuschreiben:

<?php
$daten = getenv('PUBLISHING_STORAGE') ?: '/var/www/storage';

file_put_contents($daten . '/bestellungen.csv', $zeile, FILE_APPEND | LOCK_EX);

getenv() und nicht $_ENV: In $_ENV steht hier nichts, PHP füllt es in dieser Aufstellung nicht.

Zwei weitere Variablen helfen dir:

  • PUBLISHING_VORSCHAU ist 1, wenn der Code in der Vorschau läuft, und fehlt sonst. So kann deine Website in der Vorschau etwa einen Test-Schlüssel einer Zahlungs-API nehmen.
  • PUBLISHING_HOSTING ist immer 1 – daran erkennt dein Code, dass er bei uns läuft und nicht auf deinem Rechner.

Dateien hineinlegen: der Reiter «Daten»

Im Arbeitsbereich deiner Website gibt es den Reiter «Daten». Dort lädst du hoch, legst Ordner an, lädst herunter und löschst – zum Beispiel die Konfigurationsdatei, aus der dein Code seinen API-Schlüssel liest. Eine vorgegebene Datei gibt es nicht: Der Datenbereich ist am Anfang leer, und wie die Datei heisst und was darin steht, bestimmt dein Code.

So gehst du vor:

  1. Lass dir von deinem Assistenten sagen, welche Datei der Code erwartet und was hineingehört – mit Platzhaltern statt echter Werte.
  2. Erstelle die Datei auf deinem Rechner und trag dort die echten Werte ein.
  3. Öffne den Reiter «Daten», wähle oben Live oder Vorschau und lade die Datei hoch.
  4. Ruf die Seite auf, die die Datei braucht. Prüfe zuerst in der Vorschau – dort siehst du Fehlermeldungen.

Und zwar dort und nicht im Chat. In solchen Dateien stehen Schlüssel und Passwörter, und die sollen nicht durch ein Sprachmodell laufen. Dein Assistent hat für den Datenbereich bewusst kein Werkzeug; er kann dir sagen, was hineingehört, hineinlegen musst du es selbst. FTP gibt es bei uns nicht.

Was der Reiter kann und was nicht:

  • Eine einzelne Datei darf bis 100 MB gross sein.
  • Ein Ordner lässt sich nur löschen, wenn er leer ist – ein Fehlklick soll nicht einen ganzen Baum mitnehmen.
  • Es gibt keine Versionen. Was du hier löschst oder überschreibst, ist weg. Anders als bei deinen Website-Dateien kann dein Assistent nichts zurückholen.
  • Der Ordner sessions gehört PHP und wird nicht angezeigt.
  • Ein Name darf nicht auf Punkt oder Leerzeichen enden, höchstens 120 Zeichen lang sein und nicht tiefer als zehn Ordner liegen. .. ist nicht erlaubt.
  • Ein führender Punkt bleibt: .env heisst nach dem Hochladen .env.

Live und Vorschau

Die Vorschau hat einen eigenen Datenbereich, getrennt von dem der veröffentlichten Website. Wer eine neue Fassung seiner Bestellabwicklung ansieht, soll dabei nicht die echten Bestellungen überschreiben. Mit dem Umschalter oben im Reiter «Daten» wechselst du zwischen den beiden.

  • Der Vorschau-Bereich ist am Anfang leer. Braucht dein Code eine Konfiguration zum Starten, musst du sie dort eigens ablegen. Das ist der häufigste Grund, warum etwas live läuft und in der Vorschau nicht.
  • Er bleibt über mehrere Vorschauen und Ruhepausen hinweg bestehen. Gelöscht wird er, wenn die Website nicht mehr auf MADLAB-Hosting liegt.
  • Beide Bereiche zusammen zählen gegen den Platz deines Plans.

Was geht

  • Sitzungen. Ein Login bleibt angemeldet, auch über eine Ruhepause der Website hinweg.
  • Uploads deiner Besucher bis 100 MB je Datei und bis 20 Dateien in einer Anfrage.
  • Dienste im Internet über HTTPS: Zahlungs-APIs, Kartendienste, Newsletter-Anbieter.
  • Mail über SMTP bei einem Mailanbieter, auf Port 587 oder 465. Siehe unten zu mail().
  • SQLite als Datenbank in einer Datei im Datenbereich.
  • .htaccess gilt vollständig: Weiterleitungen, Header, php_value.
  • PHP 8.4 mit den gängigen Erweiterungen, darunter curl, mbstring, openssl, sodium, gd, intl, zip, exif, pdo_sqlite und sqlite3.
  • Zeitzone Europe/Zurich, Zeichensatz UTF-8.

Was nicht geht

  • mail() verschickt nichts. Es gibt false zurück, live wie in der Vorschau. Für Kontaktformulare nimm SMTP bei einem Mailanbieter – das kommt auch zuverlässiger an, weil der Anbieter die Absenderprüfung (SPF, DKIM) für dich erledigt.
  • Kein Datenbankserver. Es gibt bei uns kein MySQL, und eine Datenbank anderswo erreichst du auch nicht: Der Weg nach draussen ist nur über die Ports 80, 443, 587 und 465 offen, MySQL braucht 3306. Nimm SQLite, oder einen Dienst, der eine API über HTTPS anbietet.
  • Nichts ausführen. exec, shell_exec, system und Verwandte sind gesperrt. Es gibt keine Kommandozeile und kein Composer auf dem Server.
  • Nichts regelmässig von selbst. Es gibt keinen Cron. Was zeitgesteuert passieren soll, muss bei einem Seitenaufruf mit erledigt werden.
  • Keine eigenen Dienste, keine offenen Ports, keine Verbindungen in private Netze.
  • Nicht in deine eigenen Dateien schreiben. /var/www/html ist nur lesbar.

Dateien mit diesen Endungen liefert die Website nie aus, auch wenn du es in einer .htaccess erlauben wolltest: .env, .ini, .log, .sql, .bak, .swp, .git, composer.json, composer.lock, und alles, was mit einem Punkt beginnt (ausser .well-known). Das ist eine zweite Sicherung – die erste ist, solche Dateien gar nicht in den Website-Dateien zu haben.

Grenzen in Zahlen

Was Grenze
Datenbereich, Live und Vorschau zusammen 500 MB im Plan «MADLAB-Hosting»
Eine Datei im Reiter «Daten» 100 MB
Upload eines Besuchers 100 MB je Datei, 20 Dateien, 110 MB je Anfrage
Arbeitsspeicher je Anfrage 128 MB
Rechenzeit je Anfrage 30 Sekunden
Gleichzeitige Anfragen 8
Pause nach 15 Minuten ohne Besuch (Vorschau: 10)

Nach einer Pause dauert der erste Aufruf etwas länger, weil die Website erst startet. Sitzungen und der Datenbereich überstehen das; was in /tmp lag, nicht.

Fehlermeldungen

Die Vorschau zeigt Fehlermeldungen an. Auf der veröffentlichten Seite bleiben sie aus, damit keine Pfade und Abfragen vor Besuchern stehen – du siehst live also eine weisse Seite oder eine allgemeine Fehlerseite. Zum Fehlersuchen deshalb immer die Vorschau benutzen. Ein Protokoll der veröffentlichten Website ist für dich nicht einsehbar; wenn du eines brauchst, schreibe es selbst in den Datenbereich (siehe Best Practices).

Sicherung

Der Datenbereich wird nicht gesichert – weder Live noch Vorschau. Deine Website-Dateien sind versioniert und lassen sich zurückholen; was dein PHP in den Datenbereich schreibt, nicht. Lade wichtige Daten wie Bestellungen deshalb regelmässig im Reiter «Daten» herunter, oder bau deiner Website eine Exportfunktion.

Wie du eine PHP-Website so baust, dass sie sicher, robust und leicht zu pflegen ist, steht in den Best Practices für PHP-Websites.

Hat das nicht geholfen? hallo@madpublishing.ch