Score:1

How to make a custom entity fieldable?

us flag

This has been asked here before; but question is closed and the few replies do not provide sufficient information.

I am trying to use a contrib module (sitewide_alert) which provides its own custom entity. I am trying to figure out how to patch this module to make it fieldable (and how to do this in general).

In other posts I have seen suggestions to add the follinwg to the ContentEntityType annotation:

  • fieldable = TRUE;
  • bundle_entity_type = ??
  • field_ui_base_route -> different suggestions but already exists for this module pointing to the module's config form.

But none of those seemed to fix this.

the full annotation for the entity is:

* @ContentEntityType(
 *   id = "sitewide_alert",
 *   label = @Translation("Sitewide Alert"),
 *   label_plural = @Translation("Sitewide Alerts"),
 *   label_collection = @Translation("Sitewide Alerts"),
 *   handlers = {
 *     "storage" = "Drupal\sitewide_alert\SitewideAlertStorage",
 *     "view_builder" = "Drupal\Core\Entity\EntityViewBuilder",
 *     "list_builder" = "Drupal\sitewide_alert\SitewideAlertListBuilder",
 *     "views_data" = "Drupal\sitewide_alert\Entity\SitewideAlertViewsData",
 *     "translation" = "Drupal\sitewide_alert\SitewideAlertTranslationHandler",
 *
 *     "form" = {
 *       "default" = "Drupal\sitewide_alert\Form\SitewideAlertForm",
 *       "add" = "Drupal\sitewide_alert\Form\SitewideAlertForm",
 *       "edit" = "Drupal\sitewide_alert\Form\SitewideAlertForm",
 *       "delete" = "Drupal\sitewide_alert\Form\SitewideAlertDeleteForm",
 *     },
 *     "route_provider" = {
 *       "html" = "Drupal\sitewide_alert\SitewideAlertHtmlRouteProvider",
 *     },
 *     "access" = "Drupal\sitewide_alert\SitewideAlertAccessControlHandler",
 *   },
 *   base_table = "sitewide_alert",
 *   data_table = "sitewide_alert_field_data",
 *   revision_table = "sitewide_alert_revision",
 *   revision_data_table = "sitewide_alert_field_revision",
 *   show_revision_ui = TRUE,
 *   translatable = TRUE,
 *   admin_permission = "administer sitewide alert entities",
 *   entity_keys = {
 *     "id" = "id",
 *     "revision" = "vid",
 *     "label" = "name",
 *     "uuid" = "uuid",
 *     "uid" = "user_id",
 *     "langcode" = "langcode",
 *     "published" = "status",
 *   },
 *   revision_metadata_keys = {
 *     "revision_user" = "revision_user",
 *     "revision_created" = "revision_created",
 *     "revision_log_message" = "revision_log",
 *   },
 *   links = {
 *     "canonical" = "/admin/content/sitewide_alert/{sitewide_alert}",
 *     "add-form" = "/admin/content/sitewide_alert/add",
 *     "edit-form" = "/admin/content/sitewide_alert/{sitewide_alert}/edit",
 *     "delete-form" = "/admin/content/sitewide_alert/{sitewide_alert}/delete",
 *     "version-history" = "/admin/content/sitewide_alert/{sitewide_alert}/revisions",
 *     "revision" = "/admin/content/sitewide_alert/{sitewide_alert}/revisions/{sitewide_alert_revision}/view",
 *     "revision_revert" = "/admin/content/sitewide_alert/{sitewide_alert}/revisions/{sitewide_alert_revision}/revert",
 *     "revision_delete" = "/admin/content/sitewide_alert/{sitewide_alert}/revisions/{sitewide_alert_revision}/delete",
 *     "translation_revert" = "/admin/content/sitewide_alert/{sitewide_alert}/revisions/{sitewide_alert_revision}/revert/{langcode}",
 *     "collection" = "/admin/content/sitewide_alert",
 *   },
 *   field_ui_base_route = "sitewide_alert.settings",
 *   constraints = {
 *     "ScheduledDateProvided" = {}
 *   }
 * )
 */

In my trial/error approach I did notice I created the Manage Fields/Display/etc UI for each entity I had previously created. So I think this is possibly related to not having a bundle defined? My use case doesn't require making new bundles (similar to the User entity).

Despite the other posted answers; my guess is modifying the annotation is not enough to add this functionality.

Score:1
cn flag

There is nothing wrong with the entity type annotation. After you have removed this code intentionally disabling the field UI routes

https://git.drupalcode.org/project/sitewide_alert/-/blob/8.x-1.6/src/Routing/RouteSubscriber.php

the entity should be fieldable at admin/content/sitewide_alert/settings/fields.

This is a very cool module. After playing around a little bit I've found out the module has two settings routes, the mentioned dummy form in an odd place under content and the official module settings form in configuration. If you attach the field UI to this form it's easier to find I think:

field_ui_base_route = "sitewide_alert.sitewide_alert_config_form"
liquidcms avatar
us flag
awesome. I hadn't even seen that route file intentionally blocking user from getting to field management. I guess the project maintainer assumes to know every possbile use case for their module. And yes, moving the field ui under the config form makes more sense, i guess. Like the User entity; although always personally though that was wrong to be there and should be under Structure. I'll add the missing links/tabs as well and create a patch. Thanks for your help.
liquidcms avatar
us flag
I guess this means the predominent answer I have seen posted that annotation: "fieldable = true" is requied - is not required (it isn't as i don't have it now and everything is working as expected).
4uk4 avatar
cn flag
No, this annotation doesn't exist in D8/9. For a minimal fieldable entity type see https://drupal.stackexchange.com/questions/283826/how-do-i-add-a-view-mode-to-a-simple-custom-entity
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.