ConoHa WING ou Xserver pour tester PHP sur une copie WordPress isolée

Prouver que la bascule PHP vise seulement la copie

Une équipe maintient un WordPress destiné au public japonais et prépare un changement de version PHP. Elle veut d’abord éprouver un bloc éditorial utilisé sur plusieurs pages, puis revenir à l’état initial si la mise à jour de son extension modifie ses réglages. Le site public doit conserver sa version et sa base pendant l’essai. Le choix de l’hébergeur dépend de la portée du réglage PHP, de l’éligibilité du site à l’outil de copie et de la possibilité de vérifier le retour.

Un dossier différent ne prouve pas qu’une version PHP différente sera utilisée. Un nom de recette peut aussi être rattaché au domaine public et partager son réglage. Choisissez un domaine de recette qui apparaît comme entrée distincte dans le panneau et confirmez la portée du changement avant de l’appliquer. Une copie sur le même serveur partage des ressources et peut encore avoir accès à des secrets. Pour l’essai, traitez son répertoire, sa base et ses sorties comme des éléments à isoler séparément.

Avant de changer de version, relevez le domaine, la racine, le nom de base, l’utilisateur prévu et la version PHP des deux environnements. Préparez un marqueur différent sur chacun. Faites un premier relevé sur le web avec le nom attendu, car la commande PHP en terminal peut utiliser un autre moteur que les requêtes. Retirez le diagnostic à la fin. Une page publique d’informations PHP expose plus de détails que les quelques valeurs utiles à l’essai.

Préparer une copie représentative avec des sorties coupées

Copiez les fichiers et la base nécessaires au test. Un modèle de thème et d’extensions ne suffit pas lorsque le défaut dépend des réglages ou des contenus déjà présents. En revanche, les données sensibles et les comptes réels ne sont pas nécessaires pour vérifier un bloc. Préférez des données de test ou une copie protégée et réduite au périmètre utile. Contrôlez la destination de la base dans la configuration et l’URL utilisée par WordPress.

Protégez l’accès avant de déposer les données. Un réglage d’indexation ne bloque pas un visiteur qui connaît l’adresse. Vérifiez le refus sans authentification et l’accès avec un compte de test. Déconnectez les envois de courriel, les webhooks et les tâches qui touchent des services réels. Vérifiez les liens et les requêtes sortantes d’un bloc témoin. Un texte affiché au bon endroit peut masquer une dépendance qui appelle toujours la production.

Enregistrez les résultats du bloc et une modification inoffensive en base sous la version de départ. Vérifiez que l’écriture apparaît seulement dans la copie. Répétez la lecture de production avant et après le changement de PHP de la recette. Préparez un export de la base de recette et un relevé de ses fichiers avant la mise à jour de l’extension. Ce point permet de mesurer ce qu’un simple retour à l’ancienne version de PHP rétablit.

ConoHa WING et le réglage PHP par domaine

ConoHa WING documente la copie d’un WordPress entre deux domaines du même serveur. Dans WING, ouvrez la gestion du site, ses réglages et l’onglet WordPress. La copie complète emporte le contenu attendu pour la recette. Le mode modèle reprend le thème et les extensions, sans les articles ni les médias. Le guide demande de renseigner la base, son utilisateur et son mot de passe. Vérifiez que l’utilisateur de la base de recette ne peut pas écrire dans la base publique. Le guide indique que la copie reprend les identifiants WordPress du site d’origine. Protégez le dossier avant d’exposer la copie, puis limitez les comptes actifs à ceux utilisés pour la recette.

Pour PHP, le guide passe par la gestion du site, les réglages avancés puis PHP. ConoHa documente le réglage PHP par domaine et donne priorité au réglage individuel. La procédure de changement de version ajoute une directive AddHandler au fichier .htaccess du domaine. Relevez le domaine et contrôlez le fichier de configuration de la copie avant d’enregistrer. La FAQ WING liste les branches 8.4 et 8.5. Le panneau du compte et un relevé via le web restent nécessaires pour confirmer la disponibilité et la portée sur la configuration précise. Le guide de copie invite à vérifier la compatibilité du thème et des extensions lorsqu’une autre version PHP est utilisée.

ConoHa documente une restriction d’accès par répertoire dans les réglages de sécurité. Vérifiez la protection de la racine de recette, des fichiers et des routes d’administration. L’aide indique quatorze jours de sauvegardes automatiques et distingue Web et base. La reprise des fichiers Web crée une copie dans un répertoire de sauvegarde que l’équipe doit récupérer ou utiliser pour une remise ciblée. Les fichiers générés sont temporaires. Pour un essai reproductible, conservez aussi le point créé juste avant le changement.

Xserver Standard et l’éligibilité à la copie

