Re[3]: [spip-dev] Synchonisation de bases entre différentes mach?? = =?us-ascii?Q?=3D=3Fus-ascii=3FQ=3F=3D3Fiso-8859-1

Et:
inc-cache.php3 inc-debug.php3 inc-public.php3
inc-urls-html.php3
inc-calcul.php3 inc-formulaires.php3 inc-stats.php3
inc-urls-standard.php3
inc-calcul-squel.php3 inc-forum.php3 inc-urls-dist.php3
Je fais comment ?

Bin une simple copie. Je ne vois pas le problème ...

Je fais juste un cvs checkout

OK... Faudra que je fasse gaffe à ne pas écraser quelque chose,
genre inc_connect ou un truc du genre, je suppose...

Il n'est pas dans la distrib, puisqu'il est créé à l'install.

-Nicolas

Salut,

> Et:
> inc-cache.php3 inc-debug.php3 inc-public.php3
> inc-urls-html.php3
> inc-calcul.php3 inc-formulaires.php3 inc-stats.php3
> inc-urls-standard.php3
> inc-calcul-squel.php3 inc-forum.php3 inc-urls-dist.php3
> Je fais comment ?
Bin une simple copie. Je ne vois pas le problème ...

- C'est sous la meme racines que mes squelettes perso gerés sous CVS.
- C'est aussi geré par CVS
-> Ca fait conflit.

Si spip était bien séparé, je ferais un co de spip dans un coin,
et pour chaque site perso, je ferais juste un ln -s vers le répertoire
spip, maintenu à jour par CVS.
Architecture ideale(selon moi):

/ -> Racine du site
/spip -> Code de spip: read only, lien symbolique vers le CVS co.
/spipdata -> Cache, inc_connect et autres données que spip doit écrire

Le reste: mon site :slight_smile:

Avantages:
- spip peut etre installé en un point central et tenu à jour une fois pour
tous les sites, il suffit de faire un lien symbolique depuis ma racine de
travail.
- Les données spécifiques et changeantes ne sont pas sous l'arboresence
CVS de spip...
- Ni mon site.

Voilà.

Là, je dois tenir à jour le CVS et ai du écrire un script bidouille pour
recopier ensuite cela dans mon arborescence perso sans tout casser à
chaque fois (et ca se mélange allegrement).

Bref, pas top...

  Yannick

Yannick Patois wrote:

Le reste: mon site :slight_smile:

Avantages:
- spip peut etre installé en un point central et tenu à jour une fois pour
tous les sites, il suffit de faire un lien symbolique depuis ma racine de
travail.
- Les données spécifiques et changeantes ne sont pas sous l'arboresence
CVS de spip...
- Ni mon site.

Non, car :

- SPIP maintient les squelettes "par défaut" : article-dist.html, rubrique-dist.html,
etc
- tu maintiens tes propres squelettes, qui sont préférés par SPIP à la version "-dist" :
article.html, rubrique.html....

Le seul endroit où ça s'entrechoque, c'est les article.php3, rubrique.php3, et tutti
quanti. Mais ça n'influe que sur la durée de mise en cache, c'est assez limité....

Note :

> / -> Racine du site
> /spip -> Code de spip: read only, lien symbolique vers le CVS co.
> /spipdata -> Cache, inc_connect et autres données que spip doit écrire

Impossible car avec un "open_basedir" réglé à ".", le répertoire spip
ne pourrait pas accéder aux fichiers de spipdata.

@ Antoine Pitrou <antoine@rezo.net> :

Le seul endroit où ça s'entrechoque, c'est les article.php3, rubrique.php3,
et tutti
quanti. Mais ça n'influe que sur la durée de mise en cache, c'est assez
limité....

Non, il y a aussi spip_cookie.php3, inc-formulaires etc, qui peuvent changer
dans le cvs.

> / -> Racine du site
> /spip -> Code de spip: read only, lien symbolique vers le CVS co.
> /spipdata -> Cache, inc_connect et autres données que spip doit écrire

Impossible car avec un "open_basedir" réglé à ".", le répertoire spip
ne pourrait pas accéder aux fichiers de spipdata.

avec /spip/ et /spip/data/ ça pourrait marcher je pense. La seule raison
(historique) pour laquelle les images ne sont pas sous ecrire/ c'est
l'authentification par .htaccess, je pense.

Cela dit, modifier la structure de ces fichiers mettrait le bazar sur
l'ensemble des sites existants ;(

-- Fil

Fil wrote:

Non, il y a aussi spip_cookie.php3, inc-formulaires etc, qui peuvent changer
dans le cvs.

Et alors ? Ceux-là, tu n'y touches pas quand tu fais tes squelettes.

avec /spip/ et /spip/data/ ça pourrait marcher je pense. La seule raison
(historique) pour laquelle les images ne sont pas sous ecrire/ c'est
l'authentification par .htaccess, je pense.

inc_connect.php3 est obligé d'être sous ecrire/

