alwaysdata ou Hostpoint pour vérifier une variable PHP dans WordPress

Le terminal lit le réglage, la page WordPress le croit absent

Une extension WordPress personnalisée lit un interrupteur de synchronisation. La commande de recette affiche que l’interrupteur vaut zéro, et l’équipe attend que la synchronisation reste désactivée. Dans l’écran web, l’extension indique que le réglage est introuvable. Avant de déplacer le fichier de configuration ou de changer de version PHP, vérifiez comment le code lit ce réglage. Une valeur peut être présente dans l’environnement du processus alors que PHP ne la place pas dans le tableau `$_ENV`.

La directive PHP `variables_order` contrôle l’initialisation de plusieurs tableaux de requête et d’environnement. Dans l’exercice, le serveur reçoit la même variable fictive avec deux valeurs de cette directive. Avec `EGPCS`, la clé est disponible dans `$_ENV`. Avec `GPCS`, le tableau ne contient pas la clé, alors que `getenv()` lit toujours la valeur. La lettre `E` concerne l’environnement. L’observation de la clé dans le tableau dépend ainsi de la configuration PHP en plus de la présence de la variable.

Le comparatif couvre un seul interrupteur fictif et compare les deux mécanismes de lecture. Il distingue aussi la valeur textuelle `0`, l’absence réelle et un format invalide. alwaysdata et Hostpoint documentent des réglages PHP au niveau du site. L’objectif est de trouver la configuration qui produit la réponse web et de mesurer le résultat dans ce contexte avant de modifier l’extension.

Comparer les deux contextes sur une copie privée

Identifiez le site, le chemin et la fonction qui signalent l’absence du réglage. Si une commande WordPress sert de référence, vérifiez d’abord qu’elle cible la même installation. Relevez ensuite la version de PHP, son interface d’exécution, l’ordre effectif des variables et le résultat de deux tests de présence. Dans l’exercice, la ligne de commande indique `cli` et le serveur de développement `cli-server`. Sur un hébergement, les libellés peuvent différer. L’intérêt est de savoir quel processus a réellement produit le relevé.

Pour éviter d’exposer une valeur de configuration, utilisez une variable témoin sans donnée réelle et un journal de recette privé. Demandez au mainteneur de comparer `getenv($nom) !== false` et `array_key_exists($nom, $_ENV)` pour ce seul nom. Relevez aussi `ini_get('variables_order')`. Chaque test répond à une question précise. Un inventaire de toutes les variables ou une page publique de diagnostic donnerait des informations inutiles et pourrait exposer d’autres réglages du site.

Comparez les résultats sur la commande et sur l’écran concerné, avec la même variable témoin. Si les deux lectures échouent côté web, vérifiez la manière dont le processus web reçoit la variable. Si `getenv()` réussit et que la clé manque dans le tableau, examinez l’ordre effectif et la méthode de lecture. Un terminal peut recevoir des variables de son propre lancement. Sa réussite est un indice sur ce terminal, puis la requête web fournit la preuve qui concerne l’écran.

• Relever l’identifiant du site, la version PHP, le contexte et l’ordre effectif.
• Tester la même clé fictive par les deux méthodes, dans le terminal et dans le traitement web.

Faire de zéro, de l’absence et d’une valeur invalide trois cas différents

Pour un interrupteur dont le format attendu est `0` ou `1`, comparez la chaîne exacte. PHP documente que `getenv()` renvoie `false` lorsque la variable n’existe pas. Un test de vérité générique confondrait la chaîne `0` avec une valeur fausse. Dans la recette, une variable présente à `0` garde un état distinct de la variable absente. Une valeur en dehors du format attendu produit aussi un état distinct. L’extension peut ainsi informer le mainteneur de la cause sans afficher la valeur.

Précisez la conduite prévue pour chaque état. Le témoin de recette indique que seule la chaîne `1` autorise la simulation. La chaîne `0` indique une désactivation explicite. L’absence et une valeur invalide désactivent également la simulation, avec deux diagnostics distincts. Pour un vrai module, reprenez la convention décidée par son mainteneur et vérifiez aussi les valeurs déjà utilisées en production avant de changer le comportement.

Vérifiez le périmètre du réglage. Un interrupteur utilisé par l’extension peut appartenir à un compte, à un site ou à une tâche. Une copie de recette qui réutilise la configuration du site principal risque d’exercer un autre comportement que celui voulu. Utilisez le nom fictif et observez seulement le résultat de décision pendant l’exercice. Si le réglage concerné est fourni par un mécanisme officiel de l’extension, documentez ce mécanisme avant de choisir une autre source de valeur.

Si vous tracez le réglage, séparez la valeur de configuration des données entrantes. La variable témoin est fournie au processus. Les paramètres d’une URL, les champs de formulaire et les cookies suivent leur propre parcours. Modifier `request_order`, qui régit la construction de `$_REQUEST`, ne rétablit pas cette clé dans `$_ENV`. Cette distinction évite d’attribuer à un formulaire un problème qui se produit avant que l’extension lise son paramètre.

