Tests et avis sur les Page Builder

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • Tortue Genial 69
    a répondu
    ok merci pas mal de chose sont plus claires

    Envoyé par dolmenhir Voir le message
    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

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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?

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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).

    Envoyé par Tortue Genial 69 Voir le message
    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.
    Dernière édition par dolmenhir à 12/02/2020, 12h20

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    déjà merci encore de prendre le temps de répondre aussi précisément

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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 ?

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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?

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    - 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.

    Envoyé par Tortue Genial 69 Voir le message
    - 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.

    Envoyé par Tortue Genial 69 Voir le message
    - 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.

    Envoyé par Tortue Genial 69 Voir le message
    - 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).

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    - 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

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    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 ?

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    genre tu vois ici je n'ai pas d'éditeur :

    Cliquez sur l'image pour l'afficher en taille normale  Nom : 2020-02-11_21-08-30.jpg  Affichages : 0  Taille : 129,0 Ko  ID : 2012958

    EDIT : désolé j'ai trouvé par moi même, j'étais juste à la ramasse question observations ce soir.
    Fichiers joints
    Dernière édition par Tortue Genial 69 à 11/02/2020, 23h57

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    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à.

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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 )
    Dernière édition par dolmenhir à 11/02/2020, 17h36

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    Envoyé par dolmenhir Voir le message
    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

    Envoyé par dolmenhir Voir le message
    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 ?


    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    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)?

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    - 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.

    Envoyé par Tortue Genial 69 Voir le message
    - 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é.

    Envoyé par Tortue Genial 69 Voir le message
    - 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.

    Envoyé par Tortue Genial 69 Voir le message
    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é.

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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.

    Laisser un commentaire:


  • dolmenhir
    a répondu
    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.

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    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.


    Laisser un commentaire:

Annonce

Réduire
1 sur 2 < >

C'est [Réglé] et on n'en parle plus ?

A quoi ça sert ?
La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
Comment ajouter la mention [Réglé] à votre discussion ?
1 - Aller sur votre discussion et éditer votre premier message :


2 - Cliquer sur la liste déroulante Préfixe.

3 - Choisir le préfixe [Réglé].


4 - Et voilà… votre discussion est désormais identifiée comme réglée.

2 sur 2 < >

Assistance au forum - Outil de publication d'infos de votre site

Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

UTILISER À VOS PROPRES RISQUES :
L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

Problèmes connus :
FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

Installation :

1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

Archive zip : https://github.com/AFUJ/FPA/zipball/master

2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
et remplacer www. votresite .com par votre nom de domaine


Exemples:
Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/
Pour executer le script: http://www..com/fpa-fr.php

Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/cms/
Pour executer le script: http://www..com/cms/fpa-fr.php

En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
Voir plus
Voir moins

Partenaire de l'association

Réduire

Hébergeur Web PlanetHoster
Travaille ...
X