features

Si hay alguien por acá interesado (u obligado) en mejorar su fujo de desarrollo (developer workflow), lo invito a leer el articulo que escribí: Flujos de desarrollo en Drupal: Para ganar, primero hay que invertir

Se aceptan comentarios, criticas, consultas, etc.

Buenos humos a todos los drupaleros!

Discussion around using Panopoly features as dependencies within a child distribution, where per-site feature development and customisation is required.

Hi guys!
I wanted to share something I published today: http://drupalignite.com.
Basically it's a tool and a set of practices to setup a Drupal environment under a full Continuous Integration cycle using some well-known tools as drush, phing, composer and jenkins for the build phase, phpunit and behat for the testing and features and migrate for keeping everything (structure and data) in a code driven development shape.
I published the introduction, the following chapters will be published in the next months!
You can find the code on github: https://github.com/omissis/drupal-ignite

I always have a fuzz about exporting the Views as well as it's translations for STAGE and even PRODUCTION deployment. Although I have tried quite a few ways (e.g. export variable_realms, strongarm, translation.po, etc. etc.) I still ended up having to create multiple instances of the view with a different set of translation. Is there a proper way of handling translation deployment, particularly using Features?

P.S. I notice there is a features_translations module. Has anyone tried that module?

If I build a site with a feature module that includes permissions and then add a new role to my site, I'll need to recreate that feature to include the updated permissions for my new role? At that point, I've basically forked the original feature module for my own site.

Is it normal to have a feature module, such as a wysiwyg or blog, that is unique for each site? Are most feature modules that are available on d.o. (for example, the Debut modules) just a starting point to create a site-specific version for every site?

Good turnout for the January meetup. Thought I'd share some links from this presentation:

drupal.org/project/features
drupal.org/project/features_extra
drupal.org/project/strongarm
developmentseed.org/blog/2009/dec/04/strongarm-2-leaner-and-meaner/
drupalize.me/videos/exporting-settings-variables-strongarm

Look forward to the February meetup. What was decided for a topic?

I was doing some research on Drupal Apps for our institution wide Drupal distribution and was wondering if:

a) Does an App server exist specifically for Higher Ed institution's use cases?

b) If not, would there be interest if one existed?

What kind of standards is needed to make features as compatible as possible:
- module based
- naming conventions
- ???

The usual suspects:
- Strongarm
- Roles
- Permissions
- Text Format
- Content Types
- Taxonomy

Related content
Roles Conflicts comparison :Harmonize app/distro/feature role names
Distro Based Conflict Comparison:Commons 7.x
Related Discussion: Should distro based features be compatible with other distro features?

Buenas estoy probando features de drupal 7
Pero me crea los tipos de contenido y las views correctamente pero no sus nodos que lleva consigo su tipo de contenido ni el nombre de los bloques que son quien lleva toda o parte de la informacion.
Es normal o algo estoy haciendo mal
Gracias por adelantado

I've had an idea for a way of joining up Features and Migrate in order to export entities that are data rather than config. I'd be interested in what people think...

The background is that lately I'm working on a project where we have several taxonomy vocabularies that are more part of the site structure than really content, so I used the Taxonomy CSV module to export them to CSV files and wrote a quick custom module with a UI to import them back in, so our various developers could use them to get test sites up to speed.