Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
brenk28 CreditAttribution: brenk28 commentedThe 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.
Comment #2
hefox CreditAttribution: hefox commentedThere's only so much strongarm can do
#1279928: Features Extra support for date_formats