Posted by rcross on July 19, 2012 at 12:52am
Start:
2012-07-19 18:30 - 21:30 Australia/Sydney Organizers:
Event type:
User group meeting
A little less exciting than my last post, but a short reminder about the Sydney meetup tonight. Usual time & place.
When: Thursday, July 19th
Time: 6:30pm - 9:30pm (Show up around 6:30pm for firm 7pm start)
Venue: ABC Centre 700 Harris Street, Ultimo ( Map | Directions )
Agenda:
- Greetings and Welcome new people
- Community News by Ryan Cross
- Case Study: Documentation Site by Magda Kostrzewa
- Support/Hackfest/BoF
Bring your laptops and your current projects and we can work together to get over any hurdles you have. Small groups will also be able to break out. - Continued at the pub with Drinks/food
Resources:
Twitter: http://twitter.com/DrupalSydney
Meetup: http://www.meetup.com/drupalsydney/
Slides: http://www.slideshare.net/group/sydney-drupal-users-group
Photos: http://www.flickr.com/groups/drupal-au/
Chat: #drupal-au on freenode : Connect
Comments
Modules and tool from the meetup
Great meetup last night. There were quite a few Drupal modules and other software tools mentioned in discussions, perhaps everyone can add the ones they mentioned. I know that some included:
Context Export
During the meetup I briefly mentioned strategies for overcoming Features overrides. I stated that in general it is possible to turn on a Feature, enable the config, and then turn it off. This would allow a site builder to start with a template of config which they would then be free to alter (in the database) without leading to overrides. Whilst it is true that this might work for strongarm and permissions, it won't work for context (or fields).
Boris made the observation that this stuff would be better handled as exportables in code and just avoid Features altogether. True, this would be the best approach but I must admit that the Features UI certainly is handy for marshalling the various bits and pieces.
Following up on Boris' suggestion I found the seldom used Context Export module which dumps out all contexts into a directory of your choosing. The workflow for a developer would be to export the config into a dir, put it into version control and then deploy to site. Subsequent site builders could then come and change/add the contexts without any overrides. Job done.
Context Export... Worth checking out IMO.
http://drupal.org/project/context_export
Of course you could implement your own version of hook_context_default_contexts() although this module takes some of the pain out of handling the export. Any thoughts on better approaches?
Managing Director
Morpht
Brief thoughts on Context Export
Just a quick update on Context Export. I flirted with it for a while but retreated from using it. The main reason for this is that with context, any addition to a context (in the DB) will lead to an override. So, it suffers the same issues as Features in this regard. It is an all or nothing approach. If you use Context with Features to place Blocks then you need to be prepared to use it for all of your block placements for a particular context.
The halfway house I settled on was to use context for blocks for content types where that block was crucial for the operation of the content type. eg. a "blog" content type needs an "articles" block and we can use context for this.
However, when it comes to building a distro and allowing site builders maximum flexibility with the installed site it makes much more sense to handle block placement using the standard method in the DB. It's old school but you don't have overrides headaches. You can tidy this up by moving some of the block placement logic into the install.
Moral of the story - you fall in love with Features (great for building out functionality when in a vertical). You fall out of love with Features when you need the flexibility for different sites or have horizontal concerns. It makes me question how useful they can be when used in a truely plugable way. ie. taking a Feature and dropping it into another site. The answer is of course to design features which can store their important config outside of the code in feature itself. This is more easily said than done when there is a lot of state to be wrangled. It is also counter to the way many of us use features in day to day development - as a way to capture config.
OK. That's enough from me for now :)
Managing Director
Morpht