Tests et avis sur les Page Builder

[GraphiqueDesign]

Je ne saisis pas bien la question. Quand ce sont des pages statiques, j'utilise intégralement le Page Bluilder pour faire le travail, donc les addons de texte ou d'entête qui conviennent. Quand juste une partie du texte de la page statique doit pouvoir être mis à jour, je peux utiliser un module personnalisé importé via l'addon qui va bien ou autre chose, on trouve toujours une solution.

[Tortue Genial 69]

en fait ce n'est pas le sens de ma question, je vais essayer d'être plus clair désolé

déjà qu'entends tu par pages statiques ?
quel distinguo fais-tu entre page statique et non statique ?
donc si je comprends bien, les textes de tes pages sont directement dans le page builder et pas dans les articles joomla?

en effet on trouve toujours une solution, mais pas nécessairement la plus adaptée pour l'utilisateur final

[Tortue Genial 69]

ajout du page builder T4 de Joomlart !
qui n'est peut-être pas encore en version stable.

[GraphiqueDesign]

en fait ce n'est pas le sens de ma question, je vais essayer d'être plus clair désolé

déjà qu'entends tu par pages statiques ?
quel distinguo fais-tu entre page statique et non statique ?
donc si je comprends bien, les textes de tes pages sont directement dans le page builder et pas dans les articles joomla?

en effet on trouve toujours une solution, mais pas nécessairement la plus adaptée pour l'utilisateur final

Ce que je nomme "page statique", c'est une page qui n'a que très peu de chance d'être modifiée fréquemment, une page de présentation d'un site vitrine par exemple. En général, on y touche plus trop une fois en ligne, enfin dans mon monde.

Une page non statique, pour reprendre ton expression, c'est une page que selon moi, on modifie sans cesse, comme les pages d'un blog par exemple. De plus, c'est l'utilisateur final qui intervient à ce niveau, contrairement à la page statique où selon moi, c'est au Web Designer de porter les modifications, si possible, celui qui a conçu le site. Les enrichissements typographiques, le graphisme, etc, je considère que l'utilisateur final n'a pas forcément les compétences graphiques pour intervenir sur les pages statiques. D'ailleurs, pourquoi aurait il sollicité les services d'un Web Designer s'il pouvait le faire lui-même ...

Oui, pour les pages statiques donc, j'utilise les outils de texte et de mise en page du PageBuilder qui propose une multitude de réglages (dont typographiques) pour donner au rendu final de la page, un esthétisme irréprochable et attrayant. Par contre, pour les pages non statiques, je préfère utiliser les articles et les outils natifs de Joomla qui sont eux, totalement adaptés à l'utilisateur final. L'esthétique de ces pages est sous-jacent puisque soumis au fichier custom.css, l'utilisateur final ne fait dans ce cas, que rentrer des informations sans trop se soucier de la mise en page.

Un PB permet de faire de belles choses en un minimum de temps, c'est selon moi un outil de productivité qui demande une certaine maitrise. Il doit aussi n'être utilisé que là où son usage est le plus productif et adapté.

[Tortue Genial 69]

ok je vois mieux ta définition des choses.
je comprends tout à fait la séparation que tu fais entre les deux, mais je trouve que ce n'est pas la bonne approche, enfin d'après ce que j'ai comme retours de mon coté, ce qui est tout à fait subjectif je te l'accorde.
je pense que la tendance est à rendre l'utilisateur de plus en plus autonome sur le contenu uniquement..quoi que..je vais y revenir.

dans un premier temps, je suis d'accord que si une personne fait appel à un intégrateur ou webmaster, ce n'est pas pour le faire lui même.
le soucis est que, je trouve, de plus en plus de personnes demandent à pouvoir faire des modifications simples par elles mêmes, qui malheureusement ne sont souvent pas accessibles simplement.

le meilleur exemple est la mise en page d'une page.
même si le client n'est pas qualifié pour faire du CSS, il a très souvent besoin de pouvoir faire des petites ajustements lui même.
exemple, mettre une image à gauche et du texte à droite, faire des colonnes, des marges, travailler un peu des images etc....

et la, si tu sépares les pages comme tu le fais, tu seras tôt ou tard embêté car le jour ou il voudra modifier une page que tu n'as pas prévue comme ça, c'est vite le bazar.
après cela dépend bien évidemment du type de clients que tu adresses.

