Identifying modules that are not supported? [#2234207]

Am I correct that the are modules that are not supported configuration, since there is a list of modules that are supported?

If so, is there a way to identify modules that are being used but are not supported?

And, if this is correct and a module could store settings that are not handled by configuration how should one handle this? Is there a safe way to use configuration in the meantime?

Sorry if I've completely misunderstood and there is nothing to worry about...

Comments

Comment #1

GDrupal CreditAttribution: GDrupal commented 5 April 2014 at 18:07

Configuration Management is more close to an API than a module per se. If we are supporting a configuration so must be a handler class dealing with that. If you want to check for sure all the handlers that are currently supported in your system you can run configuration_configuration_handlers() and check the result.
Other contributed modules can create new handlers to deal with specific configurations as explained in https://drupal.org/node/1861082, you could even disable the support for a configuration unsetting its handler as explained in https://drupal.org/node/2218235.
The only perhaps confusing situation here could be the CtoolsConfiguration handlers that provides support for any modules making their data exportable using CTools. So if module is implementing this will be probably be supported, and I say probably because i depends in its implementation some times a few extra tweaks could be needed (check PageManagerHandlerConfigurations handler for example).

Comment #2

GDrupal CreditAttribution: GDrupal commented 5 April 2014 at 18:09

Status:

Active

» Fixed

Comment #3

jsibley CreditAttribution: jsibley commented 5 April 2014 at 19:25

Is it correct then that the way to see if any module settings aren't supported is by manually comparing what is supported to ewhat is enabled? Could this be automated?

Also, is the best way to see if it is safe to push changes from dev to test to try it and see if anything breaks or is there a better way?

Thanks for a module with great potential. I am using Pantheon and this could be a great tool for individual developers pushing from dev to test to live.

Comment #4

GDrupal CreditAttribution: GDrupal commented 5 April 2014 at 19:53

It's not plausible to know what you can't know... as the drupal community provides thousand of contributed modules and new ones are created every day. Make not sense to keep a list of what you are not supporting... but what you "are" indeed.
About the different approaches to deal with configuration between different environments you can read this https://drupal.org/node/1872288.
Beyond that if you just want replicate your environment... you can use https://drupal.org/project/backup_migrate . The idea of using configurations is that you are in control on what you are moving piece by piece with its dependencies etc.
For example you could make some configuration tweak in you dev export that as a tar... import it in your test.. see if it works.. if not, write your current data store (with the working configuration) back to active store.