PostNuke
En réponse à certains commentaires (sur le site officiel) sur l'article "A road to 0.8", voici en gros les explications sur la façon dont nous envisageons distribuer PostNuke dans l'avenir.

Le pack principal PostNuke sera allégé ne contenant que les modules essentiels à son fonctionnement. Tous ces modules seront placés dans un répertoire "system" et le répertoire "modules" des versions précédentes ne contiendra que les modules ajoutés par l'administrateur.(Voir suite). Les avantages sont nombreux. Sous PostNuke 0.8, vous saurez exactement quels sont les modules nécéssaires pour faire tourner votre site, vous n'aurez pas à supprimer ou retirer tous les modules que vous ne désirerez pas utiliser avant de faire l'installation PostNuke car le pack principal sera vide, prêt à recevoir les modules tiers de votre choix. L'effet de structure en sera aussi améliorté.

Ceci étant dit, il y aura aussi des désavantages. Le pack principal n'aura que la structure de base pour construire le site. Les anciens modules de contenu, d'extensions ou tout ce qui faisait qu'autrefois, il suffisait de télécharger PostNuke et de l'utiliser.

C'est ici que les distributions ciblées entrent en jeu. Sur PostNuke.com, nous distribuerons une série de packs destinés à différents usages. Ces packs ne contiendront pas nécéssairement que le système, des modules tiers pourront y être inclus. Comment seront-ils inclus et comment se fera le contrôle de qualité est encore un débattu actuellement car inclure du code n'étant pas directement maintenu par l'équipe officielle de développement dans une distribution officielle apporte son lot de problêmes.

Alors quelles sont les distributions possibles que nous pourrions voir ? Il y a en fait une multitude de possibilités comme par exemple :
  • Solution de gestion de Contenu
  • Portail d'entreprise
  • Portail communautaire
  • Outils de Blog
  • Portail de Jeu
  • Démonstration

Cette liste pourrait s'allonger au besoin...

Evidemment, cibler ne s'arrête pas aux modules. Nous aimerions avoir de nouveaux thèmes dans la distribution officielle. De plus, différents thèmes pourraient être inclus selon la distribution choisie.

Donc, selon la nécéssité, les différents packs pourraient inclure un forum, des modules de contenu, de support, des utilitaires de blog, la liste est longue. Et, grâce à cette nouvelle approche de distribution, les utilisateurs pourraient débuter plus facilement avec PostNuke.

Au lieu de télécharger un pack complet mais contenant des modules ayant de sérieux manques au niveau fonctionalités ou ne correspondant pas aux besoins, ce qu'un utilisateur pourrait avoir besoin pour un type de site spécifique devrait être disponible. De plus, la distribution de démonstration pourrait inclure une sélection de modules donnant une bonne idée des énormes possibilités de PostNuke permettant d'attirer l'attention de plus de gens et d'expérimenter la puissance de PostNuke pour la gestion d'un site.

Rien de tout ça n'est actuellement coulé dans le béton mais cet article a pour but de donner une idée de ce qui pourrait venir et comment fonctionnera la distribution dans le futur. Pour toutes autres questions relatives à PostNuke 0.8, n"hésitez pas, nous ferons de notre mieux pour y répondre en commentaire ou par le biais d'articles comme celui-ci.

Chestnut - Dimanche 20 Novembre 2005 » Commentaire(s) : 9 » Lire la suite... 'Pack PostNuke - Les méthodes de distributions' » Forum

Commentaires

magicvince - 21.11.2005, 12:54
Je trouve que c'est plutôt une bonne direction.

Est-ce que l'on pourrait envisager aussi un répertoire "plugin", j'appelle ainsi les "modules" qui s'incrustent dans les autres modules comme par exemple les fonctionnalités de commentaires, les différents éditeurs wysiwyg etc...

Mon rêve étant un plugin "voir aussi" qui permettrait d'ajouter à un contenu quelconque un liste de contenu connexe que l'auteur (ou des commentateurs) pourraient aller piocher dans les autres modules de contenu.

Par exemple on écrit une news et on peut lui associer un lien ou une catégorie de liens piocher dans weblinks, on ajoute un "voir aussi" cibler dans les téléchargements ou vers un article créer avec page setter etc... etc...
magicvince - 21.11.2005, 13:09
Retour sur la structure globale.

