HostHere.lk au Sri Lanka, tarifs WordPress et contextes PHP

HostHere.lk en pratique

Présentation fondée sur les offres et la documentation vérifiées le 10 novembre 2026. Aucun test de charge ou de support n’a été réalisé pour ce dossier.

Les offres et leur coût

Les montants ci-dessous correspondent au marché et à la durée précisés pour chaque offre. Vérifiez le prix final, les taxes et les options avant de souscrire.

Langues et accompagnement

Site et documentation

Anglais dans la vitrine et les SLA consultés.

Interface de gestion

cPanel. Version et langues réellement disponibles à vérifier.

Assistance

Documentation anglaise. SLA d’assistance du lundi au samedi, 10 h–22 h SLT. Cinghalais et tamoul à confirmer.

HostHere.lk au Sri Lanka pour vérifier trois contextes PHP

HostHere.lk propose au Sri Lanka six formules Managed WordPress sur cPanel. La page annonce un espace de préproduction, des sauvegardes et des outils WordPress. La boutique fictive de Colombo veut mettre à jour une extension qui intervient lors de l’affichage des pages, d’un contrôle dans le terminal et d’un traitement planifié. Elle doit vérifier que ces trois voies utilisent un environnement PHP compatible. Une page d’accueil qui s’ouvre ne prouve pas que le traitement nocturne sait exécuter le même code.

La décision porte donc sur la mise à jour et sur les accès nécessaires pour la répéter. L’équipe peut avoir la main sur la version PHP d’un domaine sans disposer du même réglage pour le binaire du terminal ou pour une commande cron. Un autre cas existe si le site délègue les tâches à un appel Web au lieu d’exécuter directement PHP. La fiche sépare ces mécanismes avant de comparer les forfaits.

L’exercice compare des inventaires locaux fictifs. Aucun PHP distant, terminal du fournisseur ou site WordPress n’est ouvert. Les résultats servent à préparer une recette sur copie privée et à savoir quelle preuve chercher si une tâche ne s’exécute plus après une mise à jour.

Comparer les prix mensuels, la fiscalité et la sortie

La grille Managed WordPress affiche les montants mensuels en roupies sri-lankaises. Les fiches d’offres distinguent le prix mensuel publié et la projection obtenue en multipliant ce chiffre par douze. La projection sert à budgéter. Elle ne représente pas une offre annuelle publiée ni un prix garanti à l’échéance. Les conditions commerciales de reconduction, les frais éventuels d’ouverture et le prix d’un cycle annuel doivent être repris de la proposition correspondant au plan et à la région.

L’Inland Revenue Department publie un taux normal de TVA de 18 %. La grille HostHere.lk ne précise pas si les montants incluent cette taxe. Si 449 LKR sont hors taxe et que le taux normal s’applique, le total de référence est de 529,82 LKR par mois. Si les prix affichés incluent déjà la taxe, ce calcul ne s’applique pas. Faites confirmer le prix payé, la TVA et les éventuels frais de domaine ou de copie supplémentaire sur des lignes distinctes.

Le SLA général décrit des cycles de facturation et des règles de service. Le SLA WordPress précise que les sauvegardes peuvent être supprimées après suspension ou fin du service. Les pages actuelles de la gamme et de son SLA ne chiffrent pas de tarif de renouvellement distinct et ne fixent pas un préavis commercial de résiliation propre à ces six offres. Faites préciser le calendrier, le renouvellement et la date limite d’accès aux fichiers avant de retenir un cycle. Pour la boutique, gardez une copie utilisable ailleurs avant toute fermeture, même si le compte permet encore de télécharger un point à la date de l’essai.

Lire les ressources et choisir la région du site

