NPDS : Gestion de contenu et de communauté
Content & Community Management System (CCMS) robuste, sécurisé, complet, performant, parlant vraiment français, libre (Open-Source) et gratuit.
43 visiteur(s) et 0 membre(s) en ligne.
Autres infos
Activité du Site
Pages vues depuis 25/05/2001 : 108 399 061
- Nb. de membres 8 693
- Nb. d'articles 1 695
- Nb. de forums 26
- Nb. de sujets 8
- Nb. de critiques 92
Index du forum »» Version future »» [Résolu] - geoloc + user.php V16
[Résolu] - geoloc + user.php V16#26467
3Contributeur(s)
3 Modérateur(s)
Jireck
Hello,
Pour inserer dans le fichier user.php :
- Le module geoloc alors que c'est un module qui non necessaire au bon fonctionnement du core comme archives news ou autres...
c'est 100 lignes de plus et c'est non désactivable et cela va generer des erreurs si on utilize le champs C7.
Alors qu'une seule ligne du genre
et dans le fichier user-modules.php
tu fais les !include! qui vont bien pour les differents modules comme géoloc ou video_yt ou complement autres.
Pour inserer dans le fichier user.php :
- Le module geoloc alors que c'est un module qui non necessaire au bon fonctionnement du core comme archives news ou autres...
c'est 100 lignes de plus et c'est non désactivable et cela va generer des erreurs si on utilize le champs C7.
Alors qu'une seule ligne du genre
If (file_exist('modules/!include!/user-modules.php')){
!include! ('modules/!include!/user-modules.php');
}
et dans le fichier user-modules.php
tu fais les !include! qui vont bien pour les differents modules comme géoloc ou video_yt ou complement autres.
jpb
oui l'implémentation n'est pas encore parfaite mais l'idée principale c'est :
pour une V16 "neuve" pour un webmaster lambda
- que les données de géolocalisation lat long pour chaque utilisateurs soient dans les champs C7 et C8 (et donc que ces champs soient consacrés à ça uniquement) ...
- si elle sont renseigné par l'utilisateur la carte apparait sinon pas de carte ...
et bien sûr tu as raison il faudra réfléchir pour les cas ou sur des anciens site ces champs sont déjà utilisés
pour une V16 "neuve" pour un webmaster lambda
- que les données de géolocalisation lat long pour chaque utilisateurs soient dans les champs C7 et C8 (et donc que ces champs soient consacrés à ça uniquement) ...
- si elle sont renseigné par l'utilisateur la carte apparait sinon pas de carte ...
et bien sûr tu as raison il faudra réfléchir pour les cas ou sur des anciens site ces champs sont déjà utilisés
Jireck
J'utilise regulierement ces champs et cela pose probleme.
J'ai rien contre ce module mais je trouve que c'est de l'addon du module quoi et qu'il ne doit pas etre dans le core des fichiers npds.
Typiquement je trouve cela bien mais pas utile pour tous les sites donc....
Il vaut mieux alleger le core et mettre les modules a leur place en tant que module enlevable ou/et inserable.
Si tu estime que c'est vitale au niveau core il faut rajouter les champs dans user et non dans extends qui sont par definition des champs utilizable a volonté et non figé par le core.
de plus, je pense que 80% des membres d'un site ne se geolocalise pas a part les site qui y ont un interet.
Cela te laisse Deux choix :
1/ Suppression du core et mise en module complet plus developpement d'un enclipsable facilement
2/ passage des champs C7 C8 dans la table User
Je penche pour le deux qui si cela est bien fait peux apporter plein de possibilité de mettre des choses dans le profils user.
De plus si besoin je peux regarder.... si besoin ... le clipsable (user.php) et le module (clipsé) geoloc.
Voila
Maintenant fais comme tu pense, tout est dit / ecrit
J'ai rien contre ce module mais je trouve que c'est de l'addon du module quoi et qu'il ne doit pas etre dans le core des fichiers npds.
Typiquement je trouve cela bien mais pas utile pour tous les sites donc....
Il vaut mieux alleger le core et mettre les modules a leur place en tant que module enlevable ou/et inserable.
Si tu estime que c'est vitale au niveau core il faut rajouter les champs dans user et non dans extends qui sont par definition des champs utilizable a volonté et non figé par le core.
de plus, je pense que 80% des membres d'un site ne se geolocalise pas a part les site qui y ont un interet.
Cela te laisse Deux choix :
1/ Suppression du core et mise en module complet plus developpement d'un enclipsable facilement
2/ passage des champs C7 C8 dans la table User
Je penche pour le deux qui si cela est bien fait peux apporter plein de possibilité de mettre des choses dans le profils user.
De plus si besoin je peux regarder.... si besoin ... le clipsable (user.php) et le module (clipsé) geoloc.
Voila
Maintenant fais comme tu pense, tout est dit / ecrit
jpb
Citation : Jireck
J'utilise regulierement ces champs et cela pose probleme.
J'ai rien contre ce module mais je trouve que c'est de l'addon du module quoi et qu'il ne doit pas etre dans le core des fichiers npds.
Typiquement je trouve cela bien mais pas utile pour tous les sites donc....
Il vaut mieux alleger le core et mettre les modules a leur place en tant que module enlevable ou/et inserable.
Si tu estime que c'est vitale au niveau core il faut rajouter les champs dans user et non dans extends qui sont par definition des champs utilizable a volonté et non figé par le core.
==> oui tu as tout a fait raison !
(on dit pour la beta alors car ca fait beaucoup de boulot et y'en a plein qui vont nous maudire d'un nouveau changement de la table user ...)
de plus, je pense que 80% des membres d'un site ne se geolocalise pas a part les site qui y ont un interet.
Cela te laisse Deux choix :
1/ Suppression du core et mise en module complet plus developpement d'un enclipsable facilement
2/ passage des champs C7 C8 dans la table User
Je penche pour le deux qui si cela est bien fait peux apporter plein de possibilité de mettre des choses dans le profils user.
==> oui moi aussi ( il deviendrait lat long)
De plus si besoin je peux regarder.... si besoin ... le clipsable (user.php) et le module (clipsé) geoloc.
Voila
Maintenant fais comme tu pense, tout est dit / ecrit
J'utilise regulierement ces champs et cela pose probleme.
J'ai rien contre ce module mais je trouve que c'est de l'addon du module quoi et qu'il ne doit pas etre dans le core des fichiers npds.
Typiquement je trouve cela bien mais pas utile pour tous les sites donc....
Il vaut mieux alleger le core et mettre les modules a leur place en tant que module enlevable ou/et inserable.
Si tu estime que c'est vitale au niveau core il faut rajouter les champs dans user et non dans extends qui sont par definition des champs utilizable a volonté et non figé par le core.
==> oui tu as tout a fait raison !
(on dit pour la beta alors car ca fait beaucoup de boulot et y'en a plein qui vont nous maudire d'un nouveau changement de la table user ...)
de plus, je pense que 80% des membres d'un site ne se geolocalise pas a part les site qui y ont un interet.
Cela te laisse Deux choix :
1/ Suppression du core et mise en module complet plus developpement d'un enclipsable facilement
2/ passage des champs C7 C8 dans la table User
Je penche pour le deux qui si cela est bien fait peux apporter plein de possibilité de mettre des choses dans le profils user.
==> oui moi aussi ( il deviendrait lat long)
De plus si besoin je peux regarder.... si besoin ... le clipsable (user.php) et le module (clipsé) geoloc.
Voila
Maintenant fais comme tu pense, tout est dit / ecrit
j'aimerai avoir d'autres avis ....
Jireck
On s'est mal compris; je pense ... non j'ai mal écrit
Le mieux n’étant pas, justement, de modifier la table user, mais plutot de faire les action suivantes :
- modif user pour pouvoir enclipser des modules
- modif geoloc pour utiliser le champs qu'on souhaites dans la table extends
- modif geoloc pour pouvoir etre enclipser dans user.
Le mieux n’étant pas, justement, de modifier la table user, mais plutot de faire les action suivantes :
- modif user pour pouvoir enclipser des modules
- modif geoloc pour utiliser le champs qu'on souhaites dans la table extends
- modif geoloc pour pouvoir etre enclipser dans user.
jpb
je réfléchis .. j'aimerai bien avoir d'autres avis ...
- modif user pour pouvoir enclipser des modules => oui ... c'est déjà plus ou moins le cas non ? user-inc ?...
- modif geoloc pour utiliser le champs qu'on souhaites dans la table extends ==> c'était déjà le cas avant et
c'est la que je réfléchi pour moi ... les champs lat et long indissociable du user
- user name et pseudo avatar ....etc = QUI
- user lat long = OU
- modif geoloc pour pouvoir etre enclipser dans user. ==> OUI mais en fait dans user on a juste besoin d'une carte pas de tout geoloc .. juste son config ...
- modif user pour pouvoir enclipser des modules => oui ... c'est déjà plus ou moins le cas non ? user-inc ?...
- modif geoloc pour utiliser le champs qu'on souhaites dans la table extends ==> c'était déjà le cas avant et
c'est la que je réfléchi pour moi ... les champs lat et long indissociable du user
- user name et pseudo avatar ....etc = QUI
- user lat long = OU
- modif geoloc pour pouvoir etre enclipser dans user. ==> OUI mais en fait dans user on a juste besoin d'une carte pas de tout geoloc .. juste son config ...
Jireck
Citation : jpb
je réfléchis .. j'aimerai bien avoir d'autres avis ...
- modif user pour pouvoir enclipser des modules => oui ... c'est déjà plus ou moins le cas non ? user-inc ?...
Il me semble pas, je m'y plongerais d'ici peu ... mais non de principe
- modif geoloc pour utiliser le champs qu'on souhaites dans la table extends ==> c'était déjà le cas avant et
c'est la que je réfléchi pour moi ... les champs lat et long indissociable du user
- user name et pseudo avatar ....etc = QUI
- user lat long = OU
Que ce soit dans la table user ou extends c'est la meme chose puisque liaison.
Moi la difference que je vois c'est :
- Utilisation generaliste (user)
- Utilisation specifique (extends)
Moi, je n'utilise pas geoloc et bien d'autre je pense comme d'autre l'utilise mais c'est pas premier.
- modif geoloc pour pouvoir etre enclipser dans user. ==> OUI mais en fait dans user on a juste besoin d'une carte pas de tout geoloc .. juste son config ...
Ben justement si on peux gerer un menu module (partie variable d'un site), l'utilisateur pourrais mettre sa localization, des photos / des liens, derniere posts forum etc...
je réfléchis .. j'aimerai bien avoir d'autres avis ...
- modif user pour pouvoir enclipser des modules => oui ... c'est déjà plus ou moins le cas non ? user-inc ?...
Il me semble pas, je m'y plongerais d'ici peu ... mais non de principe
- modif geoloc pour utiliser le champs qu'on souhaites dans la table extends ==> c'était déjà le cas avant et
c'est la que je réfléchi pour moi ... les champs lat et long indissociable du user
- user name et pseudo avatar ....etc = QUI
- user lat long = OU
Que ce soit dans la table user ou extends c'est la meme chose puisque liaison.
Moi la difference que je vois c'est :
- Utilisation generaliste (user)
- Utilisation specifique (extends)
Moi, je n'utilise pas geoloc et bien d'autre je pense comme d'autre l'utilise mais c'est pas premier.
- modif geoloc pour pouvoir etre enclipser dans user. ==> OUI mais en fait dans user on a juste besoin d'une carte pas de tout geoloc .. juste son config ...
Ben justement si on peux gerer un menu module (partie variable d'un site), l'utilisateur pourrais mettre sa localization, des photos / des liens, derniere posts forum etc...
Jireck
Citation : jpb
je réfléchis .. j'aimerai bien avoir d'autres avis ...
je réfléchis .. j'aimerai bien avoir d'autres avis ...
Oki Je post pour relancer le sujet. c'est au niveau fonctionnel et non technique. a vos avis.
Je viens de reconsulté le user.php.
Et il n'y a pas de systeme de personnalisation de la vision user.php au niveau code.
Dans ce que je vois comme a peu pres ideal :
- Menu Add-on pour les modules clipsables.
- generation d'onglet (.nav-tabs)
- Generation des div des modules en rapport avec les onglets.
Jireck
Citation : Jireck
Dans ce que je vois comme a peu pres ideal :
- Menu Add-on pour les modules clipsables.
- generation d'onglet (.nav-tabs)
- Generation des div des modules en rapport avec les onglets.
Dans ce que je vois comme a peu pres ideal :
- Menu Add-on pour les modules clipsables.
- generation d'onglet (.nav-tabs)
- Generation des div des modules en rapport avec les onglets.
De plus c'est bien adapter avec la function nav de user.
C'est juste cette function a modifier
avec un (fait a la vole) :
$reqsql = sql_query select mname from module
while list sql_fetch_assoc $reqsql {
if file_exist (modules/$modulename/mod-user.php){
$onglet .=" $modulename";
$contenu.= !include! modules/$modulename/mod-user.php
}
C'est schematique
le mod-user.php de geloc contiendrait :
les form pour les 2 champs (edition).
Une carte si besoin, etc ...
jpb
oui la méthode est bonne pour une inclusion de module ..
notamment si on met une galerie ou autre ressource issue des modules...
c'est probablement la bonne solution ...
mais ca ne change pas mon avis pour les deux données de géolocalisation que j'aimerai bien laisser dans C7 C8 ...
notamment si on met une galerie ou autre ressource issue des modules...
c'est probablement la bonne solution ...
mais ca ne change pas mon avis pour les deux données de géolocalisation que j'aimerai bien laisser dans C7 C8 ...
Jireck
Si tu veux utiliser ses champs dans entends pas de soucis pour moi il faut juste que ce soit paramétrable afin qu'il ne rentre pas en conflit avec un autre module
jpb
oui ca c'était l'ancienne config de géoloc ou on pouvait choisir les champs qu'on voulait ...( donc pour des nouveaux site on peut dire que C7 et 8 serait les champs par defaut ?) et que si il sont occupé on en choist d'autres ? et si y'en a plus de dispo tant pis pas de géolocalisation de l'utilisateur ?
Jireck
Citation : jpb
bon on laisse ouvert car cela reste à corriger ....
bon on laisse ouvert car cela reste à corriger ....
Ou sinon tu le met sur GIT etcomme cela on peux le corriger en ligne