J'utilise parallèlement un cms de formation (moodle: http://www.moodle.org) et il y a un truc plutôt pas mal dans la structure, c'est le répertoire "datas"

Ce répertoire est le seul dans lequel sont enregistrés les contenus déposés par les utilisateurs (images, doc divers etc...) quelque soit le module. En fait le répertoire "datas" va contenir les contenus en se basant principalement sur les utilisateurs pour créer des sous-répertoires ou sur les modules lorsqu'il s'agit de contenus partagés avec une gestion des droits d'accès par utilisateurs.

L'intérêt est surtout en terme de maintenance:

On a d'un côté le moteur de gestion de contenu et à deux autres endroits (la base mysql et le répertoire datas) on a les contenus a proprement parlé.

Bien plus simple lorsque l'on fait un backup du système ou une mise à jour du moteur, on limite sérieusement les risque d'écrasement ou de perte des données utilisateurs.
Chestnut - 22.11.2005, 09:30
Il me semble que le truc des plugins a déjà été mentionné dans le passé mais je l'ai remis en route pour voir ce qu'il en était.

Pour ce qui est de la deuxième suggestion, elle n'a d'intérêt que si on a une gallerie ou si on reçoit quelque chose des utilisateurs qui ne soit pas à mettre dans la base de données. Par exemple, pnFrance n'aurait pas de bénéfice à avoir un répertoire pnData puisque pnFrance ne permet aucun upload ni n'héberge quoique ce soit provenant des utilisateurs dans la structure du site. Dans le meilleur des cas, une doc ou autres serait mis sur le projet pnFrance sur le noc.

(Et je le répète pour tout le monde, les demandes d'hébergement de fichier seront laissées sans suite ;-))

Dans la plupart des cas, les modules ayant ce type de fonctions ont un paramêtre permettant de lui assigner un répertoire choisi par l'admin et c'est l'admin qui gère ses répertoires.

Mais comme PostNuke n'a aucun fonction native justifiant un tel répertoire... aucun raison dans créer un par défaut.

Du moins en ce moment.......

A suivre...

C !
mumuri - 22.11.2005, 12:25
C'est pas con du tout, et ca évitera d'avoir des problémes de sécurité avec des modules qu'on n'utilise pas, on gagne en plus sur notre bande passante pour uploader (et vous pour distribuer), reste a savoir comment seront distribué les modules ancienement inclus par défaut.

bravo en tout cas
domo - 22.11.2005, 14:05
Je suis content de voir que le Projet devient bien plus lisible qu'il ne l'etait avant:
Des infos sur le futur, un site plus clair, un commité de direction bien defini.
Cette amelioration de la communication ainsi que de bon progres dans le code en lui meme (vivement la .8), ca fait vraiment plaisir.

Longue vie a Postnuke.
nephaste - 01.12.2005, 10:17
Idée originale et intéressante. Une version minimale et des versions spécialisée.
Pourquoi pas une version "éducation" (j'utilise Postnuke dans un environnement scolaire).

Bon travail et merci.
mumuri - 01.12.2005, 17:02
ce qui serai bien c'est de centraliser toutes les distributions crée sur postnuke.com, pour que les gens sachent ou chercher.

Personnellement j'ai quelques petites idées aussi.
Chestnut - 01.12.2005, 17:33
Les différents pack seront sûrement centralisé à un seul endroit... tout comme sur pnFrance, nous n'hébergerons ni ne feront de lien direct sur un pack mais plutôt sur la catégorie ou autres...

De sorte que si un changement se produit (lien modifié, zip modifié, etc), nous ne soyons pas obligé de nous taper nous aussi ce boulot...

Déjà que c'est probablement moi qui va créer une partie des scripts de construction de pack.........

Tout ça, c'est de la spéculation de toute façon pour le moment.

C !
mumuri - 28.12.2005, 12:15
de faire un lien vers le site distributeur plutot que vers son pack, ca laisse plus d'autonomie et de liberté au site qui crée son pack.
Seuls les utilisateurs enregistrés peuvent ajouter un commentaire. S'enregister/S'identifier