Family Relations among plants

Unable to install farmOS Species vocabulary, core.entity_form_display.taxonomy_term.plant_type.default, core.entity_view_display.taxonomy_term.plant_type.default already exist in active configuration

I implemented the hook_preinstall in order to delete this config before installing the module (the hook_install will create them again with the new configuration), but looks like this preinstall never runs. If I delete that configuration with drush, I can install the module and works fine.

It would not be good form to delete this configuration. If someone had customized it themselves on their instance, and then installed your module, it would wipe out their customizations.

Unfortunately, this is one of the reasons I dislike those two types of config (it’s an issue I have with Drupal core upstream - which we don’t have much control of in farmOS). They need to include information about ALL fields on an entity type. But in farmOS that’s tricky because we can never know what modules are installed, and therefore what fields need to be included in the config.

The only “proper” way to make the changes you want would be to load the config in hook_install() (and hook_uninstall()), modify it in PHP (ONLY the bits relevant to your module), and save it.

Although, come to think of it, there is another variable at play here: the farm_update module will automatically revert “overridden” config when the cache gets cleared. So what I suggested wouldn’t work either. :thinking:

You’ve picked a particularly thorny bit to work on here @c4ndel4, I’m sorry to say. But we were bound to run into it eventually I suppose.

Perhaps Enable bundle plugins for taxonomy terms [#3190851] | Drupal.org is going to be necessary, after all.

Or we hold our breath for this upstream Drupal core issue: https://www.drupal.org/project/drupal/issues/2346347

I wish I had better guidance to provide @c4ndel4 :face_with_diagonal_mouth: - it’s hard to work with the view_display and form_display config…

Although, come to think of it, there is another variable at play here: the farm_update module will automatically revert “overridden” config when the cache gets cleared. So what I suggested wouldn’t work either. :thinking:

We should probably open an issue about this, now that I think about it. The farm_plant_type module is the only place in farmOS core where we are providing core.entity_form_display.* and core.entity_view_display.* config - and this presents a real issue if anyone tries to alter those with the farm_update module installed. We might want to rethink how we’re handling the plant_type bundle specifically in that regard… otherwise it’s going to cause someone a bad time.

Yes, I’m already realizing. It’s a pity, expanding an asset, with location, files, logs, etc. is very simple, and instead expanding a taxonomy, which is just a name and description, is a hell.

I am not going to dwell on this topic any further. I understand that it is a change in the data model that we could all agree on, but we can also all agree that it is not worth it.

I’ve learned some new things, it wasn’t bad. Thanks for the help!

2 Likes

I appreciate you taking the time to give it a try either way @c4ndel4. Sorry it ended up being hard. It has my gears turning now about potential ways forward… I’ll let you know if we come up with any clever solutions. Ideally I’d love to find a way to bypass those two configs entirely.

1 Like