Grav-plugin-admin: Ajouter des options de page personnalisées

J'en aurais besoin bientôt pour un client
avez-vous des indications sur la façon dont je pourrais mettre cela en œuvre moi-même?

Eh bien, lorsque vous dites à un client d'ajouter une page, tout ce qu'il doit faire est de sélectionner un modèle pour la bonne chose. Si vous créez le blog, la galerie, etc. ce sera tout aussi simple. Cependant, si vous vouliez vraiment ajouter des boutons, dupliquez simplement le bouton d'ajout de page mais mettez le modèle de champ présélectionné et masqué (si vous le souhaitez)

@ricardo118 J'aimerais pouvoir simplement leur dire de sélectionner le bon modèle et le bon dossier, malheureusement à cause de la façon dont le modal est actuellement conçu, la boîte de sélection du dossier répertorie toutes les pages du site, ce qui est problématique car dans l'ordre pour trouver le bon dossier, ils ont besoin de faire défiler potentiellement des centaines de pages. D'où les modaux prédéfinis.

J'espérais une solution plus élégante pour implémenter cela que simplement copier et coller les modaux et éditer directement les fichiers du plugin. (À cause des mises à jour)
J'ai quand même essayé de le faire, mais je rencontre des problèmes lorsque j'essaie de spécifier la valeur par défaut des zones de sélection : assez étrangement, je n'obtiens jamais la bonne option par défaut.

Existe-t-il un moyen d'étendre le plugin admin sans changer son code pour faire ce que je veux ?

Je pense que nous pourrions faire une configuration pour cela.
Je l'ai dans ma version locale si nous pouvons nous mettre d'accord sur la structure de configuration, je peux la refactoriser dans un PR.

Par défaut, il utilise le modèle utilisé par Ajouter une page.

admin.yaml

add_modals:
  post:
    label: Add Post
    blueprint: admin/pages/new_post
    template: custom_template
    link_classes: some_class
    modal_classes: some_modal_class
    with:
      some_data: for the template
    show_in: dropdown
  image:
    label: Add Image
    blueprint: admin/pages/new_image
    show_in: bar

Un exemple de plan. Sur mon blog j'ai plus de 1 auteurs donc avec le getNewPostRoute je peux générer une route pour l'utilisateur, par exemple pour mon compte il génère : "/dave/posts"

nouveau_post.yaml

form:
  validation: loose
  fields:
    section:
        type: section
        title: Add Post

    title:
      type: text
      label: Post Title
      validate:
        required: true

    folder:
      type: hidden

    route:
      type: hidden
      data-default@: '\Grav\Plugin\MyPlugin::getNewPostRoute'

    name:
      type: hidden
      default: 'post'

    visible:
      type: hidden
      default: ''

    blueprint:
      type: blueprint

Quelques images

@david-szabo97 C'est précisément ce que j'avais en tête. Bon travail! Cette configuration me semble assez raisonnable. J'aime particulièrement ce show_in: bar|dropdown, soigné. Comment gérez-vous la partie nom du dossier ?

En attendant que l'équipe donne son impression pour un PR, avez-vous une version de votre code quelque part en ligne ?

@fireraccoon J'ai modifié la partie javascript de la page d'ajout pour slugifier automatiquement le titre. Tout comme il le ferait lorsque vous créez une page. Bien que dans ce cas, vous ne puissiez pas voir le dossier car il est masqué. Mais cela ferait la même chose lorsque vous créez une page normale, copiez simplement le titre slugifié dans la zone de texte du dossier.

Parce qu'il met la nouvelle page (dossier) dans la route, vous pouvez spécifier une route personnalisée, tout comme je l'ai fait data-default@: '\Grav\Plugin\MyPlugin::getNewPostRoute et à la fin vous aurez le même effet. ($route . $dossier)

Je ne l'ai pas encore disponible, mais je peux le télécharger pour vous si vous le souhaitez.

@david-szabo97 Ok je vois ! Je me demandais si vous l'aviez fait à la manière JS ou avec une sorte de crochet de traitement post-formulaire. Oui j'aimerais bien le voir si vous avez le temps merci !

@fireraccoon Cela pourrait être fait avec un hook d'événement, mais la méthode JS semble meilleure.
J'ai joint un fichier zip, remplacez simplement vos plugins/admin par ce dossier admin.
Vous pouvez rechercher les modifications que j'ai apportées en recherchant * MessedCode (C'est mon prochain blog basé sur Grav)
J'ai eu d'autres changements alors j'espère que j'ai supprimé tout le reste et que cela fonctionne bien.

Le code que vous trouverez dans admin.min.js est copié à partir de add.js. C'est juste un moyen pour moi d'éviter de reconditionner l'ensemble du projet JS.

Nous avons quelques utilisateurs sur mon blog, j'ai donc dû faire de nombreux changements pour rendre la publication confortable pour tout le monde. C'est l'un des changements dont nous avons grandement besoin.
admin.zip

@david-szabo97 Merci beaucoup ! Tu m'as sauvé la journée. J'ai réussi à le faire fonctionner avec la dernière version assez facilement. Fonctionne comme un charme. Je pense que c'est un cas d'utilisation assez important, et j'espère vraiment le voir intégré dans le plugin bientôt. De plus, les changements sont très simples.

Un PR serait bien. Je préférerais cependant ne pas compter sur JS pour le faire.

Fonctionnalité fusionnée dans https://github.com/getgrav/grav-plugin-admin/issues/1104

@rhukster , je voudrais transmettre des données arbitraires de frontmatter à partir du modal. Cela semble ne pas fonctionner pour le moment. Pourriez-vous suggérer où je devrais chercher dans la base de code pour résoudre ce problème ? Est-ce que je me trompe sur le but de ces modaux ?

form:
  validation: loose
  fields:
    section:
      type: section
      title: Add Fancy Page

    title:
      type: text
      label: Title

    a_custom_attribute:
      type: text
      default: dummy
      label: Won't pre-populate the corresponding field

    header.another_custom_attr:
      type: text
      label: Neither will this
      validate:
        required: true

@k8n
Je peux confirmer que cela ne fonctionne pas comme on pourrait s'y attendre. À l'heure actuelle, seuls les champs de répertoire et de modèle fonctionnent, mais tous les attributs personnalisés de l'avant-propos ne seront pas renseignés.

Je ne sais pas comment le champ with transmet les données à la page réelle qu'il génère. J'ai créé un modal personnalisé ; comme ci-dessous - essayer de définir des champs dans l'en-tête, mais rien n'apparaît dans l'en-tête et aucune erreur n'est enregistrée ?

``` forme :
validation : lâche
des champs:
section:
type : rubrique
titre : Ajouter un élément multimédia

title:
  type: text
  label: Media Item Title
  validate:
    required: true

header.article_hyperlink:
  type: text
  label: Article Hyperlink (URL)
  validate:
    required: true
    type: url
header.article_date:
  type: date
  label: Article Date
  validate:
    required: true
header.article_blurb:
  type: textarea
  label: Article Blurb

folder:
  type: hidden
  default: '@slugify-title'

route:
  type: hidden
  default: /media

name:
  type: hidden
  default: 'media-item'

blueprint:
  type: blueprint

```

Le modal apparaît et crée le contenu, mais aucune des données des champs n'est transmise ?

@sjclark , comme je l'ai dit dans mon commentaire au-dessus du vôtre, actuellement la transmission des données du modal n'est pas implémentée, j'ai vérifié avec Grav Dev Team.

Espérons que quelqu'un fera bientôt un PR pour cela !

+1 à ce sujet.