Skip to content

Tout pour WordPress, le développement web — et plus encore

✏️ Modifier les pages Grav depuis le frontend : installation et droits d'accès

✏️ Modifier les pages Grav depuis le frontend : installation et droits d'accès

Un responsable de contenu se connecte au panneau d’administration, retrouve une page parmi 50 autres, ouvre l’éditeur, corrige un titre, enregistre, retourne sur le site et rafraîchit l’onglet. Six clics pour une seule modification. Pour Grav CMS, il existe une solution simple: le plugin Editable with ContentTools intègre un éditeur WYSIWYG directement sur la page du site. Vous ouvrez la page, cliquez sur «modifier», corrigez le texte et l’enregistrez dans un fichier Markdown sans passer par le panneau d’administration.

Le plugin n’a pas été mis à jour depuis 2022 (l’auteur a officiellement arrêté le support), mais il fonctionne de manière stable sur Grav 1.7 et couvre le scénario de base de l’édition de pages Markdown simples, sans logique dynamique. L’installation prend cinq minutes et, ensuite, modifier du texte en frontend devient beaucoup plus simple.

Voici un guide complet, de l’installation à la gestion des droits d’accès, avec un point sur les limites et une alternative (Fred).

💡 Aperçu rapide:

  • Installez le plugin via GPM ou une archive zip et copiez la configuration.
  • Configurez git-sync pour pousser les modifications vers un dépôt (optionnel).
  • Balisez les zones éditables avec le shortcode editable en utilisant des noms uniques.
  • Accordez la permission site.editable aux utilisateurs frontend.
  • Fusionnez les sessions admin et frontend via session.split: false.
  • Gardez à l’esprit la limite: uniquement du Markdown simple, pas de Twig ni de contenu dynamique.

Installation: via GPM ou manuellement

Le plugin s’installe via Grav Package Manager, la méthode standard pour tout add-on dans Grav:

1bin/gpm install editable-contenttools

Exécutez la commande depuis le dossier racine du site (là où se trouve bin/). GPM téléchargera la dernière version et l’extraira dans /user/plugins/editable-contenttools.

Vous pouvez également l’installer manuellement: téléchargez l’archive zip depuis GitHub, extrayez-la dans /user/plugins/ et renommez le dossier en editable-contenttools (sans le suffixe -master). La structure doit ressembler à ceci: /user/plugins/editable-contenttools/editable-contenttools.php.

Copiez la configuration vers un emplacement sûr

Après l’installation, veillez à copier le fichier de configuration dans le répertoire utilisateur:

1cp user/plugins/editable-contenttools/editable-contenttools.yaml user/config/plugins/editable-contenttools.yaml

Cette étape est importante: si les paramètres restent dans le dossier du plugin, ils seront réinitialisés lors d’une mise à jour via GPM. Une autre approche consiste à installer via le panneau d’administration de Grav (Plugins → Ajouter); dans ce cas, le système crée automatiquement la configuration dans user/config/plugins/ et aucune copie manuelle n’est nécessaire.

Configuration: trois options de paramétrage

Le fichier editable-contenttools.yaml contient trois paramètres:

1enabled: true
2git-sync: false
3git-sync-mode: foreground

enabled active le plugin. Sans enabled: true, l’éditeur n’apparaîtra pas en frontend, même si les permissions sont accordées. La valeur par défaut est true.

git-sync déclenche une synchronisation avec un dépôt Git après chaque enregistrement. Cela ne fonctionne que si le plugin Git Sync est installé. Si votre site est géré sous Git et que vous souhaitez consigner chaque modification dans l’historique, passez ce paramètre à true. Sinon, laissez-le sur false.

git-sync-mode détermine s’il faut attendre la fin de la synchronisation avant de rendre la main à l’utilisateur. foreground signifie que le bouton «Enregistrer» ne se déverrouille qu’une fois le commit et le push terminés. background fonctionne de manière asynchrone, mais certains serveurs Linux peuvent rencontrer des problèmes avec les processus en arrière-plan. Dans la plupart des cas, foreground est suffisant.

Balisage des zones éditables: le shortcode [editable]

Exemple du shortcode [editable] dans un fichier Markdown de page Grav

Le plugin ne rend pas automatiquement toute la page éditable. Vous définissez les blocs modifiables à l’aide du shortcode [editable]:

1[editable]
2## Section heading
3
4Text that can be edited from the frontend.
5[/editable]

Une page peut contenir autant de zones de ce type que nécessaire. Chaque zone doit avoir un nom unique, sinon ContentTools ne saura pas où enregistrer les modifications.

Le paramètre name: une unicité obligatoire

Par défaut, le plugin attribue des noms automatiquement (region-0, region-1, etc.), mais il est préférable de spécifier manuellement des noms explicites:

