Closed (fixed)
Project:
Features
Version:
6.x-1.x-dev
Component:
Documentation
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
6 Dec 2009 at 18:46 UTC
Updated:
22 Feb 2010 at 14:40 UTC
For example I want to export some views with custom themeing. It's clear enough with *.css. How about *.tpl.php?
If features are modules, should I use 'hook_theme' as usual?
Comments
Comment #1
flickerfly commentedI'm also curious about this. I don't want the feature to require a theme, but it would be nice to provide a solid starting point that a theme could override. Are we talking a custom module here?
Comment #2
yhahn commentedjames of sprocket (username q0rban) has a good answer to how you can do this here:
http://sprocketcreative.com/blog/2010/01/20/creating-extending-features-...
Comment #3
tema commentedThanks a lot, yhahn!
Nice :)
And still nothing about *.tpl.php :(
Comment #4
flickerfly commentedThanks yhahn. That hits on the right neighborhood and interesting information to be sure. I see how the tpl.php information is sort of answered in the comments by using hook_theme_registry_alter(), but I assume that also wouldn't be packaged in the auto tarring up of the feature module.
It sounds like the general advice would be that if we are building a feature for general release, it should not include any themeing components so as not to create technical debt in resolving that. It seems to me that this is a major disadvantage of a feature over a typical module.
Am I gathering everything together as intended?
Comment #5
yhahn commentedThat is a good summary of the situation. That said, we regularly build features with additional files and components and use the drush integration to update our features (which you should be using anyway). This is a reasonable workaround to the issue that the UI-based currently export cannot tar up additional files.
Comment #6
flickerfly commentedOh, the drush integrating will bundle that stuff unlike the web UI? That's good to know as I am using that.