Dans le but de constituer une version de test et de développement de mon site, je souhaite installer spip en local. Mais comme j’ai besoin des tables existantes pour effectuer mes tests, je me disais qu’il serait fort pratique de paramétrer mon spip local pour qu’il utilise les tables distantes déjà en ligne. En lecture seule pour que ce soit parfait…
J’ai vu cette page Les bases de données en SPIP qui me semble fort intéressante, mais j’ai pas tout saisi sauf que cela a l’air possible, et même prévu !
Sauriez vous m’expliquer brièvement comment le mettre en pratique, et éventuellement qu’elles sont les erreurs de manip à éviter ?
Dans le but de constituer une version de test et de développement de mon site, je souhaite installer spip en local. Mais comme j’ai besoin des tables existantes pour effectuer mes tests, je me disais qu’il serait fort pratique de paramétrer mon spip local pour qu’il utilise les tables distantes déjà en ligne. En lecture seule pour que ce soit parfait…
J’ai vu cette page Les bases de données en SPIP qui me semble fort intéressante, mais j’ai pas tout saisi sauf que cela a l’air possible, et même prévu !
Sauriez vous m’expliquer brièvement comment le mettre en pratique, et éventuellement qu’elles sont les erreurs de manip à éviter ?
Le fichier de connexion ? Je n’en ai jamais entendu parler… Peux-tu être plus précis s’il te plaît ? Qu’elle en est la fonction ? Que dois-je en faire ?
Je n’ai sinon pas bien saisi ton avertissement, cela signifie t’il que je ne suis pas en mode « test », que mes tables ne sont pas en lecture seule ?
Merci infiniment en tout cas pour ton début de réponse.
Paul a écrit :
Il te suffit d’utiliser en local le fichier de connexion que tu as en distant.
Attention pas contre avec des tests dans ces conditions !
Dans le but de constituer une version de test et de développement de mon site, je souhaite installer spip en local. Mais comme j’ai besoin des tables existantes pour effectuer mes tests, je me disais qu’il serait fort pratique de paramétrer mon spip local pour qu’il utilise les tables distantes déjà en ligne. En lecture seule pour que ce soit parfait…
J’ai vu cette page Les bases de données en SPIP qui me semble fort intéressante, mais j’ai pas tout saisi sauf que cela a l’air possible, et même prévu !
Sauriez vous m’expliquer brièvement comment le mettre en pratique, et éventuellement qu’elles sont les erreurs de manip à éviter ?
Le fichier de connexion ? Je n'en ai jamais entendu parler...
config/connect.php
Peux-tu être plus précis s'il te plaît ? Qu'elle en est la fonction ?
Stocker les informations de connexions à la base de données ? Avec le mot de passe qui permet d'écrire dedans et tout...
Que dois-je en faire ? Je n'ai sinon pas bien saisi ton
avertissement, cela signifie t'il que je ne suis pas en mode "test",
Oui (cela signifie que tu *n*'es *pas* en mode "test"). Tu te connectes avec tous les droits.
que mes tables ne sont pas en lecture seule ?
Pour tester tranquillement: exporter la base (phpmyadmin fait ça très bien), la réimporter en local, installer spip et déclarer la table ; plutôt simple à faire, que des clics. Pour tester sur la base distante (drôle d'idée) : créer sur la base distante un utilisateur qui n'a que des droits en lecture, et modifier config/connect.php en conséquence, ou l'effacer et repasser par /ecrire pour le renseigner (mais bon, il me semble que cela serait une très mauvaise idée ; comme ça , intuitivement).
Cela dit: *ne pas* faire de tests sur un site *en production*.
Les tests, il faut les faire *en local*.
J'oubliais: *ne pas faire de tests sur un site en production*.
Bonsoir, importer la base en production vers le site local ok ! mais la question que je me pose, dans la base via phpmyadmin faut pas y modifier l'url du site ? la passer en http://127.0.0.1/ ?
fremoin a écrit :
Bonsoir,
Jonathan Chibois a écrit :
Le fichier de connexion ? Je n'en ai jamais entendu parler...
config/connect.php
Peux-tu être plus précis s'il te plaît ? Qu'elle en est la fonction ?
Stocker les informations de connexions à la base de données ? Avec le mot de passe qui permet d'écrire dedans et tout...
Que dois-je en faire ? Je n'ai sinon pas bien saisi ton
avertissement, cela signifie t'il que je ne suis pas en mode "test",
Oui (cela signifie que tu *n*'es *pas* en mode "test"). Tu te connectes avec tous les droits.
que mes tables ne sont pas en lecture seule ?
Pour tester tranquillement: exporter la base (phpmyadmin fait ça très bien), la réimporter en local, installer spip et déclarer la table ; plutôt simple à faire, que des clics. Pour tester sur la base distante (drôle d'idée) : créer sur la base distante un utilisateur qui n'a que des droits en lecture, et modifier config/connect.php en conséquence, ou l'effacer et repasser par /ecrire pour le renseigner (mais bon, il me semble que cela serait une très mauvaise idée ; comme ça , intuitivement).
Cela dit: *ne pas* faire de tests sur un site *en production*.
Les tests, il faut les faire *en local*.
J'oubliais: *ne pas faire de tests sur un site en production*.
--
hth
FM
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Cela dit: *ne pas* faire de tests sur un site *en production*.
Les tests, il faut les faire *en local*.
J'oubliais: *ne pas faire de tests sur un site en production*.
--
hth
FM
Exactement !
en plus, il n est pas certain du tout que ton hebergement de production accepte que tu te connectes depuis un spip local sur le serveur mysql distant (perso, faut que je signe une décharge de responsabilite pour obtenir ca, mais bien sur, je ne le fais pas)
triton
Merci fremoin ! Je crois que le message est passé
Il n'y a donc pas d'autre solution pour tester en toute sécurité que d'exporter la base puis de la réimporter. Tant pis, je n'ai plus qu'à mettre ma flemmardise au placard. J'ai compris : on ne développe et on ne teste qu'en local.
Ceci dit, je trouve assez fort cette histoire de fichier de connexion. Il suffirait de l'utiliser en local ce fichier là, et hop on a accès à la base distante ? Pas besoin de paramêtres à entrer manuellement dans un obscur fichier de conf ?
fremoin a écrit :
Bonsoir,
Jonathan Chibois a écrit :
Le fichier de connexion ? Je n'en ai jamais entendu parler...
config/connect.php
Peux-tu être plus précis s'il te plaît ? Qu'elle en est la fonction ?
Stocker les informations de connexions à la base de données ? Avec le mot de passe qui permet d'écrire dedans et tout...
Que dois-je en faire ? Je n'ai sinon pas bien saisi ton
avertissement, cela signifie t'il que je ne suis pas en mode "test",
Oui (cela signifie que tu *n*'es *pas* en mode "test"). Tu te connectes avec tous les droits.
que mes tables ne sont pas en lecture seule ?
Pour tester tranquillement: exporter la base (phpmyadmin fait ça très bien), la réimporter en local, installer spip et déclarer la table ; plutôt simple à faire, que des clics. Pour tester sur la base distante (drôle d'idée) : créer sur la base distante un utilisateur qui n'a que des droits en lecture, et modifier config/connect.php en conséquence, ou l'effacer et repasser par /ecrire pour le renseigner (mais bon, il me semble que cela serait une très mauvaise idée ; comme ça , intuitivement).
Cela dit: *ne pas* faire de tests sur un site *en production*.
Les tests, il faut les faire *en local*.
J'oubliais: *ne pas faire de tests sur un site en production*.
Il n'y a donc pas d'autre solution pour tester en toute sécurité que d'exporter la base puis de la réimporter. Tant pis, je n'ai plus qu'à mettre ma flemmardise au placard. J'ai compris : on ne développe et on ne teste qu'en local.
Franchement en tant que flemmard professionnel, je fainéantise beaucoup plus sereinement en sachant que je ne vais pas effacer la base en prod -mes potes pros m'ont toujours dit que delete/insert est beaucoup plus rapide que update- sous prétexte que j'ai encore tout cassé.
Ceci dit, je trouve assez fort cette histoire de fichier de connexion. Il suffirait de l'utiliser en local ce fichier là, et hop on a accès à la base distante ? Pas besoin de paramêtres à entrer manuellement dans un obscur fichier de conf ?
J'imagine ; jamais eu l'idée d'essayer ; déjà frémi avec une plante mysql sur le serveur de prod ? déjà goûté, pas aimé ; du tout du tout.
Quand au côté obscur, le fichier est tout simple...
--
hth
Frédéric
n’y a donc pas d’autre solution pour tester en toute sécurité que d’exporter la base puis de la réimporter. Tant pis, je n’ai plus qu’à mettre ma flemmardise au placard. J’ai compris : on ne développe et on ne teste qu’en local.
Ceci dit, je trouve assez fort cette histoire de fichier de connexion. Il suffirait de l’utiliser en local ce fichier là, et hop on a accès à la base distante ? Pas besoin de paramêtres à entrer manuellement dans un obscur fichier de conf ?
non, en effet
je l’ai même déjà fait… mais bon c’est pas pratique et dangereux !
Merci fremoin ! Je crois que le message est passé
Il n'y a donc pas d'autre solution pour tester en toute sécurité que d'exporter la base puis de la réimporter. Tant pis, je n'ai plus qu'à mettre ma flemmardise au placard. J'ai compris : on ne développe et on ne teste qu'en local.
Ceci dit, je trouve assez fort cette histoire de fichier de connexion. Il suffirait de l'utiliser en local ce fichier là, et hop on a accès à la base distante ? Pas besoin de paramêtres à entrer manuellement dans un obscur fichier de conf ?
Bonjour,
sinon pour les cossards y a moyen de faire une sauvegarde distante et restauration locale automatiquement avec un petit bout de bash en ssh (on peut meme le lancer directement depuis eclipse, mais la, faut vraiment pas avoir peur de revendiquer sa haute flemme)
Je peux refiler le bout de code si besoin
triton
