Je me permets de poser cette question sur la Zone après l’avoir fait sur core.spip.org.
Sur l’un des clusters de serveurs d’hébergement PHP/MySQL de mon hébergeur, il y a un problème technique qui affecte les restaurations de sauvegardes de base de données.
Dans le même temps, sur un site SPIP 3, hébergé dans un sous répertoire de mon espace d’hébergement, les sauvegardes et restauration, depuis l’espace privé de SPIP, ne fonctionnent pas et lorsque je clique sur « sauvegarder la base », le message d’erreur « Impossible de faire une sauvegarde SQLite sur votre hébergement » s’affiche.
Est-ce le même problème ?
Remarque importante :
le site SPIP 3, hébergé à la racine de l’espace d’hébergement, n’est pas affecté par ce problème.
Quelles fonctions PHP/MySql sont mise en œuvre dans ce processus ?
Des précisions à ce sujet, transmises à mon hébergeur, permettraient de savoir si le problème technique sur le cluster de serveurs d’hébergement est en rapport avec le problème sous SPIP 3.
Tout d'abord tu as besoin que SQLite soit disponible sur ton
hébergement et que son support dans PHP soit activé. Mis à part cela,
faut voir si le répertoire des destination des sauvegardes (je ne sais
plus lequel) existe (sinon est-que SPIP peut le créer ?) et que
l'application a le droit d'y écrire.
Le problème est que, comme je l’indique dans mon message :
Remarque importante :
le site SPIP 3, hébergé à la racine de l’espace d’hébergement, n’est pas affecté par ce problème.
Donc, il y a 2 sites SPIP 3 sur le même espace d’hébergement et la même base de données (en utilisant un préfixe pour les tables de base de données pour le 2e site) :
Celui qui est dans le sous-répertoire « www » de la racine « / » de l’espace d’hébergement et lié au nom de domaine principal n’a aucun problème avec les sauvegardes et les restaurations des archives SQLight.
Celui qui pose problème est dans un 2e sous-répertoire de la racine « / » de l’espace d’hébergement et est lié à un sous-domaine du nom de domaine principal. Quant aux droits en écriture, ils sont les mêmes pour les 2 sites.
Tout d’abord tu as besoin que SQLite soit disponible sur ton
hébergement et que son support dans PHP soit activé. Mis à part cela,
faut voir si le répertoire des destination des sauvegardes (je ne sais
plus lequel) existe (sinon est-que SPIP peut le créer ?) et que
l’application a le droit d’y écrire.
Juste pour dire que j’ai eut des problèmes récurrent avec des préfixes personnalisés et les dumps sqlite depuis spip3 (il me manquait des tables ou elles étaient vides), du coup je passe par PhpMyAdmin ou une tache cron de mon hébergement.
Merci pour l’info:
Mais tout est OK sur un autre site, lui-même en sous-domaine et sous répertoire, chez le même hébergeur, mais sur un autre cluster de serveurs d’hébergement qui lui n’est pas affecté par le bug de sauvegarde et restauration signalé par ce même hébergeur.
Donc:
soit le bug signalé par l’hébergeur affecte spécifiquement les sites en sous répertoire et sous domaine,
soit le bug est un bug, spécifique à spip 3, engendré par un certain type de préfixe personnalisé:
→ le site qui est OK à comme préfixe « salon »
→ le site qui buggue à comme préfixe « one4all »
Est-ce la présence d’un chiffre dans le préfixe qui fait bugguer la sauvegarde de spip 3?
Je n’ai pas encore eu le temps de tester cette hypothèse.
Hervé LE DANTEC