Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Good idea, will post something tomorrow. For short, one of the differences is that you don't need to install loads of helper modules that are only a burden on performance for visitors.
Just thought I'd poke my head in here, as it's a topic that I'm pretty interested in these days. Features in particular requires a pretty short list of dependencies. Features Module itself, CTools, and Strongarm are the only ones that I'm aware of; Ctools will already be there if you're using Panels or any number of other CTools dependent modules.
I'm sympathetic on the dependency chain issue, but for better or worse you'll end up reinventing an awful lot of wheels if you decide to solve the deploy-chain problem independent of CTools and Features as they currently stand. I hope that you'll at least collaborate with the Features team to ensure that the work of making key Drupal components 'deployable' is done in a way that benefits both projects.
Also, a point of clarification: the modules in question are not a performance sink for the sites they're enabled on. That makes no sense, as the hooks that Features and similar modules expose aren't triggered on normal page loads. They're administrative tools and helper functions for other modules; if your sites are slow it's because of what you've built, not the dependencies needed to deploy them.
I agree with @eaton, the dependency chain for features doesn't mean it is a bad module. Try installing the php5-gd package on any Linux distro and it pulls in a lot of stuff, but it is worth it.
I'd be interested in knowing what advantages this module has over the feature module.
I am quite interested to hear more. Features is great but I have not found it to be a great tool for deployment after a site has launched (ie subsequent revisions of a site). To me features shines in encapsulating similar functionality across multiple sites.
A more deployment focused tool is most welcome in my book.
This looks like maybe it has stalled... seems like all this can be handled fine with Features already so I'm also curious what advantage (beyond installing 1 or 2 "extra" modules) is...
@teezee/#2: apart from what is possibly updated on the project page meanwhile, is there another/more detailed comparison in the pipeline?
And is the main focus this year going to be on D6 branch or D7?
Comments
Comment #1
jerry commentedSubscribing.
Comment #2
teezee commentedGood idea, will post something tomorrow. For short, one of the differences is that you don't need to install loads of helper modules that are only a burden on performance for visitors.
Comment #3
eaton commentedJust thought I'd poke my head in here, as it's a topic that I'm pretty interested in these days. Features in particular requires a pretty short list of dependencies. Features Module itself, CTools, and Strongarm are the only ones that I'm aware of; Ctools will already be there if you're using Panels or any number of other CTools dependent modules.
I'm sympathetic on the dependency chain issue, but for better or worse you'll end up reinventing an awful lot of wheels if you decide to solve the deploy-chain problem independent of CTools and Features as they currently stand. I hope that you'll at least collaborate with the Features team to ensure that the work of making key Drupal components 'deployable' is done in a way that benefits both projects.
Also, a point of clarification: the modules in question are not a performance sink for the sites they're enabled on. That makes no sense, as the hooks that Features and similar modules expose aren't triggered on normal page loads. They're administrative tools and helper functions for other modules; if your sites are slow it's because of what you've built, not the dependencies needed to deploy them.
Comment #4
skwashd commentedI agree with @eaton, the dependency chain for features doesn't mean it is a bad module. Try installing the php5-gd package on any Linux distro and it pulls in a lot of stuff, but it is worth it.
I'd be interested in knowing what advantages this module has over the feature module.
Comment #5
danny englanderThis looks like a great module, subscribing.
Comment #6
ygerasimov commentedSubscribing.
Comment #7
daniel wentsch commentedSubscribing, sounds promising.
Comment #8
ghankstef commentedI am quite interested to hear more. Features is great but I have not found it to be a great tool for deployment after a site has launched (ie subsequent revisions of a site). To me features shines in encapsulating similar functionality across multiple sites.
A more deployment focused tool is most welcome in my book.
Comment #9
joelstein commentedInterested to see where this goes.
Comment #10
rcross commented+1
Comment #11
bwinett commented+1
Comment #12
TheDoctor commented+1
Comment #13
R-H commentedsubscribing
Comment #14
izmeez commentedsubscribing. This looks interesting.
Comment #15
scothiam commentedsubscribing... using this module to capture all settings, while using Features to gather all else, including dependencies, could be a winning solution
Comment #16
kristen polThis looks like maybe it has stalled... seems like all this can be handled fine with Features already so I'm also curious what advantage (beyond installing 1 or 2 "extra" modules) is...
Kristen
Comment #17
Leeteq commented@teezee/#2: apart from what is possibly updated on the project page meanwhile, is there another/more detailed comparison in the pipeline?
And is the main focus this year going to be on D6 branch or D7?