Chez Xserver, la fonction WordPress Site Copy du panneau se trouve dans WordPress簡単インストール, puis dans les détails de l’installation. L’annonce de la fonction précise que la copie intégrée vise les WordPress créés avec l’installateur du service. Choisissez la copie complète pour éprouver un contenu existant. Le manuel signale que certaines données produites par des extensions de sauvegarde sont exclues et que certaines URL peuvent ne pas être réécrites. Après la copie, ouvrez le bloc témoin et vérifiez les liens qui pointent encore vers l’adresse publique.

Si le site ne figure pas parmi les installations éligibles, vérifiez un chemin par export et import séparés avant de retenir l’offre pour ce besoin. Vérifiez l’export de la base, les fichiers et les URL sur une copie privée avant d’en faire la voie de recette. Pour changer le moteur, utilisez PHP Ver.切替 dans le panneau. L’aide de prise en main montre le réglage par domaine. Le guide PHP liste 8.4 et 8.5 lorsque Xアクセラレータ Ver.2 est actif. Relevez ce prérequis, puis confirmez le choix sur l’entrée de recette et lisez sa version via le web.

Le panneau Xserver documente l’authentification Basic par dossier. Le guide de sauvegarde Web annonce quatorze jours et mentionne sept jours sur certains anciens serveurs. L’extraction crée une copie dans userbackup. Le manuel indique une suppression après 24 heures et demande de vérifier l’espace disque avant l’extraction. Le panneau propose aussi une action séparée pour les données MySQL. Confirmez les points et la destination disponibles pour l’offre retenue. Ces procédures ne décrivent pas un bouton unique qui ramènerait à la fois PHP, les fichiers et la base à leur état précédent.

Comparer douze mois et la prochaine échéance

Sur douze mois, le barème WING Pack Basic publié pour la révision de juillet 2026 donne 13 068 JPY TTC, soit 1 089 JPY par mois en équivalent. Chez Xserver Standard, le tableau courant indique 1 100 JPY TTC par mois sur douze mois prépayés, soit 13 200 JPY TTC. Les deux montants sont des repères d’hébergement pour la durée complète. L’écart de 132 JPY est calculé hors domaine ou option payante, sans conversion de devise ni hypothèse de promotion.

La campagne ConoHa relevée se terminait le 5 novembre 2026 à 16 h, heure du Japon. Son prix d’appel de 659 JPY par mois concernait un contrat de trente-six mois. La campagne Xserver qui s’achevait le 4 novembre 2026 à 17 h, heure du Japon, concernait l’entrée en contrat. La réduction maximale annoncée dépendait de la durée. Les prix de ces campagnes ne sont pas retenus dans le calcul du 10 novembre. Vérifiez la disponibilité d’une promotion et le prix total sur la page de commande de la durée choisie.

Le WING Pack est prépayé et son renouvellement automatique est actif par défaut. La documentation indique une reconduction et un prélèvement trente jours avant la fin, lorsque ce réglage reste actif. Chez Xserver, le renouvellement automatique du serveur utilise la durée configurée et intervient entre le 20 et la fin du mois d’échéance. La procédure de paiement initial par carte active la reconduction pour la durée sélectionnée. Pour l’interrompre, le manuel demande de désactiver le réglage au plus tard le 19 du mois du prélèvement. Comparez le tarif normal de la durée retenue et vérifiez le montant et le calendrier propres au compte. Une option de domaine peut avoir des conditions distinctes.

Vérifier les accès et la langue avant le créneau de test

Les panneaux et les guides étudiés sont en japonais. ConoHa propose des guides WING et un formulaire d’assistance par produit. La grille mentionne le téléphone et le courriel. Xserver documente l’acceptation des demandes écrites en continu et le téléphone et le chat en semaine, avec des plages séparées. Faites confirmer la langue et le canal accessibles à l’équipe. La présence d’une rubrique d’assistance ne garantit pas une intervention pendant le créneau choisi.

Pour un essai chez le fournisseur, il faut pouvoir sélectionner les deux domaines, copier les fichiers, lire les paramètres de base et gérer la restriction d’accès. Les accès au panneau, à WordPress et au DNS éventuel peuvent relever de personnes différentes. Répartissez aussi la lecture des journaux. Si un autre environnement se trouve sur le même compte, identifiez-le avant de toucher à un réglage serveur ou à une tâche commune. Une copie sur ce compte n’est pas l’équivalent d’une séparation complète entre deux comptes.

Si une des deux branches PHP manque, vérifiez le réglage serveur ou demandez la configuration prise en charge pour le compte. Si la copie intégrée est indisponible, exigez une méthode que l’équipe peut rejouer et un export lisible. Une recette qui partage sa base avec la production, accepte des visiteurs anonymes ou continue à envoyer des notifications réelles ne remplit pas les conditions de cet essai. Corrigez ces écarts avant de modifier l’interpréteur.

Lire le résultat de l’exercice PHP et SQLite

