Funio ou 34SP pour tester une montée PHP sur WordPress sans SSH ?

Protéger le formulaire pendant une montée de PHP

Une association établie en France reçoit les demandes de bénévolat par un formulaire WordPress. La personne chargée du site a accès à WordPress et au panneau d’hébergement. Elle doit préparer un changement de version PHP sans ouvrir de session SSH. Le parcours à protéger commence sur la page de contact et se termine quand la soumission est acceptée et que l’association peut vérifier son arrivée. L’équipe veut d’abord reproduire ce parcours sur une copie privée, puis décider si le changement peut être appliqué au site public.

Le formulaire peut se dégrader alors que l’accueil et l’administration restent accessibles. Une partie du code peut ne se charger qu’au moment de la soumission. Une extension PHP qui manque dans la nouvelle configuration peut aussi affecter une pièce jointe, un traitement de caractères ou une fonction de validation. Pour l’association, une page qui s’ouvre et un bandeau de confirmation apparent donnent peu d’information si le message ne parvient jamais à la bonne destination.

Funio WordPress Starter et 34SP WordPress Hosting 1 Site proposent des parcours de réglage PHP dans leur documentation. Leur intérêt pour l’association dépend surtout de la portée de ce réglage. Il faut savoir si le changement vise la copie ou le site public, quelles versions sont proposées et comment revenir à la valeur précédente. La capacité à trouver un bouton dans le panneau compte moins que la capacité à isoler l’essai et à refaire le contrôle.

Préparer un point de comparaison dans WordPress

Choisissez une demande fictive que vous pouvez reconnaître à chaque étape. Notez le chemin du formulaire, les champs obligatoires, la réaction attendue à un champ invalide et la destination prévue pour un essai accepté. Si le formulaire utilise une protection contre le spam ou une intégration externe, vérifiez qu’elle fonctionne sur le sous-domaine de test ou prévoyez une configuration distincte. Un test bloqué par la clé du sous-domaine ne permet pas de conclure sur PHP.

Dans l’administration du site public, ouvrez Outils, Santé du site, Informations, puis Serveur. Relevez la version PHP observée par WordPress et les paramètres utiles au formulaire. Identifiez les extensions et le thème actifs ainsi que leurs versions. Faites ensuite le même relevé sur la copie. Gardez la date, l’adresse exacte et les captures utiles dans un document de recette. La version affichée dans un menu d’hébergement est une valeur configurée. Celle observée dans WordPress permet de vérifier ce qui exécute réellement le site.

Préparez une sauvegarde de fichiers et de base indépendante et vérifiez à quel moment elle correspond. Dans la copie, gardez la même version initiale de PHP et faites passer le formulaire une première fois. Restreignez l’accès à la copie et vérifiez dans une fenêtre privée qu’un visiteur anonyme ne peut pas l’ouvrir. Remplacez la destination de production par une boîte ou un journal de test dédié. Un envoi d’essai doit être reconnaissable et rester dans ce circuit. Si la copie échoue déjà avant toute modification, corrigez cette différence ou documentez-la avant de poursuivre.

Vérifier la portée du réglage avant de l’appliquer

Demandez qui peut modifier PHP sur le sous-domaine privé, quelle version de départ reste disponible et comment savoir si le site public partage le même réglage. Un accès administrateur dans WordPress donne les moyens de contrôler le formulaire. L’accès au panneau d’hébergement sert à modifier le moteur. Si ces rôles sont portés par deux bénévoles, réunissez les deux relevés avant que la personne responsable du panneau confirme le changement.

Relevez le nom de la cible et l’ancienne valeur du réglage, y compris un éventuel mode hérité. Faites de même pour les modules et options réellement nécessaires. L’intitulé d’une version ne dit pas quels modules sont activés. Un changement de version peut donc changer à la fois le moteur et ses réglages. Si l’association doit modifier un fichier de configuration depuis le panneau, sauvegardez ce fichier à part et identifiez son dossier avant de l’éditer.

Lorsque le fournisseur ne confirme pas de réglage séparé ou que le panneau montre seulement le site public, gardez la copie hors de cette opération. Demandez une destination dont le moteur peut être changé indépendamment. Juste après un essai, relisez Santé du site sur la copie et sur le public. Si le public a changé, remettez la valeur précédente et contrôlez le formulaire public avant de reprendre. Une vérification du périmètre protège davantage qu’un simple retour prévu dans un document.

Reproduire un échec visible uniquement à la soumission

L’exercice téléchargeable fait exécuter quatre cas à PHP en local. Il utilise un formulaire fictif et deux fichiers de traitement. Le code ancien déclare un paramètre de type chaîne avec une valeur par défaut nulle, sans le déclarer explicitement comme nullable. PHP 8.4 signale cette forme comme dépréciée. Le test transforme volontairement cet avertissement en exception pour rendre l’échec observable. Une dépréciation n’interrompt pas automatiquement tous les sites qui chargent un tel code.