Cela dit, modifier la structure de ces fichiers mettrait le bazar sur
l'ensemble des sites existants ;(

Oui.

Bon,

Je comprends qu'il n'y a pas de solutions... Snif.

Bonjour,

Je viens de faire une MAJ SPIP-v1-4d5 chez Ouvaton dont la version de GD ne
supporte pas la fonction ImageCreateFromGIF.

Le test des formats d'images (vignettes)
/spip_image.php3?test_formats=oui&redirect=config-contenu.php3
renvoie un Warning liée à GD.

Dans le fichier spip_image.php3 : ligne 22,
il manque un arobase comme suit :

$srcImage = @ImageCreateFromGIF("IMG/test.gif");

Sinon ok pour JPEG et PNG.

A+ °°)

Dom

modifier la structure de ces fichiers mettrait le bazar sur
l'ensemble des sites existants ;(

Donc ça ne pourra être envisagé que pour la version 2.x, avec le
passage à PHP4, ses sessions natives, PEAR DB et tout et tout ... :wink:

-Nicolas

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

> modifier la structure de ces fichiers mettrait le bazar sur
> l'ensemble des sites existants ;(

Donc ça ne pourra être envisagé que pour la version 2.x, avec le
passage à PHP4, ses sessions natives, PEAR DB et tout et tout ... :wink:

Pour installer spip façon Yannick, il y a aussi la solution très simple des
liens symboliques : il faut faire un lien symbolique sur chacun des fichiers
spip de la racine, et un sur ecrire/ et le tour est joué. Je ne suis pas sûr
qu'on chambarde tout juste pour ça.

Quant aux sessions natives php4, je n'en vois pas l'intérêt : les nôtres
sont mieux, non ?

-- Fil

Pour installer spip façon Yannick, il y a aussi la solution très
simple des liens symboliques

Très simple quand c'est possible, ce qui est le cas pour une infime
partie des utilisateurs de SPIP à priori. Mais c'est vrai que ceux-là
sont les seuls intéressés par ce type de mise à jour ... :wink:

Quant aux sessions natives php4, je n'en vois pas l'intérêt : les
nôtres sont mieux, non ?

Quelles "nôtres" ??? Je n'ai toujours pas vu de sessions dans SPIP au
sens des sessions applicatives ...

-Nicolas

Nicolas Hoizey wrote:

Quelles "nôtres" ??? Je n'ai toujours pas vu de sessions dans SPIP au
sens des sessions applicatives ...

Heu, tu veux dire avec passage de variables via la session ?
Ben, ça pourrait se faire mais il faut encore en définir l'utilisation
dans SPIP :wink: Vu que de toute façon, le parcours de navigation n'est
pas contraint par une suite d'actions (à part pour l'installation).

Pour les sessions PHP4, outre que c'est PHP4, j'ai l'impression qu'elles
ne sont pas forcément mises en place correctement chez tous les hébergeurs.
Maintenant qu'on a nos propres sessions (au moins pour l'auth), ce serait
un peu comme repasser sous .htaccess et se retaper les problèmes de
compatibilité subséquents, non ?

Propager les données de profil et de préférences de l'utilisateur, par
exemple ...

Là tu parles de l'espace public, non ? Je ne vois pas en quoi SPIP est
impliqué : tu gères des sessions dans tes squelettes si tu veux ?

Justement non, il n'y a pas de sessions, même pour l'auth, juste un
cookie. Une sorte de session au rabais en quelque sorte. :wink:

Non, nos sessions sont mieux que les sessions natives : sécurisées, php3.. :wink:

-- Fil

Nicolas Hoizey wrote:

Non, de l'espace privé, mais ce serait aussi utilisable dans l'espace
public quand l'authentification sera possible ...

Pour l'espace public, le problème c'est de savoir comment on
l'intègre dans le langage SPIP (à moins de laisser le webmestre
s'amuser en PHP).

Pour l'espace privé, il y a déjà les préférences stockées sous
MySQL. Il y a aussi la classe Link, enfin il y aurait si elle
était utilisée.

Tiens, au fait, encore un trou PHP.
http://linuxfr.org/2002/07/22/9044,0,1,0,0.php3

Non, de l'espace privé, mais ce serait aussi utilisable dans
l'espace public quand l'authentification sera possible ...

En fait, il y aurait peut-être des utilisations possibles même quand
il n'y a pas d'auth, j'ai été un peu vite.

Pour l'espace public, le problème c'est de savoir comment on
l'intègre dans le langage SPIP (à moins de laisser le webmestre
s'amuser en PHP).

Soit PHP est configuré pour lancer et propager automatiquement la
session, auquel cas il n'y a rien à faire ...

Soit les cookies sont actifs, auquel cas il n'y a pas grand chose à
faire.

Soit aucun des deux, et il faut propager la session "à la main", en
mettant l'ID de session dans les URL générées. Et là, vive la classe
Link, et la génération auto des liens internes.

