trollix
Core Developer    Messages: 2732 Inscrit(e) le: 2003/1/14 Statut: Déconnecté(e)
|
Posté le 2006/5/27 à 09:47 |
Depuis longtemps j'y pensais. C'est fait. Un nouveau système de
plugins pour les blocs a vu le jour. Très simple, il permet
d'insérer des blocs dans le CMS sans toucher au noyau. Extensible
à l'infini, utilisant la structure des blocs de Ixprim (droits,
freeblocks, blocks classiques). A pré-tester dans la beta 2.
Ixprim 1.3 beta 2 sur sourceforge SVN.
- administration: ajout de sysinfo - infos système
- ajout d'un système de plugins (ou modules) pour les blocs. | HQCH - Hope Que ça Helpe
Celui qui vise à la perfection sera au-dessus de la
médiocrité, mais celui qui vise à la
médiocrité tombera plus bas encore. "Proverbe chinois" |
|
|
|
coach
Béta-testeur    Messages: 151 Inscrit(e) le: 2005/2/2 Statut: Déconnecté(e)
|
Posté le 2006/5/27 à 11:07 |
salut
je suis sans doute un peu bête mais je le trouve pas.
J'ai bien installé le bloc utilisateur mais je ne trouve rien dans
le systeme (dans l'interface)
Je présume qu'il faut les créer dans un certain repertoire,
mais lequel ?
ou alors cela se passe t-il directement en ligne avec un éditeur que
je ne trouve pas ?
PS : Mon code que tu as intégré a l'air de marcher
correctement |
|
trollix
Core Developer Messages: 2732 Inscrit(e) le: 2003/1/14 Statut: Déconnecté(e)
|
Posté le 2006/5/27 à 11:20 |
Ton bloc est dans ixp_blocks/blocks/ixpdownloads_topics.
Les fichiers nécessaires:
- ixp_blocks/blocks/conf/ixpdownloads_topics.modconf.php
- ixp_blocks/blocks/language/french/ixpdownloads_topics.lang.php
- ixp_blocks/blocks/ixpdownloads_topics/index.php (ton code)
Et c'est tout...
Ensuite, aller dans l'administration des blocs et afficher tous les
blocs. Les blocs Users devraient y apparaitre.
Pour terminer les activer et y mettre les droits, comme pout tout autre
bloc de Ixprim
Tu as un autre exemple dans le répertoire
ixp_blocks/blocks/rss_ajax.
| HQCH - Hope Que ça Helpe
Celui qui vise à la perfection sera au-dessus de la
médiocrité, mais celui qui vise à la
médiocrité tombera plus bas encore. "Proverbe
chinois" |
|
|
coach
Béta-testeur Messages: 151 Inscrit(e) le: 2005/2/2 Statut: Déconnecté(e)
|
Posté le 2006/5/27 à 13:50 |
donc il faut mettre le code dans le repertoire mod.
Ne serait-il pas plus judicieux de le mettre dans le repertoire du
thème. Aisni l'utilisateur n'aurait des modifs qu'à faire
dans ce repértoire.
De plus est-ce que les images qu'on met dans le repertoire du theme
prennent le dessus sur celles présentes dans le repertoire images
à la racine du site ?
Là ou je veux en venir : ne faudrait-il pas un créer un
repertoire pour l'utilisateur ou seraient regroupées toutes les
modifications qu'il a fait ou peut faire. Ainsi il ne toucherait pas au
reste des répertoires.
Dans ce repertoire on aurait :
- le theme
- les images
- les blocks
- et eventuellement des parties du code modifié qui prendrait le
dessus sur le code original si elles sont présentes et ont la
même construction en termes de repertoire
je ne sais pas si j'ai été clair |
|
coach
Béta-testeur Messages: 151 Inscrit(e) le: 2005/2/2 Statut: Déconnecté(e)
|
Posté le 2006/5/27 à 14:03 |
Sinon, un plus que j'ai réellement apprécié, c'est la
possibilité de rajouter des feuilles de style a charger dans chaque
layout : par exemple possibilité de rajouter dans l'entete de
layaout0 une feuille de style layout0.css.
Cela permet d'alléger les feuilles de styles, de ne charger que
celles qui sont nécessaires et de les organiser de façon
propre. |
|
pgilbert
Mod Developer    Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/5/31 à 18:47 |
trollix a
écrit:Depuis longtemps j'y pensais. C'est fait. Un
nouveau système de plugins pour les blocs a vu le jour. Très
simple, il permet d'insérer des blocs dans le CMS sans toucher au
noyau. Extensible à l'infini, utilisant la structure des blocs de
Ixprim (droits, freeblocks, blocks classiques). A pré-tester dans la
beta 2.
Je viens de regarder ça. Ca peut être pratique car ça
permet de créer et diffuser des blocks sans avoir à
créer un module (cf. les modules d'inconue_team par ex...). Mais
dans ce cas, je ne vois plus vraiment l'intéret des blocks
personnalisés (HTML, PHP & JavaScript). Ca fait double emploi
non ?
- administration: ajout de sysinfo - infos
système
Ca devrait pas être dans un module externe ce genre de chose ?
Parce qu'honnêtement je pense que les utilisateurs qui y trouverons
un intérêts sera limité.
[mode radin d'espace disque]
Surtout que ça bouffe presque 1mo de juste pour savoir si le serveur
de mon hébergeur n'est pas enrhumé. Bon OK, c'est rien 1mo
mais des petits Mo un peut partout ca fait lourd :-( Il a fallut tout
l'après-midi à ma connexion internet à pédale
pour monter tout ixprim b3 sur mon serveur 
[/mode radin d'espace disque] | | Out of iXprim project... |
|
|
trollix
Core Developer Messages: 2732 Inscrit(e) le: 2003/1/14 Statut: Déconnecté(e)
|
Posté le 2006/5/31 à 22:45 |
pgilbert a
écrit:Mais dans ce cas, je ne vois plus vraiment
l'intéret des blocks personnalisés (HTML, PHP &
JavaScript). Ca fait double emploi non ?
Oui et non. Disons non, dans la mesure ou pour mettre deux ou trois liens
pas besoin de developper des scripts de blocs en php. mais bon... C'est le
webmaster qui décide ce qui est le mieux. Ces userBlocs me sont
très utiles (pas ceux livrés comme exemple...) et j'ai
pensé qu'ils le seraient pour ixprim.
Pour l'anecdote un des deux blocs exmples (celui des downloads) m'avait
été proposépar coach, et tels quels ils ne me semblait
pas utile de les ajouter au noyau.
Comme ils étaient utiles pour lui et son thème, la solution
des usersBlocs semble s'imposer comme la meilleure. Plus de
flexibilité.
- administration: ajout de sysinfo - infos
système
Ca devrait pas être dans un module externe ce genre de chose ?
Peut-être oui, peut-être non...
Parce qu'honnêtement je pense que les utilisateurs
qui y trouverons un intérêts sera
limité. Intérêt
limité pour un hébergeur lambda, intérêt maximum
pour celui qui a un serveur dédié. (C'est mon cas uajourd'hui
et pour la majorité des sites gérés par ixprim en
intranet). Un coup d'oeil rapide sur la capacité du serveur est bien
utile dans certains cas. Comme c'est un module d'admin système, je
ne voyais pas de raisons de poluer encore la table de gestin des modules
avec un module 99% des cas utilisé par l'admin ou le webmaster.
je pense d'ailleurs faire passer phpMyadmin en module système.
Surtout que ça bouffe presque 1mo de juste pour
savoir si le serveur de mon hébergeur n'est pas enrhumé. Bon
OK, c'est rien 1mo mais des petits Mo un peut partout ca fait lourd :-( Il
a fallut tout l'après-midi à ma connexion internet à
pédale pour monter tout ixprim b3 sur mon serveur
Dasn révision 126, en supprimer certains fichiers inutiles, on passe
à 750ko
| HQCH - Hope Que ça Helpe
Celui qui vise à la perfection sera au-dessus de la
médiocrité, mais celui qui vise
à la
médiocrité tombera plus bas encore.
"Proverbe
chinois" |
|
|
pgilbert
Mod Developer Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/6/1 à 07:42 |
trollix a
écrit:je pense d'ailleurs faire passer phpMyadmin en
module système.
Oh non !!!! Pas phpMyAdmin !!!!
C'est exactement le module qui illustre bien ce que je disais hier. C'est
un module lourd (en poids) qui n'est utile qu'à certains et
justement si un utilisateur ne le veut pas, il doit pouvoir le
désactiver.
Personnellement, j'ai un hébergement mutualisé avec plusieurs
sites. J'ai sur cette hébergement une version de phpMyAdmin qui me
permet d'accéder à toutes mes bases. Je ne vois donc pas
l'intéret pour moi d'installer une deuxième version de
myAdmin pour chaque site sous iXprim. | | Out of iXprim project... |
|
|
trollix
Core Developer Messages: 2732 Inscrit(e) le: 2003/1/14 Statut: Déconnecté(e)
|
Posté le 2006/6/3 à 11:37 |
| Bien réfléchi, oui, pas phpMyAdmin. Je vais plutôt
plancher sur un module "admin_tools" activable ou pas comme module. | HQCH - Hope Que ça Helpe
Celui qui vise à la perfection sera au-dessus de la
médiocrité, mais celui qui vise
à la
médiocrité tombera plus bas
encore.
"Proverbe
chinois" |
|
|
pgilbert
Mod Developer Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/6/3 à 11:47 |
trollix a
écrit:Bien réfléchi, oui, pas
phpMyAdmin. Je vais plutôt plancher sur un module "admin_tools"
activable ou pas comme module.
Oui, ca c'est pas mal comme idée...
En fait l'idéal serait d'avoir un système de "plugins" pour
le module d'administration.
Ce qui permettrait d'ajouter ou d'enlever des fonctionalités.
Par exemple, si je n'ai pas besoin de faire des mises à jour par
SQL, je désactive cette partie t je peux la supprimer.
De cette manière, les modules comme bannières, statistiques,
phpmyadmin (et peut être d'autres) pourrait etre
intégrés à cette administration.
On pourrait alors se retrouver avec une administration hyper simple ou
hyper développée. | | Out of iXprim project... |
|
|
pgilbert
Mod Developer Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/6/3 à 16:26 |
trollix a
écrit:Depuis longtemps j'y pensais. C'est fait. Un
nouveau système de plugins pour les blocs a vu le jour. Très
simple, il permet d'insérer des blocs dans le CMS sans toucher au
noyau. Extensible à l'infini, utilisant la structure des blocs de
Ixprim (droits, freeblocks, blocks classiques). A pré-tester dans la
beta 2.
Avec ce nouveau système, et en considérant ma suggestion sur
la réorganisation de l'arborescence (cf. nettoyage de printemps), je pense qu'il faudrait
réfléchir dès maintenant à l'emplacement de
stockage de ces blocks personnalisés. Actuellement, il sont dans un
dossiers "blocks" dans le module qui les gère.
Personnellement, je ne suis pas pour placer des fichiers
personnalisés par l'utilisateurs dans des répertoires
provenant du moteur (kernel & modules). Je placerai donc ce
répertoire "blocks" dans databank.
À définir avant que la beta 1.3 passe en final à mon
avis... | | Out of iXprim project... |
|
|
© powered by Ixprim 1.3 rc1 | E-mail: trollix at trollix.com | Contact | Rapports de bug | Feed XML des News | Feed XML du Forum
