Using Strongarm with Features is difficult. You need an intimate knowledge of the machine names of variables, which makes it very difficult to find the obscure settings you need for a complete configuration export.

I want a mechanism to simplify exporting the configuration of an entire module to a single mouse click. Module maintainers have better things to do than implement an entire export mechanism that will 1. Provide little added value from their perspective to Strongarm's capabilities, and 2. Clutter up the Features UI with new categories.

The attached module code is tested as working. It creates a new hook_strongarm_package() which returns an array of variables each module declares as useful for a production feature based on that module. For example, to support this mechanism with SMTP, you would insert:

/** 
 * Implementation of hook_strongarm_package().
 */
function smtp_strongarm_package() {
  return array(
    'smtp_on', 'smtp_library', 'smtp_host', 'smtp_hostbackup', 'smtp_port', 'smtp_protocol', 'smtp_username', 'smtp_password', 'smtp_from', 'smtp_fromname',
  );
}

I will roll this code into a patch once I know which project this should go in. Especially given that I cannot use the 'strongarm' namespace without breaking this and strongarm's existing export mechanism.

If you install the module, be sure to implement hook_strongarm_package() somewhere, then check the Create Features page for "Module Settings".

Partially inspired by this pain

CommentFileSizeAuthor
strongarm_packages.tar_.gz682 bytesGrayside

Comments

jmiccolis’s picture

jmiccolis commented
Assigned: Grayside » Unassigned

Interesting idea.

Honestly I think this realm really needs a solution upstream in Drupal. We certainly wouldn't add strongarm specific code to features, and I'm nervous about adding a new concept, 'component packages', to features. (though I do find the idea intriguing) It seems to me like the underlying issue cold be solved if variables had descriptions, like most other exportables do.

Grayside’s picture

Grayside commented

Yes, as per IRC discussion with yhahn, this is really something for better UI with Variable Descriptions.

I'm still trying to think through the middle ground. There are modules like SMTP whose somewhat straightforward 11 strongarm checkboxes could easily be simplified by single-click feature generation.

Grayside’s picture

Grayside commented
Status: Needs review » Closed (won't fix)

Similar concept as #870040: Provide hook to allow modules to define what variables they own, same problem. Variables Registries are complex, and should be approached in a centralized way.

alfthecat’s picture

alfthecat commented

@grayside

Hi,

What exactly do you mean by

If you install the module, be sure to implement hook_strongarm_package() somewhere

I have installed the module but I don't really understand how and where I would implement the hook. I have no Module settings option available when creating a new feature and I am really looking for this feature :)

Thanks in advance!

Grayside’s picture

Grayside commented

This module requires you to create a custom module to implement the hook. By implementing the hook as in the example and clearing the cache, it should work unless it has become incompatible with Features.

There is no Drupal UI for the functionality beyond the new Features component for the package in the Module Settings category.

alfthecat’s picture

alfthecat commented

Thanks Grayside, that clears things up for me. Would you have such a module that implements the hook? I'd love to use this.

All the best!

Grayside’s picture

Grayside commented

The hook implementation in the first post is an example taken directly from a site's custom module. You could drop such a thing into a contrib module directly, or implement the hook once for each module you are using for which you want to bundle settings.

I take it yours is a vote to turn this into a real module? :P

alfthecat’s picture

alfthecat commented

Yeah you can count my vote in :)

As a specific example, I have created a set of five features. They result in, amongst other stuff, Panels 3.7 integration with its in place editor (provides a 'customize this page' button to edit the page from the front end.) Now there are a lot of exportable settings to figure out, for cTools and many other dependencies are required. Right now, I am missing one setting somewhere, resulting in the fact that the in place editor works, until you visit the admin page. On return to the front end the in place editor is gone and will only return after a db update.

One can imagine the extent of such a search for tiny setting. Where if I could see the settings from the dependencies in the way that the proposed module does, it would save me a serious amount of time. I think this module would help, because it are the small inconspicuous module settings that will cause the delay, even if the majority of settings are straight forward to find. A weakest link kind of reasoning. So having an extra item called 'module settings' in the create new feature page makes an enormous amount of sense to me. I am quite new to using features but after installing it, the first ting I did was look for this setting even before I read this thread.

Grayside’s picture

Grayside commented

There are some hooks newer than Strongarm Package, such as hook_features_component_alter(). This would allow you to create a module that observes what Features components are being exported, and automatically add components you think are related to it.

This is a more streamlined approach to the problem. Where Strongarm Package is still potentially useful is when you have no clear, single option that indicates other stuff to export, such as when you have a module like SMTP where you just want to capture a dozen variables.