1

I am working on a Drupal 8 module that has a fairly large number of configs (a few content types and fields, with 20-25 config files per content type), and one thought I had for organization was to put the configs for each CT into a subfolder under config/install. However, I see that the configs are not read in this case.

Which is the better way to proceed?

1) Just place everything in config/install, with 100-150 config files.

2) Create sub-modules for each content type, which would require a bit more overhead but could be done given the module's use case.

3) Is there a way to add subdirectories in config/install?

For some background, I wrote a Python daemon that does server monitoring, and the module handles communication between the monitors and a central reporting server. Each content type corresponds to a plugin for the monitor, so someone could turn on only the plugins that they want. However, in the current iteration I would prefer to have a core set of content types that are managed by one module.

4

No, you can't put config in sub-folders, those are reserved for config collections (e.g. language overrides/translations).

The only option would be submodules as you already said, and it's up to you to decide if that's something that makes sense for you.

For some background, I wrote a Python daemon that does server monitoring, and the module handles communication between the monitors and a central reporting server. Each content type corresponds to a plugin for the monitor, so someone could turn on only the plugins that they want.

Not sure I fully understand that and it's not exactly the same but our project https://www.drupal.org/project/monitoring might still be interesting? it uses plugins and a single config entity for a sensor, it is about monitoring things about a single drupal site and not other servers (We do then use sensu to collect the data and alerting).

And without having the full picture, using content types/content for something that doesn't really sound like content seems like a strange idea. In Drupal 8, it's pretty easy to create your own entity type with support for bundles, then you could make all the shared fields base fields and would probably get rid of 90% of your configuration.

  • The Python Daemon/script I am using is meant to be software-independent, and the Drupal component is mainly a project to manage settings for a variety of customers and software packages (i.e. web, DB, and load balancing servers). – Mike Nolan May 14 '18 at 21:42
  • For your module, I think it is interesting and perhaps I can work with you on integrating ZSM when my project is a bit more mature. That said, this module is also planning to integrate with D8 Groups, and with a second Python library that does web crawling. The use case is to do testing with the monitor watching servers while the crawler is testing in a Selenium browser. – Mike Nolan May 14 '18 at 22:00
  • Yeah, as I said, not an exact match. Still think that your use of node/node types is strange and you could possibly simplify it a lot if you use your own entity type. (As well as simplify the database structure and improving performance if you don't need revision and/or translations) – Berdir May 15 '18 at 7:12
  • I started with nodes for my alpha version because it is easier to set up initially, and I'm learning the entity API. I've used ECK in 7, and tried it a few months ago in 8, but now that I'm getting more comfortable with writing controllers, etc. I might try it again. – Mike Nolan May 15 '18 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.