[CMS] Vital CMS

WRInaute impliqué
Bonjour à tous,

Je ne suis pas sûr d'être au bon endroit vu que je n'ai rien à vous montrer pour le moment mais bon, je tente ! :)

Je souhaite vous parler d'un projet que je suis en train de réaliser : Vital CMS

C'est un projet tout récent que j'ai commencé ce week-end mais qui avance rapidement car je suis partie d'un site que j'ai développé il y a plus d'un an et je revois entièrement le code afin d'en faire un CMS.

Ce CMS fonctionnera entièrement sous forme de modules indépendants. Seules quelques fonctionnalités seront natives (pages et blocs CMS, module de recherche ...).

Technologies utilisées : PHP5, SQL, HTML5, CSS3, jQuery ...

Il sera par la suite peut-être réalisé sous Symfony 2 cependant l'objectif étant qu'il soit facilement compréhensible et modifiable par tous, débutant compris, ce n'est pas une certitude (d'ailleurs qu'en pensez vous ?)

Pourquoi créer un CMS ?

Pour plusieurs raisons ! Tout d'abord car je trouve cela super intéressant comme projet et ensuite car les CMS existant ne me plaisent pas vraiment bien que j'ai une bonne connaissance en Joomla.

Je trouve que :
  • Wordpress est mal réalisé
  • Drupal & Joomla sont deux CMS trop importants et lourds pour de petits sites et difficile à prendre en main.

Vital CMS sera dans l'idée assez proche des fonctionnalités de Wordpress mais différent dans son administration afin d'offrir plus de fonctionnalités (notamment dans la personnalisation)

Il n'aura rien de révolutionnaire mais sera une solution alternative et sera au minimum utilisé par moi même sur deux de mes sites :)

Où j'en suis ?

Actuellement il développement est donc pas testable cependant certaines fonctionnalités sont déjà prêtes du côté Front End :

  • Affichage d'un ou plusieurs blocs personnalisés (texte HTML) par page
  • Listing des derniers articles (possibilité de choisir le nombre d'articles à afficher et de mettre un nombre maximum de caractères par titre d'articles).
  • Affichages des catégories avec gestions des sous-catégories
  • Affichage des pages
  • Activations / désactivations de modules
  • Partages d'un article sur les réseaux sociaux
  • Appel d'un module (natif ou complémentaire)

A venir très prochainement :

  • Gestion de l'affichage d'un article / d'une catégorie d'articles / d'articles ayant un ou plusieurs tags
  • Gestion des commentaires sur un article
  • Module de recherche
  • Module de connexion
  • Début de la réalisation du panel d'administration

Et un peu plus tard :

  • Module d'inscription (pour le moment je n'en ai pas besoin sur mes 2 sites donc ce n'est pas ma priorité)
  • Module "Forum" (qui prendra pas mal de temps)
  • Gestion des MàJ du CMS
  • Réalisation d'un moteur WYSIWYG
  • Tout ce qui me passera par la tête

Le but de ce topic est de vous faire suivre l'évolution de mon petit CMS maison et de partager vos avis sur celui-ci !
Un site internet sera réalisé lorsque le CMS sortira dans sa V1.0 (donc pas tout de suite :mrgreen: )
 
WRInaute accro
Hello

Triixx a dit:
Il sera par la suite peut-être réalisé sous Symfony 2 cependant l'objectif étant qu'il soit facilement compréhensible et modifiable par tous, débutant compris, ce n'est pas une certitude (d'ailleurs qu'en pensez vous ?)
Je n'en sais rien c'est à toi de voir ce que tu veux faire :)

Triixx a dit:
Pour plusieurs raisons ! Tout d'abord car je trouve cela super intéressant comme projet
C'est vrai

Triixx a dit:
Wordpress est mal réalisé
:lol: :lol: :lol: :lol: :lol: :lol:

Là, désolée, mais avec les sites que tu nous as montrés sur WordPress et ton "niveau d'expérience" sur ce CMS (genre tu mets un thème totalement nul et tu dis "mais je croyais que WordPress c'était bon pour le SEO) je crois que tu manques un peu de connaissances pour affirmer ça.

Triixx a dit:
Vital CMS sera dans l'idée assez proche des fonctionnalités de Wordpress mais différent dans son administration afin d'offrir plus de fonctionnalités (notamment dans la personnalisation)
Par exemple ?

Sur le fond je pense que c'est un excellent projet de faire son propre CMS. Après tout dépend des objectifs que tu te fixes. Il existe déjà de nombreux concurrents à WordPress, dont l'excellent InfiniCMS. Si tu développes pour toi et pour tes sites, fais toi plaisir, c'est terriblement formateur en plus.

Mais si tu veux distribuer ta solution largement, c'est une autre paire de manches :D

En tout cas je suivrai avec intérêt.
 
WRInaute accro
C'est vrai :) je ne l'aime pas, mais ça c'est un autre problème ^^ , mais c'est aussi extrêmement rapide à installer
 
WRInaute impliqué
Là, désolée, mais avec les sites que tu nous as montrés sur WordPress et ton "niveau d'expérience" sur ce CMS (genre tu mets un thème totalement nul et tu dis "mais je croyais que WordPress c'était bon pour le SEO) je crois que tu manques un peu de connaissances pour affirmer ça.

Alors pour répondre concernant Wordpress j'ai eu à réaliser des template et à les intégrer, donc pour le blog que j'ai montré c'est une exception ^^ Mais j'adhère pas à ce CMS (peut être car je suis plus sur du Joomla donc Wordpress me semble super bordelique) et il est vrai que moins je pense de temps dessus, mieux je me porte :p

Après c'est un avis personnel, j'ai du mal avec Wordpress mais je l'utilise donc c'est que je le trouve pas mauvais non plus ^^

Par exemple ?
Pouvoir ajouter une class personnalisé à un widget. Ce n'est pas possible (du moins nativement) dans Wordpress mais ça l'est dans Joomla par exemple. Et c'est une fonctionnalité que je trouve top ! (et qui est déjà en place dans mon CMS car pas très compliqué ^^).

Sur le fond je pense que c'est un excellent projet de faire son propre CMS. Après tout dépend des objectifs que tu te fixes. Il existe déjà de nombreux concurrents à WordPress, dont l'excellent InfiniCMS. Si tu développes pour toi et pour tes sites, fais toi plaisir, c'est terriblement formateur en plus.

Mais si tu veux distribuer ta solution largement, c'est une autre paire de manches :D

Ce sera dans un premier temps pour "blog in france" et pour le site d'un client (qui me sert de base de développement d'ailleurs sur un serveur de test).

Après dans l'idée c'est de le proposer comme solution alternative à mes clients et pourquoi pas à toutes les personnes qui le souhaitent. De toute façon une fois que le CMS est en route, que je sois seul à l'utiliser ou non, je continuerai de le développer pour mes clients. Donc autant que d'autres en profite ! (mais je n'ai pas prévu d'en vivre ^^)

Joomla n'est ni lourd

Joomla est bien plus lourd que d'autres CMS mais il est ultra complet

ni difficile à prendre en main.

L'administration est bien plus compliquer à prendre en mains que d'autres CMS (Wordpress par exemple) mais ils se sont bien améliorer. Montre l'administration de Joomla à un novice et celui de Wordpress, il ne choisira pas Joomla.

Côté développement, son Framework maison rends l'apprentissage plus long. Je suis cependant un grand fan de ce CMS et je l'utilise sur mon site principal.

Après ce sont des avis personnels qui n'engage que moi ;)
Par contre le but n'est pas de se lancer dans un débat sur Wordpress ou Joomla donc si on peut éviter d'en faire le sujet principal je ne suis pas contre ;) Mais si certaines fonctionnalités d'un CMS vous semblent indispensables ou top (et que d'autres CMS n'ont pas) je suis tout ouïe !

Merci pour vos messages, ça fait plaisir de voir que ça attire la curiosité :)
 
