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 :) )

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'
  • 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 '13 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 '13 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 '13 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 '13 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 '16 at 2:55

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.