alwaysdata Plus Small, séparer la configuration du compte de celle du site

Dans l’administration alwaysdata, ouvrez Web → Sites et sélectionnez la copie qui produit le résultat. La documentation PHP décrit une configuration du compte dans Environnement → PHP et la possibilité de personnaliser PHP au niveau du site. Elle indique aussi que la version par défaut du compte est utilisée lorsque vous lancez la commande `php`. Relevez ces deux périmètres et contrôlez l’ordre des variables depuis la requête web. Une lecture du fichier de configuration du compte aide à préparer le test. Elle doit être rapprochée des réglages supplémentaires du site.

Si la valeur de la variable témoin est disponible par `getenv()` et que l’extension dépend de `$_ENV`, essayez une correction sur la copie. Relevez la directive actuelle et sauvegardez le réglage de site. Dans le cas précis d’un ordre `GPCS`, l’ajout de `E` donne `EGPCS`. Conservez les autres lettres et leur ordre lorsque votre configuration est différente. Rejouez les deux lectures. Si le résultat ne change pas, vérifiez le contexte effectif et rétablissez le réglage précédent avant de poursuivre.

Si la variable manque également pour `getenv()`, examinez le mécanisme utilisé pour la fournir au processus du site. Une directive PHP qui demande d’alimenter un tableau ne fournit pas la valeur manquante. Si l’extension propose un réglage de site à la place d’une variable d’environnement, comparez le résultat de cette voie sur la copie. Le choix dépend de la source attendue par le module et du périmètre de l’installation.

Hostpoint Standard, vérifier les réglages PHP du domaine

Dans le Control Panel Hostpoint, ouvrez Sites Web → Réglages Web puis Configuration PHP pour le domaine de recette. L’aide décrit des réglages par site ou répertoire et la possibilité d’ajouter une option personnalisée. Elle indique que les réglages du site sont écrits dans `.user.ini` à la racine de document. Relevez le dossier, la version et le résultat de `ini_get()` dans l’écran qui utilise l’extension. Pour une installation qui se trouve dans un autre répertoire, vérifiez aussi les réglages qui s’appliquent à cette URL.

Sur la copie, si la valeur est présente et que le tableau en est privé, vous pouvez vérifier si `variables_order` est acceptée comme option pour ce site. Sauvegardez la configuration actuelle et modifiez une seule valeur pendant l’essai. Lisez ensuite l’ordre effectif depuis la même requête, puis relancez le témoin. Ce contrôle établit si la directive a réellement pris effet. Si le compte refuse l’option ou si sa portée ne convient pas, conservez le réglage de départ et examinez la lecture explicite dans le code.

Pour revenir à la configuration initiale, restaurez l’ancienne valeur ou retirez l’option que vous avez ajoutée. Vérifiez l’état dans le domaine de recette et sur une page normale de la même installation. Un changement de tableau PHP peut concerner d’autres composants du site. Une correction limitée à la lecture du paramètre peut donc être plus simple à vérifier quand l’équipe maintient l’extension.

Offres et conditions vérifiées le 11 novembre 2026

alwaysdata Cloud Public Plus Small affiche 5 € HT par mois en paiement annuel, soit 60 € HT sur douze mois. En facturation mensuelle, la grille affiche 6 € HT par mois. Douze mensualités au même tarif représenteraient 72 € HT. Small annonce 50 Go de disque à l’échelle du compte, 1 Go de RAM et 1 CPU. Vérifiez le total fiscal, le cycle et le tarif applicable à la reconduction pour votre dossier. L’aide indique que les contrats validés et à valider se consultent dans Abonnements → Contrats. La page Plus annonce aussi 30 jours offerts. Vérifiez à la commande comment ils s’articulent avec le premier cycle payé.

Hostpoint Standard est affiché à 15,90 CHF par mois, TVA incluse selon la grille publique suisse. Douze mois à ce tarif représentent 190,80 CHF. L’aide indique des durées de 6, 12 ou 24 mois pour l’hébergement web. Elle décrit une reconduction automatique pour la même durée si la résiliation n’est pas faite au plus tard 30 jours avant l’échéance. Vérifiez le montant de reconduction et le total dû pour le contrat retenu. Standard présente 100 Go NVMe, dix domaines et dix bases MariaDB. Le catalogue présente séparément un essai gratuit de 30 jours. Vérifiez son périmètre si vous choisissez de passer par l’essai.

Gardez les devises et les durées de facturation sur des lignes distinctes. Pour la difficulté étudiée, comparez surtout la facilité à retrouver le site et son contexte PHP effectif. Les ressources des deux offres dimensionnent l’hébergement et sa copie de recette. Elles ne permettent pas de déduire si une variable est injectée ni si `$_ENV` sera alimenté pour une requête.

Corriger la lecture au niveau le plus proche de l’extension