WRInaute accro
Triixx a dit:
Alors pour répondre concernant Wordpress j'ai eu à réaliser des template et à les intégrer
ça ne prouve rien (ni dans un sans ni dans l'autre, il y a des tas d'agences pro ayant pignon sur rue qui font des daubes ignobles avec WordPress)

Triixx a dit:
Mais j'adhère pas à ce CMS (peut être car je suis plus sur du Joomla donc Wordpress me semble super bordelique) et il est vrai que moins je pense de temps dessus, mieux je me porte :p
Joomla et WordPress ont effectivement deux logiques et deux structures différentes, c'est d'ailleurs pour ça que je n'aime pas Joomla, WordPress est plus proche de la logique de nodes de Drupal. Mais je n'irais pas dire, comme toi qu'il est "mal réalisé"

Triixx a dit:
Pouvoir ajouter une class personnalisé à un widget. Ce n'est pas possible (du moins nativement) dans Wordpress mais ça l'est dans Joomla par exemple. Et c'est une fonctionnalité que je trouve top ! (et qui est déjà en place dans mon CMS car pas très compliqué ^^).
Euh ?
Chaque widget est généré dans la sidebar avec un ID qui lui est propre, et avec une classe qui lui est spécifique

Autrement dit tu as widget id="identifiant_widget-numero" class="widget identifiant_widget", le numéro dans l'id étant obligatoire, à cause des widgets répétables.
Standard wordpress.
A partir de là, tu as déjà une "class personnalisée", avec tous les moyens nécessaires, avec les sélecteurs css, non ? Ou alors je n'ai pas compris le problème ? Je ne vois pas l'intérêt de charger en base de données une information supplémentaire pour quelque chose qui existe déjà ?
(Et boyclass() permet d'aller beaucoup plus loin dans la personnalisation du css, si on le souhaite)

Triixx a dit:
Par contre le but n'est pas de se lancer dans un débat sur Wordpress ou Joomla donc si on peut éviter d'en faire le sujet principal je ne suis pas contre ;)
Un peu si quand même, car en dehors du plaisir pur de coder, développer un produit c'est s'attaquer à une concurrence, qui est à la fois purement technique et "environnementale" avec les apports d'une communauté. J'ai une vision utilitaire de mon temps :D à la fois pour le développement et pour les tests.

