I have a feature with strongarm that has a custom date format exported. The featurename.strongarm.inc file contains this snippet:

  $strongarm = new stdClass();
  $strongarm->disabled = FALSE; /* Edit this to true to make a default strongarm disabled initially */
  $strongarm->api_version = 1;
  $strongarm->name = 'date_format_webb_date';
  $strongarm->value = 'd F Y h:i a';
  $export['date_format_webb_date'] = $strongarm;

After installing the feature (as part of an install profile), that variable is placed in the variable table. But that's not where date formats go. They need to go in the date_formats and date_format_type tables. (The structure of which makes no sense whatsoever.) But they don't end up there, so are unusable in the site.

Comments

brenk28’s picture

brenk28 commented

The problem is that 'date_format's do get saved to the variable table, which is why they are being picked up by strongarm for export. (The custom format should work in a format_date call, since that uses variable_get.) However, the tables mentioned above have data saved to them as well. Since strongarm just handles the simple name, value variables, to handle this special case it will need to save the extra data and then call system_date_format_type_save and system_date_format_save when the feature is reverted.

hefox’s picture

hefox commented
Status: Active » Closed (works as designed)

There's only so much strongarm can do

#1279928: Features Extra support for date_formats