Le ZIP lance réellement deux exécutables locaux, PHP 8.4.8 et PHP 8.5.12 pour la vérification de ce dossier. Deux fichiers SQLite temporaires portent des marqueurs différents. Une requête simulée sans autorisation est refusée. Lorsque la recette pointe par erreur vers le fichier de production, le script vérifie le marqueur de la base avant d’autoriser l’écriture. Une autre exécution écrit un témoin dans la bonne base et confirme que l’empreinte du fichier de production reste stable.

La version v2 du bloc fictif utilise `array_first()`, une fonction de PHP 8.5. Sous 8.4, le scénario échoue avant d’écrire le nouveau format. Sous 8.5, l’extension fictive convertit son libellé en options structurées et le bloc s’affiche avec le témoin. Remettre PHP 8.4 seul laisse un code qui appelle la fonction indisponible. Remettre également le code v1 laisse des données qu’il refuse de lire. Le scénario restaure alors la copie SQLite prise juste avant la conversion.

Les onze contrôles vérifient le retour du bloc et du témoin sous l’ancien moteur, ainsi que l’absence d’écriture dans la base de production. Le programme lance des processus CLI. L’autorisation et les codes 401, 409 et 500 sont modélisés. Les bases SQLite sont des témoins locaux. La maquette ne teste ni une installation WordPress ni les moteurs web des fournisseurs. Pour la rejouer, préparez les deux exécutables avec PDO SQLite. Les versions de correctif peuvent différer du résultat livré.

• Téléchargez le ZIP dans « Pour aller plus loin » et extrayez-le dans un dossier de test. Suivez la commande du fichier LISEZ-MOI avec deux exécutables PHP qui chargent PDO SQLite.
• Comparez les onze contrôles au fichier attendu.json. Les numéros de correctif peuvent différer. Vérifiez le refus d’écriture dans la mauvaise base et les trois états du retour, moteur seul, ancien code sans la base, puis état complet.

Tester le même parcours dans le navigateur chez l’hébergeur

Pour transposer l’exercice, relevez la version PHP via Santé du site ou un diagnostic minimal protégé. Faites la mesure sur les deux domaines avant et après le changement. Vérifiez aussi les redirections et l’URL finale, car le navigateur peut avoir quitté la recette sans que l’équipe s’en aperçoive. Comparez les journaux dans la même fenêtre et notez le fuseau utilisé. Un ancien résultat en cache peut masquer le moteur qui vient d’être sélectionné. Vérifiez une route dynamique avec un marqueur distinct.

Testez le bloc sur plusieurs contenus, dans l’éditeur et en lecture. Enregistrez une modification de recette puis relisez-la. Testez le rôle qui doit pouvoir éditer et un rôle qui ne le doit pas. Confirmez que les liens d’administration et les médias ne renvoient pas vers la production. Si un seul contenu échoue, relevez son réglage ou son ancien format et examinez les dépendances actives avant de conclure à une erreur du moteur.

Si le domaine de production change de version, si la copie écrit dans la mauvaise base, si une route privée répond sans autorisation ou si un journal montre une erreur bloquante, arrêtez le changement. Revenez d’abord au réglage et à la destination identifiés. Prenez un export de l’état obtenu avant d’enlever un code ou des données. L’isolement se démontre par le comportement avant et après, avec une trace que l’équipe peut relire.

Décider si le retour porte sur PHP, le code ou les données

Lorsque seul le moteur a changé, le retour peut se limiter à la branche précédente si elle figure encore dans le panneau. Vérifiez le bloc et les journaux après l’action. Si une extension ou le thème a été mis à jour, conservez les fichiers des deux versions. Cherchez ensuite si une migration de données a eu lieu. Un retour PHP suivi d’un retour des fichiers peut laisser le contenu incompatible. Dans ce cas, le point de base doit correspondre au code et à l’instant précédant la conversion.

Pour la recette, restaurez le périmètre nécessaire vers une destination contrôlée et vérifiez la lecture et l’écriture de nouveau. En production, un ancien export peut effacer des pages ou des réglages publiés après le point choisi. Identifiez ces écritures et leur traitement avant de restaurer. Une copie datée et indépendante permet d’inspecter le problème avant de décider d’un remplacement. Retirez les sondes et les comptes d’essai quand les contrôles sont clos.

ConoHa WING convient à une équipe qui peut préparer un domaine distinct et renseigner les accès de la base de copie dans son parcours intégré. Xserver Standard convient lorsque l’installation est éligible et que le panneau confirme le moteur pour le domaine de recette. Pour les deux offres, les éléments décisifs sont la branche disponible sur le compte, le résultat du témoin sans fuite d’écriture et la reprise du bloc après restauration.

Pour aller plus loin

• Consulter la fiche ConoHa WING
• Consulter la fiche Xserver
• Protéger les pages d’une préproduction WordPress
• Télécharger la maquette de changement PHP et de retour arrière (ZIP)