Triixx a dit:
Mais si certaines fonctionnalités d'un CMS vous semblent indispensables ou top (et que d'autres CMS n'ont pas) je suis tout ouïe !
- e commerce (plus important qu'un forum pour une solution "pro")
- multilangue optimisé, y compris pour les images et la gestion des stocks de l'e-commerce
- modèle de données souple, permettant d'insérer de façon simple et sans avoir à créer de tables "quasiment n'importe quel type de contenu" via des API Json / XML
- gestion avancée du duplicate content et du seo sur les taxonomies
 
WRInaute impliqué
Mais je n'irais pas dire, comme toi qu'il est "mal réalisé"

Bon d'accord, je l'aime tout simplement pas :mrgreen:

Euh ?
Chaque widget est généré dans la sidebar avec un ID qui lui est propre, et avec une classe qui lui est spécifique

Autrement dit tu as widget id="identifiant_widget-numero" class="widget identifiant_widget", le numéro dans l'id étant obligatoire, à cause des widgets répétables.
Standard wordpress.
A partir de là, tu as déjà une "class personnalisée", avec tous les moyens nécessaires, avec les sélecteurs css, non ? Ou alors je n'ai pas compris le problème ? Je ne vois pas l'intérêt de charger en base de données une information supplémentaire pour quelque chose qui existe déjà ?
(Et boyclass() permet d'aller beaucoup plus loin dans la personnalisation du css, si on le souhaite)

Ah d'accord ! C'est pas forcement le plus simple pour s'y repérer que d'avoir une class et un id qui se génère automatiquement mais ça existe ^^ (Faudrait vraiment que j'y remette le nez dedans :mrgreen: ). Je l'avais vue pendant ma formation en cours mais c'est vrai que, n'ayant pas accroché, je n'ai pas fouillé plus profondément que les besoins (très basiques) de mes clients. Je dis donc une bêtise, autant pour moi ;)

- e commerce (plus important qu'un forum pour une solution "pro")
- multilangue optimisé, y compris pour les images et la gestion des stocks de l'e-commerce

Pour tout ce qui est e-commerce c'est prévue mais ça devient très vite lourd à faire c'est pour cela que je ne l'ai pas listé.
D'autant plus que, n'en ayant pas besoin pour mes 2 sites, ça me ferai un investissement assez énorme pour pas grand chose (en dehors du fait de l'avoir fait).

Enfaite l'avantage du forum c'est que je pourrais assez facilement trouver des particuliers pour utiliser mon CMS. Alors qu'un pro lui dire "Mais si viennnnnnnt, il est bien et je suis gentil. Bon par contre tu sera le premier à l'utiliser" c'est plus compliqué :mrgreen: (bien que je devrais pouvoir passer assez facilement un client pro de Wordpress à mon CMS d'ici la fin de l'année)

- modèle de données souple, permettant d'insérer de façon simple et sans avoir à créer de tables "quasiment n'importe quel type de contenu" via des API Json / XML
Tu as un exemple ?
Pouvoir importer n'importe quel fichier et que celui-ci se stock en base de données sans que tu n'ai besoin d'aller créer de tables ? C'est pas simple comme besoin au vue du nombre de possibilités ^^

- gestion avancée du duplicate content et du seo sur les taxonomies
Cette partie sera réalisé cependant n'étant pas un expert SEO (je connais les bases mais c'est tout), je serai vite limité. Mais je sais où demander conseil :)

Un peu si quand même, car en dehors du plaisir pur de coder, développer un produit c'est s'attaquer à une concurrence, qui est à la fois purement technique et "environnementale" avec les apports d'une communauté. J'ai une vision utilitaire de mon temps :D à la fois pour le développement et pour les tests.

Je me suis mal fait comprendre je pense (désolé :oops: ) on peut bien sûr en parler mais le but n'est pas de débattre sur le fait que l'un aime tel ou tel CMS et l'autre pas mais de savoir ce qui vous plait ou ce qui au contraire manque. :)

Merci en tout cas pour tes remarques, malgré tout ça me motive !
Ce soir je m'attaque à la gestion des articles :)
 
WRInaute accro
Triixx a dit:
Ah d'accord ! C'est pas forcement le plus simple pour s'y repérer que d'avoir une class et un id qui se génère automatiquement
Ben si puisque :
  • c'est basé sur l'identifiant du widget, donc clairement compréhensible
  • ça évite toute manipulation, donc erreur de saisie
  • t'as rien à faire, c'est là
  • il suffit d'afficher le front end avec Firefox pour identifier la classe en question (tu peux le faire dans l'admin aussi mais il faut bien connaître là)

Triixx a dit:
(Faudrait vraiment que j'y remette le nez dedans :mrgreen: ). Je l'avais vue pendant ma formation en cours mais c'est vrai que, n'ayant pas accroché, je n'ai pas fouillé plus profondément que les besoins (très basiques) de mes clients.
Oui et en fait le message il est là : WordPress est à la fois un outil très simple à utiliser en basique pour mettre un site en ligne en dix minutes, et très puissant pour faire des choses très complexes, avec une API remarquablement bien documentée, très complète, et un modèle de données hyper puissant et "minimaliste", avec "11 tables".
Même en rajoutant un plugin comme WooCommerce, tu montes à 27 tables (et certaines ne sont là que pour la perf. on va dire que c'est du cache, d'autres vont disparaître à terme parce que des fonctionnalités manquantes ont été intégrées dans le core).
C'est pour ça qu'au contraire, je le trouve très bien réalisé. Je ne suis pas sectaire, il manque des trucs, il n'est pas adapté pour d'autres, etc... mais dans sa catégorie "middle size" il est tout simplement excellent.

Triixx a dit:
Pour tout ce qui est e-commerce c'est prévue mais ça devient très vite lourd à faire c'est pour cela que je ne l'ai pas listé.
D'autant plus que, n'en ayant pas besoin pour mes 2 sites, ça me ferai un investissement assez énorme pour pas grand chose (en dehors du fait de l'avoir fait).

C'est pourtant indispensable pour beaucoup de clients pro, même en mode catalogue. En plus, la problématique, pour un bon CMS, c'est de pouvoir évoluer sans tout casser. Donc poses toi quand même la question de l'e commerce maintenant pour voir si au moins ton modèle de données tient la route.

Triixx a dit:
En faite l'avantage du forum c'est que je pourrais assez facilement trouver des particuliers pour utiliser mon CMS.
Je ne suis pas certaine que ce soit un avantage ^^

Triixx a dit:
Tu as un exemple ?
Pouvoir importer n'importe quel fichier et que celui-ci se stock en base de données sans que tu n'ai besoin d'aller créer de tables ? C'est pas simple comme besoin au vue du nombre de possibilités ^^
Tu penses bien que si je te pose la question, c'est parce que c'est ce que je peux faire avec WordPress. Je suis en train de migrer un de mes sites anciens, fait à la main avec mon propre CMS sous WP. Pourquoi ? Parce que je me suis rendue compte que j'étais purement et simplement en train de re-créer la structure de données de WP, et que, tant qu'à faire, autant utiliser leur admin. Et pourtant, dans ce site, il y avait des pages, des articles, des produits, des bouquins, des recettes, des cartes google, des galeries photos, bref une dizaine de types de contenus différents.

Triixx a dit:
ce qui au contraire manque. :)
[/quote]
Honnêtement ? Pas grand chose et ce qui me manque (application mobile et pas "version mobile") est en route.
 
WRInaute impliqué
Merci !
Quand je vois Wordpress et Joomla!, je me dis qu'il y a moyen de faire quelques choses entre les deux. Plus j'y réfléchie plus je me dis que tu as raison pour le e-commerce. Surtout que de ce côté là il n'y a pas vraiment de solution parfaite et ça peut être super intéressant :)

Mais je vois que tu es une adepte de Wordpress, et je vois de quoi tu parle pour la migration de données. Ca existe sur pas mal de CMS enfaîte tu associe chaque tables / champs à ceux du CMS afin de tout migrer ? C'est plutôt simple à réaliser :)
 
WRInaute accro
Non ce n'est pas "migration de données". Ou pas seulement.
Tu as combien de tables pour gérer ton forum ? Et tu rajoutes combien de tables pour gérer un e-commerce ? Tu as besoin de combien de tables pour gérer un annuaire de petites annonces immobilières ?

Un Prestashop a bien plus de tables qu'un WordPress + WooCommerce ou qu'un Joomla avec JoomlaCart parce que le modèle de données est merdique, ce qui fait que l'évolution de l'outil est difficile, et sa personnalisation un vrai traquenard.

Un bon CMS, avant d'être des "fonctions", c'est un modèle de données pour "organiser, gérer" le contenu. Si ton modèle de données est bon, tu ajoutes des fonctions sans difficultés. Sinon, tu souffres, tu rajoutes des tables, des tests, etc...

Quant à la migration de données "Simple à réaliser".... mouais, tu as déjà migré un Spip ou un Magento ? :D :D :D
Et surtout, tu as déjà fait la migration d'un gros site legacy codé sur Notepad ? La question n'est pas "technique", elle est d'arriver à faire rentrer dans un modèle de données, sans avoir à le modifier, des sites construits avec d'autres outils, voire avec tout le foisonnement d'un site fait sur notepad
 
WRInaute impliqué
Ben si puisque :
c'est basé sur l'identifiant du widget, donc clairement compréhensible
ça évite toute manipulation, donc erreur de saisie
t'as rien à faire, c'est là
il suffit d'afficher le front end avec Firefox pour identifier la classe en question (tu peux le faire dans l'admin aussi mais il faut bien connaître là)
J'ai réflechie là dessus mais du coup si jamais tu as plusieurs blocs avec le même style (couleur de fond, polices d'écriture ...) tu dois ajouter a ta feuille de style tes nouveaux id à chaques fois ? Alors qu'avec une classe personnalisée, tu l'ajoute dans ton backoffice et c'est réglé (ce que je fais sous joomla).

Dis moi si je me trompe ^^'
Mais du coup je vais modifier un peu mon code pour générer automatiquement un id (qui devrait ressembler à nom_du_module + id_du_module) et offrir la possibilité d'ajouter une classe personnalisée.

En effet pour la migration de données cela peut être vraiment lourd suivant le CMS (j'ai déjà du migrer une base de données PHPBB3 sous Joomla, j'y ai passé plusieurs heures avec sous du Magento *_*

J'utilise au quotidien du Magento (étant salarié dans une société qui l'utilise) et c'est une vrai usine à gaz. Malheureusement sans trop de concurrents sur son marché (Prestashop étant vite trop léger pour les gros sites). Mais je n'ai pas pour ambition d'aller le titiller :D

Actuellement je dois avoir 7-8 tables pour la gestion des articles et de mes modules existants (1 table par module pour le moment). Mais Joomla ou Wordpress ont des années de développement donc je ne pourrais de toute façon pas sortir une V1 aussi optimiser qu'eux (mais le plus possible bien entendu !).

Sinon j'ai aussi pour objectif de proposer des modules avec des solutions alternatives à celles qu'on trouve sur les gros CMS (et des solutions Françaises si possibles). Mais tout ça c'est bien sûr pour plus tard. Il me faut déjà avoir une base CMS "classique" et optimisée :)
 
WRInaute accro
Triixx a dit:
J'ai réflechie là dessus mais du coup si jamais tu as plusieurs blocs avec le même style (couleur de fond, polices d'écriture ...) tu dois ajouter a ta feuille de style tes nouveaux id à chaques fois ? Alors qu'avec une classe personnalisée, tu l'ajoute dans ton backoffice et c'est réglé (ce que je fais sous joomla).

"Oui" si tu veux un style différent pour chacun de tes widgets, tu devras faire un style différent à chaque fois.
Oui bien, si tu es à fond dans la personnalisation, tu fais ta propre sidebar
Ou alors tu fais une simple recherche Google et bingo...
https://wordpress.org/plugins/widget-css-classes/

(Oui c'est un plugin... ça fait 8 ans que je fais du WP, et je n'ai jamais eu le besoin de styler individuellement chaque widget, perso je trouve même ça mauvais, ça fait une interface bordélique, mais si le besoin est là, y'a un plugin, parce que ce n'est pas difficile à faire avec l'API Wordpress)

Triixx a dit:
1 table par module pour le moment
Ouch.... bad design, ça va dans le mur ça....

Triixx a dit:
Mais Joomla ou Wordpress ont des années de développement donc je ne pourrais de toute façon pas sortir une V1 aussi optimiser qu'eux (mais le plus possible bien entendu !).
En fait, en 12 ans la structure de table de WordPress a très peu évolué depuis la création, ils ont dû en rajouter trois et en enlever une. Je le sais, je me suis fait l'historique des versions pour rigoler :)

C'est là où, à mon avis, tu te trompes dans ton raisonnement. Faire évoluer un modèle de données sur un système existant, c'est ce qu'il y a de plus galère, car cela remet tout en cause, toutes les requêtes notamment.

Matt Mullenweg avait 20 ans quand il a sorti la V1 de WordPress, certes un fork d'un outil déjà existant, mais son modèle de données d'origine tient toujours. Je ne connais pas l'histoire de Joomla, mais (je sais je répète, tellement c'est essentiel), la BASE d'un "content management system" c'est comment on identifie et on classe les contenus, donc le modèle de données. Et je peux te dire qu'une table par module, c'est baaaaaaaaaad