L’ouverture du formulaire affiche un succès dans le modèle, car le traitement ancien n’est chargé qu’à la soumission. Avec la version du code corrigée, la soumission renvoie le marqueur de test. Le quatrième cas vérifie qu’un champ vide est encore refusé. La correction ne se limite donc pas à supprimer un message d’erreur. Elle doit aussi conserver la validation. Les statuts du rapport représentent les réponses attendues dans la maquette et le moteur PHP émet réellement l’avertissement.

Le ZIP a été vérifié sous PHP 8.4.8 en ligne de commande. Les quatre cas tournent dans ce même moteur. L’exercice ne mesure pas un changement de version sur un compte hébergeur. Il montre pourquoi il faut ouvrir puis soumettre le formulaire et distinguer un problème de PHP d’un problème d’envoi. Pour contrôler la remise du message sur votre site, rejouez la demande depuis le navigateur et vérifiez la destination de recette séparément.

• Télécharger la recette PHP du formulaire depuis « Pour aller plus loin », extraire le ZIP et vérifier la version avec php -v.
• Lancer php recette.php depuis le dossier. Comparer à attendu.json les quatre statuts et le marqueur RECETTE-FRM-01.

Funio Starter et le réglage cPanel par domaine

Le guide Funio indique cPanel, Logiciel, puis Sélectionner une version de PHP. Il précise que les extensions et options personnalisées dépendent de la version choisie. Sur la copie, relevez les modules utiles avant le changement, comme celui qui traite les caractères ou les fichiers dans votre formulaire. Vérifiez ensuite leur présence dans la nouvelle version. Activez seulement ceux dont le formulaire ou son environnement a besoin, et relevez tout écart avec le point de départ.

Pour des versions distinctes selon les domaines ou sous-domaines d’un même compte, l’aide décrit une règle de gestionnaire PHP dans le fichier .htaccess du dossier concerné. Le sélecteur CloudLinux ne suffit pas à attribuer directement une version à chaque sous-domaine. Avec l’autorisation et le gestionnaire confirmés par Funio, utilisez File Manager dans cPanel, ouvrez la racine de la copie, affichez les fichiers masqués et sauvegardez son .htaccess. Appliquez le bloc documenté pour la version confirmée et contrôlez la version servie par la copie. Ne remplacez pas le bloc de réécriture de WordPress.

Starter présente un site et 20 Go. Les guides du panneau ne prouvent pas que ce forfait permet une deuxième installation isolée ou que chaque option est visible sur le compte. Faites confirmer le périmètre de la copie et les droits avant de retenir ce parcours. Si la règle ne s’applique pas ou produit une erreur serveur, rétablissez la copie du .htaccess dans File Manager. Si vous avez changé le sélecteur général, remettez sa valeur initiale et vérifiez les autres sites concernés avant de relancer l’essai.

34SP et les réglages du panneau WordPress Hosting

34SP documente la création de la copie depuis Manage Sites, puis le site et l’onglet Staging. La copie ne compte pas comme un site public supplémentaire dans le conteneur selon le guide. Elle consomme des ressources et de l’espace. Elle utilise notamment un seul processus PHP et des règles de cache différentes. Ces écarts conviennent à un contrôle du fonctionnement d’un formulaire, avec une limite claire pour toute comparaison de vitesse.

Le parcours officiel pour modifier le moteur du site passe par Manage Sites, le site ou domaine choisi, Advanced, puis PHP Version. Le menu Version et Update PHP Version permettent d’appliquer le réglage documenté. Les deux guides établissent que la copie et le sélecteur existent. Ils ne confirment pas que l’onglet Staging expose un sélecteur indépendant sur chaque compte. Avant de toucher au réglage, demandez quelle entrée cible la copie et comment le vérifier. Gardez le sélecteur public à sa valeur relevée pendant cet essai.

Si 34SP confirme un réglage indépendant, ouvrez Santé du site sur la copie, appliquez la version proposée et relisez la valeur sur les deux adresses. Rejouez ensuite la demande fictive. Si elle échoue, rétablissez la valeur initiale sur la même cible si elle est encore disponible, puis répétez le contrôle. Le bouton de retour décrit dans l’aide de staging concerne des fichiers ou une base transférés vers le site public. Le retour de version PHP se prépare dans le sélecteur ou avec l’assistance selon le compte.

Comparer les prix du premier mois et de la suite

