PHP et l’espace de données

Avec le module « PHP », du code côté serveur tourne sur votre site. Il voit deux répertoires : vos fichiers publiés sous /var/www/html – en lecture seule et remplacés à chaque publication – et l’espace de données sous /var/www/storage, où votre code écrit et qu’aucune publication ne touche. Vous lisez le chemin avec getenv('PUBLISHING_STORAGE'). Les fichiers comme une configuration avec une clé d’API se déposent dans le portail, dans l’onglet « Données » – jamais dans la conversation.

En un coup d’œil

Emplacement	Ce qui s’y trouve	Votre code peut
/var/www/html	Vos fichiers publiés	seulement lire
/var/www/storage	L’espace de données : configuration, commandes, téléversements	lire et écrire
/var/www/storage/sessions	Les sessions de vos visiteurs – PHP les gère lui-même	ne pas y toucher
/var/www/tmp	Les téléversements pendant la requête	n’y rien déposer
/tmp	Espace temporaire, 64 Mo, vidé à chaque pause	seulement l’éphémère

Un chemin en dehors de ces quatre s’arrête avec un message sur open_basedir. Ce n’est pas une erreur de votre code, c’est la limite.

Dans l’aperçu, PHP fonctionne pour tout le monde. Pour le publier, il faut le module.

Deux répertoires – et pourquoi

Vos fichiers – tout ce que votre assistant construit – forment l’état publié. Ils sont intégralement remplacés à chaque publication, et pendant que le site tourne, il ne peut pas les modifier. C’est voulu : ce qui est livré ne doit pas pouvoir se réécrire soi-même. C’est précisément ce qui arrête la forme la plus courante d’infestation après une faille – qui trouve une faille ne peut pas laisser derrière lui un fichier qui s’exécute avec le prochain visiteur.

L’espace de données se trouve à côté. C’est là que votre PHP écrit, et une publication n’y touche jamais. Il n’est pas accessible depuis le web : ce qui s’y trouve, votre site le livre lui-même – avec sa propre vérification de qui a le droit de le voir. Un .php téléversé n’y est jamais exécuté non plus.

Accéder à l’espace de données en PHP

Le chemin se trouve dans la variable d’environnement PUBLISHING_STORAGE. Prenez-le là plutôt que de l’écrire en dur :

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

file_put_contents($donnees . '/commandes.csv', $ligne, FILE_APPEND | LOCK_EX);

getenv() et non $_ENV : ici, $_ENV est vide, PHP ne le remplit pas dans cette installation.

Deux autres variables vous aident :

• PUBLISHING_VORSCHAU vaut 1 quand le code tourne dans l’aperçu, et est absente sinon. Votre site peut ainsi utiliser dans l’aperçu, par exemple, une clé de test d’une API de paiement.
• PUBLISHING_HOSTING vaut toujours 1 – votre code sait ainsi qu’il tourne chez nous et non sur votre ordinateur.

Y déposer des fichiers : l’onglet « Données »

L’espace de travail de votre site comporte l’onglet « Données ». Vous y téléversez, créez des dossiers, téléchargez et supprimez – par exemple le fichier de configuration dans lequel votre code lit sa clé d’API. Il n’y en a pas d’imposé : l’espace de données est vide au départ, et c’est votre code qui décide du nom du fichier et de son contenu.

Comment procéder :

1. Demandez à votre assistant quel fichier le code attend et ce qu’il doit contenir – avec des valeurs fictives à la place des vraies.
2. Créez le fichier sur votre ordinateur et saisissez-y les vraies valeurs.
3. Ouvrez l’onglet « Données », choisissez en haut En ligne ou Aperçu et téléversez le fichier.
4. Ouvrez la page qui a besoin du fichier. Vérifiez d’abord dans l’aperçu – c’est là que vous voyez les messages d’erreur.

Et cela se fait là, pas dans la conversation. Ces fichiers contiennent des clés et des mots de passe, et ceux-ci ne doivent pas passer par un modèle de langage. Votre assistant n’a volontairement aucun outil pour l’espace de données ; il peut vous dire ce qui doit y figurer, mais c’est à vous de l’y déposer. Nous ne proposons pas de FTP.

Ce que l’onglet sait faire ou non :

• Un fichier peut peser jusqu’à 100 Mo.
• Un dossier ne se supprime que s’il est vide – un faux clic ne doit pas emporter toute une arborescence.
• Il n’y a pas de versions. Ce que vous supprimez ou écrasez ici est perdu. Contrairement à vos fichiers de site, votre assistant ne peut rien récupérer.
• Le dossier sessions appartient à PHP et n’est pas affiché.
• Un nom ne peut pas se terminer par un point ou une espace, compter plus de 120 caractères ni se trouver à plus de dix niveaux de dossiers. .. n’est pas autorisé.
• Un point initial reste : .env s’appelle toujours .env après le téléversement.