Tiens, au fait, tu as vu ? WordPress internalise WooCommerce, le CMS avec lequel 23% des sites webs sont créés va avoir sa solution e-commerce "core". De Profundis Prestashop et son modèle de données effrayant ^^
 
WRInaute impliqué
Non l'idée n'est pas d'avoir un style différent par widget au contraire. Tu as 5 widget avec des id et class différents mais tu veux qu'ils aient tous la même apparence vu que tu ne peux pas personnaliser ta classe tu es obligé d'ajouter dans ton css ?
Code:
#id1, #id2, #id3, #id4, #id5 {
blablabla
}

Bon après mon but c'est pas de faire un wordpress ;)

Je ne savais pas pour WooCommerce, c'est une bonne idée de leur part bien que les 80% de sites sous Wordpress doivent être de simple blog ou sites vitrines et n'ont donc rien à faire de cette fonctionnalité ^^

Je réfléchie aussi à intégrer, au seins de l'espace d'administration, un extranet complet avec module de tchat, todolist, planning ... Pour proposer une solution "Front end" pour le site et "Back End" pour l'administration mais avec un accès "Entreprise" (donc plus limité que l'accès d'administration). Qu'en pense tu ?

Après encore une fois mon but est pas de faire de mon projet le CMS vedette du marché, mais de m'amuser à développer une solution alternative :)

En tout cas merci pour ton intérêt, ça me permet de penser à plein de chose et de remettre en question d'autres éléments :)
 
WRInaute accro
J'espère que tu pars sur de bonnes bases et que tu es donc familier avec :
- Composer / Autoloading / PSR
- MVC
- ORM (tables/entities, relations, lazy loading, ...)
- RESTful
- Routing (+ reverse)
- Template inheritance
- Event dispatcher/listener
- I18n
- Caching
- CSRF
- ... et j'en passe
 
WRInaute accro
Triixx a dit:
Non l'idée n'est pas d'avoir un style différent par widget au contraire. Tu as 5 widget avec des id et class différents mais tu veux qu'ils aient tous la même apparence vu que tu ne peux pas personnaliser ta classe tu es obligé d'ajouter dans ton css ?

:D :D :D
tu connais le C de CSS ? "Cascading" ?
Tu as donc 5 widgets qui doivent avoir la même apparence, et qui, toujours marquage de base standard ont "aussi" une classe widget et sont contenus dans une sidebar qui a "une id" et "des classes" de la même façon

.masidebar .widget {
}

et si tu veux UN widget qui soit différent

.masidebar #widgetid


Triixx a dit:
Bon après mon but c'est pas de faire un wordpress ;)
J'ai bien compris... mais comme tu le cites comme exemple de 'mal codé' 'il manque des trucs', je me permets de te montrer que tu sembles mal connaître un outil que je trouve très bien codé, justement, pour la souplesse qu'il a, et sa bonne utilisation, à tous les niveaux, de la logique d'héritage.

Triixx a dit:
bien que les 80% de sites sous Wordpress doivent être de simple blog ou sites vitrines et n'ont donc rien à faire de cette fonctionnalité
Mon dieu, mon dieu...
comment peut-on être "pro" et se couper, comme ça, de 20% de son marché potentiel ?
https://wordpress.org/plugins/search.php?q=woocommerce
Plus d'un millions d'installations actives de WooCommerce...
Plus tous ceux qui sont sur Prestashop "par habitude" avec un blog WP et qui vont migrer

Triixx a dit:
Je réfléchie aussi à intégrer, au seins de l'espace d'administration, un extranet complet avec module de tchat, todolist, planning ... Pour proposer une solution "Front end" pour le site et "Back End" pour l'administration mais avec un accès "Entreprise" (donc plus limité que l'accès d'administration). Qu'en pense tu ?
Très honnêtement, fais d'abord ton e-commerce
 
WRInaute impliqué
+ de 7 millions d'installations mais sur combien de sites sous Wordpress ? ^^ D'après ce que j'ai trouvé, plus de 70 millions donc on est même sur du 10% :D :D

Je trouve cela étrange de leur part d'intégrer nativement Woocommerce car ils sortent de leur image initiale de "CMS de blog" (me tape pas, quand on parle de Wordpress on pense pas au e-commerce).

Mais je n'ai jamais réalisé de site e-commerce sous Wordpress et ne connait nullement WooCommerce :)

Après comme tu l'as compris je n'adhère pas spécialement à Wordpress mais c'est sans doute une question d'habitude :)

Promi, j'arrête de le critiquer, tu as réussi a me convaincre sur le fait qu'il est pas si mauvais :mrgreen:
 
WRInaute accro
Tu sais, ça fait longtemps qu'ils sont sortis de leur image initiale de blog. Après s'il y a des gens qui ne sont pas allés plus loin que ce qu'on leur a appris en cours (sous entendu : par des profs qui se sont formés quand la modernité c'était Joomla, j'ai les mêmes ici, des gens qui sont incapables de faire avec Joomla ou Spip le 10° de ce que je fais avec WordPress mais qui regardent dédaigneusement en disant "ce truc pour faire des blogs"), je n'y peux rien.

Aux 7 millions tu rajoutes les gens qui sont sur jigoshop, wp-ecommerce, ceux qui ont un prestashop couplé à un blog wordpress, par habitude ou parce qu'ils ont commencé il y a longtemps.

En dehors du "blog" tu rajoutes tous les gens qui font de la vente sans e-commerce, parce que quelques produits simples, ceux qui font "autre chose" (événements, hôtels avec réservation, etc)

Le message que j'essaye de te faire passer, et auquel tu as l'air de rester hermétique c'est que, au delà du plaisir de te former en faisant ton propre CMS, si tu veux être "pro et indépendant" tu as sacrément intérêt à maitriser les principaux outils sur le marché, sinon tu vas devenir comme toutes ces agences qui fourguent d'autorité une solution au client parce qu'elles ne maîtrisent pas les autres. Et que si une solution truste un quart des sites qui s'installent, elle doit avoir quelques qualités.

Et que pour ton CMS, c'est bien de réfléchir à "comment je peux arriver à répondre au maximum de besoins sans être obligé de rajouter une table à chaque module".
 
WRInaute impliqué
J'ai bien compris ce que tu me dis, c'est d'ailleurs pour ça que je propose à mes clients des sites sous CMS (2 sous Wordpress d'ailleurs) ou Joomla. J'ai d'ailleurs prévus de développer un composant de ticketing sous Joomla compatible avec Hikashop que j'utilise :). Je ne compte pas négliger les CMS du marché (du moins jusqu'à ce que le mien soit leader #rêve)

Après mon premier job a été dans une agence Web spécialisée sous Joomla! donc j'ai été formé sous ce CMS bien plus que les bases apprises sous Wordpress.

Après je ne pense toujours pas que Wordpress sois forcement la solution idéalement pour du e-commerce (sauf peut être pour des petits sites qui utilisent actuellement Prestashop en effet (et lui pour le coup son développement est très ... spécial)).

J'ai aussi bien compris pour la base de données, je suis en train d'y réfléchir pour en supprimer quelques uns :)
 
WRInaute accro
Magento est une excellent outil et WooCommerce n'est certainement pas adapté à "tout" (loin de là... déjà il n'y a pas de multiboutique décent, donc ça limite beaucoup)

Bon allez .... bon courage :)
 
WRInaute impliqué
Merci !

Et merci pour tes nombreux messages qui me permettent de réfléchir a des éléments qui étaient pour moi pas prioritaire :)

Je reviens très vite pour parler de l'avancer et présenter les premières maquettes graphiques qui BackEnd :)
 
WRInaute impliqué
Bonjour,

Un petit message pour vous tenir au courant le CMS à peu évoluer car :
- J'ai demandé l'avis à un ami expert Symfony et qui maîtrise mieux que moi la POO pour avoir son avis (quelques éléments mineurs à changer).
- J'ai mis à plat la BDD et j'essaye de voir comment l'optimiser.
- J'utilise désormais GitHub (en privé pour le moment) afin de tout versionner.