La carte WordPress Starter de Funio affiche 3,18 $ pour le premier mois et 12,71 $ par mois comme référence barrée. Le catalogue de facturation affiche Starter à 12,71 USD par mois. La devise de la promotion de 3,18 $ reste à confirmer au récapitulatif, ainsi que les taxes et le montant du prochain débit. Si le premier mois est facturé à 3,18 USD et si les onze mois suivants sont au tarif de 12,71 USD, le total calculé est de 142,99 USD hors taxes et options éventuellement ajoutées. Ce calcul sert à estimer un scénario. Le montant facturé dépend de la devise et du contrat.

La carte 34SP à un site affiche 11,95 £ par mois. Les conditions indiquent que la TVA est incluse sauf mention contraire, que la période est payée d’avance et que la reconduction porte sur une période de même durée. La carte ne sépare pas un tarif d’appel d’un tarif de reconduction. Douze périodes au même barème donnent 143,40 £. La fiscalité selon le titulaire et le barème de la prochaine échéance restent à vérifier. La FAQ affiche 9,95 GBP pour un site tandis que la carte 1 Site et le résumé de l’offre affichent 11,95 GBP. Le calcul se fonde sur la carte 1 Site. Confirmez le montant du récapitulatif avant de souscrire. Le programme d’hébergement offert aux organismes caritatifs enregistrés au Royaume-Uni relève d’un parcours distinct. Le budget du scénario français utilise la carte commerciale.

Calculez le coût pour le périmètre dont vous avez besoin. Une copie incluse peut éviter de payer une deuxième offre, mais son indépendance pour PHP doit être établie. Si l’association doit réserver une destination séparée ou demander une intervention, faites chiffrer ce poste et sa durée. Mettez la fin de la remise et la date de reconduction sur le même échéancier que la recette. Comparez les totaux dans une devise commune seulement une fois les devises et frais confirmés.

Valider le formulaire après le changement

Après avoir contrôlé la version servie par la copie, ouvrez la page de contact comme le ferait un visiteur autorisé. Envoyez d’abord une demande dont un champ obligatoire est vide. Vérifiez le message présenté et l’absence de nouvelle entrée dans la boîte ou le journal de test. Envoyez ensuite une demande valide avec votre marqueur. Si le formulaire propose un fichier et que cette fonction compte pour l’association, ajoutez une pièce fictive assez petite pour respecter les limites documentées.

Vérifiez trois résultats pour l’envoi valide. La page doit afficher la confirmation attendue, la demande doit apparaître au bon endroit avec son marqueur, et une soumission ne doit produire qu’une entrée. Si la confirmation apparaît sans livraison, relevez l’heure et vérifiez le journal de l’extension ou la file d’envoi. Le résultat peut venir du routage de courrier ou de la configuration de la copie. Un refus avant l’envoi oriente plutôt vers la validation, les modules ou le code.

Si vous avez besoin d’un diagnostic, consultez les journaux disponibles sur la copie. WordPress documente l’activation de WP_DEBUG_LOG avec WP_DEBUG et la désactivation de l’affichage des erreurs. Utilisez un emplacement protégé et notez seulement l’erreur utile avec l’heure et la version PHP. Les journaux peuvent contenir le contenu d’une demande ou un chemin interne. Remettez les réglages de diagnostic à leur état initial dès la fin du contrôle. Si le panneau masque le journal, demandez l’extrait lié à votre essai plutôt qu’un export complet.

Revenir à la version précédente et choisir l’offre

Si une demande valide ne passe plus, consignez le symptôme avant de changer un autre réglage. Rétablissez la version initiale sur la cible et les modules qui lui étaient associés. Si un fichier de gestionnaire a été modifié sur la copie, remettez sa version sauvegardée. Vérifiez que WordPress sert à nouveau le moteur attendu, puis rejouez la demande. Un retour de version après un simple réglage PHP évite d’écraser des entrées de formulaire récentes en restaurant une base entière.

Pour Funio, l’intérêt est le parcours cPanel et la méthode documentée par dossier quand le compte accepte un sous-domaine distinct. Pour 34SP, l’intérêt est la copie accessible depuis le panneau avec un sélecteur de version documenté pour le site. La décision dépend de la confirmation du réglage indépendant sur cette copie. Si un fournisseur confirme seulement la version du site public, demandez une destination séparée pour l’essai avant d’utiliser son parcours sur l’association.

Une fois le test concluant, notez la cible, la version retenue, les réglages et la personne qui peut revenir à la configuration précédente. Faites vérifier le formulaire public avec une demande identifiable si l’association applique ensuite la même modification. Si la version initiale n’est plus proposée, faites préciser le retour possible et la compatibilité des extensions avant de modifier le site. La possibilité de rétablir le formulaire, preuves à l’appui, donne un critère de décision plus concret que le nombre de versions annoncées.

Pour aller plus loin

• Consulter la fiche Funio
• Consulter la fiche 34SP
• Vérifier les prérequis PHP de WordPress
• Télécharger la recette PHP du formulaire (ZIP)