> Je suis en train d'essayer de lier SPIP avec un table 'utilisateur'
> pré-existante sur un site intranet.
>
> Données de pb : il existe un table avec : id, nom, login, mot de
> passe. J'ai donc créé une deuxième table avec les autres
> champs : nom_site, url_site, messagerie, etc...
Si tu as fait 2 tables, tu les lies par quoi tes 2 tables ?
Il y a évidemment un 'user_id' dans ma table 'spipuser' qui me
permet de faire la liaison entre ces deux tables 
Petit bémol il
faut par exemple 2 updates pour changer le login et le nom du
site de d'auteur.
> Et ensuite on rentre dans le code, et là qu'est-ce que je vois
> des $row[0] ou $row[8] : ce serait tellement plus lisible d'avoir
> $row['auteur_id'] ou $row['statut']. Surtout que j'ai lu je ne sais
> pas où que SELECT *, c'est pas ce qu'il y a de top
Il suffit à ce moment là d'utiliser mysql_fetch_array à la place de
mysql_fetch_row
C'est bien ce qu'il y a dans Spip. Donc j'en reviens à ma
question de base, est-ce qu'on pourrait changer mes
$row[NUMERO] en $row['NOM'] ?
Effectivement select * n'est pas ce qu'il ya de mieux, mais cela n'a
rien à voir avec le fait que tes $row comportent un chiffre ou quelque
chose de plus explicite. Tout dépend de la taille moyenne d'une ligne
des enregistrements retournés par ta requête ainsi que du nb
d'enregistrements que tu estime avoir en retour. Des fois, il est plus
pratique de tout faire en une fois (*), plutot que de multiplier les
requêtes juste pour récupérer à chaque fois une variable de plus. Après,
il suffit de bien déclarer sa variable pour que la portée puisse jouer
pour d'autres parties du script.
Sauf que dans notre cas, on récupère tout (15 variables) pour
ne sortir que 7 variables, dans 'auteurs.php' par exemple.
> De plus ça permettrait de n'avoir à changer que (sic) les
> requêtes SQL pour que le reste du site fonctionne avec une
> autre table d'utilisateur
Ce n'est pas forcement aussi simple que ça puisque les variables en plus
(ou en moins), il faudra bien les intégrer dans le script.
De plus si ta table (ou tes tables si elles sont liées) n'a (ont) pas
les mêmes noms de colonnes et le même ordre dans les colonnes, ça risque
de pas être triste
Je vous accorde que c'est au niveau des requêtes SQL que je
dois faire tout le boulot. Heureusement qu'il y a 'AS' qui me
permet de doner le nom que je veux à ma variable : en général,
ça donne :
$query = "SELECT user.id as id_auteur, ".
"user.username as login, ".
"user.name as nom, ".
"user.password as pass, ".
"user.email as email, ".
"spipuser.bio as bio, ".
"spipuser.nom_site as nom_site, ".
"spipuser.url_site as url_site, ".
"spipuser.statut as statut, ".
"spipuser.en_ligne as en_ligne, ".
"spipuser.messagerie as messagerie, ".
"spipuser.imessage as imessage, ".
"COUNT(spip_articles.id_article) as compteur".
Donc plus de soucis pour faire correspondre mes champs dans
la suite du code puisque tout le monde est indexé sur le nom et
pas sur un position dans la table !
En poussant un peu plus loin, la "persistence" de l'identification est
basée dans Spip et dans bcp d'autres applications Web sur les cookies
donc tu seras aussi obligés d'accorder le type de données inscrites dans
le cookie entre ton intranet et Spip.
Pour l'instant j'ai réussi à faire marcher sans les cookies (je ne
me suis pas encore plongé dans cette partie du code). Il faut
aussi que je trouve un truc pour transformer l'insciption
'intranet' vers un auteur 'Spip'. Mais chaque chose en son
temps
Perrick