Il est fort probable que je ne passe pas sous sf2 par la suite mais que j'utilise certains de ses composants, notamment Twig.

A bientôt !
 
WRInaute impliqué
Salut !

Toujours en pleine réflexion et discussion avec un autre dev, je vais regarder pour developper VitalCMS sous Silex (un micro framework).
 
WRInaute impliqué
Merci Spout pour ces liens :)

Cependant je vais rester sur Silex car :
- C'est le microFramework de Symfony qui est l'un des Framework les plus utilisés. La communauté est donc présente
- Il est développé par des Français dont tant qu'à faire autant utiliser un outil qui vient de chez nous
- Il me permet de mettre un pied dans Symfony, ce qui me sera surement bien utile :)
 
WRInaute occasionnel
Haha, bon courage...
J'appuie les conseils de Spout. Mais si je devais me lancer dans la construction d'un CMS en 2015, j'utiliserais absolument des technologies nouvelles.
J'essaie depuis un moment de m'initier à des nouvelles choses. J'ai commencé par Symfony2 puisque tout le monde en parlait, j'ai trouvé ça très bien, mais vraiment rigide et lourd. On doit installer l'usine à gaz pour le moindre site. Ceci dit composer et Twig, c'est déjà super. Puis je me suis dirigé vers javascript, et là j'ai découvert des tas de choses vraiment intéressantes. Pour ne citer que quelques noms en vrac : Node, Npm, Express, Mongo, Angular, Bower, Firebase ou encore Polymer... Actuellement j'ai ma préférence pour Angular et Firebase (angularfire). Seul bémol ça serait le référencement à cause des urls, haha... mais bon j'ai pas approfondi, il y a surement un moyen et au pire, on peut utiliser Node côté serveur.

Bref, un langage en pleine expansion, des plateformes et frameworks novateurs, des nouveaux moyens de stocker les données, et de les synchroniser en temps réel... Et surtout, un esprit de code modulaire vraiment prometteur.
Trop tard :)

A mon avis le CMS du futur, c'est juste un script qui va chercher des modules de code et les assemblent selon les besoins (polymer devrait t'intéresser).

ps: tiens, lavarel est à ce point populaire ?
 
WRInaute accro
Doubrovski a dit:
A mon avis le CMS du futur, c'est juste un script qui va chercher des modules de code et les assemblent selon les besoins
C'est plus un CMS alors c'est un plugin :D
 
WRInaute impliqué
Je suis persuadé que cette mode de ne plus rien à voir sur ces machines et que tout soit virtuel va passer. Il y aura forcement une merde à un moment qui entraînera une belle perte de données ^^'

Après j'ai pris un peu de retard sur les technologies récentes (on remercie au passage le BTS passé il y a 3 ans et qui ne nous à pas enseigné la POO ...) donc le but de ce CMS est de rattraper ce retard. J'ai choisis Silex car il offre plus de flexibilité que Symfony.

J'entends beaucoup parler de Angular et Node, j'y regarde de loin mais une fois Silex maîtrisé je m'y attarderai davantage !
 
WRInaute accro
@Doubrovski: ah un autre qui a osé sortir de la "zone de confort" PHP/MySQL :)

Zend Framework et Symfony sont les 2 frameworks les plus contre productifs que j'aille utilisé. C'est flexible mais absolument pas du "Rapid development framework". PHP != Java.

Symfony est surtout populaire en France: https://twitter.com/Loran750/status/558234676104822786
Laravel est très populaire, mais je trouve que la doc est vraiment faible. Twig (SF2) est clairement mieux fourni que Blade (Laravel).
Je préfère CakePHP.

AMHA c'est mieux que Triixx parte sur un framework que de tout coder from scratch, ça lui permettra d'appréhender les design patterns que j'ai cité plus haut.
 
WRInaute occasionnel
C'est plus un CMS alors c'est un plugin
Pas faux :)
Par module, je pensais à des morceaux de site : des petits paquets contenants html/css/js. C'est ce que fait polymer : des petits modules normés et réutilisables (web components) qui sont utilisés avec de simples balises html personnalisées.
Ce genre de système serait parfait pour un CMS.

c'est mieux que Triixx parte sur un framework que de tout coder from scratch
C'est sûr, mon petit tour des frameworks m'a bien aidé. Maintenant je vais essayer d'approfondir une ou deux technos.
Après, je pense pas que ce soit vraiment très bien de faire aujourd'hui un framework perso en partant de 0. Le grand intérêt de Node/Npm ou Polymer, c'est qu'on se dirige vers des systèmes qui gèrent des petits morceaux de codes injectables dans son site. (153 267 packages sur Npm...). Ça ne sert à rien de réinventer la roue, en tous cas je préfère utiliser des dépendances pour me concentrer sur ce qui est plaisant à coder.
 
WRInaute accro
Doubrovski a dit:
Ça ne sert à rien de réinventer la roue
ça c'est de la fausse excuse toute faite dans 90% des cas. La vérité sur les stagiaires que j'évalue en BTS c'est surtout qu'il ne savent pas créer une roue. C'est les mêmes que tu retrouve en entreprise 6 mois plus tard car de toute façon on ne peut pas les plomber direct sinon le taux de réussite friserait les 10% et c'est pas propre même si cela serait légitime.

Je ne dis pas qu'il ne faut jamais s'appuyer sur une base logiciel de temps en temps mais sur le web c'est typique, beaucoup sont incapables de créer pour leur besoins. Le journée du dev web moyen c'est piocher des morceaux de code sur google et exhiber avec fierté trois pauvres photos qui bougent avec de la transparence (je force légèrement le trait).

C'est comme ça partout note bien, on y peut rien, mais faut pas non plus qualifier de mécanicien le mec qui branche un pc sur une voiture et qui change ce que la machine lui dit de changer car c'est un manutentionnaire pas un mécano. Le mec qui a créé la machine de diagnostique a la limite lui respect mais l'utilisateur :roll:
Hors sur le web déployer des solutions toutes faites sous prétexte qu'elles sont dispo c'est de l'utilisation avec un poil de configuration et très peux de création. Bref parler de développement est souvent un poil abusif voir abaissant pour les gens qui codent vraiment (ceux par exemple qui ont créé ces framework).
C'est au même niveau que ces agences web qui te balancent un CMS open source avec un template gratos et qui sont fier d'avoir changé la couleur de fond ...
Je ne dis pas non plu qu'il faut réécrire l'OS a chaque coup mais entre assembler des modules via des liaisons codées et mettre en oeuvre un groupe de solutions logiciel dans un langage précis c'est pas le même métier.

A l'extrême ce principe ne conduit pas a une maintenance plus aisée c'est le contraire car on ne peux plus bidouiller une rustine facilement a partir de pas grand chose il faut avoir l'outil compatible.
De façon générale aussi et ça se vérifie souvent plus il y a de code plus il y a de problèmes ...
Si sur le web c'est moins grave car ça reste "du code de débutant" c'est nettement différent quand tu code vraiment des trucs vitaux.

"réinventer la roue" > c'est une expression du monde POO, elle y prend d'ailleurs tout son sens car elle est inscrite en filigrane dans les fondements de ce principe. Mais sur le web parler de POO est un poil déplacé dans beaucoup de cas car c'est de la POM (programmation orientée module :D ).
 
WRInaute impliqué
Merci Zed !

