First off thanks for all of your great work on this. It's more than helpful in many ways daily.

Next...

Reuse configuration
I know this might be the wrong place to start this conversation in....but right now this place feels best for me regarding the purpose of quickstart and my subject. I am more than willing to shift this conversation to a certain group if you want.

Like many drupal developers I want to automate my workflow as much as possible. Quickstart is saving me a lot of time by setting up a drupal website (environment) with one simple command quickly.

Versioning
Thing is, we all have our (custom) needs for our specific "basic" installation of a drupal installation. Include certain modules you use all of the time (views, ckeditor etc) and more important, configurate those modules to meet certain needs (needs that are reoccuring and thus are suitable for DRY)

I am curious about how you guys are handling this. I'm aware of drush make and profiles but uncertain how to implement them correctly and not sure they will fullfill all of my needs.

Because, let's say...

I have my custom build with Drupal Core 7.xx and some modules, all configurated and well.I have put all of this nicely in some version control system because I want to push future changes/bugfixes into my previous installations.

I created a site based on some export of that version controlled image. I discover that some things are not working as expected, I make the changes in the version control system and push those changes to my sites.

How are you guys doing these things considering you don't want to repeat yourself over and over again?

Thanks for any help in advance
Undersound

Comments

MichaelCole’s picture

MichaelCole commented
Status: Active » Closed (fixed)

Hi undersound3,

You're bringing up a pretty big and diverse topic. Drupal 8 is working on this with the configuration initiative.

For myself on simple projects, I just version control the whole thing and push it around through git. It's the simplest thing that could possibly work. If you're doing multiple sites on the same code, consider multisite.

Hope that helps!

Mike

undersound3’s picture

undersound3 commented
Status: Closed (fixed) » Active

Thanks Mike for your answer...

Just to pick one use case. I find myself configurating a wysiwyg-editor every time when starting a new project.
Setting permissions for certain fields and defining the correct input formats for them feels like something that can be predefined.

I'm curious about how you handle this.
I'm doubting between putting a base drupal installation under version control with all those "basic" settings pre configured (like you always will need an editor role etc...) or create a .make file which will take care of that.

MichaelCole’s picture

MichaelCole commented
Status: Active » Closed (won't fix)

See previous post.

Chris Charlton’s picture

Chris Charlton
Primary language English
Location Los Angeles
commented

There are add-ons to CTools, and Features module that help export those tedious repeated settings for stuff like WYSIWYG and almost anything else under the sun. A few things still aren't fully exportable like folks want like Taxonomy, so that still requires an import/export workflow. Also checkout the following Drush add-on http://drupal.org/project/drush_ctex_bonus

undersound3’s picture

undersound3 commented

thanks for your update on this and especially the drush_ctex_bonus

undersound3’s picture

undersound3 commented
Issue summary: View changes

better readability