En ligne et aperçu

L’aperçu possède son propre espace de données, séparé de celui du site publié. Qui regarde une nouvelle version de son traitement de commandes ne doit pas écraser au passage les commandes réelles. Le sélecteur en haut de l’onglet « Données » passe de l’un à l’autre.

• L’espace de l’aperçu est vide au départ. Si votre code a besoin d’une configuration pour démarrer, vous devez aussi la déposer là. C’est la raison la plus fréquente pour laquelle quelque chose fonctionne en ligne mais pas dans l’aperçu.
• Il subsiste d’un aperçu à l’autre et pendant les pauses. Il est supprimé lorsque le site n’est plus hébergé chez MADLAB.
• Les deux espaces comptent ensemble dans l’espace de votre plan.

Ce qui fonctionne

• Les sessions. Une connexion reste active, même pendant une pause du site.
• Les téléversements de vos visiteurs jusqu’à 100 Mo par fichier et jusqu’à 20 fichiers par requête.
• Les services sur Internet via HTTPS : API de paiement, services de cartes, fournisseurs de newsletters.
• L’e-mail via SMTP chez un fournisseur de messagerie, sur le port 587 ou 465. Voir plus bas à propos de mail().
• SQLite comme base de données, dans un fichier de l’espace de données.
• .htaccess s’applique entièrement : redirections, en-têtes, php_value.
• PHP 8.4 avec les extensions courantes, dont curl, mbstring, openssl, sodium, gd, intl, zip, exif, pdo_sqlite et sqlite3.
• Fuseau horaire Europe/Zurich, jeu de caractères UTF-8.

Ce qui ne fonctionne pas

• mail() n’envoie rien. La fonction renvoie false, en ligne comme dans l’aperçu. Pour les formulaires de contact, utilisez SMTP chez un fournisseur de messagerie – les messages arrivent aussi plus sûrement, car le fournisseur se charge de la vérification de l’expéditeur (SPF, DKIM).
• Pas de serveur de base de données. Nous n’avons pas de MySQL, et une base de données ailleurs n’est pas joignable non plus : la sortie n’est ouverte que sur les ports 80, 443, 587 et 465, et MySQL a besoin du 3306. Utilisez SQLite, ou un service qui propose une API via HTTPS.
• Rien à exécuter. exec, shell_exec, system et leurs semblables sont désactivés. Il n’y a ni ligne de commande ni Composer sur le serveur.
• Rien de planifié. Il n’y a pas de cron. Ce qui doit se faire à intervalles réguliers doit être accompli lors d’un appel de page.
• Pas de services propres, pas de ports ouverts, pas de connexions vers des réseaux privés.
• Pas d’écriture dans vos propres fichiers. /var/www/html est en lecture seule.

Les fichiers avec ces extensions ne sont jamais livrés, même si vous vouliez l’autoriser dans un .htaccess : .env, .ini, .log, .sql, .bak, .swp, .git, composer.json, composer.lock, et tout ce qui commence par un point (sauf .well-known). C’est une seconde protection – la première est de ne pas avoir de tels fichiers parmi vos fichiers de site.

Les limites en chiffres

Quoi	Limite
Espace de données, en ligne et aperçu ensemble	500 Mo dans le plan « hébergement MADLAB »
Un fichier dans l’onglet « Données »	100 Mo
Téléversement d’un visiteur	100 Mo par fichier, 20 fichiers, 110 Mo par requête
Mémoire par requête	128 Mo
Durée d’exécution par requête	30 secondes
Requêtes simultanées	8
Pause après	15 minutes sans visite (aperçu : 10)

Après une pause, le premier appel prend un peu plus de temps, car le site doit démarrer. Les sessions et l’espace de données le supportent ; ce qui se trouvait dans /tmp, non.

Messages d’erreur

L’aperçu affiche les messages d’erreur. Sur la page publiée, ils restent masqués, pour qu’aucun chemin ni aucune requête ne se retrouve sous les yeux des visiteurs – en ligne, vous voyez une page blanche ou une page d’erreur générique. Pour chercher une erreur, utilisez donc toujours l’aperçu. Le journal du site publié ne vous est pas accessible ; si vous en avez besoin, écrivez-le vous-même dans l’espace de données (voir les bonnes pratiques).

Sauvegarde

L’espace de données n’est pas sauvegardé – ni en ligne ni pour l’aperçu. Vos fichiers de site sont versionnés et peuvent être récupérés ; ce que votre PHP écrit dans l’espace de données, non. Téléchargez donc régulièrement les données importantes, comme les commandes, dans l’onglet « Données », ou dotez votre site d’une fonction d’export.

Comment construire un site PHP sûr, robuste et facile à entretenir est expliqué dans les bonnes pratiques pour les sites PHP.