web-dev-qa-db-fra.com

Des moyens alternatifs pour ajouter des champs utilisateur par programme?

Actuellement, j'utilise cela pour ajouter des champs utilisateur par programme:

function openid_connect_entity_base_field_info(EntityTypeInterface $entity_type) {
    if ($entity_type->id() === 'user') {
        $fields['field_family_name'] = BaseFieldDefinition::create('string')
          ->setLabel(t('Family Name'))
          ->setDescription(t('Add a description'))
          ->setRevisionable(TRUE)
          ->setTranslatable(TRUE)
          ->setDisplayOptions('form', array(
            'type' => 'string_text_field',
            'weight' => 30,
            'default_value' => 0,
          ))
          ->setDisplayConfigurable('form', TRUE);
      }
return $fields;
}

mais il en résulte que l'administrateur du site ne peut pas désinstaller mon module comme indiqué: enter image description here

Existe-t-il d'autres moyens d'ajouter par programmation des champs utilisateur sans que l'administrateur du site Web ne soit pas en mesure de désinstaller le module qui a ajouté les champs utilisateur par programmation?

8usersentities
5
Callum

J'ai trouvé une solution en utilisant des fichiers .yml dans le répertoire config/install de vos modules.

1. Créez le champ utilisateur

allez dans Configuration -> Personnes -> Paramètres du compte -> Gérer les champs et appuyez sur "+ Ajouter un champ". Je recommande de donner au champ un nom unique lisible par machine pour éviter les champs utilisateur conflictuels.

enter image description here

Activez le champ utilisateur dans Gérer l'affichage du formulaire et Gérer l'affichage si vous souhaitez qu'il apparaisse dans la page de modification du profil et d'inscription des utilisateurs.

2.Exportation de la configuration du champ utilisateur

allez dans Configuration -> Développement -> Synchronisation de la configuration -> Exporter -> Élément unique

Une fois que vous arrivez à un écran similaire à celui ci-dessous, définissez le type de configuration sur "Champ" puis définissez le nom de la configuration sur le champ que vous avez créé.

Dans vos dossiers Config/install dossier (créez-en un si nécessaire) créez un nouveau fichier nommé d'après le nom de fichier surligné en rouge ci-dessous.

Enfin, copiez le texte yml dans le fichier que vous venez de créer.

enter image description here

puis définissez le type de configuration sur "Field Storage" puis définissez le nom de la configuration sur le champ utilisateur que vous avez créé.

Dans votre dossier Config/install des modules (créez-en un si nécessaire) créez un nouveau fichier nommé d'après le nom de fichier surligné en rouge ci-dessous (ne copiez pas celui de l'exemple votre champ utilisateur aura un nom différent).

Enfin, copiez le texte yml dans le fichier que vous venez de créer.

enter image description here

VOUS AVEZ BESOIN DES DEUX FICHIERS YML POUR CRÉER PAR PROGRAMMATION UN CHAMP UTILISATEUR

Je recommande de le faire pour chaque champ utilisateur que vous souhaitez ajouter par programme plutôt que de copier la configuration et de modifier quelques propriétés.

Avec cette méthode, vous pouvez désinstaller le module qui a créé ces champs utilisateur.

7
Callum

Réponse mise à jour:

Vous pouvez inclure le champ comme configuration par défaut lors de l'installation du module. En ajoutant la configuration de champ aux fichiers exportables (fichiers yaml), ceux-ci peuvent ensuite être installés et ajoutés. Lors de la désinstallation du module, le champ et les données resteront.

Dans votre module, créez les dossiers config/install et y placer les fichiers de configuration: Par exemple, si j'ajoute un champ field_test_email Je placerais le stockage sur le terrain puis l'instance sur l'entité Utilisateur.

field.storage.user.field_test_email.ymlfield.field.user.user.field_test_email.yml

https://www.drupal.org/docs/8/creating-custom-modules/include-default-configuration-in-your-drupal-8-module

Ancienne réponse:

Si vous souhaitez conserver les champs et leurs données, la réponse courte est Non, vous ne pouvez pas et ne devriez pas . Les définitions de champ, la configuration sont couplées à son créateur "le module", et lors de la désinstallation tout ce qu'il a fait s'en va avec.

Drupal supportait la désactivation d'un module, mais cela a été supprimé. Voir l'explication ici: https://www.drupal.org/node/2225029

Un énorme débat et une réflexion approfondie ont eu lieu à ce sujet, avec des discussions fortes des deux côtés. Les raisons en sont les suivantes: * Parce que les mises à niveau de certains modules contrib ne fonctionnent pas réellement (et ne peuvent pas> fonctionner) si la mise à niveau est désactivée. * Parce que les données laissées par un module désactivé qui est réactivé par la suite> provoquent des problèmes d'intégrité et des pannes. * Certaines mises à niveau ont laissé derrière elles une perte de données en raison de choses comme des dépendances inattendues, des plugins ou des hooks indisponibles aux moments clés - lorsque les choses ont été désactivées. .. cette question comporte plusieurs centaines d'arguments, il est donc injuste de trop résumer.

Lors d'une désinstallation, différents validateurs sont appelés pour garantir que le système ne casse pas ou ne conserve pas les données qui ne peuvent pas être traitées ultérieurement. Pour votre cas, c'est le validateur FieldModuleUninstallValidator qui vous donne ces messages d'erreur.

Donc, pour désinstaller le module, toutes les données doivent être supprimées; Vous pouvez essayer d'utiliser la suppression en bloc de l'API de champ pour cela: https://api.drupal.org/api/drupal/core!modules!field!field.purge.inc/group/field_purge/8.2.x

0
johndevman