1[editable name="hero-block"]
2## Main heading
3
4Text that can be edited.
5[/editable]

Lors du premier enregistrement via le frontend, le plugin ajoute automatiquement un paramètre name au shortcode s’il en manquait un. En pratique, il est plus simple de préciser les noms dès la phase de balisage, car cela facilite le débogage (vous pouvez voir quel bloc vous modifiez dans les outils de développement du navigateur).

Après avoir balisé et enregistré la page, visitez le site en tant qu’utilisateur disposant de la permission site.editable, cliquez sur l’icône en forme de crayon à gauche et modifiez le texte comme vous le feriez dans un éditeur de texte standard. Maintenez la touche Maj enfoncée pendant environ trois secondes pour mettre en surbrillance toutes les zones éditables.

Vous pouvez l’essayer sur le site de démonstration du plugin (l’enregistrement est désactivé, Grav 1.7.46).

Droits d’accès: frontend et backend

Pour qu’un utilisateur voie l’icône en forme de crayon, il doit disposer des permissions de modification. Les règles diffèrent pour les utilisateurs frontend (gestionnaires de contenu) et les utilisateurs backend (administrateurs).

Utilisateurs frontend

L’utilisateur doit pouvoir se connecter via le plugin Grav Login ou Private Grav. Ajoutez ensuite ce qui suit dans le fichier de compte (user/accounts/username.yaml):

1access:
2 site:
3 login: 'true'
4 editable: 'true'

Sans la permission site.editable, l’icône en forme de crayon n’apparaîtra pas, même si l’utilisateur est connecté et dispose d’autres droits.

Utilisateurs backend (administrateurs)

Par défaut, Grav sépare les sessions admin et frontend. Pour permettre à un administrateur de modifier des pages directement sur le site (sans passer par le panneau d’administration), définissez ce qui suit dans system.yaml (ou via le panneau d’administration Configuration → Système):

1session:
2 split: false

Cela fusionne les sessions: se connecter au panneau d’administration accordera automatiquement l’accès à l’éditeur frontend. L’administrateur aura également besoin de la permission admin.super ou admin.pages dans son fichier de compte.

Si l’icône n’apparaît pas après la connexion, vérifiez les paramètres de cache de l’administration:

1admin:
2 super: 'true'
3 login: 'true'
4 cache: 'false'

Le paramètre cache: false désactive le cache pour l’administration et peut résoudre le problème de l’icône invisible.

Limitations: ce que le plugin ne peut pas faire

Le plugin fonctionne exclusivement avec du Markdown simple. Il s’agit d’une limitation architecturale, pas d’un bug: ContentTools modifie le HTML dans le navigateur, et le plugin reconvertit le HTML en Markdown. Au cours de ce processus, tout balisage dynamique sera corrompu. Ne modifiez pas le contenu via ContentTools s’il:

  • est assemblé par des templates Twig (par exemple, les pages modulaires: les blocs enfants sont insérés dynamiquement par le parent, et le plugin ne peut pas voir leur source);
  • est injecté par d’autres plugins (Page Inject et les plugins similaires insèrent du contenu provenant d’autres pages, ce qui est un processus à sens unique);
  • change via JavaScript dans le navigateur (les sliders, accordéons et autres éléments interactifs seront convertis en HTML statique);
  • contient des balises spéciales Grav Markdown (les images avec les paramètres ?lightbox et ?resize seront endommagées lors de la conversion HTML → Markdown, car les paramètres de traitement disparaîtront).

Les règles de sécurité sont simples:

  • Gardez les images et les shortcodes complexes en dehors des zones éditables.
  • Gardez des zones de petite taille: leur nombre est illimité, et 10 petits blocs valent mieux qu’un seul grand bloc comportant des risques.
  • Testez sur une copie de l’article ou dans un environnement de staging avant de donner l’accès aux éditeurs.
  • Si vous remarquez des différences de formatage Markdown entre la version avec l’icône en forme de crayon et la version sans, déplacez ce fragment en dehors de [editable].

Alternative: le plugin Fred

Si les fonctionnalités d’Editable with ContentTools ne vous suffisent pas, jetez un œil à Fred, un éditeur frontend plus récent pour Grav, également basé sur ContentTools. Principales différences:

  • Téléversement d’images via une boîte de dialogue (avec rotation et traitements de base).
  • Enveloppement automatique du contenu via l’événement onPageProcessed, ce qui réduit le recours manuel aux shortcodes.
  • Développement actif: l’auteur traite les issues sur GitHub et continue d’ajouter des fonctionnalités.

Installation par clonage du dépôt dans /user/plugins/fred:

1cd user/plugins
2git clone https://github.com/BugHunter2k/grav-plugin-fred.git fred

Les permissions se règlent de manière similaire: site.editor: true dans le fichier de compte utilisateur (attention: site.editor, et non site.editable).

