| [11:50:19] | <symbioquine[m]> | farmOS dev call in about 10 minutes. All are welcome! |
| [11:50:19] | <symbioquine[m]> | Join: https://meet.jit.si/farmos-dev |
| [13:05:09] | <paul121[m]> | The thing I wanted to share is re: taxonomy term bundle fields. Right now we have a bit of an unsolved issue where it is possible for contrib modules to add bundle fields to a taxonomy term, but it is challenging for this contrib module to manage the form & view display of their bundle fields for this taxonomy term |
| [13:06:21] | <paul121[m]> | Well, it actually could be simple for a single contrib module to manage this, but the challenge is when multiple contrib modules want to provide & manage bundle fields to the same taxonomy vocabulary |
| [13:07:01] | <mstenta[m]> | (Semi related: https://www.drupal.org/project/farm/issues/3190851) |
| [13:07:37] | <paul121[m]> | This issue does not exist for assets/logs because they use bundle plugins, but it seems quite challenging to enable this for taxonomy terms |
| [13:07:44] | <paul121[m]> | ^ yes! |
| [13:08:19] | <paul121[m]> | SO I think I've found an alternative solution for managing the default form/view display for taxonomy terms |
| [13:08:28] | <mstenta[m]> | Yea I ended up closing that issue as "won't fix" ... we could reconsidder, but yea: |
| [13:08:28] | <mstenta[m]> | > This is a more invasive change to Drupal core functionality (taxonomy terms), so it may require more testing than our other primary asset types did. |
| [13:09:27] | <paul121[m]> | via hook_entity_form/view_display_alter and the View/FormDisplay::setComponent() method |
| [13:10:46] | <paul121[m]> | it's possible to detect if the `default` entity view/form display has been saved into configuration via its entity `$entity->isNew()` |
| [13:11:50] | <paul121[m]> | so basically... a module can add bundle fields to a taxonomy, implement hook_entity_view_display_alter and add their own bundle fields to the default display as desired |
| [13:12:45] | <paul121[m]> | but only do so if the default display has not been saved or modified into configuration. The default displays are not saved by default |
| [13:13:41] | <paul121[m]> | This came up because I'm needing to do this for the farm_product module adding 2 bundle fields to units taxonomy terms |
| [13:13:55] | <paul121[m]> | ACTION uploaded an image: (49KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/CKKjawVFsTV... > |
| [13:14:48] | <paul121[m]> | here is the view display configuration for units. Notice that the package bundle fields are hidden... |
| [13:14:57] | <paul121[m]> | ACTION uploaded an image: (56KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/mqiiJyHViXm... > |
| [13:15:31] | <paul121[m]> | yet when you actually view a unit term, these bundle fields are displayed. That is because of the alter hook. |
| [13:15:37] | <paul121[m]> | ACTION uploaded an image: (14KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/TBBCfDqvNEy... > |
| [13:16:23] | <paul121[m]> | paul121[m]: But importantly, once you click "Save" on this "Manage display" form, the `default` view mode is then saved & will behave as expected |
| [13:19:32] | <paul121[m]> | So there is some weird UX in these screenshots because the "Manage display/form" may not actually behave as seen, but this is only for super farmOS admins. We could add a message to this page saying "This entity display has not been saved and may be altered by other modules" & also provide a button to "reset" these view/form displays back to their original configuration (surprised drupal doesn't already have this) |
| [13:23:55] | <paul121[m]> | I kinda wonder if we could use this same approach for the default view/form displays of assets/logs as well, they have a similar issue where it is challenging to completely modify the default display. But less of a concern. For taxonomy this is actually something I need to figure out soon :-) |
| [13:24:35] | <paul121[m]> | code example:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/8f7837d89a...) |
| [13:25:44] | <paul121[m]> | oh also... taxonomy terms are weird because the default view display mode is actually called full. but their form mode is default 🤷 |
| [13:45:51] | <mstenta[m]> | Interesting! |
| [13:46:34] | <mstenta[m]> | What would we need to do in farmOS core (if anything)? |
| [13:56:03] | <paul121[m]> | Well the above works without changes to farmOS core |
| [13:56:42] | <paul121[m]> | But I think we could remove the default view/form displays we provide for a few of our taxonomies & update to this approach |
| [13:56:51] | <mstenta[m]> | Ahh |
| [13:56:52] | <mstenta[m]> | Love it! |
| [13:57:23] | <mstenta[m]> | I suppose that would also mean deleting existing saved config for those... but of course we'd want to make sure they were not overridden already |
| [13:57:23] | <paul121[m]> | I just happen to not be modifying one of the taxonomies that has the display committed... |
| [13:57:49] | <mstenta[m]> | (in an update hook) |
| [13:58:28] | <paul121[m]> | Right, but to simplify that, can we just check if farm_update is/is not enabled? |
| [13:58:40] | <mstenta[m]> | I was just thinking something like that too :-) |
| [13:58:50] | <paul121[m]> | Maybe make sure the specific config item isn't excluded as well |
| [13:58:55] | <mstenta[m]> | Oh yea |
