The Kit features spec is a big step towards enabling interoperability of features, but there's still a need to be able to adjust features to a local install. Regions are a case in point: contexts used for block placement in a feature need to specify a region, but that region may not be available in a given site's theme.
The attached module is a first cut at addressing this need. It provides a configuration form at admin/build/features/customize, with a sub menu item there for each enabled theme. For each region specified in a feature context but not available in the given theme, an admin can select a region to be used.
hook_context_load_alter() is used to switch out the unavailable regions for ones mapped for the current theme. I first tried the new hook_context_default_contexts_alter() but it doesn't enable altering at run time.
Context regions probably are only a first example of what could be customized--hence the name Features customize.
This could be a separate contrib module, but maybe it fits as part of the Features core?
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | features_customize.tar_.gz | 1.92 KB | nedjo |
| #1 | features_customize.tar_.gz | 1.95 KB | nedjo |
| features_customize.tar_.gz | 1.97 KB | nedjo |
Comments
Comment #1
nedjoMinor fixes: remove some obsolete code, only show theme-specific configuration if more than one theme enabled.
Comment #2
nedjoTagging.
Comment #3
nadavoid commentedI think that this needs a much more generalized approach, because there are so many scenarios where local customizations need to happen.
- adding fields to content types
- changing filters or fields in a view
- adding a display to a view
- changing the layout or content of a panel
- changing what region a block displays in
What I would like to see in these cases is pretty simple from a usability perspective, but I'm not sure what needs to happen within the Features module to get there. That is: if I override a feature (say, add a field to a content type), and that feature gets updated (say, a different field got added, and an existing field's display setting got changed), the new field and the changed field get in, and my custom added field stays in.
In other words, only the granular items that were overridden should remain overridden, while items that were not customized can receive the updates from the updated Feature.
It looks like #693024: Add alter hooks for the "faux" exportables enables custom additions to a Features module, as discussed at http://treehouseagency.com/blog/roger-lopez/2010/08/19/building-reusable...
The only downside of this approach is that it requires the Feature builder to anticipate how someone might want to alter what is defined in the feature. If the site admin wants to add a field to a content type that is defined by a feature, it would be great if they could, without the developer having to add in custom code to a Features module.
What would be the next logical steps forward on this front?
Comment #4
nedjo@nadavoid: agreed that what I've sketched in here is only part of the picture. The aim in this issue is to enable mapping of specific data in enabled features to local equivalents. Maybe features_map would be a better name than features_customize.
For the broader feature customization you're looking for, see #876226: Export changes to feature components and http://drupal.org/project/features_override.
Besides theme regions, probably the most needed item would be user roles. E.g., a feature supplies permissions for role 'editor' but a local site (or a distribution) has instead an equivalent role, 'content editor'. We should allow mapping of the feature's roles to those on the site (or defined by e.g. a distro feature).
Comment #5
barrapontoI believe there are different use cases here, needing different approaches. Mapping Roles, Input Filters and Vocabularies are being solved through new exportables and machine-names. I believe some new approaches can work on top of that (merging roles or mapping objects).
However, the region mapping is a issue we can work with a different focus. The pressing issue is that Kit compliance requires declaring left and right regions in the theme, while some themes (mainly, ZEN) declares the regions as sidebar-first and sidebar-second ( see http://drupal.org/node/254940#sidebars-renamed ). This is true for D7 themes as well.
I believe we can solve this with a default _alter declaration for context or boxes. Also, we could write a wrapper function to make region mapping easier, should the feature require it. Installation Profiles would surely benefit from this approach.
Of course these alter functions should only run if the regular left/right regions aren't available.
Comment #6
nedjo@barraponto:
Thanks for the comments.
Yes, a solution needs to work in features and distros, but it should also be configurable on individual sites. Use case: user downloads kit-compliant feature, enables, but site's theme doesn't have left or right region. Need ability to configure and select replacements.
Comment #7
nedjoDraft module is causing problems on a site of mine--disabling regions in non-features contexts.
Comment #8
nedjoFixed error.
Comment #9
barrapontomaybe we would be better off writing the region mapping in the theme .info. it would make changing themes easier. therefore features' region mapping should support this, and we should add mapping to the Kit proposal (which would finally allow us to have first-sidebar in the Kit proposal, while mapping it to legacy themes that declare left/right regions).
Comment #10
nedjoCreated a sandbox for the draft module: http://drupal.org/sandbox/nedjo/1118098.
Comment #11
alberto56 commentedsubscribing
Comment #12
socialnicheguru commentedJust tried it. Pretty good.
I made some suggestions/feature requests but It also illustrates some short comings in my own theme and modifications. Always learning!
Comment #13
mpotter commentedSandbox listed above. Not a core Features issue.