je pense que l'utilisateur doit se concentrer sur le contenu et sa mise en forme et le webmaster/intégrateur sur la mise en place du site en terme de structure.
bien que lorsqu'on livre un site, il est généralement remplit de contenu, par la suite le client va inévitablement vouloir se faire des modifs lui même.

le problème n'est pas simple et je n'ai pas répondu à tous les problèmes je l'admet.
c'est pour ça qu'un page builder est interréssant car il permet de gagner en productivité (coté intégrateur/webmaster) mais aussi d’éventuellement donner un peu de liberté au client..moyennant formation car la prise en main n'est pas toujours plug & play.

sinon, et c'est la que je n'arrive pas à y voir clair, c'est que le page builder permettrait de concevoir la structure/la mise en page, mais si le client doit se cantonner au contenu, il faudrait que cela reste dans les articles joomla car beaucoup plus simple à prendre en main pour lui.

d'ou ma question : est-il possible avec un page builder de créer la structure des pages et de garder le contenu dans joomla?

[RobertG]

Je viens de vérifier : en ce qui concerne PageBuilder CK, les données du contenu principal sont dans la table "#__content", mais des infos complémentaires dans une table de PageBuilder.
J'essaierai peut-être de désinstaller PBCK pour voir ce que donne cette suppression au niveau du rendu.

Bon, je viens de faire le test : aucune perte sinon celle de la disposition.
Il s'agit d'un site de test a minima, recettes de cuisine, qui ne comportent qu'une image d'entête, du contenu et un module ou champ complémentaire pour les ingrédients, avec la version free du composant (sans le plugin "Parameters" donc). Les ingrédients définis sous PBCK comme devant s'afficher dans la colonne de droite de l'article se retrouvent sous le texte principal.

Il faudrait tester avec des compositions plus complexes, mais je reste persuadé que le contenu ne sera pas perdu en cas de désinstallation de PBCK.

[Tortue Genial 69]

Je viens de vérifier : en ce qui concerne PageBuilder CK, les données du contenu principal sont dans la table "#__content", mais des infos complémentaires dans une table de PageBuilder.
J'essaierai peut-être de désinstaller PBCK pour voir ce que donne cette suppression au niveau du rendu.

Bon, je viens de faire le test : aucune perte sinon celle de la disposition.
Il s'agit d'un site de test a minima, recettes de cuisine, qui ne comportent qu'une image d'entête, du contenu et un module ou champ complémentaire pour les ingrédients, avec la version free du composant (sans le plugin "Parameters" donc). Les ingrédients définis sous PBCK comme devant s'afficher dans la colonne de droite de l'article se retrouvent sous le texte principal.

Il faudrait tester avec des compositions plus complexes, mais je reste persuadé que le contenu ne sera pas perdu en cas de désinstallation de PBCK.

good news deja !

[Tortue Genial 69]

hello,

petit up sur le sujet.
est ce que certains ont tésté nicepage ?
je l'ai testé en surface, mais je manque de recul..donc si certains ont des retours

merci

[Tortue Genial 69]

Ce que je nomme "page statique", c'est une page qui n'a que très peu de chance d'être modifiée fréquemment, une page de présentation d'un site vitrine par exemple. En général, on y touche plus trop une fois en ligne, enfin dans mon monde.

Une page non statique, pour reprendre ton expression, c'est une page que selon moi, on modifie sans cesse, comme les pages d'un blog par exemple. De plus, c'est l'utilisateur final qui intervient à ce niveau, contrairement à la page statique où selon moi, c'est au Web Designer de porter les modifications, si possible, celui qui a conçu le site. Les enrichissements typographiques, le graphisme, etc, je considère que l'utilisateur final n'a pas forcément les compétences graphiques pour intervenir sur les pages statiques. D'ailleurs, pourquoi aurait il sollicité les services d'un Web Designer s'il pouvait le faire lui-même ...

Oui, pour les pages statiques donc, j'utilise les outils de texte et de mise en page du PageBuilder qui propose une multitude de réglages (dont typographiques) pour donner au rendu final de la page, un esthétisme irréprochable et attrayant. Par contre, pour les pages non statiques, je préfère utiliser les articles et les outils natifs de Joomla qui sont eux, totalement adaptés à l'utilisateur final. L'esthétique de ces pages est sous-jacent puisque soumis au fichier custom.css, l'utilisateur final ne fait dans ce cas, que rentrer des informations sans trop se soucier de la mise en page.

