Template Joomla! 4 : quel framework privilégier ?

[RobertG]

Merci des ces infos.

Jusqu'ici, je n'ai pas utilisé de Framework, mais en ce moment, c'est une cliente qui a flashé sur un template non encore disponible pour J 4, puis sur la démo de Marc sur Astroid.
Comme elle veut personnaliser vraiment à son gré, il faut qu'on parte donc, le template qui lui plait risquant de ne pas être disponible avant 3 mois, partir d'un template existant, soit basique comme les zero ou one livrés avec Astroid (avec l'avantage de la gratuité) ou un template élaboré sur la même base (avec la nécessité de mise à jour et donc d'abonnement).
Certaines fonctionnalités de ces templates commerciaux n'étant pas disponibles seules comme la personnalisation d'UIkit qu'a fait Joomlaplates (et j'ai constaté que je ne serais pas en mesure d'utiliser la version gratuite de ce script pour en faire autant), passer à une extension dédiée comme le Widgetkit de Yootheme veut dire aussi prendre un abonnement.

Quant à penser à modifier Cassiopeia, ce n'est pas d'actualité pour moi...

[Tortue Genial 69]

Reste le bon vieux template maison ;-)
A l'agence nous n'utilisons aucun builder ou templates depuis 12 ans, quelques projets avec une base Gantry pour "gagner" du temps sur les layout en général mais pour la dernière refonte client en date nous sommes de nouveau repartit de 0 ou presque (sans framewok lourd juste un reset css de snackss). Je les tests régulièrement pourtant mais à chaque fois les trouve lourd et cela fait ca de moins à mettre à jour ou à chercher les soucis de compatiblité, de duplicate js etc.

Par conte evidemment faut bosser l'UX et surtout l'UI complètement avant de se lancer à intégrer ;-)

Pour les futurs projets J!4 (en 2022 et encore après que tout soit bien testé et migré coté extentions populaires) ca sera surement une base de Cassiopea très largement adaptée pour nous. J!4 charge déjà BS5 en framework, bon choix ou pas cela reste à tester ;-)

Pour donner la main aux clients, cela passe par les options de templates c'est très souple et centralisé.

J'avoue que je suis à moitié d'accord avec toi
c'est vrai que certains buider peuvent sembler lourd et dans l'absolu, ce sera toujours le cas par rapport à du dev ou de la customisation sur mesure type CSS, overrides, etc..

Mais pour mettre entre les mains de clients qui, desfois (voire souvent), ne sont pas des gens techniques, je trouve que même la, les settings des framework sont déjà trop compliqués.

Après c'est comme toujours, tour dépend qui on a en face. Mais dans 90% des cas, le côté "jouet" du builder ou le client peut glisser, déplacer etc...et voir le rendu en temps réel, en terme d'expérience utilisateur c'est juste incomparable (même si c'est pas parfait j'en conviens).

Sans compter le budget ou beaucoup ne pourront pas se payer se travail d'UX avancé dont tu parles.donc ça reste quand même pour une niche de clients.

[Niko.Semaphore]

Oui evidemment tout fépends du contexte mais de base je considère que laisser la main au client de jouer avec les polices, couleurs etc c'est déjà de trop On nous paye pour créer une charte et la faire respecter sur l'ensemble du site. J'ai un projet sérieux pour lequel on utilise un pagebuilder (le CK) car on avait besoin de donner la souplesse pour créer des pages type magazine et d'y ajouter des plug-ins/blocs maison lié à un autre composant.

Aujourd'hui ce qui me semblerait le plus opérationnel serait un Gutemberg pour J! (en plus d'un wisysig classique) ce n'est pas un page builder dans le sens où il est plus souple/moins propriétaire et que la communauté developpe au final des blocks pour Gutemberg, là où pour J! chacue société développe son propre Pagebuilder "plusmieuxquelesautres" dispersant les énergies.

