Comment ajouter des champs personnalisés et des paramètres d'affichage aux types de contenu intégrés via l'installation d'un module personnalisé?
Je suis assez nouveau sur Drupal, je viens du développement Wordpress et j'essaie de "traduire" certains de mes plugins en modules dans Drupal 8.
Je suis la documentation essayant d'ajouter un nouveau champ, dites "prix" à un nœud. Toute la documentation que j'ai trouvée est liée à l'ajout d'un champ à un nœud personnalisé, mais dans mon cas, je veux ajouter ces champs à des nœuds prédéfinis normaux.
La première question qui me vient à l'esprit est, je peux créer le champ personnalisé avec des fichiers de configuration YML ou du code non?
J'ai créé le champ avec YML et il est reconnu par drupal; le problème est qu'ils n'apparaissent pas sur les nœuds (je dois l'activer manuellement).
J'ai créé sur mon module/config/install /:
- core.entity_form_display.node.article.default
- core.entity_view_display.node.article.default
J'ajoute mon champ, mais bien sûr quand j'essaye d'activer le module ça ne lui plaît pas car ils sont déjà définis par Drupal.
Existe-t-il un moyen "d'étendre" ces fichiers principaux? est-ce possible avec YML ou du code?
J'ai suivi https://www.drupal.org/docs/8/api/entity-api/programming-custom-fields-into-your-content-type . J'ai créé les fichiers YML sur/config/install, et en effet le champ est créé, le problème est que je ne sais pas "étendre" les entités d'affichage et de formulaire car elles ne sont pas liées à un type de nœud personnalisé, sinon elles devraient être lié à des types de nœuds prédéfinis et je ne peux pas redéfinir ces fichiers (core.entity_form_display.node.article.default core.entity_view_display.node.article.default) car ils existent déjà sur le noyau.
Suite à cela commentaire J'ai créé les fichiers suivants:
/config/install/field.field.node.article.field_price.yml
langcode: en
status: true
dependencies:
config:
- field.storage.node.field_price
- node.type.article
id: node.article.field_price
field_name: field_price
entity_type: node
bundle: article
label: Price
description: 'Premium Price'
required: false
translatable: false
default_value: { }
default_value_callback: ''
settings:
min: 1
max: 9999
prefix: ''
suffix: ''
field_type: integer
/config/install/field.storage.node.field_price.yml
langcode: en
status: true
dependencies:
module:
- node
id: node.field_price
field_name: field_price
entity_type: node
type: integer
settings:
unsigned: false
size: normal
module: core
locked: false
cardinality: 1
translatable: true
indexes: { }
persist_with_no_fields: false
custom_storage: false
J'ai également créé FieldFormatter et FieldWidget. (Je ne sais pas si c'est bien.)
Ce que j'ai découvert, c'est que le module crée le champ Prix. Si je vais dans/admin/structure/types/manage/article/display, j'y vois mon prix, mais il est sous Désactivé .
Je sens que je suis si proche, mais en même temps si perdu.
Que manque-t-il pour activer ce champ?
Pour un débutant, je recommande d'utiliser l'interface utilisateur pratique de Drupal dans le back-end. Créez un utilisateur administrateur, connectez-vous, commencez à ajouter des champs, changez l'affichage, réorganisez - tout se fait en cliquant sur l'interface.
Par exemple, vous pouvez ajouter des champs personnalisés au type de contenu d'article existant sur https://example.com/admin/structure/types/manage/article/fields . Il y a un bouton Add fields. Cliquez dessus et explorez . Il n'y a aucune différence dans l'ajout de champs à un type de contenu intégré.
Comme d'autres l'ont déjà dit, YML est destiné à l'exportation et à l'importation de configuration lors du déploiement d'un site. Comme vous le feriez en tant que développeur avancé: vous auriez cette page localement sur votre ordinateur, ajoutez des champs en cliquant sur le back-end, exportez leur config, Poussez cela vers un dépôt Git, puis sur votre page en direct, tirez de votre référentiel, importez les fichiers de configuration et obtenez les mêmes champs là-bas sans avoir à cliquer à nouveau sur quoi que ce soit.
L'ajout de champs à partir d'un module personnalisé peut être réalisé en fournissant certains YML dans le dossier /config/install De vos modules. Il n'y a pas non plus de différence entre les types de contenu intégrés ou les types de contenu personnalisés. Il est décrit assez bien sur DO à https://www.drupal.org/docs/8/api/entity-api/programming-custom-fields-into-your-content-type . Sauf que vous devrez changer la dénomination et surtout changer la valeur du bundle: car_brand (Type de contenu) auquel vous voulez ajouter vos champs.
En dehors de cela, vous devrez peut-être installer et désinstaller ce module assez souvent pendant le développement. Habituez-vous aux commandes drush, par exemple drush dre module_name Pour le faire dans Terminal/Console (vous devez avoir installé le module Devel pour utiliser drush dre ). Pour votre bien, j'espère que vous travaillez déjà avec un système d'exploitation basé sur UNIX (Linux ou OSX). Peut-être avez-vous toujours une nouvelle sauvegarde de base de données disponible que vous pouvez réimporter avec drush sql-cli < database.sql Lorsque vous souhaitez recommencer pendant le développement.
Juste pour référence, je colle le code de réponse supprimé ici, OP avait initialement posé sa question. Pour finalement rendre les champs disponibles dans le type de contenu OP, cela a été proposé. Je suppose fortement qu'il avait mis cela dans le fichier *.install Du module appelant hook_install() ou hook_update_N(). Fonctions peut-être obsolètes, mais je pense que vous aurez l'idée.
$entity_type = 'node';
$bundle = 'article';
$field['field_name'] = 'field_price'; // your field id
entity_get_form_display($entity_type, $bundle, 'default')
->setComponent($field['field_name'], array())
->save();
entity_get_display($entity_type, $bundle, 'default')
->setComponent($field['field_name'], array())
->save();
Les fichiers de configuration YML de Drupal sont principalement destinés à l'importation/exportation, pour rendre la configuration portable entre les instances du même site et pour permettre le contrôle de version. Ils ne sont pas vraiment destinés à être un outil de développement et je ne recommanderais jamais de les écrire à la main, même lorsque vous êtes un développeur expérimenté Drupal.
Quelle que soit la façon dont un type de nœud a été défini, vous devriez pouvoir y ajouter des champs via l'interface utilisateur d'administration. Je vous recommande de le faire de cette façon et d'utiliser le système d'exportation de configuration (soit dans l'interface utilisateur d'administration ou en utilisant Drush sur la ligne de commande) pour générer des YML de configuration qui contiennent toutes les données nécessaires.
Je l'ai fait fonctionner en utilisant un core.entity_form_display.node.<modulename>.default.yml fichier avec le contenu suivant:
langcode: en
status: true
dependencies:
config:
- field.field.node.modulename.body
- node.type.modulename
module:
- link
id: node.modulename.default
targetEntityType: node
bundle: modulename
mode: default
content:
body:
label: hidden
type: string_textarea
weight: 4
settings:
rows: 5
placeholder: ''
third_party_settings: { }
region: content
hidden:
created: true
path: true
promote: true
sticky: true
uid: true
body: true
Ce qui manque à @leymannx, c'est une explication de ce qui peut (et devrait) être livré avec un module personnalisé et ce qui ne peut pas.
Le stockage sur site peut et doit être expédié avec votre module.
L'instance de champ peut être fournie avec votre module, mais uniquement sous la forme optional, car elle dépendrait d'autres modules fournissant des types de contenu (sauf si votre module fournit à la fois le type de contenu et les champs, auquel cas vous pouvez simplement fournir dans config/install). Btw, vous pouvez stocker ces fichiers dans ce module ou dans un autre module - lorsqu'il est activé, Drupal analysera tous les répertoires config/optional Pour que tous les modules récupèrent toute configuration pertinente. https://www.drupal.org/node/2453919
L'affichage du formulaire d'entité ne peut pas être expédié avec votre module. De plus, si votre module ne fournit qu'un champ, l'affichage du formulaire d'entité d'expédition pour l'entité entière remplacerait la configuration existante. Au lieu de cela, votre module doit inclure l'implémentation de hook_install() où les champs seront modifiés pour l'affichage du formulaire pour tous les types de contenu pris en charge.
L'affichage de la vue d'entité doit être traité de la même manière que l'affichage du formulaire d'entité.