Un PB permet de faire de belles choses en un minimum de temps, c'est selon moi un outil de productivité qui demande une certaine maitrise. Il doit aussi n'être utilisé que là où son usage est le plus productif et adapté.

Re,

Je reviens sur ce que tu disais car j'ai pris un peu de temps pour re-décomposer les choses, suite à certaines demandes clients récentes.
En effet je comprends la différence entre les 2 et je fais plus ou moins pareil actuellement (sauf que j'utilise pas encore de page builder).

Page statique : c'est l'admin qui modifie via page builder
Page dynamique : c'est le client qui gère et la mise en page est celle du template au final (via custom.css)

Mais en fait c'est pas toujours simple de différencier les 2.
J'ai eu de récentes demandes ou cela n'a pas été simple de catégoriser les pages car peu après avoir mis le site en ligne, le client à voulu modifier lui même certains réglages, mais ce n'était pas possible car il n'était pas censé le faire.

Typiquement, comment tu fais ou ferais, pour permettre à un client de faire la mise en page ci-dessous, simplement, sans page builder?
On est typiquement dans un cas ou :

- on a besoin d'une mise en page dédiée
- mais c'est du contenu pur car le client peu rajouter des blocs
- mais il ne l'a modifie pas tous les jours non plus

Le page builder semble adapté, mais cela impose un niveau de manipulation plus avancé que de remplir un simple article.

Du coup la frontière entre les 2 types de pages devient très mince...

[dolmenhir]

Salut,

Typiquement, comment tu fais ou ferais, pour permettre à un client de faire la mise en page ci-dessous, simplement, sans page builder?

[...]

Le page builder semble adapté, mais cela impose un niveau de manipulation plus avancé que de remplir un simple article.

Moi j'utilise les deux fonctions sur de nombreux projets.
Pour les + petits et les moins actualisés, ce n'est que du page builder.

Pour les autres c'est un mix, entre la partie "dynamique" (parties du site où il y a de fréquentes màj comme les actus) et la partie "statique" où on trouve des contenu comme les mentions légales, la politique de confidentialité, etc.

Mais j'ai des sites en "full page builder" que les clients peuvent modifier eux-même, de façon simple et ergonomique, depuis le front-end, avec en plus la possibilité de voir, en direct-live et avant validation, le rendu de la modification.
C'est un vrai + par rapport aux articles "classiques" et un vrai confort pour les clients.

Le niveau de manipulation est également relativement simple quand le client ne cherche pas à pousser les murs.
S'il s'en tient à modifier les textes et images, ça va. Mais s'il veut ajouter des lignes, des blocs et des colonnes, là il faudra préalablement l'avoir formé à l'outil, même si les builder actuel sont relativement intuitifs et ergonomiques.

Pour ton exemple de page "classiques", avec une feuille de style bien pensée et quelques classes bien placées, l'utilisateur pourrait faire ça de façon simple en plaçant :
- l'image 1
- le texte 1
- l'image 2
- le texte 2

sans même chercher à faire la moindre mise en forme, ou presque.
C'est toute la force des CSS

A savoir que l'éditeur JCE permet de générer des templates de contenu, réutilisables à volonté.
Il y a aussi l'extension "content templater" de Regular labs qui mérite un petit détour.

Dol.

[Tortue Genial 69]

Merci pour ce retour, c'est cool de voir comment travaillent les autres ça permet de mettre les choses en perspectives

Juste quelques précisions :

Pour les + petits et les moins actualisés, ce n'est que du page builder.

ok why not, ca permet d'être plus rapide...mais si jamais du jour au lendemain il leur prend l'envie de mettre les mains dedans, comment tu gères?

S
Pour les autres c'est un mix, entre la partie "dynamique" (parties du site où il y a de fréquentes màj comme les actus) et la partie "statique" où on trouve des contenu comme les mentions légales, la politique de confidentialité, etc.

donc pour la partie dynamique tu utilises les articles?
et pour la partie statique page builder?

Mais j'ai des sites en "full page builder" que les clients peuvent modifier eux-même, de façon simple et ergonomique, depuis le front-end, avec en plus la possibilité de voir, en direct-live et avant validation, le rendu de la modification.
C'est un vrai + par rapport aux articles "classiques" et un vrai confort pour les clients.

ok je vois, mais par contre tu peux déjà le faire en donnant les droits d'accès aux articles depuis le front-end.
donc c'est pareil au final non?

pour ma part, j'ai jamais voulu ouvrir l'accès au front-end et ce pour 2 raisons :

- coté sécurité : cela permet d'ouvrir une "brèche" potentielle...toutes proportions gardées bien entendu, mais çà retire un "point of failure" comme in dit ( ou SPOF pour les intimes )
- coté apprentissage : le fait de cloisonner l'utilisateur au back-offce permet au client d'avoir accès a d'autres fonctions comme l'ajout de liens de menus etc...perso cela m'a été demandé. de plus, pas de tuning CSS à faire dans le back-office, contrairement au front-end ou si tu veu une cohérence graphique, il faut retoucher des choses..maintenant c'est un choix perso

Le niveau de manipulation est également relativement simple quand le client ne cherche pas à pousser les murs.
S'il s'en tient à modifier les textes et images, ça va. Mais s'il veut ajouter des lignes, des blocs et des colonnes, là il faudra préalablement l'avoir formé à l'outil, même si les builder actuel sont relativement intuitifs et ergonomiques.

Pour ma part j'utilise cet éditeur que je trouve très bien coté ergonomie : https://www.joomunited.com/products/dropeditor
Combiné a DropFiles pour les fichiers : https://www.joomunited.com/products/dropfiles
Et DropPics pour les images : https://www.joomunited.com/products/droppics

J'ai utilisé JCE depuis toujours (donc depuis + de 10 ans en gros) et j'ai changé il y a peu.
La raison : bien que JCE soit incroyablement stable et efficace, je trouve (et d'après des retours clients) qu'il est à la ramasse coté approche et ergonomie.
Les clients avaient beaucoup de mal à faire des choses simples, soit par Drag & Drop soit par simples click.
De plus la gestion des images et fichiers est trop techniques, il y'a trop d'options et le rendu visuel n'est pas top (et j'utilisais pourtant des profils restreints pour les clients).
JCE s'est récemment amélioré avec la gestion des colonnes etc..mais il n'est pas très user friendly je trouve.

Du est-ce que dans ton ou tes page builder tu peux utiliser un éditeur tiers style JCE ou DropEditor?

Pour ton exemple de page "classiques", avec une feuille de style bien pensée et quelques classes bien placées, l'utilisateur pourrait faire ça de façon simple en plaçant :
- l'image 1
- le texte 1
- l'image 2
- le texte 2

sans même chercher à faire la moindre mise en forme, ou presque.
C'est toute la force des CSS

A savoir que l'éditeur JCE permet de générer des templates de contenu, réutilisables à volonté.
Il y a aussi l'extension "content templater" de Regular labs qui mérite un petit détour.

Dol.

Oui c'est possible en effet, mais ça reste carrément moins intuitif pour le client.
Je fais déjà énormément de choses avec du CSS, mais tôt ou tard il faudra mettre les mains dedans.

Je vais jeter un oeil sur content templater merci

[dolmenhir]

mais si jamais du jour au lendemain il leur prend l'envie de mettre les mains dedans, comment tu gères?

L'utilisateur peux mettre les mains dedans s'il le souhaite. Mais comme pour les articles, s'il fait des bêtises, il devra assumer.
Mais en fait j'anticipe puisqu'une fois les pages statiques faites et livrées, je les exporte au format json.
Si le client, bien que préalablement formé, "casse" quelque chose, je n'ai qu'à importer le json pour retrouver ma page telle qu'elle était avant que le client n'intervienne.
Sous oublier les sauvegardes quotidiennes s'il a fait une très grosse bêtise.

Ensuite, un outil comme SP PageBuilder permet d'être utilisé directement dans l'article (en fait on découvre un onglet qui permet de basculer entre le mode d'édition classique et le pagebuilder) et il y a même un type de module dédié.
A savoir que SP Pagebuilder, quand on s'en sert dans un article, copie/colle le contenu de certains blocks (ceux qui ont du contenu de type texte) dans la partie d'édition classique.
Cela signifie que si jamais on désactive ou supprime le pagebuilder, ces contenus ne sont pas perdus, même s'il faudra reprendre leur mise en forme.

Il est également possible d'avoir un mix très utile pour les blog :
- saisir un texte d'intro,
- placer une ligne de rupture "lire la suite"
- éditer l'article complet avec le pagebuilder

On peut alors afficher une page de blog de catégorie classique, qui affichera l'intro, et en cliquant sur le "lire la suite" on tombera sur la page mise en forme avec le builder.

donc pour la partie dynamique tu utilises les articles?
et pour la partie statique page builder?

En fait j'ai un peu menti... les articles ultra basique, comme les mentions légales ou la politique de confidentialité, c'est généralement des articles simples via l'éditeur classique de Joomla!
Un peu de style appliqué aux chapitres, et sous-chapitres via l'éditeur avancé et ça suffit.
Le builder sera plutôt utilisé sur des pages "statiques" qui nécessitent une petite mise en forme spéciale, plus simple à faire avec le builder qu'avec un article standard, genre un page de contact avec des coordonnées à gauche sur 1/3 de la page et un formulaire à droite sur les 2/3 restant, et en dessus un plan de localisation dynamique type GG map.
Mais l'emploi de champs personnalisés et l'arrivée de nouvelles fonctionnalités dans la v4 de Joomla, va me conduire à reconsidérer le traitement et l'organisation de certains contenus.

ok je vois, mais par contre tu peux déjà le faire en donnant les droits d'accès aux articles depuis le front-end.
donc c'est pareil au final non?

Non.
Ce qui est radicalement différent c'est la prévisualisation de l'article en même temps qu'on le saisi et avant même de le valider et donc d'écraser l'ancien contenu.
Avec un joomla classique, en front comme en back, on édite le contenu via l'éditeur avancé mais il faut valider pour voir la page se remettre en forme avec tous les éléments qui la composent.
Avec un builder, on édite dans la mise en forme et toutes les modifications se visualisent sans avoir à sauvegarder.
On ne sauvegarde la page qu'à la fin, quand on est content du rendu final.
A noter qu'une page réalisée avec un page builder peut intégrer des bloc de différentes natures, comme un slider, un formulaire, un compteur à rebours, un tableau de prix, une fiche client, des contenus en accordéon, etc... et toutes les modifications de ces éléments se font là aussi avec une une prévisualisation en temps réel, sous les yeux de l'utilisateur.
Avec du Joomla classique, il faut éditer l'article, puis aller voir du côté des modules pour, par exemple, modifier le slider, le formulaire, etc...
Rien que pour ça, le page builder c'est le champion de l'édition.

pour ma part, j'ai jamais voulu ouvrir l'accès au front-end et ce pour 2 raisons :
- coté sécurité : cela permet d'ouvrir une "brèche" potentielle...toutes proportions gardées bien entendu, mais çà retire un "point of failure" comme in dit ( ou SPOF pour les intimes )
- coté apprentissage : le fait de cloisonner l'utilisateur au back-offce permet au client d'avoir accès a d'autres fonctions comme l'ajout de liens de menus etc...perso cela m'a été demandé. de plus, pas de tuning CSS à faire dans le back-office, contrairement au front-end ou si tu veu une cohérence graphique, il faut retoucher des choses..maintenant c'est un choix perso

Ben en terme de sécurité, je préfère laisser les utilisateurs sur le front et limiter les accès à l'admin.
Le client, ce dont il a généralement besoin, c'est un accès au contenu, textes et images.
Lui ouvrir la porte de l'admin, même de manière étroite, ne me semble pas nécessaire, voire imprudent même si j'ai, là aussi, un certain nombre de garde-fous.
C'est d'ailleurs pour ça que par défaut dans Joomla! peu de groupes ont accès au back-office. Et on ne s'improvise pas administrateur sans une bonne petite formation à Joomla.
L'accès aux menus, aux utilisateurs, aux extensions... vaut mieux pas si la personne ne sait pas exactement ce que cela implique.
Toucher aux menus ça peut flinguer une mise en page, pénaliser le référencent, bref être dangereux, et généralement la plupart de sites que je conçois n'ont ce type de besoin (ou alors mes clients me contactent).
Et s'il faut créer un profil d'accès au back-end en limitant l'accès aux zones sensibles, autant passer par le front.

Pour ma part j'utilise cet éditeur que je trouve très bien coté ergonomie : https://www.joomunited.com/products/dropeditor
Combiné a DropFiles pour les fichiers : https://www.joomunited.com/products/dropfiles
Et DropPics pour les images : https://www.joomunited.com/products/droppics

J'ai utilisé JCE depuis toujours (donc depuis + de 10 ans en gros) et j'ai changé il y a peu.
La raison : bien que JCE soit incroyablement stable et efficace, je trouve (et d'après des retours clients) qu'il est à la ramasse coté approche et ergonomie.
Les clients avaient beaucoup de mal à faire des choses simples, soit par Drag & Drop soit par simples click.
De plus la gestion des images et fichiers est trop techniques, il y'a trop d'options et le rendu visuel n'est pas top (et j'utilisais pourtant des profils restreints pour les clients).
JCE s'est récemment amélioré avec la gestion des colonnes etc..mais il n'est pas très user friendly je trouve.

Dropeditor a l'air sympa, mais encore une fois, je conçois des sites pour des gens qui n'ont pas vraiment la maîtrise de ces outils, même s'ils ont droit à une formation préalable.
Je configure énormément de chose en amont pour leur simplifier la vie et leur éviter de faire des bêtises.
Et pour ça, JCE me semble parfaitement adapté.
Comme toi je le pratique depuis très longtemps (depuis qu'il existe en fait). J'en ai donc une excellente maîtrise.
La configuration des profils me permet de ne laisser dans l'éditeur que le strict nécessaire, ce qui le rend très simple d'utilisation.
L'upload des images se fait dans un dossier dédié et étanche du reste du contenu du dossier images (mais auquel moi j'ai accès).
Idem pour les fichiers, importés dans un dossier à part des images pour ne pas tout mélanger.
Les types de fichiers autorisés sont prédéfinis, et exit les .doc, .xls, etc. Sur les sites c'est du jpg, png, pdf et basta.
Les images ont des dimensions d'import prédéfinies, adaptées à la structure des pages du site.
Même les vidéos transitent par YT histoire de ne pas surcharger le serveur d'hébergement et de simplifier leur intégration.
Et bien sûr le poids maximal de chaque type de fichier est également défini, pour éviter de voir débarquer un pdf de 5 Go...

Du est-ce que dans ton ou tes page builder tu peux utiliser un éditeur tiers style JCE ou DropEditor?

Dropeditor je sais pas, j'ai pas essayé, mais TinyMCE ou JCE oui, parfaitement.

Oui c'est possible en effet, mais ça reste carrément moins intuitif pour le client.
Je fais déjà énormément de choses avec du CSS, mais tôt ou tard il faudra mettre les mains dedans.

La majorité de mes clients veulent quelque chose de simple, facile et rapide.
Donc un champ texte, un ou deux clic pour l'image, idem pour un fichier ou une vidéo, et voilà.
Ensuite, au fil du temps, pour ceux qui pratiquent régulièrement, les besoins peuvent croître et donc des fonctionnalités apparaître, mais ça reste assez marginal.
Et puis je ne suis jamais bien loin

[Tortue Genial 69]

L'utilisateur peux mettre les mains dedans s'il le souhaite. Mais comme pour les articles, s'il fait des bêtises, il devra assumer.
Mais en fait j'anticipe puisqu'une fois les pages statiques faites et livrées, je les exporte au format json.
Si le client, bien que préalablement formé, "casse" quelque chose, je n'ai qu'à importer le json pour retrouver ma page telle qu'elle était avant que le client n'intervienne.
Sous oublier les sauvegardes quotidiennes s'il a fait une très grosse bêtise.

De mon coté je n'exporte pas en Json, mais ayant les sauvegardes de l'hébergeur + celles que je fais moi en plus dans le cloud (Google Drive via Rclone), je peux tout remonter sans problème.
Et de mémoire, ce n'est jamais encore arrivé...tant mieux pour le moment

Ensuite, un outil comme SP PageBuilder permet d'être utilisé directement dans l'article (en fait on découvre un onglet qui permet de basculer entre le mode d'édition classique et le pagebuilder) et il y a même un type de module dédié.

Ok ça c'est cool en effet.
par contre tu entends quoi par il y a même un type de module dédié. ?

A savoir que SP Pagebuilder, quand on s'en sert dans un article, copie/colle le contenu de certains blocks (ceux qui ont du contenu de type texte) dans la partie d'édition classique.
Cela signifie que si jamais on désactive ou supprime le pagebuilder, ces contenus ne sont pas perdus, même s'il faudra reprendre leur mise en forme.

oui pratique en effet, dans le cas d'un changement de page builder...au moins on perd pas tout.

Il est également possible d'avoir un mix très utile pour les blog :
- saisir un texte d'intro,
- placer une ligne de rupture "lire la suite"
- éditer l'article complet avec le pagebuilder

tu veux dire que l'article joomla contient l'intro + le lien lire la suite et le page builder contient l'article complet?
ou j'ai raté un truc la

En fait j'ai un peu menti... les articles ultra basique, comme les mentions légales ou la politique de confidentialité, c'est généralement des articles simples via l'éditeur classique de Joomla!
Un peu de style appliqué aux chapitres, et sous-chapitres via l'éditeur avancé et ça suffit.

yes idem pour moi.

Le builder sera plutôt utilisé sur des pages "statiques" qui nécessitent une petite mise en forme spéciale, plus simple à faire avec le builder qu'avec un article standard, genre un page de contact avec des coordonnées à gauche sur 1/3 de la page et un formulaire à droite sur les 2/3 restant, et en dessus un plan de localisation dynamique type GG map.

oui c'est clairement le top pour ça.

Mais l'emploi de champs personnalisés et l'arrivée de nouvelles fonctionnalités dans la v4 de Joomla, va me conduire à reconsidérer le traitement et l'organisation de certains contenus.

idem j'attends de voir ce que ça donner, mais l'emploi d'un page builder sera toujours utile je pense.
du coup, avec un page builder, tu n'utilises aucun template stylle yootheme ou joomlart ni aucun framework du coup? pas besoin?

Ce qui est radicalement différent c'est la prévisualisation de l'article en même temps qu'on le saisi et avant même de le valider et donc d'écraser l'ancien contenu.
Avec un joomla classique, en front comme en back, on édite le contenu via l'éditeur avancé mais il faut valider pour voir la page se remettre en forme avec tous les éléments qui la composent.
Avec un builder, on édite dans la mise en forme et toutes les modifications se visualisent sans avoir à sauvegarder.
On ne sauvegarde la page qu'à la fin, quand on est content du rendu final.

oui c'est vrai que y'a cet aspect visu en live qui est très bien c'est clair.

A noter qu'une page réalisée avec un page builder peut intégrer des bloc de différentes natures, comme un slider, un formulaire, un compteur à rebours, un tableau de prix, une fiche client, des contenus en accordéon, etc... et toutes les modifications de ces éléments se font là aussi avec une une prévisualisation en temps réel, sous les yeux de l'utilisateur.

alors la, du coup, si tu créé par exemple un bloc slider avec un page builder, comment tu l'assignes à plusieurs pages sans le dupliquer physiquement?
car un slider positionné via un module, peut être assigné à plusieurs pages sans être dupliqué.

Avec du Joomla classique, il faut éditer l'article, puis aller voir du côté des modules pour, par exemple, modifier le slider, le formulaire, etc...

c'est sur que c'est la contre-partie en effet.

Ben en terme de sécurité, je préfère laisser les utilisateurs sur le front et limiter les accès à l'admin.
Le client, ce dont il a généralement besoin, c'est un accès au contenu, textes et images.
Lui ouvrir la porte de l'admin, même de manière étroite, ne me semble pas nécessaire, voire imprudent même si j'ai, là aussi, un certain nombre de garde-fous.
C'est d'ailleurs pour ça que par défaut dans Joomla! peu de groupes ont accès au back-office. Et on ne s'improvise pas administrateur sans une bonne petite formation à Joomla.
L'accès aux menus, aux utilisateurs, aux extensions... vaut mieux pas si la personne ne sait pas exactement ce que cela implique.
Toucher aux menus ça peut flinguer une mise en page, pénaliser le référencent, bref être dangereux, et généralement la plupart de sites que je conçois n'ont ce type de besoin (ou alors mes clients me contactent).
Et s'il faut créer un profil d'accès au back-end en limitant l'accès aux zones sensibles, autant passer par le front.

je comprends, mais la j'avoue que j'ai le raisonnement inverse et jamais eu de soucis avec l'accès au back-office, ni pour le clients.
au contraire tout est centralisé au sein d'une même IHM, donc bon...question d'approche et d'usage au final.

Dropeditor a l'air sympa, mais encore une fois, je conçois des sites pour des gens qui n'ont pas vraiment la maîtrise de ces outils, même s'ils ont droit à une formation préalable.
Je configure énormément de chose en amont pour leur simplifier la vie et leur éviter de faire des bêtises.

DropEditor est très simple à utiliser, pas besoin de connaissance..sauf une mini formation.
pour ma part j'ai une chaine youtube avec des vidéo tutoriels pour les clients ou je présente l'utilisation de chaque composant.
les retours sont bons à priori

La configuration des profils me permet de ne laisser dans l'éditeur que le strict nécessaire, ce qui le rend très simple d'utilisation.
L'upload des images se fait dans un dossier dédié et étanche du reste du contenu du dossier images (mais auquel moi j'ai accès).
Idem pour les fichiers, importés dans un dossier à part des images pour ne pas tout mélanger.
Les types de fichiers autorisés sont prédéfinis, et exit les .doc, .xls, etc. Sur les sites c'est du jpg, png, pdf et basta.

idem pour moi, sauf pour les extensions ou j'en tolère un poil plus car c'est un besoin qui a été remonté.

Les images ont des dimensions d'import prédéfinies, adaptées à la structure des pages du site.

ce point m'intéresse, tu gères ça comment?
je veux dire que tu re-taille à la volée les images que les users envoient?
ou tu forces les dimensions via du CSS?

[dolmenhir]

De mon coté je n'exporte pas en Json, mais ayant les sauvegardes de l'hébergeur + celles que je fais moi en plus dans le cloud (Google Drive via Rclone), je peux tout remonter sans problème.
Et de mémoire, ce n'est jamais encore arrivé...tant mieux pour le moment

Le coup du fichier json, c'est un chouïa + rapide, puisque ça se fait en 2 clics.
Et surtout on ne touche que ça : remonter une sauvegarde t'oblige à annuler toutes les modifications, même les bonnes.

par contre tu entends quoi par il y a même un type de module dédié. ?

C'est un module, c'est comme un module personnalisé, qui permet de produire du contenu mais mis en forme avec toutes les fonctionnalités du PageBuilder
Et évidement, qui dit module, dit transversalité potentielle

tu veux dire que l'article joomla contient l'intro + le lien lire la suite et le page builder contient l'article complet?

Oui Môssieur, parfaitement

du coup, avec un page builder, tu n'utilises aucun template stylle yootheme ou joomlart ni aucun framework du coup? pas besoin?

Si si, ça me permet d'aller + vite, et par exemple de sortir un site dans la journée, voire moins selon le projet.
Pour l'heure j'utilise Helix Ultimate de Joomshaper, ceux là me^me qui éditent SP PageBuilder.
Je garde un oeil sur les autres, et plus particulièrement sur Astroïd (un problème de vitesse).
GridBox de Balbooa est intéressant aussi, mais très atypique par rapport aux autres.
De tous c'est Gantry que j'aime le moins, suivi de T3, mais j'attend de voir le T4
Je pourrais cependant parfois me contenter d'un simple Protostar ou pondre mon propre Template si nécessaire.
Je réfléchit d'ailleurs à me faire mon propre Framework, histoire de sortir un code + propre, parce que c'est un des défauts des frameworks actuels.

alors la, du coup, si tu créé par exemple un bloc slider avec un page builder, comment tu l'assignes à plusieurs pages sans le dupliquer physiquement?
car un slider positionné via un module, peut être assigné à plusieurs pages sans être dupliqué.

Plusieurs solutions :
- tu peux créer un module qui exploite les fonctionnalités du Page Builder. Du coup tu peux l'affecter comme n'importe quel module
- tu peux sauvegarder un bloc, une ligne, un addon réalisé dans une page sous Pabebuilder, et le réutiliser dans une autre page d'un simple clic.

A noter que dans ce Pagebuilder tu peux placer un addon de type module.
Donc tu peux aussi faire un module avec le pagebuilder, qui contient lui même un module, etc... et le placer dans une page, ou plusieurs si tu l'as sauvegarder pour le ré-utiliser.

ce point m'intéresse, tu gères ça comment?

avec JCE, et cela retaille les images à la volée lors de l'upload
JCE > Profil > Paramètres de l'éditeur > Fichier système > Edition de l'image

[Tortue Genial 69]

ok super merci pour ces retours c'est très clair.
j'avais pas vu que SP page builder avait un module qui permettait de créer du contenu issu du page builder dans le module directement...malin car pas lié juste au composant

pour l'export Json, tu passes par quoi? un plug-in dédié?

c'est vrai que SP page builder pro à l'air top...du coup au final tu n'as besoin que d'un seul template (helix dans ton cas) et tu fais juste varier le contenu avec les blocs du page builder?
du coup j'aimerai bien avoir ton avis sur ce que nicepage appelle le web desgin 3.0 : https://nicepage.com/doc/article/265...t-so-different

c'est vrai que leur solution est intéressante, car le placement d'un élément ne se limite pas à une grille, mais peut chevaucher d'autres éléments.