Comme je l'ai dis plusieurs fois le but principal est surtout de comprendre le fonctionnement d'un CMS, ses besoins et de comprendre pourquoi Joomla, Wordpress ... ont été fait de tel ou tel façon. Pas de faire un CMS avec vocation de devenir leader sur le marché. Si j'ai 5-10 sites qui l'utilise 1ans après sa sortie, ça me suffira, ça me poussera à le faire évoluer (et donc à m'auto former constamment) sans avoir la pression de 5.000 utilisateurs :)
 
WRInaute accro
C'était surtout une remarque "générique" pas spécialement destinée a ton projet.

Si je devais m'exprimer en tant que créateur / mainteneur de CMS ce qui est mon cas depuis plus de 10ans avec comme toi une utilisation quasi exclusivement personnelle je t'inviterais justement a te détacher de toute technologie tierce afin d'entrer en profondeur dans les concepts techniques avancés qui font parfois une grosse différence mais je sais aussi que pour cela il faut du temps et je comprend très bien que ce ne soit pas ta priorité ou ton axe de travail.
 
WRInaute occasionnel
Je suis bien sûr d'accord sur le fait qu'il faille comprendre comment ça marche. Utiliser un framework, c'est pas bidouiller un CMS avec des scripts trouvés sur le net. Ça demande une bonne connaissance du langage, des design patterns, du protocole http... et ça permet aussi de coder avec une couche d'abstraction supplémentaire, pour garder un code plus clair, plus élégant. Cette couche d'abstraction permet de garder plus facilement une vision d'ensemble du projet, et aussi, de ne pas TOUT devoir assimiler du premier coup. Selon moi c'est bien, car on aborde la complexité du système par couches, et par étapes. On approfondi quand c'est nécessaire, et avec l'expérience on en sait de plus en plus. En plus, le framework est souvent bien bâti, et nous permet d'aborder cette complexité avec les bonnes méthodes. Pas besoin de connaître le langage machine pour faire un programme. Au fil du temps les couches d'abstraction se multiplient pour arriver à des moyens de plus en plus puissants. Aujourd'hui la complexité est telle qu'un apprentissage progressif me semble adapté.

Passer son temps à placer des if() pour tester si telle fonction est disponible sur tel navigateur, copier 3 fois le même code... désolé mais c'est à s'arracher les cheveux. Je laisse ces if à jQuery, ou à d'autres frameworks. Je trouve bien plus intéressant d'accumuler davantage de connaissances génériques, comprendre comment ça marche sans forcément comprendre chaque ligne d'une méthode cachée dans une dépendance. :)

ps: Je suis d'accord que cette manière de coder avec des couches d'abstraction est directement liée à la POO. Je serais curieux de découvrir autre chose.
 
WRInaute accro
Doubrovski a dit:
Ça demande une bonne connaissance du langage, des design patterns, du protocole http ...
Comme tout projet de quelque nature que ce soit.
Doubrovski a dit:
Cette couche d'abstraction permet ... Au fil du temps les couches d'abstraction se multiplient pour arriver à des moyens de plus en plus puissants.
Tout comme un développement bien fait.
Doubrovski a dit:
Passer son temps à placer des if() pour tester si telle fonction est disponible sur tel navigateur,
ça ne m'est jamais arrivé de tester un navigateur. Si ça passe pas sur les 3 courants je code autre chose.

Le souci, encore une fois, c'est pas d'utiliser un framework ou pas, c'est dans cette habitude de passer par un framework car on est incapable de faire la même chose sans dans 90% des cas.
 
WRInaute occasionnel
ça ne m'est jamais arrivé de tester un navigateur. Si ça passe pas sur les 3 courants je code autre chose
C'est plutôt tester une fonction pour voir si elle est disponible (true c'est ok, false c'est IE). Typique du javascript pur, la guerre des navigateurs... D'où l’existence, et le succès de jQuery, des très bons codeurs qui décident d'utiliser leurs connaissances pour s'affranchir de ces absurdités. Les navigateurs n'évoluent pas assez vite, donc on fait une couche d'abstraction pour garder de la lisibilité et de la simplicité.

c'est dans cette habitude de passer par un framework car on est incapable de faire la même chose sans dans 90% des cas
Qu'on parle de framework ou de langage, pour moi c'est la même chose. Le langage est une couche, le framework une autre, souvent utile.
Si on prend l'exemple d'un router, je trouver bien d'en coder un ou deux pour comprendre comment ça fonctionne. Mais passer 2 mois à coder un router aussi puissant que celui d'un framework, pourquoi ? Pendant ce temps on aurait pu comprendre plein d'autres choses :)

J'ai pas cette vision d'un langage comme quelque chose de statique. Ça évolue avec couches supplémentaires, des couches qu'on fait soi même, ou pas, peut-être parfois trop complexes, c'est vrai. Mais finalement c'est quoi le mérite du gars qui fait une liste en allant chercher des données dans une base avec 15 lignes de codes, par rapport à celui qui fait un $find() ? Les 15 lignes de codes seront également compilées.
 
WRInaute accro
zeb a dit:
Le souci, encore une fois, c'est pas d'utiliser un framework ou pas, c'est dans cette habitude de passer par un framework car on est incapable de faire la même chose sans dans 90% des cas.
En même temps tu codes pas en langage machine :)
 
WRInaute impliqué
Mais passer 2 mois à coder un router aussi puissant que celui d'un framework, pourquoi ?
Car tu aura alors compris pourquoi le router de tel ou tel CMS est fait ainsi, tu aura eu plein de reflexion et tu aura fait évoluer ton code. A mon sens c'est plus ça le job de développeur que d'installer un CMS et de lui foutre un design.

Mais chacun son kiff ^^'
 
WRInaute occasionnel
A mon sens c'est plus ça le job de développeur
Tu seras simplement devenu un spécialiste des routers, pas un bon développeur. Un architecte n'est pas bon quand il est spécialiste de la plomberie. Plutôt quand il a une bonne vision d'ensemble, et qu'il sait orchestrer les différents corps d'état. Il doit comprendre comment les charges circulent dans la structure du bâtiment, mais personne ne lui demande de calculer l'épaisseur d'une poutre au mm près. :p

que d'installer un CMS et de lui foutre un design.
Là par contre, c'est vraiment pas ce que je défendais. Un framework est un environnement de travail, un outil, un langage presque. Le CMS est un travail "fini". Je suis pour la cuisine sur-équipée, pas pour les plats surgelés. :)
Mais même, je ne comparerais pas un CMS à un plat surgelé, car ils sont souvent devenus des environnements de travail riches pour qui aime mettre les mains dans le cambouis. C'est juste plus contraignant qu'avec un framework.
 
WRInaute accro
Doubrovski a dit:
Mais même, je ne comparerais pas un CMS à un plat surgelé, car ils sont souvent devenus des environnements de travail riches pour qui aime mettre les mains dans le cambouis. C'est juste plus contraignant qu'avec un framework.
Oui et non, tout dépend de la conception initiale de la bête... Une architecture bien conçue n'est pas particulièrement contraignante, en revanche on ne peut pas "tout" faire avec.
Je regrette quand je vois des gens pousser au delà des limites d'un outil parce qu'ils n'en connaissent pas d'autres et / ou ne savent pas vraiment développer.
 
WRInaute accro
Sujet très intéressant dans lequel je me permet d'intervenir pour apporter ma petite réflexion personnelle.

Selon moi il n'y a pas de CMS idéal car la vocation d'un CMS est de répondre à tous les besoins de la terre entière de la façon la plus aisée possible pour l'utilisateur. Mais ça devient vite une usine à gaz et monter quelque chose de particulier avec un cms devient vite presque aussi complexe que de coder notre besoin en partant de rien. Il faut des années pour être à l'aise avec un CMS et en avoir une connaissance parfaite. Et pendant ce temps le CMS continue d'évoluer ce qui fait que la connaissance que l'on a acquise devient caduque à chaque version.

Quand on utilise un CMS on utilise souvent 1% des possibilités du CMS. Si je veux faiee un simple blog avec wordpress je dois quand même installer toute l'usine.

Le CMS idéal ça serait un CMS qui permette de mettre en place rapidement ce que l'on souhaite faire et rien de plus.

