Citation :

Pourquoi utiliser une gestion des hacks alors que ce ne sont que des améliorations de modules ou du noyau ? Une mise à jour ne serait elle pas plus simple à gérer ; que ce soit côté utilisateur, administrateur ou développeur ?

Je pense qu'une telle gestion peut etre pratique le temps de voir arriver la mise à jour, combien de hack ne seront pas intégrer dans le core? Je parle en therme de gestion de hack, e fait de pouvoir ajouter de fonctionnalités sans pour autant remplacer une procédure du core
Réalisable ou pas, je me dis que cela pourrait etre utile

Entièrement d'accord avec MusS,

Mais ça risque d'être difficile à gérer. Notamment si tu as plusieurs hack pour une même portion de code....

moi, personnellement tous ces petits trucs en plus, ça m'embrouille, sur joomla il y les modules et des mambots et dejà ça se complique. En plus la structure des thèmes me paraissent pas simple, c'est très difficile de changer un thème, il y a trop choses imbriquées,
par contre, sur xoops entre les modules et les blocs c'est beaucoup plus simple ,( pour un débutant ou une personne qui désire un produit simple d'accès)

La gestion des group et user de xoops permet de faire un compte a tes clients qui ne verait pas forcement ces parties techniques qui sont dans l'admin.
Il faut attirer les noobs mais il faut aussi attire les developpeurs qui veulent un outil puissant et customisable (pour le vendre au client;) )

Je croix qu'il serait bon d'inclure directement dans le core des modules tel que :
-Protector
-waiting
-multiMenu, ou toutes autres solutions pour fabriquer ses menus, et ce de manière dynamique, ou comme dans certain thème Morpho.
-mpmanager, déja cité
-xplorer
-marquee
-XOOP DB backup & restore ou équivalent.
-xoopsinfo
-avaman
-xoopscare
-myReferer
-sitemap
-blocksadmin
-le hack de Dugris.
-les améliorations d'Hervé
-Du café pour nos longues nuits de configurations et un cendrier pour le plus grand bonheur de mon clavier.
-A noter que certain de ces modules seront regroupé dans ce projet.
-Que le thème morpho soit celui par défaut de xoops, je croix que c'était prévu. Comprenant donc des menus dynamiques, la gestion du "web 2.0" et tous les avantages prévus dans cet excellent boulot.

Oui et non,

C'est claire que pour celui qui veut tester, s'amuser ou qui a besoin de tout ça, oui

par contre pour celui qui veut faire un site de 3 pages, ça alourdit considérablement son package.

Qui dit poids, dit temps de chargement bien que maintenant le 56k est plus ou moins fini.

L'autre problème, c'est la gestion des mise à jour de chaque module, s'il faut à chaque fois devois resortir une version de l'ensemble pour un changement, ça devient aussi difficile à gérer.

Par contre et comme c'est le ca maintenant, inclure le strict nécessaire, point de sécurité oui comme Protector et j'ajouterais même Xoopsinfo.

Pour le reste, il me semble qu'une solution serait de créer, avec lesmodules, des packages thématiques ou autres, par exemple.

démarrer sur xoops sans aucun module de base est assez pertubant pour un débutant,à mon sens il faudrait au minimum un module d'article (non non j'ai pas dit news ) mais il faudrait aussi une aide intégrée des fonctions de base de xoops (qu'est ce que j'ai dans le pack, comment j'installe un module , comment j'administre le tout etc...) sans forcément rentrer dans le détail de tout mais il ne faut pas oublier que si l'apprentissage de xoops est simple quand on en a compris la logique beaucoup sont des débutants complets (je le fut avant d'arriver ici)
Je me souviens que solo avait fait un truc sympa il y a quelques temps dans cette idée là , une fois qu'on l'avait lu on savait les bases de xoops .
Ensuite lorsqu'on arrive sur l'administration les choses ne sont pas claires pour tous, les débutants que j'ai mis sur l'administration du site n'ont pas eu intuitivement les clés d'accès .
L'aide pourrait être un fichier accessible par des liens à partir des différentes partie de l'admin, par exemple "préferences/parametres généraux" accéder d'un clic à une explication de cette fonction et des exemples, ou bien en fichier sur le pack ou sur un site d"aide" , le travail de burning pourrait être une base .


ah j'oubliais un éditeur wysi , c'est un mini aussi non?

Vi... mais le plus simple serait un référentiel à jour et peut être "mieux organisé" (je mets les guillemets car je ne veux fâcher personne et j'imagine que cela prend du temps, voir sur le site xoops.org le travail est entamé depuis plusieurs semaines il me semble) :

- tant pis pour les modules qui ne sont plus entretenus... on pourrait les mettre de côté, mais pas forcément en vrac, au cas où des développeurs souhaitent les reprendre

- une liste de modules d'administration indispensables (Protector / XoopsInfo / BlocksAdmin ou Altsys / ...)

- une liste de modules de gestion de contenu (texte / image / medias)

Evidemment il y a des doublons... si l'on en met 1 en avant et un lien vers une liste secondaire pour les modules qui ont un usage équivalent, cela devrait clarifier un peu les choses...

En tout cas pour ma part je ne suis pas pour l'incorporation de module avec le noyau : comme indiqué plus haut c'est ensuite un boulot de maintenance qui n'est pas forcément agréable. Ni utile : pour le choix des modules l'important est l'accès à la bonne information et pas au zip du module.

@+