8

At work we are moving to getting our new sites set up in git and doing local development. So far I've created a drush make file along with an installation profile, and I have this scripted via puppet so that when a user does a fresh clone of a repository it will download all of the packages and run a basic site install. This works OK.

Now, my question is for when I need to use a new module for a site. For example, we build a new module for the site. I want the other developers to pull from git and have the new module automatically installed. Adding it to the drush make file will only cause it to be downloaded, and running 'drush si' will cause the site to be reinstalled, wiping out all of the data.

What's the best way to accomplish this?

Edit

I feel I haven't explain this properly. I'm looking for a way to automatically enable modules based on the makefile entries in drush. The idea is the user checks out a project, and then I'll have puppet run 'drush make' and 'drush si' if no settings.php file exists. What I need to figure out is for when the next time the user does a pull and we've added a new module, how to have that automatically enabled through some script. If I need to I'll write something to parse the makefile and run 'drush en' manually, but I'd like to find something that is pre-built to do this.

Improve this question
5
  • "drush en" isn't what you want perchance?
    – Sam Becker
    Jun 5, 2013 at 3:44
  • I need a way to automate it. 'drush en' can be run from the CLI, but what I want is a way to to determine what modules are new and automatically enable them.
    – dragonmantank
    Jun 5, 2013 at 13:43
  • 1
    The problem is going to be that having a module present as a set of files doesn't mean you want it enabled. Someone has to make that decision. For example if you download Views you also get Views UI. Do you want that enabled or not? It's a conscious decision. So you need a list of the modules and it might as well be in a script.
    – Alfred Armstrong
    Jun 5, 2013 at 13:56
  • Sorry, forget that. I sort of get what you mean though I am not sure of the point of it all being done through make.
    – Alfred Armstrong
    Jun 5, 2013 at 13:57
  • 1
    @AlfredArmstrong the idea was that since I already have to curate the make file, to just use that in some way. If I want 'devel' enabled, but not 'devel_generate', then only 'devel' would in in the make file. If I decided later to have 'devel_generate' enabled, I'd add that to the make file. I don't want to do it just based on what files are available specifically for the reason you mentioned, so I need to control that in some way.
    – dragonmantank
    Jun 5, 2013 at 14:05

9 Answers 9

Reset to default
4

I worked for a company that had a large dev/stage/prod flow that tried to automate as much as possible. Everything had to be done in code, scripted either using features or update hooks.

Basically, what you wanting is to have 1 custom module that exists to contain update hooks. This way, when a developer pulls an update to the code base, they run the db update, and that can perform whatever module enable/disables need to happen. The update hooks do not affect a new installation, because it is assumed that the module is already up to date when it is installed, and will only execute newer updates.

To summarize:

  1. Continue using your installation profile to perform the necessary installation tasks (enabling modules, etc.).
  2. Use a custom "update" module which uses hook_update_NXXX() to enable/disable new modules and otherwise keep your site's administrative tasks in sync.

Here is a post that talks about a similar approach and gives code examples.

Improve this answer
1

This is a great question. drush make is convenient for downloading modules. We don't want to contribute to module bloat. Over here the case is made not to extend make in this way. Perhaps Features is best for managing the site's module enabled state, as well as other configuration aspects.

Improve this answer
1

Consider modifying your workflow.

It sounds like you want to do distributed work and "share" enabling modules and other configuration values ... somehow.

If you think about it -- even Drupal "core" and Drupal.org don't do this. Code is submitted to Core and community modules which run in a Continuous Build Process. Drupal.org and many projects use Jenkins.

For an installation of Jenkins geared towards Drupal development, it also uses Phing, see this git repo: http://reload.github.io/jenkins-drupal-template/

Using Jenkins, you can push code to your master Git repo and have the site built for a demo site from your Installation Profile and Drush Makefile(s). This doesn't solve your problem exactly but does provide 1 location you all push change(s) to add/enable/delete modules and hopefully you all don't "break the build".

Assuming the build isn't broken -- it's safe to pull its changes into your local development system.

Jenkins + a Staging or Development server is only 1 piece of development.

Your local workflow can use installation profiles + makefiles. Consider sharing content using custom modules with Migrate if you can afford the content generation time. Examples of sharing content with developers using Migrate, and Phing usage can be read up on here:

http://marzeelabs.org/blog/2014/03/17/coding-as-a-team-content-fixtures/ http://marzeelabs.org/blog/2014/03/03/coding-as-a-team-automation-using-phing/

Lastly see this PDF on a session from Drupal Camp Ohio 2014 on continuous integration and working with your team:

Improve this answer
1

For the same purpose we are using Master. It uses the settings.php to provide information about what the master modules are. With a simple command drush master-execute all modules (and their dependencies) that are missing are enabled and modules that are not used anymore are disabled.

Currently the module does not read information from the makefile, but maybe that could be an option for a new release.

Improve this answer
0

You could enable the modules either manually by going through Modules option or by terminal using drush command 

drush en -y modulename1 modulename2

and so on.

Improve this answer
1
  • I'm looking for a way to automate this based on makefiles, not just how to enable a module manually.
    – dragonmantank
    Jun 5, 2013 at 13:47
0

Modules can be enabled in 2 ways:

  1. either from terminal using drush command by:
    A. drush dl modulename - for downloading the module firstly
    B. drush en -y modulename - for enabling the module

  2. By using the Module menu option and then enabling module from the number of modules being displayed.

Improve this answer
2
  • I'm looking for a way to automate this based on makefiles, not just how to enable a module manually.
    – dragonmantank
    Jun 5, 2013 at 13:48
  • There some more ways. module_enable() for example. Or by importing a prepared database.
    – leymannx
    Jun 24, 2015 at 12:13
0

I want to some this that be sure. The make function is used for download the different parts of the site: module, themes and project via git. When you write down your installation profile you are writing in the info file the depended modules. The problem is when you need to add new module for your installation profile for existing profile - am i correct?

For that you need to use the hook_update_N when the N stand for the number update. The hook is used for module that need to do actions such as: updating schemes, adding variables and used for sites and distirbution, such as OpenScholar, for enable new downloaded modules on live site.

You probably need to add this in the most generic module and the function will look like this https://github.com/openscholar/openscholar/blob/SCHOLAR-3.x/openscholar/modules/os/os.install#L16

The hook need to be located in the module.install file. If you using the UI you need to go to www.site.com/update.php and if you using drush just use the command drush updb.

Improve this answer
0

As I understand, Drush .make file only downloads projects from drupal.org, if you want to enable some modules, can do with an installation profile**(.install)**. An installation profile gives you options, what modules you want to enable at the time of installation.

Recently I have also contributed one distribution with the help of .make file. Even I shared the whole experience of .make here. I know this is not related to what exactly you are asking but it can help you understand what exactly .make file does.

So from this whole task, what I understand, using .make file you can not automate module enabling. To do this you need to follow some other approach.

I hope this forum URL can help you. Drupal automation with Bash scripting and Drush.

You need to write some bash script where exactly you will use Drush commands.

drush en -y modulename
Improve this answer
-1

How about using a Drush Make file in conjunction with a Drupal Installation Profile? see: https://drupal.org/node/1022020

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.