Duplicate effort?

Thanks for the note. I haven't used Strongarm yet, but my understanding from a webcast on it is that it's meant to enforce the same values across sites. In this case, I needed different values (nids) across sites.
The Devel editor is good, but lists thousands of variables; I wanted a UI to list a handful of custom variables for administrative use. So you could give editors access to this UI where you wouldn't want them using the whole Devel UI.
There's also PURL, which I haven't taken the time to figure out what it's for, but it says it's only an API.

FYI, Reptag provides site-wide variables/tokens, along with replacement of those tokens within most content areas. Reptag has a bit of history, and predates the Drupal 'token' system.

I haven't looked at how this works but from its description it provides the useful and distinct functionality that I had to build for myself for my own site.

The way I do it is not suitable for a generic publicly available module but works fine and quite efficiently for my purposes. However, had this module existed I would have used it rather than doing something myself. (Of the above mentioned modules only Reptag comes anywhere near to providing what I wanted and had there been a v6 version I'd have fitted in with its way of doing things).

So although I'm not currently in the market for this module I think it has a place and I would most likely use it if I had to do the same thing again in a more robust fashion for a client. (Depending on all the usual caveats, of course.)

That's good to hear, and thanks for introducing me to RepTag. Any idea when a stable D6 version for that will be released?

features (export/import) + strongarm (override variables) + variable_changes (compare variables in export to db) + diff (provide diff functionality for all these modules and content too) probably covers the scope of this module

regarding node IDs, UUID Features and UUID

LPCA, I don't use this module anymore, so I have no stake either way, but which of those modules lets you set variables in a UI? They're all code-based as far as I'm aware.

none actually.

but you can add them manually to the exports generated by features.
in the .info file, you add the variable name.
features[variable][] = "my_var"
in the .strongarm.inc file, you add the data.

  $strongarm = new stdClass;
  $strongarm->disabled = FALSE; /* Edit this to true to make a default strongarm disabled initially */
  $strongarm->api_version = 1;
  $strongarm->name = 'my_var';
  $strongarm->value = 'something here or TRUE or FALSE etc';
  $export['my_var'] = $strongarm;

note, you won't need to do this for nodes if you use UUID Features.
it is only needed for custom code, like PHP code with a variable_get call in PHP content for nodes, blocks or ctools content panes.

perhaps it would be a good idea to submit patches for adding new variables into Strongarm.

@LCPA - the Features UI does actually provide that for you when creating or updating a feature. Strongarm presents a list of checkboxes allowing you to choose which variables to serialize. You are not required to do it by hand.

Look at the screenshot, that's not what this module does: http://drupal.org/node/755466

Anyway, this was built for a very particular use case that I had once and never again, so I don't expect a lot of people to use it.

i've tested the constants module before.

AFAIK, features, ctools, strongarm, etc, do not let you create new variables, like constants does.
but exporting and importing and overriding/providing defaults they do.

UUID Features let's you export/import nodes as it makes use of UUIDs for things that don't have machine names like the nodes or the taxonomy.

the thing missing, from what i can see, that none of these modules can do, is create new variables from within the GUI. but you can still add variables directly to the DB or to code in exported features.

my suggestion is to try push a patch to strongarm to allow creating variables.
then IMO it would be safe to deprecate the module and suggest an alternative path: features + strongarm; optionally with variable_changes and diff for comparison, and uuid_features for node/taxonomy exporting. ctools and uuid are also required.

> my suggestion is to try push a patch to strongarm to allow creating variables.
Agreed, a variable editor (devel.module has it) seems like a best fit for strongarm, which is a bit underpowered without it

posted. #1231824: create variable