Essential, Starter et Growth affichent les mêmes valeurs de CPU et de RAM mais des volumes de disque et de trafic différents. Business, Pro et Premium passent à quatre vCPU et 4 Go de RAM. Le SSD s’étend de 1 à 50 Go. Les plafonds détaillés d’inodes, de processus d’entrée ou d’I/O par formule ne sont pas chiffrés dans le tableau public consulté. Pour une boutique qui utilise l’administration, le terminal et une tâche planifiée, demandez quelles opérations sont autorisées, quelle version de PHP est accessible et si les limites sont partagées entre le site et sa copie. La vitesse annoncée d’un moteur de cache ne détermine pas le PHP utilisé par ces opérations.

La page cite l’Allemagne, la Finlande, les États-Unis et Singapour pour les six plans. Colombo sert de cadre à l’activité du client. La grille ne présente pas le Sri Lanka comme région de cette gamme. Vérifiez la région attribuée, la disponibilité du plan dans cette région et les lieux où les sauvegardes sont stockées. Si la boutique a des clients proches de Singapour, elle peut l’examiner comme région de production parmi celles annoncées. La mesure de ses parcours dynamiques et les conditions de traitement des données restent à vérifier séparément.

Avant de choisir un plan, comptez les fichiers du site, sa base, les données générées pendant une tâche et la taille d’une copie de travail. Les gros forfaits ont davantage de stockage, mais l’inclusion d’une sauvegarde standard suit son propre seuil de 7 Go dans le SLA. Ainsi, un site peut tenir sur l’offre Business à 10 Go tout en dépassant déjà le périmètre de sauvegarde standard. Ce seuil doit être comparé à l’espace réellement utilisé sur le compte, et pas seulement au volume des produits que l’équipe s’apprête à importer.

Délimiter WordPress, Extendify et les langues

La gamme utilise cPanel avec une interface orientée WordPress, AccelerateWP, Redis, la mise en cache NGINX et une option d’intégration Cloudflare. Elle annonce le clonage, la préproduction, les outils de transfert et l’accès administrateur WordPress. Les pages ne donnent pas la liste de toutes les versions PHP ni la disponibilité effective d’un terminal ou d’un cron pour chaque compte. Le contrôle proposé s’applique à une boutique qui peut vérifier ces contextes sur un environnement de test. Le SLA WordPress distingue l’administration du service et les éléments personnalisés du site. Gardez la responsabilité de la recette de l’extension et de ses tâches dans votre équipe.

La vitrine et les SLA consultés sont en anglais. Le panneau est cPanel. Les langues disponibles dépendent de l’installation et les sources ne garantissent pas l’assistance en cinghalais ou en tamoul. La page affiche une assistance WordPress permanente, tandis que le SLA général prévoit une plage garantie du lundi au samedi de 10 h à 22 h, heure du Sri Lanka. Le dimanche et les jours fériés suivent des modalités de meilleur effort. Pour une mise à jour tardive, fixez la plage où une réponse est couverte par le SLA et relevez le canal prévu, par exemple le ticket.

HostHere.lk annonce une création de site assistée par IA dans WordPress et des blocs Extendify. L’éditeur Extendify documente séparément le démarrage et les capacités de son agent. La grille ne précise ni crédits inclus, ni disponibilité de toutes les fonctions, ni conditions de traitement du brief pour chaque niveau. Pour une boutique existante, conservez une copie séparée avant d’essayer un modèle ou un bloc. Une page produite par cet outil doit être relue comme toute autre page. L’IA de création ne modifie pas les exigences de PHP de l’extension que l’équipe veut déployer.

Préparer les copies et isoler les tâches planifiées

Le SLA Managed WordPress décrit une sauvegarde incrémentale hebdomadaire par défaut, quatre générations et un périmètre inclus jusqu’à 7 Go par cycle. Lorsque l’espace utilisé dépasse ce seuil, la sauvegarde par défaut n’est plus disponible tant que l’usage ne revient pas dans le périmètre ou que la capacité n’est pas augmentée. La restauration ou le téléchargement peuvent passer par le panneau si la fonction est activée, ou par le support. L’assistance vise quatre heures ouvrées à partir de la confirmation, pendant la plage garantie et selon ses possibilités. Des frais peuvent s’appliquer après deux demandes de restauration sur le même cycle de facturation. Le SLA précise que cette copie est fournie à titre de service d’appoint et que sa disponibilité ou son intégrité ne sont pas garanties. Vérifiez la date du point visible et conservez votre propre copie des fichiers et de la base.

