2

Many modules does not support Features, so I need Strongarm module to export config in the code. But in situation where i have many contrib modules, it seems tedious work. not all variables are named after module.

More important, how can I know which variables are used for settings, as I noticed some vars are not used for settings but may be user/module specific, and I need to aviod them.

I want to Strongarm only variables that have to do something with the config.

Is it done by researching modules one by one ? What are your experiences (It would be nice if I could filter variables that are used only in config :) )

1 Answer 1

3

Unfortunately, the Drupal variables table doesn't provide any distinction between variables used for configuration (e.g., whether anonymous pages should be cached) and variables used to store transient values (e.g., date cron was last run, which tabs are currently active in the UI), so there's no automatic way to do this. (Fortunately, it looks like Drupal 8's configuration management system will handle this better.)

I typically export and update Features modules from the command line using Drush. I've been using the following Unix shell script to list Features Components which haven't yet been exported to any feature — the script filters out Features Components I know I don't want in my Features modules:

drush fc % --not-exported \
    | grep -v '^ dependencies:' \
    | grep -v '^ user_permission:access devel information' \
    | grep -v '^ user_permission:execute php code' \
    | grep -v '^ user_permission:switch users' \
    | grep -v '^ uuid_node:' \
    | grep -v '^ variable:additional_settings__active_tab_' \
    | grep -v '^ variable:cron_key' \
    | grep -v '^ variable:cron_last' \
    | grep -v '^ variable:ctools_last_cron' \
    | grep -v '^ variable:date_api_version' \
    | grep -v '^ variable:dev_mem' \
    | grep -v '^ variable:dev_timer' \
    | grep -v '^ variable:devel_api_url' \
    | grep -v '^ variable:devel_error_handlers' \
    | grep -v '^ variable:devel_execution' \
    | grep -v '^ variable:devel_krumo_skin' \
    | grep -v '^ variable:devel_page_alter' \
    | grep -v '^ variable:devel_query_display' \
    | grep -v '^ variable:devel_query_sort' \
    | grep -v '^ variable:devel_raw_names' \
    | grep -v '^ variable:devel_rebuild_theme_registry' \
    | grep -v '^ variable:devel_redirect_page' \
    | grep -v '^ variable:devel_use_uncompressed_jquery' \
    | grep -v '^ variable:devel_xhprof_directory' \
    | grep -v '^ variable:devel_xhprof_enabled' \
    | grep -v '^ variable:devel_xhprof_url' \
    | grep -v '^ variable:drupal_css_cache_files' \
    | grep -v '^ variable:drupal_http_request_fails' \
    | grep -v '^ variable:drupal_js_cache_files' \
    | grep -v '^ variable:drupal_private_key' \
    | grep -v '^ variable:entityreference:base-tables' \
    | grep -v '^ variable:features_codecache' \
    | grep -v '^ variable:features_ignored_orphans' \
    | grep -v '^ variable:features_semaphore' \
    | grep -v '^ variable:install_profile' \
    | grep -v '^ variable:install_task' \
    | grep -v '^ variable:install_time' \
    | grep -v '^ variable:mimemail_key' \
    | grep -v '^ variable:prod_check_module_list_lastrun' \
    | grep -v '^ variable:simplenews_last_cron' \
    | grep -v '^ variable:simplenews_last_sent' \
    | grep -v '^ variable:simplenews_private_key' \
    | grep -v '^ variable:simplenews_source_cache' \
    | grep -v '^ variable:update_last_check' \
    | grep -v '^ variable:xmlsitemap_generated_last' \
    | grep -v '^ variable:xmlsitemap_rebuild_needed' \
    | grep -v '^ variable:xmlsitemap_regenerate_needed'
5
  • 1
    There is some effort to do this better way also for Drupal7: drupal.org/project/configuration . It looks promising. As for your answer, you suggest that I must manually discover what variables are transient and exclude them this way ? This could be tedious with many contributed modules installed, but probably unavoidable :( . Thanks!
    – NenadP
    Feb 28, 2013 at 15:22
  • Yeah, I haven't found a better way than to manually examine each variable individually, then add it to my blacklist.
    – smokris
    Feb 28, 2013 at 15:29
  • Oh my. I think then it is best approach, when I need to change config of unsupported contrib modules on dev, to research which vars are right, and add them to feature. Doing all this for +50 contrib modules would take me days, and probably most of them wont be changed (in settings)
    – NenadP
    Feb 28, 2013 at 15:39
  • 1
    There has been some effort to simplify this, but I do not see it is maintainted/developed recently drupal.org/project/selector
    – NenadP
    Feb 28, 2013 at 21:01
  • drupal.org/node/2400531 gives a list of features components that should never be exported, and mentions the Features Banish module as a way to prevent accidentally exporting them.
    – user5072
    Jan 14, 2016 at 2:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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