[Tortue Genial 69]

Oui evidemment tout fépends du contexte mais de base je considère que laisser la main au client de jouer avec les polices, couleurs etc c'est déjà de trop On nous paye pour créer une charte et la faire respecter sur l'ensemble du site. J'ai un projet sérieux pour lequel on utilise un pagebuilder (le CK) car on avait besoin de donner la souplesse pour créer des pages type magazine et d'y ajouter des plug-ins/blocs maison lié à un autre composant.

je suis d'accord avec toi, après le client est propriétaire de son site, donc s'il souhaite le modifier, c'est quand même problématique de l'enfermer dans du vendor lock-in.
et puis ils sont grands, majeurs et vaccinés, donc même si c'est eput-être un peu infantilisant, à eux d'être aussi responsable de ce qu'ils modifient.
on n'est pas leur parents non plus

chacue société développe son propre Pagebuilder "plusmieuxquelesautres" dispersant les énergies.

c'est vrai, mais c'est le marché qui veut ça aussi et surtout le fait que chacun à le droit de proposer tel ou tel service ou telle innovation.
et puis la libre conccurence permet aussi de motiver les gens et d'innover.
regarder l'open source, y'a de tout partout et c'est ça aussi qui en fait la richesse.
et puis quand on regarder bien, peu importe le ou les outils, les très bons se distinguent très vite dans le lot..y'en à pas 10 000 non plus

[Niko.Semaphore]

Chacun sa vision du business web mais assurant la maintenance complète de nos clients et assistance on leur livre deux choses : un code admin super user et des comptes rédacteurs (voire manager) MAIS toute utilisation du super user qui modifierai quoique ce soit "casse" le contrat de maintenance et toute prestation qui suivrait leur intervnetion sera payante au delà du contrat. Nous sommes garant du bon fonctionnement de leur site et pour ce faire on doit leur mlimiter la voilure. Ils peuvent tout reprendre à loisir dans certes dans du lock. C'est différence très notable et obligatoire pour assurer une relation de confiance. Par exemple récemment un client à utiliser le compte super user pour modifier des menus pour au final "casser" uen partie du fonctionnement du site. Suite à son appel on a retracé son activité, réparé et facturé en plus du contrat de maintenance. Surtout que si il nous avaaient contacté on les aurai assisté dans leur manip.
Si tu interviens sur ta voiture/vélo et que tu casses un truc et te pointes chez ton concesionnaire/vendeur il ne va pas te dire "ok on répare gratis parce que c'est votre droit de bidouiller".

Pour les pagebuilder c'est surtout le soucis dévolutions/compatiblité qui me gène. Avec un "gutemberg" Joomla qui serait étendu par des éditeurs on aurait un noyau viable dans le temps avec des éléments de base (titre, paragraphe etc) étendus par des élements "payant" genre carte, sliders etc comme les actuels plugs XTD fournit par les éditeurs tiers avec leurss extentions parfois (docman par exemple) ou Showtimegallery. La difference notable avec les pagebuilders actuels c'est que chacun developpe ses plug-ins de son coté et passé d'un pagebuilder à un autre est impossible si l'un devenait plus pertinent. Deplus le code généré est vraiment... chargés pour certains. De notre coté on arrive mais de manière très artisanalme à refaire cela en construisant des custom fields non affiché que les clients appellent dans le cors de l'article mais c'est très exigeant pour le rédacteur et pas du tout intuitif surtout quand le même rédacteur connait déjà Gutemberg par ailleurs cela lui semble très archaïque.

[schott0200]

Bonjour, personnellement avec Joomla! 4, je vais rester au plus roche des fonctionnements natifs de Joomla! et c'est pourquoi j'ai choisi T4 qui est simple, complet, efficace et qui garde un fonctionnement au plus proche de Joomla!. J'ai fait la traduction du template si besoin. Tu pourras voir le résultat ici : https://www.joomanji.fr/