Chaque développeur à son style, ses habitudes. Quand on fait un blog on sait d'avance comment il va être structuré et on ne va pas tout réinventer à chaque fois. Si on fait 10 blog ils tous un peu se ressembler. Il n'y a que le design qui va changer. Alors l'idéal ça serait un CMS qui nous aide à construire notre blog hyper rapidement, selon notre propre style, le plus gros du travail serait le design. Avec un tel CMS on l'utiliserait à 90% à chaque fois.

Pour faire un site vitrine il faudrait un autre CMS qui nous construise le site de quelques pages selon notre propre style. Encore une fois le CMS serait utilisé à 90% et il n'y aurait pas de code lourd qui ne sert à rien pour l'usage qu'on fait du CMS.

Ca serait donc à ça le CMS idéal : un CMS développé par nous même qui remplisse 100% de nos besoins et se fiche des besoins des autres.

Mais tôt ou tard on aura envie d'inclure un blog dans le site vitrine et notre CMS perso pour construire des sites vitrine trouvera sa limite.

On tourne en rond... on en revient à faire un CMS qui sait tout faire. Une usine à gaz qui sera utilisée à 1% de ses possibilités à chaque utilisation.
 
WRInaute accro
Reprenons le problème à l'envers.

Un site web c'est quoi ?

1) Il y a le style, lui même découpé en éléments de style et en éléments de design. C'est le CSS
2) On trouve ensuite les données :
- données textuelles
- données graphiques (illustrations, photos)
- données vidéos
- données sonores
3) on peut y ajouter une surcouche de données SEO qui ne s'adressent pas directement au visiteur (TITLE, Description, attribut ALT, Balises H1, H2, ....)
4) Mais autour de tout ça il y a le liant, la structure du site, la disposition des blocs

L'idéal ça serait quoi ?

1) Je commence à définir le style et le design
2) J'injecte les données d'une page, seulement les données
3) Je met en page toutes les données
4) J'ajoute quelques éléments SEO
5) J'injecte les données d'une autre page
6) Si cette nouvelle page correspond exactement à la mise en page de la première page j'ai juste à cliquer sur un bouton et la page est terminée, sinon je refait une mise en page différente
7) J'injecte les données de la troisième page
8 ) Je peux choisir la mise en page directement en m'appuyant sur celle de la page 1 ou de la page 2 (en un clic).

Vous l'avez compris, chaque page devient un modèle et à chaque nouvelle page on peut utiliser un modèle de page existante. C'est un peu comme cela qu'on procède avec notepad quand on fait un site à la main. Pour chaque nouvelle page on repart de la page existante qui s'y rapproche le plus et on remplace les données.

Pour un site un php on pourrait imaginer le même principe. L'idée c'est d'injecter des données (dans un format particulier, en XML par exemple) et ensuite de les rapprocher d'une mise en page type ou de créer un nouveau modèle de mise en page

Un tel outil ça ne s'appelle plus un CMS. Il y aurait en fait deux outils :
un générateur de code et un éditeur pour préparer les fichiers de données à injecter. Deux outils totalement dissociés.
Et le générateur de code il ne produirait que le code nécessaire pour l'usage qu'on en a. Pas de gestion de blog si on a besoin que d'un simple site vitrine de quelques pages. Pas de code lourd. Pas d'usine à gaz.

Et si on veut ajouter une fonctionnalité on repasse par le générateur qui génère un nouveau code en fonction des nouveaux paramétrages. Il suffit de l'uploader et le tour est joué.

Est-ce que ça existe un tel outil ? Un générateur qui ne génèrerait que le strict nécessaire et qu'on n'ait plus à se trainer la lourdeur (et lenteur) des CMS, ni à coder une ligne de php ou de css ?

Vous allez sans doute me répondre que ça s'appelle un framework

Mais alors pourquoi utiliser un framework pour créer un CMS alors qu'on pourrait utiliser directement le framework pour générer un site internet complet ?
 
WRInaute accro
Doubrovski a dit:
C'est plutôt tester une fonction pour voir si elle est disponible (true c'est ok, false c'est IE). Typique du javascript pur, la guerre des navigateurs... D'où l’existence, et le succès de jQuery, ...
Oui j'avais compris ;-) et effectivement j'ai toujours refusé d'écrire une ligne (de JS par exemple) qui ne produise pas parfaitement la même chose partout. J'ai pas eu besoin de JQuery pour gérer de la compatibilité ni même de tester sur quel navigateur je suis quand t'est en prod c'est trop tard pour ça. Et c'est pareil au niveau CSS ... Soit ça marche soit ça marche pas et c'est pas handicapant et alors ça peut rester.
Marie-Aude a dit:
En même temps tu codes pas en langage machine
Oui et a la limite c'est même pas côté serveur que le souci est le plus important ... j'en conviens mais si on écoute la grande majorité c'est couche sur couche donc faut fatalement qu'il y en ai pour freiner la machine qui exagère dans l'autre sens :D
Mais maintenant que t'en parle ... :lol:
Un architecte n'est pas bon quand il est spécialiste de la plomberie. Plutôt quand il a une bonne vision d'ensemble, et qu'il sait orchestrer les différents corps d'état. Il doit comprendre comment les charges circulent dans la structure du bâtiment, mais personne ne lui demande de calculer l'épaisseur d'une poutre au mm près.
Bah si en fait :D parce que sinon je vois pas trop a quoi il est utile sincèrement mis a part comme c'est le cas précisément en architecture aujourd'hui pondre des merdes qui sont très mal conçus par rapport au traditionnel qui a des qualité techniques beaucoup plus élevées :wink: La tu est tombé sur un sujet ou j'ai encore plus de recul dommage.

Bon après l'architecture logicielle va effectivement dans ton sens mais on ne peut pas dire que ça produise forcement qque chose de mieux... En tous cas c'est une branche "distincte" du développement logiciel.

Je pense qu'il faut faire un distinguo entre la réalité technique et la réalité économique car la frontière est (pour moi) uniquement là. Ce qui pousse positivement a une architecture logiciel composite c'est un souci de fric mais pas un critère de qualité technique. Avec le temps ce choix n'existera plu car on sera dans l'incapacité de faire autre chose que du modulaire.

Aujourd'hui face a une panne bien souvent on reste en rade intégralement, bien avant ça on "bricolait" une solution en attendant mieux mais on finissait ce qu'on était en train de faire. plus cela va plus c'est complexe et plus on a des "composants" irremplaçable (non interchangeable). Bref en matière de technologie on se ferme de plus en plus de portes. Ca c'est un constat de tous les jours c'est moins visible dans la conception logiciel mais c'est pas pour autant absent.
 
WRInaute accro
indigene a dit:
Le CMS idéal ça serait un CMS qui permette de mettre en place rapidement ce que l'on souhaite faire et rien de plus.
Le souci c'est que le "rien de plus" c'est justement ce que tu ne comprend pas dans les CMS car tu ne connais pas php et le reste et que du coup tu ne tire pas parti des CMS que tu as vu ce qui, de fait, te fait penser qu'ils sont lourd.
Un CMS sera toujours effectivement un poil plus lourd que du statique c'est normal mais tu ne fera jamais aussi vite une chose en statique qu'avec un CMS surtout si cela porte sur tout le site ou de nombreuses pages.

Accessoirement la frontière entre site dynamique et statique est depuis longtemps aplanie par les caches d'output qui font que ta page est enregistrée en html tous le temps qu'elle n'a pas de changements. Bref les bon CMS font aussi de la gestion automatique de site statique.

Vous l'avez compris, chaque page devient un modèle et à chaque nouvelle page on peut utiliser un modèle de page existante. C'est un peu comme cela qu'on procède avec notepad quand on fait un site à la main.
Dans le monde réel on dit pas "modèle" mais "template" tu croix que les concepteurs de CMS ont oublié ça ? De plus si tu automatisais les opération que tu fait avec notepad tu te rendrais compte que ce sont les fonctionnalités d'administration que propose les CMS.
 
