Excellent sujet de discussion.

1) La licence qui protège Xoops (GNU-GPL) n'oblige pas à afficher les crédits. Seulement à les laisser dans le code. Donc, du côté du 'droit' on fait ce qu'on veut.

2) Personnellement, je ne vois aucun inconvéniant à virer les crédits dans la partie publique d'un site. Le sujet avait été discuté sur xoops.org, et certain ne souhaitaient pas tendre un perche trop flagrante à leur concurrent. Argument qui se défend.

3) En principe, tu crée un site pour son contenu et le thème qu'il propose, et non pour faire la promotion de l'outil utilisé.

4) Personnellement, je trouve particulièrement énervant les développeurs de modules qui affichent leurs crédits sur les pages publiques générés par leurs modules. Franchement, qu'est-ce que les visiteurs de ton site en ont à faire de savoir que 'edito' (pour prendre un exemple) est développé par la WolFactory ? Aucun. Par contre, je ne vois aucun inconvénient à ce que cette information se retrouve cachée dans le code de la page (invisible pour le visiteur lambda). Histoire de se faire un peu de backlink... De même, je n'hésite pas à placarder cette info dans la partie admin du site. Libre à son utilisateur (le webmaster) à venir te lancer des fleurs (et les pots avec) sur ton module.

Voilà pour mon avis...

Houlàà, attention, il ne s'agit tout de même pas de refaire ce qui a déjà été fait.

Il existe des albums photos qui remplissent ces fonctionnalités.

Et puis, il est préférable d'y aller étape par étape.

Ben oui, d'où la possibilité de choisir le répertoire d'upload par défaut.

C'est là qu'interviennent les préférences du module.

Rien ne t'empêche d'ajouter en option la gestion admin côté utilisateur. Avec pour explication : si vous utilisez le cache sur votre module, cochez 'non'. Bonne remarque ceci dit. Personnelement, j'utilise rarement le cache sur les modules. Je l'applique plutôt sur les blocs.

Pour le mulitlangue, une seule adresse : SmartFactory...

Pour l'upload par lot, tu devrais pouvoir proposer les 2 méthodes. Mais tu as tout à fait raison.

Quand je te disais que les utilisateurs lui tordront le bras...

Quelques questions :

1) Comptes-tu mettre ce module à disposition de la communauté (gratuitement) ?

2)Ce module peut-il fonctionner avec un serveur web mutualisé ? Ce qui est le cas de la plupart des utilisateurs présents ici...

Tu peux choisir de rediriger le répertoire d'upload vers un répertoire ouvert en écriture. Il suffit de l'indiquer dans les préférences du module.

Et l'upload d'image n'a rien à voir avec l'editeur (koivi ou Xoops).

Merci Zoullou.

Donc j'ouvre le feu, étant donné que je pense que ton module a de l'avenir.

A mon sens, ton module peut devenir un excellent outil de gestion d'images pour les webmasters. Le problème des galleries disponible étant qu'elles manquent singulièrement de simplicité et/ou leur paramétrage est un vrai casse-tête. Bref, un utilisateur lambda comme moi peut s'y perdre très vite.

Voici quelques principes qui devraient t'aider à le faire évoluer dans le bon sens.

1) KISS : Keep It Simple and Stupid. Toujours garder à l'esprit que les utilisateurs (webmestre en tête) préfèrent les modules simples que les usines à gaz. Et ton modules doit pouvoir être utilisé de façon simple. En ce qui me concerne, j'installe des sites pour des gens qui ne sont pas des webmasters confirmés, et ils doivent pouvoir l'utiliser sans devoir avoir fait bac + 12.

2) Souple. Offrir un maximum d'option de paramétrage, réglables une fois pour toute et puis on y touche plus. Donc, imposer tes choix au minimum.

3) Evolutif. Même dans sa phase de démarrage, ton module doit pouvoir être facilement évolutif, et te permettre des modification et ajouts sans que cela ne te pose trop de problème.

4) User Proof. Tu n'imagines pas ce que les utilisateurs peuvent faire avec ton module, et à quel point ils vont lui tordre le bras. Il faudra donc en prévoir le maximum pour éviter tout problème.

En conséquence, concernant ton module...

- Ajout/suppression des images.

- Ajout/suppression des categories et images qui lui sont liées.

- Déplacement des images au sein des catégories

- Déplacement des catégories. Attention, vérifier que l'utiliateur ne déplace pas une catégorie en elle-même. Installer une routine de vérification.

- Gestion large côté admin, mais aussi côté utilisateur. Ajouter les boutons supprimer et déplacer pour les admin seulement sur chaque image.

- Options possibles : afficher ou non telle ou telle option. Ex : la possibilité de télécharger une image (très bonne idée) mais aussi de l'imprimer ou d'en copier/coller l'url.

- Navigation d'une image à l'autre (super !). Mais que se passe-t-il si je supprime une des images dans la liste ? Le module en tient-il compte ?

- Multilangue. Le module l'accèpte, sauf lors de l'édition d'un paramètre. Exemple : Changer le nom de la catégorie. Augmenter la taille des champs.

- Blocks. Compléter le choix des blocs en ajoutant l'image aléatoire, la possibilité d'afficher l'un au dessus de l'autre et un bloc qui permette l'upload d'images directe.

- Gestion par groupe par catégorie.

- Upload par lot. Excellente fonctionnalité (même indispensable). Mais il faut voir si tu ne peux pas limiter les interventions ftp et les transferts de fichier... Bref, l'idéal est de passer un maximum de fonctions par l'admin du site.

- Page d'aide incluse dans le module (et pas un readme que personne ne lit).

Qu'en penses-tu ?

Citation :

Tatata. Mes modules ne buggent jamais.

Tu dois simplement appliquer les permissions en écriture sur le répertoire (par défaut) 'modules/edito/images/upload'.

Sinon tu peux jeter un oeil sur le module "myHome" qui te permet d'afficher une info supplémentaire en page d'accueil.

Le menu principal de l'admin de multiMenu, ou de l'admin de Xoops ?

Pour Xoops, seuls les admin ayant les droits d'accès peuvent voir les liens/logos.

Pour multiMenu, ce n'est pas prévu, mais possible...