Préparez un point de retour qui indique la version de l’extension, ses réglages, la base et les fichiers. Une mise à jour peut changer les données, par exemple les champs enregistrés ou la structure utilisée par une tâche. Remettre l’ancien dossier de l’extension peut alors laisser la base dans le nouvel état. Décidez à l’avance si le retour implique une restauration cohérente et comment conserver les commandes ou formulaires reçus depuis la copie. Les achats et messages réels doivent rester hors de la répétition.

Distinguez les tâches déclenchées par une requête Web, celles déclenchées par WP-Cron et celles lancées par une commande PHP ou WP-CLI dans le planificateur. Un cron qui appelle une URL déclenche une exécution côté Web. Un cron qui lance directement un exécutable utilise le binaire et l’environnement de cette commande. Pour l’essai, neutralisez d’abord les tâches externes ou réelles sur la copie. N’activez ensuite qu’un seul déclencheur de test et inscrivez ce qu’il a exécuté. Gardez la sauvegarde hors du compte de préproduction si celle-ci doit survivre à une suppression de service.

Exercer le contrôle du PHP Web, du terminal et du cron

L’exercice teste séparément la version et les modules de PHP sur le Web, dans le terminal et dans le cron. — Illustration BlogPasCher.Ouvrir l’illustration en grand ↗

Dans le dossier extrait du ZIP, exécutez node EXERCICE-HOSTHERE-LK.cjs. Le programme utilise Node.js et le module d’assertions fourni. Il compare des versions et des listes de modules déclarées dans le script. Il ne démarre aucun binaire PHP et n’accède à aucun panneau. Le fichier RESULTAT-HOSTHERE-LK.json enregistre les trois jeux d’observations et le verdict par contexte. L’extension fictive demande PHP 8.2 ou supérieur ainsi que les modules intl et mysqli. Ces exigences sont propres à l’exercice.

Le premier jeu place le Web en PHP 8.2 avec les deux modules, le terminal en PHP 8.1 et le cron en PHP 8.2 sans intl. Le contrôle accepte le Web et identifie deux causes distinctes pour les autres contextes. Le deuxième jeu aligne le terminal. Il reste insuffisant, car le cron ne charge toujours pas intl. Le troisième jeu passe les trois contrôles. Les assertions vérifient que le rejet du premier jeu est attribué à la version pour le terminal et au module pour le cron.

Pour refaire le test, relevez d’abord les exigences publiées par l’éditeur de l’extension réelle. Si une version maximale ou une version corrective minimale compte, ajoutez-la explicitement au modèle. Prenez la liste des modules du même contexte que la version. Écrivez ensuite un cas où le Web fonctionne mais où un traitement planifié échoue. Le verdict doit rester bloquant tant que cette tâche fait partie du périmètre de mise à jour. Si votre boutique n’utilise pas de cron direct, adaptez la matrice au mode réel. Le résultat attendu est une décision expliquée par chaque parcours et son propre inventaire.

Rejouer le contrôle sur une copie WordPress

Sur la copie WordPress, ouvrez Outils, Santé du site, Informations et repérez la version de PHP et les informations serveur. Si le panneau propose MultiPHP Manager ou un sélecteur équivalent, relevez la version associée au domaine de test. Dans un terminal local disposant de PHP, php -v, php --ini et php -m donnent respectivement la version, la configuration chargée et les modules. Pour un traitement qui passe par WP-CLI, wp --info permet de voir le PHP associé à cette commande. Comparez ces relevés avant de changer un réglage. Pour retrouver les différences, lancez ces commandes dans le terminal de la copie et comparez le chemin PHP renvoyé par WP-CLI avec celui de la tâche planifiée.