Editable with ContentTools et Fred répondent au même besoin: fournir aux gestionnaires de contenu un outil pour des modifications rapides sans passer par le panneau d’administration. Le premier est adapté si vous cherchez un outil simple et éprouvé pour des pages Markdown, sans expérimentation. Le second convient si vous souhaitez plus d’automatisation et êtes prêt à accepter les éventuels aléas d’un développement actif.

Vidéo: fonctionnement de ContentTools

Une démonstration de deux minutes de l’édition d’une page Grav dans le navigateur: l’auteur montre comment les zones éditables sont mises en surbrillance, comment les modifications sont apportées et comment le contenu est sauvegardé en Markdown. Un bon moyen de voir le plugin en action avant de l’installer.

⁉️🤔 Foire aux questions

Pourquoi l’icône en forme de crayon n’apparaît-elle pas après l’installation?

Vérifiez quatre points. Premièrement, enabled: true dans la configuration du plugin (user/config/plugins/editable-contenttools.yaml). Deuxièmement, l’utilisateur doit disposer de la permission site.editable dans son fichier de compte. Troisièmement, pour les utilisateurs backend, session.split doit être à false dans system.yaml. Quatrièmement, videz le cache de Grav: bin/grav clear-cache. En général, le problème vient soit des permissions, soit des sessions partagées.

Puis-je éditer des pages modulaires?

Non. Les pages modulaires sont assemblées à partir de pages enfants via des templates Twig, ce qui est un processus à sens unique: le plugin ne peut pas «désassembler» le résultat pour revenir aux parties. Sur le frontend, vous voyez le HTML final, mais la source (les fichiers Markdown distincts des modules enfants) se trouve dans d’autres dossiers, et le plugin ne sait pas où enregistrer les modifications. Pour les pages modulaires, utilisez l’interface d’administration standard de Grav.

Que se passe-t-il si je laisse une image à l’intérieur de [editable]?

Les balises spéciales Markdown de Grav pour les images (avec les paramètres ?lightbox, ?resize, ?cropResize) seront endommagées lors de la conversion HTML vers Markdown. L’image elle-même restera en place (la balise <img> est convertie en Markdown standard ![](url)), mais les paramètres de traitement disparaîtront. Conclusion: placez toujours les images avec paramètres en dehors de la zone éditable. Si une image est simple (sans paramètres), vous pouvez techniquement la laisser à l’intérieur, mais en pratique il est plus sûr de sortir tous les médias de [editable].

Le plugin est abandonné par son auteur. Est-il sûr de l’utiliser?

L’auteur a officiellement annoncé la fin du support en 2022, et le dernier commit date d’août 2024 (une mise à jour de compatibilité pour Grav 1.7). Le plugin est stable sur Grav 1.7 et n’affecte pas les composants critiques pour la sécurité: il travaille uniquement avec du contenu Markdown et n’a pas accès aux opérations serveur. Si vous prévoyez de passer à Grav 2.0, envisagez de vous tourner vers Fred ou d’attendre une solution officielle d’édition frontend (de nouvelles approches basées sur TinyMCE et Prosemirror sont en cours de discussion sur le forum).

Quelle est la différence entre Editable with SimpleMDE et la version ContentTools?

Editable with SimpleMDE utilise la même approche (édition frontend), mais au lieu d’un éditeur visuel, il fournit l’éditeur Markdown SimpleMDE avec prévisualisation en direct. Il convient à ceux qui préfèrent écrire le balisage à la main et souhaitent voir le résultat à droite de l’éditeur plutôt qu’en mode WYSIWYG. Les deux plugins sont du même auteur (bleutzinn) et tous deux sont abandonnés depuis 2022.

Vaut-il la peine d’installer un éditeur frontend pour Grav en 2026

Si votre site tourne sous Grav 1.7, se compose de pages Markdown simples et que les gestionnaires de contenu en ont assez de passer par le panneau d’administration pour quelques retouches, installez Editable with ContentTools. Cinq minutes d’installation, une configuration minimale, et l’édition devient une opération en un clic. Ouvrez la page, cliquez sur le crayon, corrigez le texte, enregistrez. Plus besoin de chercher dans les listes de pages ni de changer d’onglet.

Pour les nouveaux projets ou si vous anticipez un passage à Grav 2.0 (une sortie est attendue en 2026, sans date précise pour le moment), envisagez Fred: son développement est plus actif et il a plus de chances de bénéficier d’une compatibilité avec la deuxième version du CMS. Dans tous les cas, l’édition frontend vous fait gagner des dizaines de clics et de précieuses minutes à chaque modification, ce qui est particulièrement sensible sur les sites dont le contenu est fréquemment mis à jour. Testez-la sur un environnement de test et jugez par vous-même à quel point cette approche accélère votre flux de travail.