Hi!
I've jumped on the panopoly bandwagon and am using it as the foundation for my own collection of features. As a multilingual front-end'er, I like to change things like the format of DATES --but I usually don't have those tied to any features configurations. I believe they should be autonomous features, a configuration that is independent of the tools am building --even if am developing events, calendars or any other time interfaces.
So am left here, scratching my heads as to why do things like DATE have to default configurations for Panopoly. What exactly does Panopoly do with dating that is so critical to it (I've used the distro, but haven't hit whatever this date-sensitive feature might be).
Either way: Love the distro.
EDIT:
Forgot to add: What would be the best practice for overriding this default configuration. I'd like to know if am breaking something by overriding it.
Comments
Comment #1
populist commentedAwesome to hear you are rocking the Panopoly. In terms of the date support:
Panopoly Core provides a couple *new* date options so that you can have date selectors to show either the "day" (November 1st, 2013) or the "time" (2:42pm). This is done because default Drupal only lets us have a full date view (November 1st, 2013 2:42pm) and that isn't really helpful for lots of things. It also tries to set cleaner versions of the dates since the default ones are a little complex (at least to me).
Luckily, these options are only set as "default config" and are not subject to features strict scrutiny (i.e. you can change it and not have your feature overridden). The easiest way to override this is to just have another module set those values (i.e. variable_set('date_first_day', 'WHATEVER')) after Panopoly Core has been installed. You might also want to check out http://drupal.org/project/features_override for overriding features in general, but that might be overkill here.
Comment #2.0
(not verified) commentedadded question