Tests et avis sur les Page Builder

[Tortue Genial 69]

ok merci pas mal de chose sont plus claires

Pour les fichiers téléchargeables, tu peux utiliser la fonction de JCE quand ce derniers est disponible dans l'addon (bloc texte par exemple).
Mais il y a plusieurs addons qui ne l'utilisent pas (bouton, icone, etc...) et là c'est plus compliqué.
On attend de Joomshaper (qu'on relance régulièrement) qu'ils optimisent le système de liens des ces addons.

du coup je suis sur de comprendre ce point pardon

90% de mes clients ne vont jamais en backend.
La plupart souscrivent d'ailleurs un contrat d'infogérance parce qu'ils n'ont pas le temps de s'en charger.
Pour les 5% restant, ils ont soit un accès au frontend soit un accès au backend, mais avec des services en backend adaptés selon leur besoin et leur compétences (ils sont généralement formés par mes soins).

donc en fait, pour de très petits besoins tu peux juste te contenter de SPPB et de l'accès front-end.
alors que si certains besoins nécessitent plus d'extensions ou un mix de plusieurs composants, tu utilises SPPB + extensions avec accès back-end?

paramètrage dans JCE (par exemple pour définir les dossiers accessibles pour les images, les pdfs, ou le redimensionnement automatique des images pour éviter de voir débarquer des images de 4000x3000 pixels).

j'avais déjà utilisé les paramètres de JCE pour bloquer certaines choses comme l'accès aux dossiers etc...c'est vrai que c'est pratique.
mais du coup pour les images, en gros tu autorises juste tes clients à uploader des images de X taille?

[dolmenhir]

ce soucis n'est valable que si on gère le menu via SPPB ?
si on gère le menu via Helix et les items classiques, tout est ok?

Oui, aucun problème en mode classique.

tu veux dire que le bouton de JCE qui permet d'aller chercher et insérer des fichiers n'est pas forcément disponible en fonction de l'add-on qui affiche JCE ?

Tous les boutons JCE sont disponibles (selon le profil JCE évidement) dès lors que JCE est chargé, comme dans un bloc texte.
Partout ailleurs, tu dois soit utiliser les fonctions proposées par SPPB soit faire de la saisie manuelle.
Donc, JCE chargé : tu as tous tes boutons.
JCE pas chargé : t'as rien à part les outils du builder.

oui je voulais dire que certaines extensions ne sont pas gérables depuis le front-end.
en gros c'est comme si tu ne pouvais pas éditer un article depuis le front-end.
exemple pas trop vieux que j'ai en tête : Docman (qui comme tu le sais permet de gérer des documents etc..)
Jusqu'à il n'y a pas longtemps, tu ne pouvais pas créer de catégories et sous catégorie depuis le front-end...tu pouvais juste gérer les fichiers (upload, suppresion, déplacement etc..)
Ce qui était hyper handicap car un client lambda qui gérait ses fichiers depuis le front-end, devait alors se connecter sur le back-end pour simplement créer des dossiers.
c'est en cela que je trouve le front-end moins adapté (pas pour SPPB), mais pour les extensions tierces.

Oui, les fonctions d'édition en frontend étant gérées par le composant lui-même, s'il ne le propose pas, on n'a pas d'autre choix que de passer par le backend.
Je te rejoins sur le fait que pour certaines extensions, leur administration en frontend, quand c'est disponible, n'est pas toujours aussi pratique ou ergonomique d'en backend.

donc en gros à tes clients tu leur donnes accès au front-end pour les articles et SPPB et au back-end pour les autres extensions?

90% de mes clients ne vont jamais en backend.
La plupart souscrivent d'ailleurs un contrat d'infogérance parce qu'ils n'ont pas le temps de s'en charger.
Pour les 5% restant, ils ont soit un accès au frontend soit un accès au backend, mais avec des services en backend adaptés selon leur besoin et leur compétences (ils sont généralement formés par mes soins).

Question subsidiaire, pour la sécurité via l'accès en front-end, je suppose que tu as juste créé un lien de menu de type connexion utilisateur pour le client?
tu verrouilles l'accès de la page ou tu laisses tel quel?

Soit ils ont un lien depuis le front de type connexion utilisateur, soit ils ont un lien secret pour y accéder (géré par un menu caché et que je leur fait mettre en favori dans leur navigateur).
Je ne verrouille rien de plus, hormis quelques paramétrage dans admintools (par exemple pour vérifier les paquets/fichiers envoyés par formulaire) et des paramètrage dans JCE (par exemple pour définir les dossiers accessibles pour les images, les pdfs, ou le redimensionnement automatique des images pour éviter de voir débarquer des images de 4000x3000 pixels).
L'htaccess configuré via admintools est plutôt blindé.

En 15 ans d'utilisation de Joomla, je n'ai jamais eu le moindre problème de sécurité lié à l'édition en front.
Par ailleurs, la politique de sauvegarde mise en oeuvre permet, si besoin, de restaurer très vite n'importe quel site (moins de 15 mn montre en main).
Mais, à ce jour, je n'ai jamais eu besoin de le faire.

[Tortue Genial 69]

déjà merci encore de prendre le temps de répondre aussi précisément

Les fonctions mega menu sont disponibles via le gestionnaire de menu grâce au framework du template.

en effet j'avais pas vu dans les item de menu que Helix Ultimate permettait de faire des méga menu en insérant des modules etc...
donc parfait.

Cela pose aussi un problème quand on change l'alias dans le menu source puisqu'il faut aller le changer dans la page.

ce soucis n'est valable que si on gère le menu via SPPB ?
si on gère le menu via Helix et les items classiques, tout est ok?

Pour les fichiers téléchargeables, tu peux utiliser la fonction de JCE quand ce derniers est disponible dans l'addon (bloc texte par exemple).
Mais il y a plusieurs addons qui ne l'utilisent pas (bouton, icone, etc...) et là c'est plus compliqué.
On attend de Joomshaper (qu'on relance régulièrement) qu'ils optimisent le système de liens des ces addons.

tu veux dire que le bouton de JCE qui permet d'aller chercher et insérer des fichiers n'est pas forcément disponible en fonction de l'add-on qui affiche JCE ?

Le fait qu'une extension ne soit pas accessible en front (tu parles bien de sa gestion en mode édition, hein ?)

oui je voulais dire que certaines extensions ne sont pas gérables depuis le front-end.
en gros c'est comme si tu ne pouvais pas éditer un article depuis le front-end.
exemple pas trop vieux que j'ai en tête : Docman (qui comme tu le sais permet de gérer des documents etc..)
Jusqu'à il n'y a pas longtemps, tu ne pouvais pas créer de catégories et sous catégorie depuis le front-end...tu pouvais juste gérer les fichiers (upload, suppresion, déplacement etc..)
Ce qui était hyper handicap car un client lambda qui gérait ses fichiers depuis le front-end, devait alors se connecter sur le back-end pour simplement créer des dossiers.
c'est en cela que je trouve le front-end moins adapté (pas pour SPPB), mais pour les extensions tierces.

n'est pas un problème pusiqu'il suffit d'aller dans le backend pour s'en occuper.
L'édition en front n'est utile que pour le contenu (articles ou pages SPPB).

donc en gros à tes clients tu leur donnes accès au front-end pour les articles et SPPB et au back-end pour les autres extensions?

Attention SPPB ne fonctionne pas seul. Ce n'est pas un temlate et il ne gère pas le zoning (positions).
Tu dois impérativement avoir un template actif.

oui çà aucun soucis c'est logique.

J'utilise beaucoup le duo HelixUltimate + SPPB, car les deux proviennent de la Team Joomshaper donc, en théorie, ils sont sensés bien dialoguer entre eux.

c'est aussi ce que je suis en train de faire car je repense un peu mes offres en ce moment.

A ce jour, je dirai Balbooa Joomla Gallery.
Puissant et relativement simple d'utilisation.
Import massif, vignettes automatiques, effets visuels nombreux, lazy load, compression, et plein d'autres choses qui justifient amplement le prix de la licence annuelle ($28).
Il y a une version "free" avec moins de fonctions mais qui permet de se faire une idée du potentiel.

https://www.balbooa.com/joomla-gallery#download

Idem, c'est aussi à lui que je pensais.

Question subsidiaire, pour la sécurité via l'accès en front-end, je suppose que tu as juste créé un lien de menu de type connexion utilisateur pour le client?
tu verrouilles l'accès de la page ou tu laisses tel quel?

[dolmenhir]

- tu dis que SP BUILDER peut être utilisé pour façonner un article : ok dac.
du coup on n'est pas obligé de créer un item de menu de type blog vers l'article en question.
on peut très bien créer un item de menu de type article, qui va pointer vers l'article mis en forme via SP Page builder et du coup la page d'affichera en intégralité sans l'affichage du texte d'intro et du bouton lire la suite. non?

Exactement.

- comment tu gères l'aspect mega menu via SP Page builder ? sur pas mal de template JoomShaper, on voit des menus avec des modules à l'intérieur etc...comment est-ce paramétré ?

Généralement, le menu est géré normalement par Joomla et le template.
Les fonctions mega menu sont disponibles via le gestionnaire de menu grâce au framework du template.
La page faite avec SPPB s'affiche en position "component" comme n'importe quel article d'ailleurs.
Mais SPPB permet aussi d'insérer des modules (de menu) ou des addons de navigation.

On peut alors s'amuser à ne pas pas afficher le menu dans le template et se contenter de la manière dont on a construit la page avec SPPB.
Mais ce builder est encore imparfait au niveau de la gestion liens car il faut saisir à la main l'url SEF, et donc les connaître, ce qui peut poser problème quand un item doit pointer sur des éléments de composant par exemple (en fait faut faire un menu cahcer avec les lien et récupérer l'url SEF).
Cela pose aussi un problème quand on change l'alias dans le menu source puisqu'il faut aller le changer dans la page.

Un menu via un addons sur un onepage ne pose pas trop de problème, mais sur un site avec une arborescence plus ou moins conséquente, cela devient vite compliqué à administrer.

- du coup toi tu utilises JCE en version free ou pro? car il me semble que la version pro permet d'intégrer des fichiers : est-ce cela fonctionne par exemple d'insérer un fichier téléchargeable dans un bloc de texte de SP Page builder par exemple?

J'utilise JCE Pro depuis très longtemps.
A ce jour, il est à mes yeux l'éditeur avancé le plus puissant et le plus performant, et regorge de fonctions insoupçonnées par beaucoup d'utilisateurs.
Même si TinyMCE s'améliore régulièrement, il est encore loin derrière.

Pour les fichiers téléchargeables, tu peux utiliser la fonction de JCE quand ce derniers est disponible dans l'addon (bloc texte par exemple).
Mais il y a plusieurs addons qui ne l'utilisent pas (bouton, icone, etc...) et là c'est plus compliqué.
On attend de Joomshaper (qu'on relance régulièrement) qu'ils optimisent le système de liens des ces addons.

- les sites simples de quelques pages ou one page peuvent être 100% SP Page builder ok . par contre comment tu gères un site qui aurait besoin de SP Page builder et d'autres extensions? et de surcroît, non accessibles depuis le front-end ?

Le plus simplement du monde.
Je fais des pages SPPB, appelées via des liens de menu, des articles mise en forme avec SPPB...
Ces contenus se chargent en position component, comme avec n'importe quel template.
Les contenus provenant d'extension sont soient des données de composant, et là c'est plutôt des liens de menu, donc rarement lié à une pageSPPB ou un article, soit des modules et là je les place soit dans une position du template avec le système d'assignation classique (ou avec le plug-in "advanced module manager" de regular labs) soit via un addons module si je veux le retoruver dans une page SPPB ou un article traité avec SPPB.

Le fait qu'une extension ne soit pas accessible en front (tu parles bien de sa gestion en mode édition, hein ?) n'est pas un problème pusiqu'il suffit d'aller dans le backend pour s'en occuper.
L'édition en front n'est utile que pour le contenu (articles ou pages SPPB).

finalement, selon toi, qu'apportent les templates dédiés de JoomShaper vs SP Page builder ? car au final, SP Page builder te permet de tout faire, donc pourquoi s'embarrasser d'un theme custom avec qu'avec Helix Ultime pour gérer les positions et SP Page builder pour le design, tout est (quasi) faisable finalement ?

Attention SPPB ne fonctionne pas seul. Ce n'est pas un temlate et il ne gère pas le zoning (positions).
Tu dois impérativement avoir un template actif.

Tu peux tout à fait utiliser SPPB avec un template de base comme protostar.
J'ai quand même détecté quelques bizarreries, surtout à cause du fait de la largeur du template. Mais ça se modifie facilement.

Je n'utilise pas les templates dédiés ou tout faits.
Je préfère utiliser un framework, comme HelixUltimate ou même Androïd, car ils offrent plus de possibilité pour la création d'une template, son paramétrage, son approche responsive, sa gestion des layouts et du zoning de positionnement.
Bref, ces frameworks ont beaucoup de vertus, même si le code est parfois un peu enrobé...

J'utilise beaucoup le duo HelixUltimate + SPPB, car les deux proviennent de la Team Joomshaper donc, en théorie, ils sont sensés bien dialoguer entre eux.

- pour des galeries d'images un peu sympa, t'as opté pour quoi comme solution? extension dédiée ou un add-on de SP Page builder ?

A ce jour, je dirai Balbooa Joomla Gallery.
Puissant et relativement simple d'utilisation.
Import massif, vignettes automatiques, effets visuels nombreux, lazy load, compression, et plein d'autres choses qui justifient amplement le prix de la licence annuelle ($28).
Il y a une version "free" avec moins de fonctions mais qui permet de se faire une idée du potentiel.

https://www.balbooa.com/joomla-gallery#download

[Tortue Genial 69]

dolmenhir je vais centraliser ici quelques questions ce sera plus simple :

- tu dis que SP BUILDER peut être utilisé pour façonner un article : ok dac.
du coup on n'est pas obligé de créer un item de menu de type blog vers l'article en question.
on peut très bien créer un item de menu de type article, qui va pointer vers l'article mis en forme via SP Page builder et du coup la page d'affichera en intégralité sans l'affichage du texte d'intro et du bouton lire la suite. non?

- comment tu gères l'aspect mega menu via SP Page builder ? sur pas mal de template JoomShaper, on voit des menus avec des modules à l'intérieur etc...comment est-ce paramétré ?

- du coup toi tu utilises JCE en version free ou pro? car il me semble que la version pro permet d'intégrer des fichiers : est-ce cela fonctionne par exemple d'insérer un fichier téléchargeable dans un bloc de texte de SP Page builder par exemple?

- les sites simples de quelques pages ou one page peuvent être 100% SP Page builder ok . par contre comment tu gères un site qui aurait besoin de SP Page builder et d'autres extensions? et de surcroît, non accessibles depuis le front-end ?

- finalement, selon toi, qu'apportent les templates dédiés de JoomShaper vs SP Page builder ? car au final, SP Page builder te permet de tout faire, donc pourquoi s'embarrasser d'un theme custom avec qu'avec Helix Ultime pour gérer les positions et SP Page builder pour le design, tout est (quasi) faisable finalement ?

- pour des galeries d'images un peu sympa, t'as opté pour quoi comme solution? extension dédiée ou un add-on de SP Page builder ?

[Tortue Genial 69]

genre tu vois ici je n'ai pas d'éditeur :



EDIT : désolé j'ai trouvé par moi même, j'étais juste à la ramasse question observations ce soir.

[Tortue Genial 69]

ok je comprends mieux la première partie alors.
par contre, un détail.
tu dis que SP BUILDER peut être utilisé pour façonner un article : ok dac.
du coup on n'est pas obligé de créer un item de menu de type blog vers l'article en question.
on peut très bien créer un item de menu de type article, qui va pointer vers l'article mis en forme via le builder et du coup la page d'affichera en intégralité sans l'affichage du texte d'intro et du bouton lire la suite. non?

pour le coup de l'éditeur : il faut paramétrer quelque chose pour qu'il s'affiche dans le builder ou c'est automatique? car pour ma part j'ai juste un bloc blanc sans éditeur...mais j'utilise ni jce ni tiny..Donc peut-être que cela vient de là.

[dolmenhir]

désolé moi pas compris

Je recommence en essayant d'être plus précis.
Il y a deux composants :
- com_content pour les articles Joomla de base (contenu > articles)
- com_sppagebuilder pour ceux créés directement par SPPB (sans passer par contenu > articles)

Les articles gérés par Joomla peuvent être rassemblés dans un lien de type blog, selon qu'ils appartiennent à une catégorie ou qu'ils sont marqués "en vedette".
Cela vaut aussi pour des articles dont la mise en forme s'appuient sur SPPB (donc via menu "contenu" > Articles) parce que c'est des articles Joomla.

Les pages créées directement avec SPPB (sans passer par "contenu" > "articles) ne sont pas des articles au sens natif de Joomla mais des pages créées via le composant (SPPB).
Elles ne peuvent donc être rassemblées via un lien de type blog (car ils ne sont pas enregistrés dans la table com_content des articles).
Le seul moyen d'afficher une page faite directement avec SPPB c'est de choisir un lien de type SPPB > page.

Toutefois, puisque SPPB peut être utilisé pour façonner un article, tu peux avoir un lien de type blog, qui ira chercher les articles (créés avec le com_content = contenu > articles) d'une ou plusieurs catégories, mais :
- ce lien n'affichera que la partie de contenu considéré comme le texte d'intro (ça c'est normal pour tous les articles même sans SPPB),
- et le lien "lire la suite" affichera la partie de l'article façonnée avec SPPB.

Si ta page n'a pas vocation à être utilisée comme un article d'un blog mais juste comme une page, seule, isolée, autant utiliser le builder seul (sans passer par "contenu > articles"), et t'iras la chercher via un lien de menu de type SPPB > page.

question bête : avec le builder, quand tu édites un bloc de texte par exemple, il n'y a plus d'éditeur nécessaire du coup? puisque la police et le reste se règlent via les outils du builder ?

Si.
Les addons de type texte, mais également d'autres addons nécessitant la saisie de bloc texte (exemple addon "feature box") s’appuient par défaut sur TinyMCE.
Mais si un autre éditeur est installé et configuré comme éditeur de base pour un utilisateur, c'est celui-ci qui sera utilisé.
C'est en tout cas comme ça pour moi avec JCE (TinyMCE par défaut, mais mon profil est paramétré pour JCE >> SPBB charge JCE. Du coup j'ai la puissance du builder + celle de JCE Pro )

[Tortue Genial 69]

Si toutes tes pages sont faites avec le builder sans passer par un article, tu n'auras rien derrière un lien de type blog car cela ne fonctionne qu'avec les articles.

désolé moi pas compris

Cependant, plusieurs pages actuellement absentes vont rester en mode article mais seront totalement redessinées avec le builder.

donc en gros ta page article te sert à rien si tu la dessines avec le builder?
tu feras juste pointer ton item de menu sur la page bonne page faite avec ton builer?

question bête : avec le builder, quand tu édites un bloc de texte par exemple, il n'y a plus d'éditeur nécessaire du coup? puisque la police et le reste se règlent via les outils du builder ?

[dolmenhir]

aintenant je réfléchissait plus loin et je me disais que : quitte à utiliser un page builder, en fait les articles ne servent que pour le mode blog à la fin non?
car si toutes les pages sont gérées via le builder et vu que leur contenu n'est pas dans un article, ben les articles servent juste pour le blog (si présent)?

Si toutes tes pages sont faites avec le builder sans passer par un article, tu n'auras rien derrière un lien de type blog car cela ne fonctionne qu'avec les articles.

Mais y a des cas où les pages faites avec le builder suffisent largement.

Jai quelques clients avec des petits sites de 10/15 pages, sans relation particulières entre-elles, qui n'ont pas besoin d'être classées par catégorie ni d'un affichage de type blog.
Du coup, toutes ces pages sont faites avec le builder.

Mon propre site est pour l'instant intégralement fait avec un builder.
Il est en refonte et n'a certes qu'un nombre de pages limité à l'essentiel.
Cependant, plusieurs pages actuellement absentes vont rester en mode article mais seront totalement redessinées avec le builder.

[Tortue Genial 69]

ok noté pour l'accès aux éléments du builder je vais tester.

par contre, pour travailler régulièrement avec des problématiques de cyber-sécurité (dans mon boulot principal), le fait de ne pas avoir de problème à l'instant T ne signifie pas qu'il n'y en aura jamais. en effet avec tout ce que tu décris, on peut mieux sécuriser l'accès depuis le front-end, mais dans l'absolu, même si c'est moins probable, l'accès en front reste moins secure que le back-end..c'est un fait. disons que même si rien n'est pas parfait et que depuis le back-end le piratage est aussi possible, cela permet quand même de réduire la surface d'attaque.
donc au pire je préfère conserver cette solution, c'est toujours un petit plus je trouve.

d'autant plus, que je n'avais en tête pas uniquement les site one page, mais tous les types de site en fait.
les sites one page sont un cas à part car il n'y a besoin de rien d'autre comme extensions, mais pour tous les autres types de site personnellement j'en utilise d'autres.
et la elles ne sont pas forcément toutes dispos depuis le front, et la ça coince.

ok noté pour le design en effet cela ne doit pas perturber le builder, mais les autres extensions si malheureusement (j'en ai déjà fait l'expérience).

et concernant l'accès back-end, si ça t’intéresse je peux publier un screen shot d'un back-end classique d'un site client, tu verras que c'est épuré de chez épuré et il n'a accès à presque rien..enfin juste à ce dont il a besoin. donc il est strictement impossible qu'il fasse une connerie, vu que tout est calibré.
et dans mon cas, cela me permet de le cloisonner dans un environnement contrôlé et délimité, sans avoir à toucher au design des autres extensions que le builder, car cela est pris en charge par le template admin.

après il y a toujours plusieurs chemins pour arriver au même endroit c'est sur...la pour le coup dans les 2 cas cela fonctionne.

maintenant je réfléchissait plus loin et je me disais que : quitte à utiliser un page builder, en fait les articles ne servent que pour le mode blog à la fin non?
car si toutes les pages sont gérées via le builder et vu que leur contenu n'est pas dans un article, ben les articles servent juste pour le blog (si présent)?

[dolmenhir]

tu veux dire que depuis le front-end, quand tu modifies un article, tu peux faire pointer l'affichage uniquement sur l'éditeur classique ou celui de SP PAGE BUILDER ? et masquer l'autre?

Quand tu modifies l'article avec l'éditeur classique, tu ne vois aucun des éléments du builder.
Au plus, tu as, après la ligne de rupture "lire la suite" les textes correspondants aux blocs textes des addons présents dans l'article, mais les modifier est sans effet (ce n'est que du texte qui sera remplacé par SPPB.

- sécurité : avec une page de connexion possible depuis le front-end cela augmente la surface d'attaque potentielle.

Menace relativement circonscrite puisque tu n'as pas accès au reste des fonctions de l'admin.
Avec un bon mot de passe, un outil de sécurité (admintools, aesecure), et éventuellement une double authentification, tu peux aisément renforcer la sécurité de l'édition en front.

- design : l'édition en front-end doit souvent être ajustée via du CSS pour coller à la charte du site si on veut un truc nickel ou masquer des options.

Aucun problème de design avec SPPB.
Tu travailles sur la page ou l'article courant, le rendu ne concerne que cette partie. Le reste n'est absolument pas impacté.

- accessibilité : toutes les extensions joomla ne sont pas gérables/managables depuis le fornt-end..et du coup, si jamais on en revient à proposer à l'utilisateur de modifier telle et telle extension depuis le font-end et telle et telle extension depuis le back-end, c'est une perte considérable en simplicité et ergonomie.

Idem que pour la question précédente.
Si tu proposes l'édition d'une onepage via SPPB, la question des extensions ne se posent pas puisqu'elles ne son pas concernées par la page.
Le seul intérêt de passer par le back, c'est si on a autre chose à y faire qu'une simple page à modifier.

Personnellement, je trouve beaucoup plus risqué de donner un accès, même restreint, au backoffice plutôt qu'au front vu qu'en mode édition beaucoup de fonctions, routines et process ne sont pas accessibles.
C'est d'ailleurs pour cela que le front existe : restreindre l'accès au back tout en proposant un accès limité pour la rédaction.

quand au rendu visuel depuis le back-office, comme tu l'a dis le bouton de prévisualisation est la, ou au pire on enregistre et on va voir sur le site public ce que cela donne.

Si tu veux voir, par exemple, ce que un titre, un texte, une image, donne à l'affichage selon différentes tailles, c'est plus simple et rapide d'utiliser un curseur que de définir une taille, valider, aller voir, de revenir, de changer, de valider, de retourner voir, etc, etc...
C'est vraiment plus simple et plus ergonomique, surtout pour un client qui ne maîtrise pas trop la technique, et qui va vite s'agacer de devoir faire d'incessants va-et-vient.


Moi je propose de plus en plus souvent cette formule à mes clients et n'ai jamais eu la moindre remarque ni le moindre problème de sécurité.

[Tortue Genial 69]

Dans le backoffice, quand on modifie avec l'éditeur classique, on doit cliquer sur le bouton correspondant si l'édition avec SPPB est aussi activée.
La modification ne doit concerner que le texte d'intro.
Mais si on oublie, une fois la modification faite, de recliquer sur le bouton pour rebasculer avec SPPB, l'article s'affiche en front avec le contenu présent dans l'éditeur classique, et on perd alors toute la mise en forme du builder (qu'on retrouve si on reclique sur ledit bouton.
En fait, ces boutons servent en quelque sorte à définir quel sera l'éditeur d'affichage.

ok oui je comprends, c'est fait une sorte de sélecteur d'affichage en effet.

L'édition en front permet les deux, mais là on a pas à se soucier du bouton de bascule d'un éditeur à l'autre.

tu veux dire que depuis le front-end, quand tu modifies un article, tu peux faire pointer l'affichage uniquement sur l'éditeur classique ou celui de SP PAGE BUILDER ? et masquer l'autre?

Enfin, le fait d'éditer en front l'article avec SPPB, cela permet d'avoir un rendu visuel confirme à la mise en page finale, alors qu'en back-end c'est plus technique et sans rendu sauf si on clique sur le bouton de prévisualisation.

oui mais l'édition en front-end, bien que carrément plus simple pour le end-user je suis d'accord, pose plusieurs gros problèmes selon moi :

- sécurité : avec une page de connexion possible depuis le front-end cela augmente la surface d'attaque potentielle.
- design : l'édition en front-end doit souvent être ajustée via du CSS pour coller à la charte du site si on veut un truc nickel ou masquer des options.
- accessibilité : toutes les extensions joomla ne sont pas gérables/managables depuis le fornt-end..et du coup, si jamais on en revient à proposer à l'utilisateur de modifier telle et telle extension depuis le font-end et telle et telle extension depuis le back-end, c'est une perte considérable en simplicité et ergonomie.

donc je suis quand même mitigé sur ça pour être honnête.

quand au rendu visuel depuis le back-office, comme tu l'a dis le bouton de prévisualisation est la, ou au pire on enregistre et on va voir sur le site public ce que cela donne...perso ça fait 11 ans que je fonctionne comme ça et idem pour les clients, c'est pas vraiment gênant je trouve...question de goût certainement.

[dolmenhir]

Attention !

Dans le backoffice, quand on modifie avec l'éditeur classique, on doit cliquer sur le bouton correspondant si l'édition avec SPPB est aussi activée.
La modification ne doit concerner que le texte d'intro.
Mais si on oublie, une fois la modification faite, de recliquer sur le bouton pour rebasculer avec SPPB, l'article s'affiche en front avec le contenu présent dans l'éditeur classique, et on perd alors toute la mise en forme du builder (qu'on retrouve si on reclique sur ledit bouton.
En fait, ces boutons servent en quelque sorte à définir quel sera l'éditeur d'affichage.

L'édition en front permet les deux, mais là on a pas à se soucier du bouton de bascule d'un éditeur à l'autre.
Un fois la modification faite l'article s'affiche selon l'éditeur définit en back.
Par contre si on modifie l'article avec l'éditeur classique, il ne faut modifier que l'intro.
SPPB ajouter du contenu, généralement celui des blocs textes présents dans la page, après la lire de rupture "lire la suite".
Un utilisateur peut être tenté de le modifier, mais cela ne servira à rien puisque le builder le remplacera par l'existant.
Donc la fonction de modification via l'éditeur Joomla n'a strictement aucun intérêt pour une onepage éditée avec SPPB.

Enfin, le fait d'éditer en front l'article avec SPPB, cela permet d'avoir un rendu visuel confirme à la mise en page finale, alors qu'en back-end c'est plus technique et sans rendu sauf si on clique sur le bouton de prévisualisation.

[Tortue Genial 69]

merci pour ton retour.

déjà la vidéo m’intéresse grandement

pour ce qui est de l'usage, déjà pour ma part, aucun client n'édite le site depuis le front-end (pour un tas de raisons de centralisation d'accès, de mise en forme, de design, de sécurité, etc...c'est pas le débat ici). donc tout le monde passe par le back-office.

l'idée des 2 boutons ne me gène pas, car j'ai déjà fais une demande à JoomShaper pour pouvoir les traduire...ils vont remonter ça au dev pour le faire.
en gros mon idée est d'avoir :

- le bouton JOOMLA EDITOR qui sera traduit en ÉDITEUR SIMPLE
- le bouton SP PAGE BUILDER qui sera traduit en ÉDITEUR AVANCE

Je suis conscient que cela peut rajouter de la difficulté, mais tout dépend comment cela est géré.
surtout que chaque éditeur ne répond pas aux mêmes besoin et j'ai de plus en plus de remontées de clients qui veulent plus que l'éditeur classique.

du coup il vaut mieux lui mettre tout dans un article ou dans une page SP ?

car au final ca reviendra au même pour lui non?
sauf que via l'article, l'avantage est qu'il a les 2.