Author: fil@rezo.net
Date: 2010-05-20 15:28:50 +0200 (Thu, 20 May 2010)
New Revision: 38291
Modified:
_plugins_/microblog/inc/microblog.php
Log:
mode TEST: des define() judicieux permettent d'invalider microblog et envois d'email ; exemple :
Je suis sûr qu'on est plutôt nombreux à gérer différents environnements (dev, test, pré prod, prod) pour nos SPIP, donc peut-être pourrait-il être intéressant de généraliser ce type de fonctionnement...
Je suis sûr qu'on est plutôt nombreux à gérer différents environnements (dev, test, pré prod, prod)
perso je suis un débutant, car les var_skel me suffisaient largement jusqu'ici
Tu veux dire un seul environnement technique, en prod donc, mais avec plusieurs dossiers de squelettes ?
Comment tu gères des modifs de plugins ou plusieurs versions de SPIP ?
pour nos SPIP, donc peut-être pourrait-il être intéressant de généraliser ce type de fonctionnement...
n'attends pas
Je pense qu'il faudrait trouver un moyen simple de dire dans l'interface de config, ou forcé via des constantes, dans quel environnement on est, et ensuite tout le monde (core, plugins) peut en profiter.
Par exemple, je n'ai pas toujours une connexion au web quand je suis en dev en local, donc j'utilise jQuery en local, alors que je pourrais vouloir utiliser le jQuery fourni par Google API quand je suis en prod, sans avoir de code à changer...
perso je suis un débutant, car les var_skel me suffisaient largement jusqu'ici
Tu veux dire un seul environnement technique, en prod donc, mais avec plusieurs dossiers de squelettes ?
oui
Comment tu gères des modifs de plugins ou plusieurs versions de SPIP ?
je suis prudent, j'éclate les problèmes, je teste d'abord sur des
sites de moindre importance, etc.
Je pense qu'il faudrait trouver un moyen simple de dire dans l'interface de config, ou forcé via des constantes, dans quel environnement on est, et ensuite tout le monde (core, plugins) peut en profiter.
oui ; cependant, définir l'environnement par un mot-clé "dev,
pré-prod, prod" ne suffit pas car il y a des spécificités selon ce que
tu veux tester/bloquer, qui ne sont pas les même d'un projet à
l'autre.
Par exemple, je n'ai pas toujours une connexion au web quand je suis en dev en local, donc j'utilise jQuery en local, alors que je pourrais vouloir utiliser le jQuery fourni par Google API quand je suis en prod, sans avoir de code à changer...
je n'aime pas google API car on est déjà suffisamment fliqué comme ça.
Mais sur le principe de ce genre de switch, je suis d'accord
perso je suis un débutant, car les var_skel me suffisaient largement jusqu'ici
Tu veux dire un seul environnement technique, en prod donc, mais avec plusieurs dossiers de squelettes ?
oui
Comment tu gères des modifs de plugins ou plusieurs versions de SPIP ?
je suis prudent, j'éclate les problèmes, je teste d'abord sur des
sites de moindre importance, etc.
Mais tu codes directement sur le serveur, ou tu as quand même une instance locale sur ton poste ?
Je pense qu'il faudrait trouver un moyen simple de dire dans l'interface de config, ou forcé via des constantes, dans quel environnement on est, et ensuite tout le monde (core, plugins) peut en profiter.
oui ; cependant, définir l'environnement par un mot-clé "dev,
pré-prod, prod" ne suffit pas car il y a des spécificités selon ce que
tu veux tester/bloquer, qui ne sont pas les même d'un projet à
l'autre.
Effectivement, donc il faut voir si on fait un truc générique où chacun peut définir ses environnements, et les règles/variables associées, ou si on doit quand même imposer quelques choix.
Par exemple, je n'ai pas toujours une connexion au web quand je suis en dev en local, donc j'utilise jQuery en local, alors que je pourrais vouloir utiliser le jQuery fourni par Google API quand je suis en prod, sans avoir de code à changer...
je n'aime pas google API car on est déjà suffisamment fliqué comme ça.
Moi, je n'aime pas (même si au départ ça me semblait intéressant) à cause des problèmes de performance, surtout, et parce que ça m'oblige à différencier mes environnements, justement.
Mais sur le principe de ce genre de switch, je suis d'accord
OK.
Donc on a besoin de pouvoir définir :
- des environnements : spip_envs (id_env, nom_env)
- des variables (des metas ?) dont la valeur change selon l'environnement, avec éventuellement une valeur par défaut : spip_env_vars (id_env_var, nom_var, par_defaut) et spip_env_valeurs (id_env, id_env_var, valeur)
Après :
- soit changer d'environnement fait que les balises prennent les bonnes valeurs dynamiquement,
- soit ce n'est qu'une surcharge du mécanisme de metas du core, qui fait qu'un changement d'environnement écrase juste les metas concernées
Mais tu codes directement sur le serveur, ou tu as quand même une instance locale sur ton poste ?
oui j'ai n sites en local sur mon ordi, avec MAMP
en bidouillant le /etc/hosts on peut même les faire marcher "comme en vrai".
Donc on a besoin de pouvoir définir :
- des environnements : spip_envs (id_env, nom_env)
- des variables (des metas ?) dont la valeur change selon l'environnement, avec éventuellement une valeur par défaut : spip_env_vars (id_env_var, nom_var, par_defaut) et spip_env_valeurs (id_env, id_env_var, valeur)
pour moi ça nse règle plutôt en php dans mes_options, avant même
d'installer le site le cas échéant, en recopiant par mysqldump un site
distant. Cf. l'exemple donné dans Connexion · GitLab pour les réglages
en fonction du serveur.
Par exemple, je n'ai pas toujours une connexion au web quand je suis en dev en local,
Et, tu me diras si je dis une connerie, mais avec des ip dynamiques genre no-ip.info ? Ça ne le fais pas ?
Je ne vois pas le rapport. Je parle de moments où je ne suis pas connecté à Internet, donc je n'ai que mon local, je n'aurais accès par aucun moyen à des ressources externes...
Donc on a besoin de pouvoir définir :
- des environnements : spip_envs (id_env, nom_env)
- des variables (des metas ?) dont la valeur change selon l'environnement, avec éventuellement une valeur par défaut : spip_env_vars (id_env_var, nom_var, par_defaut) et spip_env_valeurs (id_env, id_env_var, valeur)
pour moi ça nse règle plutôt en php dans mes_options, avant même
d'installer le site le cas échéant, en recopiant par mysqldump un site
distant. Cf. l'exemple donné dans Connexion · GitLab pour les réglages
en fonction du serveur.
Il faut dans ce cas proposer une liste de paramètres standards définissables dans un tableau dans mes_options.php, comme la configuration fine des URL propres...
