Building a non-config, programmatically-created, semi-dynamic, semi-manual menu

Question

We have a custom entity called "Topic". With this entity, users can build topics and reference other content to "belong" to the topic. We also have a requirement where, whenever a user creates a topic, a menu is also created for it. When content is added to the topic, a link is automatically added to the menu pointing to that content.

The workflow is like:

1. User creates a topic.
2. User references a bunch of arbitrary content to the topic.
3. User saves topic.
4. Menu associated with topic automatically adds links to added content.
5. (optional) User adds more links to menu, not necessarily for topic content.

Now this menu currently couldn't be a custom-built block, as we also have a requirement where users should be able to to add menu links like a regular menu. But the downside to using menus is that they're config - they need to be exported. Otherwise, a deploy without the config would wipe out all the created menus.

Is there a way to create a menu without making them config? Is there a better approach to this problem?

Answer 1

Without delving too much into the specifics of your complex configuration management, I'd venture to say that you should use Drupal 8's built-in configuration sync to export config to YAML and commit it to your version control repository (git or what-have-you) so that you can deploy your config along with your code.

Then, you can use the Config Filter, Config Split, and Config Ignore contrib modules to split off certain configuration from the sync directory into separate directories that can be used or ignored in different environments.

NOTE: If your users are all adding content in the production environment, you'll need to make sure your lower environments always have the latest config before deploying to a higher environment. This would be the case even if you didn't use config sync; it will just be a different workflow (i.e., you'll need to drush cex the latest config from Prod and drush cim it into your Dev environment, rather than grabbing a fresh sqldump from Prod.)

More info: https://www.o8.agency/blog/tips-dev-team-using-config-split-and-config-ignore-fine-tune-your-configuration-management

There's work underway to integrate some of the functionality provided by Config Filter and Config Split into Drupal 8 core. This is the way things are headed, so there's really no downside to config export anymore if you do it correctly.

Admittedly, setting it up can be a pain, but it's a different pain (and, I think, a less painful pain) than keeping all your config in the database and trying to keep that in sync across your local, dev, stage, and prod environments.