Use of global $theme_name and $theme_key causing unpredictable results in responsive_page_layouts_data_structure

Currently, when you install commons 3.x you get this:

WD php: Warning: Invalid argument supplied for foreach() in          [warning]
responsive_page_layouts_data_structure() (line 192 of
/home/u6195/domains/u6195.moko.vps-private.net/profiles/commons/themes/contrib/adaptivetheme/at_core/inc/plugins.inc).

I spent awhile tracking it down.

Commons does this to automate saving the theme settings form:

(from commons.install)

<?php
foreach (array('adaptivetheme', 'commons_origins') as $theme_name) {
    $form_state = form_state_defaults();
    $form_state['build_info']['args'][0] = $theme_name;
    $form_state['values'] = array();
    drupal_form_submit('system_theme_settings', $form_state);
  }
?>

This is anyway a little hacky, but there isn't any other way to automate it.

This issue is that at_core_submit_reponsive() takes $theme_name as an argument, but it calls at_build_page_layout() several times without passing in $theme_name. at_build_page_layout() doesn't take $theme_name, it uses a global $theme_key or $theme_name, as does responsive_page_layouts_data_structure() which it calls (where the error happens, because it is using "seven", not the passed in theme.

This patch adds $theme_name arguments to both those functions, allowing them to use the global var if it is not provided.

I don't think this is an ideal solution, but it's better than what it is there now which is sorta lying to the implementor who believes they can actually pass in a theme and have it used.

I recommend committing this as a stop gap, but following up by removing global variables from any supporting functions. If we are going to use a global var it should only be in the a submit handler or callback IMO so it is easily traceable and the API remains flexible.

Thanks!
J