Bonjour,
Sur un spip 13033 avec php 5.0.4 et mysql 4.1.20-1.FC4.1
inscription2 derniere version
1 - Malgré qu’en config cfg je ne demande pas d’id_societe mais seulement societe, j’obtiens une erreur sql :
Oct 14 14:23:18 ip (pid 17252) Table ‹ basemachin.spip_societes › doesn’t exist -
SELECT *
FROM basemachin.spip_societes
LIMIT 1
Cette erreur etait présente en spip 128… mais avant de passer en 13033 j’ai fait un dump (super de pouvoir choisir les tables à sauvegarder d’ailleurs)
j’ai du cocher spip_societe qui m’était proposé bizarrement (?) Et cela a eu pour effet de la créé visiblement.
Donc en 13033 il ne peut plus me dire que la table n’existe pas mais le problème subsiste probablement.
2 - la page donnant la liste des abonnés ne fonctionne pas en cela qu’aucun adhérents n’y est présenté (le reste semble fonctionner intitulé du tableau et pagination)
3 - j’ai repéré deux fonctions au moins qui ne sont disponible que pour php 5.1 et 5.2 (d’après la doc php) :
cf formulaires/inscription2_pass.php et inscription2_ajax.php (et peut-être ailleurs)
extrait non exhaustif :
//genere le tableau des valeurs à mettre à jour pour spip_auteurs
//toutes les clefs qu’inscription2 peut mettre à jour
$clefs = array_fill_keys(array(‹ login ›,‹ nom ›,‹ email ›,‹ bio ›),’’);
//extrait uniquement les données qui ont été proposées à la modification
$val = array_intersect_key($valeurs,$clefs);
Ces fonctions pourraient-elles être émulées pour les versions antérieures de php ?
@+
pierre
argghh
Pour la gestion des societes, en 193/2 on a maintenant 2 cas
* le champ societe dans la table utilisateur qui doit s'activer par "societe"
* la table societe qui ajoute des options de coordonnées et qui doit
s'activer par "id_societe"
Toutefois en l'etat les 2 ne devraient pas etre incompatible.
Les test array_* sont là entre autre (en théorie) pour éviter que I2
se mélange les pinceaux.
Et ça va etre la merde si php4 gere pas les array_intersect 
En gros c'est pas une bonne nouvelle tout ça.
Le 30 oct. 08 à 11:18, cam.lafit@azerttyu.net a écrit :
argghh
Pour la gestion des societes, en 193/2 on a maintenant 2 cas
* le champ societe dans la table utilisateur qui doit s'activer par "societe"
* la table societe qui ajoute des options de coordonnées et qui doit
s'activer par "id_societe"
Toutefois en l'etat les 2 ne devraient pas etre incompatible.
mais pourquoi ne pas générer la table societe dès qu'un champs de config pro est demandé ?
Les test array_* sont là entre autre (en théorie) pour éviter que I2
se mélange les pinceaux.
Et ça va etre la merde si php4 gere pas les array_intersect 
en l'état, c'est toutes version de php inférieure à 5.2 qui est impactée
Ecrire une émulation de la fonction mais ne serait ce pas une solution ?
au moins en attendant que tout le monde bascule en php >= 5.2 ....
(En tout cas je suis dispo pour tester évidemment)
En gros c'est pas une bonne nouvelle tout ça.
oui bien d'accord en attendant inscription 2 n'est pas compatible avec php inférieur à 5.2
Ne faudrait-il pas le mentionner dans plugin.xml ?
ps : autre fichier à problème :
- légender auteur supp
- profil_adherent
S'lt
mais pourquoi ne pas générer la table societe dès qu'un champs de config pro
est demandé ?
Car le code d'origine calculait trop souvent les tables à créer. Donc
il est plus pertinent en l'etat de créer l'ensemble des tables à
l'installation et de n'utiliser que ce qui est necessaire. Il faut le
voir plus comme une mise en disponbilité, et c'est par CFG qu'on fait
son marché.
L'utilisation des array_intersect permet de faire la jonction entre ce
qui est demandé par CFG et ce que propose I2.
Ainsi on a un code générique qui permet à tout plugin d'etendre les
champs de I2 sans avoir à recoder le script de verification lors de la
sauvegarde d'un utilisateur. Il y avait trop de gestion de cas
particulier aussi sur les correspondance nom CFG, table.
Je pense que c'est sur ce dernier point que je n'ai pas été assez rigoureux.
Ecrire une émulation de la fonction mais ne serait ce pas une solution ?
au moins en attendant que tout le monde bascule en php >= 5.2 ....
Vais potasser la doc, vu que c'est moi qui ai foutu le bronx
(En tout cas je suis dispo pour tester évidemment)
Noté 
oui bien d'accord en attendant inscription 2 n'est pas compatible avec php
inférieur à 5.2
Ne faudrait-il pas le mentionner dans plugin.xml ?
Oui vas y,
car kent1 a aussi du php5.2 sous le coude.
ps : autre fichier à problème :
- légender auteur supp
- profil_adherent
Je crois que ceux là passeront mieux des que ça passera en squelette.
Le 30 oct. 08 à 13:18, cam.lafit@azerttyu.net a écrit :
S’lt
mais pourquoi ne pas générer la table societe dès qu’un champs de config pro
est demandé ?
Car le code d’origine calculait trop souvent les tables à créer. Donc
il est plus pertinent en l’etat de créer l’ensemble des tables à
l’installation et de n’utiliser que ce qui est necessaire. Il faut le
voir plus comme une mise en disponbilité, et c’est par CFG qu’on fait
son marché.
L’utilisation des array_intersect permet de faire la jonction entre ce
qui est demandé par CFG et ce que propose I2.
Ainsi on a un code générique qui permet à tout plugin d’etendre les
champs de I2 sans avoir à recoder le script de verification lors de la
sauvegarde d’un utilisateur. Il y avait trop de gestion de cas
particulier aussi sur les correspondance nom CFG, table.
Je pense que c’est sur ce dernier point que je n’ai pas été assez rigoureux.
Je ne suis pas certains que l’on se soit compris.
Dans mon cas la table société n’était pas créée (même si je le demande dans la config cfg, vérif faite avec phpmyadmin)
jusqu’à ce que je le demande implicitement lors d’une sauvegarde standard de spip
(dont le code a évolué récemment me semble t il).
La table apparaissait dans la liste des table à sauvegarder et j’ai demandé à la sauver dans le dump.
J’ai vérifié après cout avec myadmin qu’elle est bien été créé.
(c’est un peu paradoxal mais spip sauvegarde même ce qui n’existe pas ce qui m’a dépanné du coup)
Par ailleurs, la configuration des infos pros est pas vraiment compréhensible, en tout cas je n’ai absolument pas compris le message concernant le champs id qui fait référence à une liste mais sans fournir ni syntaxe ni exemple.
Ecrire une émulation de la fonction mais ne serait ce pas une solution ?
au moins en attendant que tout le monde bascule en php >= 5.2 …
Vais potasser la doc, vu que c’est moi qui ai foutu le bronx
(En tout cas je suis dispo pour tester évidemment)
Noté
oui bien d’accord en attendant inscription 2 n’est pas compatible avec php
inférieur à 5.2
Ne faudrait-il pas le mentionner dans plugin.xml ?
Oui vas y,
car kent1 a aussi du php5.2 sous le coude.
fait
ps : autre fichier à problème :
Je crois que ceux là passeront mieux des que ça passera en squelette.
S'lt
Je ne suis pas certains que l'on se soit compris.
Peut etre
Dans mon cas la table société n'était pas créée (même si je le demande dans
la config cfg, vérif faite avec phpmyadmin)
Normal CFG ne lance plus de création de de table ou de champ
jusqu'à ce que je le demande implicitement lors d'une sauvegarde standard de
spip
Hum tu es en train de dire que tu as reinjecté dans le meme spip un
dump ? Et qu'avant le dump la table societes n'existe pas et qu'apres
tu as bien cette table ?
Il doit avoir une mauvaise declaration de la base à l'installation du
plugin alors ?
(c'est un peu paradoxal mais spip sauvegarde même ce qui n'existe pas ce
qui m'a dépanné du coup)
Bizarre.
Par ailleurs, la configuration des infos pros est pas vraiment
compréhensible, en tout cas je n'ai absolument pas compris le message
concernant le champs id qui fait référence à une liste mais sans fournir ni
syntaxe ni exemple.
Si tu parles spécifiquement du champ société oui c'est brut de
fonderie. J'ai mis en place cette table dans l'urgence et je n'ai pas
eu ni le temps de mettre en place le squelette pour créer des
societes, ni de faire un nommage pertinent des informations.
Coté formulaire d'inscription c'est du coup juste une liste des noms
des societes et on sauvegarde dans les infos utilisateur l'id_societe
de la personne.
Le 30 oct. 08 à 21:42, cam.lafit@azerttyu.net a écrit :
S'lt
Je ne suis pas certains que l'on se soit compris.
Peut etre
Dans mon cas la table société n'était pas créée (même si je le demande dans
la config cfg, vérif faite avec phpmyadmin)
Normal CFG ne lance plus de création de de table ou de champ
jusqu'à ce que je le demande implicitement lors d'une sauvegarde standard de
spip
Hum tu es en train de dire que tu as reinjecté dans le meme spip un
dump ?
non j'ai juste généré le dump (pas de réinjection)
Et qu'avant le dump la table societes n'existe pas et qu'apres
tu as bien cette table ?
oui et sans réinjecter le dump,
Il doit avoir une mauvaise declaration de la base à l'installation du
plugin alors ?
oui ou une incompatibilité due aux versions php ou un bug spip ... ?
(c'est un peu paradoxal mais spip sauvegarde même ce qui n'existe pas ce
qui m'a dépanné du coup)
Bizarre.
Par ailleurs, la configuration des infos pros est pas vraiment
compréhensible, en tout cas je n'ai absolument pas compris le message
concernant le champs id qui fait référence à une liste mais sans fournir ni
syntaxe ni exemple.
Si tu parles spécifiquement du champ société oui c'est brut de
fonderie. J'ai mis en place cette table dans l'urgence et je n'ai pas
eu ni le temps de mettre en place le squelette pour créer des
societes, ni de faire un nommage pertinent des informations.
Coté formulaire d'inscription c'est du coup juste une liste des noms
des societes et on sauvegarde dans les infos utilisateur l'id_societe
de la personne.
S'lt
Le commit 23846 commence à resoudre le pb php4
Le 31 oct. 08 à 19:26, cam.lafit@azerttyu.net a écrit :
S'lt
Le commit 23846 commence à resoudre le pb php4
super je teste ce soir ou demain