Si vous maintenez le module et que son contrat prévoit une variable de processus, lisez le nom convenu de façon explicite. Par exemple, `getenv('ATELIER_SYNCHRO_CATALOGUE')` lit le témoin de l’exercice. Comparez le retour à `false`, puis aux chaînes `0` et `1`. Contrôlez la chaîne avant de prendre une décision métier. Consignez seulement le résultat du contrôle, comme présent, absent ou invalide. Dans une installation réelle, utilisez le nom et les valeurs autorisés par le module et gardez les paramètres réels hors du diagnostic.

Selon l’interface d’exécution PHP, une variable fournie par le serveur peut être traitée différemment d’une variable du processus. Le manuel `getenv()` précise la portée du paramètre `local_only` pour les interfaces telles que FastCGI. Vérifiez la source attendue avant de modifier ce paramètre. Dans l’exercice, la valeur vient directement de l’environnement donné au processus PHP, et la fonction est appelée avec le seul nom. Rejouez le résultat sous l’interface effective de votre site si son environnement diffère. PHP classe variables_order parmi les directives configurables par répertoire ou côté serveur. Un appel à ini_set() dans l’extension ne permet pas de la modifier.

Le cœur WordPress fournit `wp_get_environment_type()` pour les types d’environnement du site, comme développement, préproduction ou production. Ce réglage a ses propres règles de lecture et de priorité. Pour l’interrupteur de synchronisation, définissez la source de configuration prévue par l’extension. Si son éditeur propose une option dans l’administration, vérifiez la priorité entre cette option et la variable existante. Un changement bien délimité doit conserver le comportement des autres paramètres et des autres sites.

• Lire la variable par son nom et traiter séparément `false`, `0` et `1`.
• Comparer le résultat dans le site, la commande et le traitement différé si le module y est appelé.

Faire un retour arrière avec la même variable témoin

Conservez le réglage PHP précédent et une version du module qui peut être restaurée. Testez un seul changement à la fois. Après une modification de `variables_order`, relancez l’écran et comparez l’ordre effectif et la présence de la clé. Après une modification du code, gardez le même ordre PHP et vérifiez les résultats de décision. Vous pouvez ainsi attribuer le changement à la bonne cause. Contrôlez également un formulaire ou une page qui utilise les autres tableaux PHP du site, surtout si vous avez modifié leur ordre.

Prévoyez quatre lectures simples dans la recette : zéro, un, absence et format invalide. Comparez la décision à celle attendue, sans lancer le traitement métier pendant le test. Si vous remettez la configuration initiale, vérifiez que l’ordre et l’affichage sont revenus au point de départ. Si vous remettez l’ancienne version du code, rejouez le témoin pour savoir si l’écart réapparaît. Le retour arrière doit restaurer le comportement prévu, en plus de restaurer les fichiers ou le réglage.

Lorsque la recette est terminée, retirez la sonde temporaire et gardez seulement le relevé privé utile. Si la valeur réelle manque dans l’environnement web, notez le processus qui en a besoin et le mécanisme autorisé pour la lui fournir. Vérifiez le résultat après un nouveau démarrage ou un redéploiement de la copie, selon le fonctionnement de votre hébergement. Le test de présence doit être reproductible par un autre mainteneur à partir de la même procédure.

Ce que montrent les huit contrôles en PHP local

Le ZIP exécute la même sonde en ligne de commande puis via HTTP sur la boucle locale. En CLI avec `EGPCS`, la valeur `0` est lue dans les deux chemins. Avec la même valeur dans le processus web et l’ordre `GPCS`, `getenv()` lit `0` et la clé manque dans `$_ENV`. Le scénario web avec `EGPCS` rétablit la clé dans le tableau. Les autres lectures séparent une variable réellement absente, une valeur invalide et la valeur `1` qui active uniquement le témoin.

Les huit contrôles ont réussi avec Python 3.14.4 et PHP 8.4.8 depuis le ZIP extrait. Le test utilise un vrai processus PHP et de vraies réponses HTTP locales. Le code de l’extension est représenté par une sonde fictive. Les réglages de PHP sur les offres comparées restent à confirmer dans le site réel. Le rapport JSON permet de vérifier le contexte et la présence dans chaque scénario, sans inscrire une valeur de configuration réelle.

alwaysdata Plus Small est adapté si votre équipe distingue les réglages PHP du compte et du site dans son administration. Hostpoint Standard convient si elle s’appuie sur les réglages du domaine et sur les options documentées dans le Control Panel. Dans les deux cas, validez la même chose : la variable est lisible dans le traitement concerné, la chaîne `0` conserve le comportement désactivé et la correction reste vérifiable lors du retour à la configuration précédente.

• Extraire le ZIP et lancer `python recette.py` avec PHP CLI disponible.
• Comparer les champs `getenv_present`, `env_present`, `variables_order` et `etat` dans le rapport.

Pour aller plus loin

• Lire la fiche alwaysdata
• Lire la fiche Hostpoint
• Comparer les extensions de migration WordPress
• Télécharger la recette de la variable PHP (ZIP)