Pour l'espace privé, il y a déjà les préférences stockées sous
MySQL.

Il faut donc refaire une connexion à la base et une requête à chaque
fois qu'on veut les récupérer, c'est à dire à chaque page. Avec les
sessions, on a éventuellement aussi cela si on les stocke en base de
données, mais on se simplifie grandement la tache.

Tiens, au fait, encore un trou PHP.
http://linuxfr.org/2002/07/22/9044,0,1,0,0.php3

Oui, et donc une version 4.2.2 sans le trou, vive la réactivité de la
communauté ... :wink:

-Nicolas

Soit aucun des deux, et il faut propager la session "à la main", en
mettant l'ID de session dans les URL générées. Et là, vive la classe
Link, et la génération auto des liens internes.

Oui mais ça limite à l'utilisation des #URL_*. Si tu fais tes
propres liens (c'est obligatoire si tu t'écartes un tout petit
peu de la structure standard), alors tes liens ne seront plus
concernés car en dur dans le squelette.

D'autre part je parlais de l'exploitation des sessions dans les
squelettes SPIP. C-à-d : tu as tes sessions dans l'espace public,
mais comment les exploites-tu simplement sans faire de PHP dans
les squelettes ?

Pour l'espace privé, il y a déjà les préférences stockées sous
MySQL.

Il faut donc refaire une connexion à la base et une requête à chaque
fois qu'on veut les récupérer, c'est à dire à chaque page.

Oui mais on parle de l'espace privé, c'est déjà le cas :wink:

Oui mais ça limite à l'utilisation des #URL_*. Si tu fais tes
propres liens (c'est obligatoire si tu t'écartes un tout petit peu
de la structure standard), alors tes liens ne seront plus concernés
car en dur dans le squelette.

Soit on se prend la tête à chercher tous les liens dans les
squelettes, et on ajoute l'ID de session, soit on met à disposition un
tag (#SESSID par exemple) qui le fait.

D'autre part je parlais de l'exploitation des sessions dans les
squelettes SPIP. C-à-d : tu as tes sessions dans l'espace public,
mais comment les exploites-tu simplement sans faire de PHP dans les
squelettes ?

Je pense plus à l'exploitation des sessions par SPIP lui-même que par
l'utilisateur. Mais cela n'empêche pas d'utiliser les fonctions de
sessions dans le code PHP, puisque SPIP prend justement en charge leur
lancement et propagation ...

Il faut donc refaire une connexion à la base et une requête à
chaque fois qu'on veut les récupérer, c'est à dire à chaque page.

Oui mais on parle de l'espace privé, c'est déjà le cas :wink:

Oui, mais ça pourrait être simplifié ou allégé.

-Nicolas

(espace public)

Je pense plus à l'exploitation des sessions par SPIP lui-même que par
l'utilisateur.

A quel usage penses-tu ?

(espace privé)

Oui, mais ça pourrait être simplifié ou allégé.

Je n'ai pas trop regardé comment c'était fait, dans les dernières versions...

(espace public)

Je pense plus à l'exploitation des sessions par SPIP lui-même que
par l'utilisateur.

A quel usage penses-tu ?

J'y réfléchis, justement ... :wink:

Il y a la propagation des infos de connexion et du profil, le caddie
dont nous avons déjà discuté il y a peu, ...

(espace privé)

Oui, mais ça pourrait être simplifié ou allégé.

Je n'ai pas trop regardé comment c'était fait, dans les dernières
versions...

De PHP ou de SPIP ?

-Nicolas

Nicolas Hoizey wrote:

(espace public)

Je pense plus à l'exploitation des sessions par SPIP lui-même que
par l'utilisateur.

A quel usage penses-tu ?

J'y réfléchis, justement ... :wink:

Il y a la propagation des infos de connexion et du profil,

C'est déjà là (mis à part l'id_session).

> le caddie

dont nous avons déjà discuté il y a peu, ...

Oui mais là il faut trouver un moyen de présenter cette
fonctionnalité de façon générique, utile, et accessible à tous.

(espace privé)

Oui, mais ça pourrait être simplifié ou allégé.

Je n'ai pas trop regardé comment c'était fait, dans les dernières
versions...

De PHP ou de SPIP ?

De SPIP.

Il y a la propagation des infos de connexion et du profil,

C'est déjà là (mis à part l'id_session).

OK, mauvais exemple.

le caddie dont nous avons déjà discuté il y a peu, ...

Oui mais là il faut trouver un moyen de présenter cette
fonctionnalité de façon générique, utile, et accessible à tous.

En effet.

Je n'ai pas trop regardé comment c'était fait, dans les dernières
versions...

De PHP ou de SPIP ?

De SPIP.

Alors moi non plus, pas trop le temps malheureusement, j'ai du mal à
suivre tout ce qui s'est passé sur l'authentification balaise (trop ?)
que vous avez créée.

-Nicolas