WRInaute accro
zeb a dit:
Je pense qu'il faut faire un distinguo entre la réalité technique et la réalité économique car la frontière est (pour moi) uniquement là. Ce qui pousse positivement a une architecture logiciel composite c'est un souci de fric mais pas un critère de qualité technique. Avec le temps ce choix n'existera plu car on sera dans l'incapacité de faire autre chose que du modulaire.
J'ai une vision assez nuancée par rapport à ça. Si on sort un peu de notre tout petit monde des petits sites gérés et des applis codées par des webmasters seuls derrière leur écran, le modulaire, les boites, la POO ne sont pas "seulement" des outils économiques, ce sont des outils qui forcent à la qualité par la standardisation.

La discussion qui se dessine dans ce fil a de douces saveurs de réchauffé par rapport aux discussions / argumentations qui avaient lieu dans des grosses boites, puis des moyennes boites quand l'ERP arrivait pour remplacer la solution maison amoureusement codée à coup de verrues et d'exceptions hard codées par une équipe d'informaticiens vieillissants qu'on entourait de tous les soins possibles, parce qu'il y avait UN mec et un seul qui était capable de lancer le processus maison, devenu ingérable à force d'être super optimisé.

J'ai déjà entendu ces "ce n'est pas de l'informatique", "c'est lourd", "c'est pas optimisé", etc... qui n'était pas faux, mais qui n'était qu'une vision d'un bout de la lorgnette.

Oui il faut du temps pour maitriser un CMS, et j'ai mis trois ans à connaître WP dans ses moindres recoins. Oui, son propre CMS on le maîtrise dans les moindres recoins au fur et à mesure qu'on le monte. Mais... même en le documentant parfaitement, le mec qui reprend un jour l'outil, il met combien de temps à le maitriser ? Quelle est la rentabilité - bouh le vilain mot - pour lui de le maitriser ? Il va tout simplement démolir le truc et migrer le site du client vers une autre solution, la sienne ou un CMS.

Alors oui, je suis super contente qu'un autre développeur se tape le boulot de générer les petites boites pour stocker les balises og: à ma place, et fasse les mises à jour à ma place quand il y a un truc qui change, à partir du moment où son plugin est suffisamment bien codé pour me permettre de faire les modifs que je veux où je veux.
Parce qu'il faut être honnête... si je devais faire moi-même l'ensemble de fonctions "méta données dans le header", je recoderais à 99% ce qu'il a fait. Pour les 1% restants, parce que je connais bien mon outil, j'ai pu choisir le plugin qui a le meilleur rapport "usine à gaz / fonctionnalités / hookabilité", qui n'est pas le plugin le plus recommandé qu'on retrouve partout, et dont je vais remplacer 3% par ma propre sauce.

Que ce soit un "plugin externe" ou "mon code" ou "le core" du CMS, en fait c'est exactement la même chose : un autoload de classes et / ou de fonctions procédurales, et un appel dans un templates.

L'avantage du CMS ? Une API complète qui me permet de générer en une demi-heure une gestion admin complète pour une cinquantaine de champs, avec toute la validation des données, le chargement des js avec les dépendances, la sauvegarde des données dans la base avec tous les tests d'existence, remplacement,etc après sanitization.

Avec la possibilité de se faire son propre framework en sur-couche :D

Ce que font d'ailleurs de nombreux plugins.

On va prendre un exemple "parlant" pour ceux qui connaissant WordPress :
un des plugins les plus utilisés est Advanced Custom Fields, qui fournit une interface "clic de souris" pour tous les gens qui ne savent pas coder, pour créer leurs champs personnalisés, avec des trucs sympas (date picker, champs répétables, upload d'images, etc)
Bon, c'est bien, c'est vraiment bien fait, bourré de fonctionnalités, mais :
- les trucs vraiment "intéressants" sont payants
- il me manque une partie importante

J'ai refait mon propre ACF :D c'est nettement moins joli en interface, il n'y a aucun clic de souris, et ça m'a pris deux jours. Mais j'ai tout ce qu'il faut, et aucun problème de cohabitation entre "mes" champs personnalisés et ceux gérés par ACF, et pas le besoin de comprendre les entrailles d'un plugin. Là, le rapport "usine à gaz / fonctionnalités / hookabilité" était nettement défavorable.

Par contre, un autre plugin, Gravity Forms, avec tout l'environnement qui va autour, répond jusqu'à maintenant complètement à mes besoins, avec un rapport "usine à gaz / fonctionnalités / hookabilité". Je "pourrais" développer mes formulaires moi-même, mais :
- par rapport au boulot nécessaire pour refaire la solution intégrable avec presque tout, y compris les moyens de paiement, je n'en vois pas la nécessité
- GF, fondamentalement, à la différence d'ACF, c'est de la fonctionnalité front-end, avec des données enregistrées comme il faut dans le modèle de données. Ça veut dire que je peux m'en débarrasser sans aucun problème du jour au lendemain si je trouve mieux.

Dans l'absolu, pour être dans la logique "la qualité maximum", on devrait coder son propre langage ... presque plus personne ne le fait (et certainement pas les "vrais informaticiens" qui sont sur ce forum)
 
WRInaute accro
Marie-Aude a dit:
J'ai une vision assez nuancée par rapport à ça. Si on sort un peu de notre tout petit monde des petits sites gérés et des applis codées par des webmasters seuls derrière leur écran, le modulaire, les boites, la POO ne sont pas "seulement" des outils économiques, ce sont des outils qui forcent à la qualité par la standardisation.
La "standardisation" oui a 200% mais quand elle est le reflet d'une norme écrite réfléchie documentés. La pour rester focalisé sur le microcosme informatique du web c'est encore et surtout une standardisation d'usage, je dirais presque de mode. C'est souvent la solution qui rend le résultat le "moins pire" et le plus "fun" qui prend le dessus, moins la qualité technique (au pire on va avancer la loi moore pour se justifier sans parler du "réinventer la roue" ).

Pour moi c'est l'intervenant qu'on souhaite avant tout standardiser ...

Marie-Aude a dit:
Oui il faut du temps pour maitriser un CMS, et j'ai mis trois ans à connaître WP dans ses moindres recoins. Oui, son propre CMS on le maîtrise dans les moindres recoins au fur et à mesure qu'on le monte. Mais... même en le documentant parfaitement, le mec qui reprend un jour l'outil, il met combien de temps à le maitriser ? Quelle est la rentabilité - bouh le vilain mot - pour lui de le maitriser ? Il va tout simplement démolir le truc et migrer le site du client vers une autre solution, la sienne ou un CMS.
Le mec qui reprend un jour l'outil il met autant de temps que toi avec WP ... ça c'est une généralité du monde pro tu ne remplace pas Pierre par Paul sans un temps de maîtrise. Les compétences pour cela ne vont pas se trouver dans l'intégrateur car l'ingenierie inverse n'est pas son fort il faut déjà que l'ingenierie le soit.

C'est en ce sens et vis a vis de ces deux points que je case la raison économique au premier plan du choix technologique.
 
Membre Honoré
Bonjour,

Questions :
- Le CMS sera-t-il Open Source ?
- Possibilité de modules externes ?
Merci. :)

Cordialement.
 
WRInaute impliqué
Salut,

Oui une fois la V1 en place (c'est pas gagné vu le peu de temps que j'ai pour le moment :mrgreen:) il sera Open Source. Il faut juste que je regarde pour quelle licence optée.

Et oui le but est de pouvoir importer facilement compétences et modules.
Un composant est 1 extension plus complète créant lors de son installation, une modification en base de données comme par exemple : ajout d'une boutique e-commerce, ajout d'un forum ...
Un module est 1 extension pouvant fonctionner seul ou se "couplant" à une extension (native ou ajouté). Un module ne devra faire que des interrogation en base de données, pas d'insertion ni de suppression. Uniquement du front end comme par exemple : Affichage des derniers produits de la boutiques, les statistiques du forum, les derniers articles publiés ...
 
Discussions similaires
Haut