Si la tâche planifiée lance PHP directement, relevez son chemin d’exécutable et ses arguments. Exécutez le contrôle avec le même binaire sur une copie locale. Pour une vérification planifiée dans un environnement privé, écrivez la sortie dans un journal privé puis retirez la tâche témoin. Évitez d’exposer les informations de configuration dans une page publique. Dans cPanel, Cron Jobs se trouve dans Advanced si l’hébergeur active la fonction. Sa documentation recommande le chemin absolu pour la commande. Si l’ordonnanceur déclenche une URL, vérifiez l’adresse et le domaine de la copie, puis observez le résultat dans les journaux WordPress plutôt que de supposer qu’il utilise le PHP du terminal.

Après la mise à jour de test, vérifiez un parcours Web qui utilise l’extension, lancez la vérification en terminal si elle est requise, puis attendez l’exécution du seul déclencheur d’essai. Relevez l’heure, le code de sortie ou l’état de la tâche et l’effet attendu sur un enregistrement de test. Une absence d’erreur n’a de valeur que si le résultat existe. Si une tâche échoue encore, revenez à la configuration précédente de la copie et conservez les deux relevés pour isoler la différence.

php -v
php --ini
php -m
wp --info

Décider avant d’activer la mise à jour

Pour la boutique, le feu vert doit tenir dans une fiche de recette avec une ligne par contexte. Indiquez l’exigence de l’extension, la valeur observée, le réglage ou le chemin utilisé, le résultat d’une exécution et l’identité de la copie. La version et les modules ont des rôles différents. Si le Web et le terminal sont compatibles mais que la tâche échoue, vérifiez d’abord le binaire et la configuration du déclencheur. Si les trois passent au niveau PHP mais que la tâche ne produit rien, contrôlez les données de test, le déclencheur et le résultat attendu avant de changer de plan.

Choisissez le forfait après avoir mesuré la place nécessaire pour la boutique et sa répétition. Un passage de Starter à Growth ajoute du SSD et du trafic mais conserve les mêmes valeurs de CPU et de mémoire. Il ne garantit ni un terminal actif, ni l’accès à une version de PHP particulière, ni des sauvegardes au-delà du seuil de 7 Go inclus. Si la préproduction et la production ne peuvent pas cohabiter avec leurs copies, utilisez un environnement distinct ou obtenez des conditions de sauvegarde supplémentaires compatibles avec le budget. Associez au devis la région, la configuration PHP, la date de reconduction et la procédure de récupération.

Si la mise à jour échoue sur copie, gardez la production au point précédent. Corrigez un seul paramètre à la fois, rejouez le contrôle et répétez la tâche avec les mêmes données. Si l’extension nécessite une configuration inaccessible dans le compte, comparez le coût d’une option adaptée avec celui d’un autre environnement avant d’engager la mise à jour. En production, un retour doit distinguer fichiers, base et éventuelles écritures récentes. Préparez une fenêtre dans laquelle quelqu’un peut confirmer la réussite ou interrompre l’opération.

Enfin, conservez les relevés hors du site, en supprimant les détails qui ne sont utiles qu’à l’exécution. Lors d’une mise à jour future, utilisez la même méthode pour vérifier si l’environnement a changé, puis remplacez les valeurs de l’extension par les exigences réellement publiées. La décision appartient à la boutique, avec un résultat observable pour chaque parcours retenu.

Pour préparer votre site

• 25 outils de sauvegarde WordPress selon le besoin de reprise
• WP-CLI échoue avec un autre PHP : corriger le contexte du terminal
• Tâches de fond WordPress en retard : diagnostiquer WP-Cron et Action Scheduler
• Télécharger l’exercice sur les contextes PHP