Drupal 7 Composer

Posted onby admin
  1. Drupal 7 Drush Composer
  2. Install Drupal 7 With Composer
  3. Drupal 7 Composer Autoload

Install new Drupal site. Create a new Drupal project from the drupal/recommended-project template. Drupal 7 has no composer.json for this to command to work. You can use one of the other 2 methods mentioned on Using you need to tell the version.

Published on Vie, 10/04/2015 - 12:02

Crosspost from the WunderRoot blog. This is an article I wrote when I worked at WunderRoot and it's the output of an evaluation on how feasible is to use Composer as an alternative to Drush make.

What is composer

Composer

Before Drupal 8.8.x, the Drupal core maintainers took the whole Drupal core project on Drupal.org and separated it into two Composer packages: drupal/drupal and drupal/core. Essentially, drupal/core was everything in the core directory, and drupal/drupal was a wrapper one.

Composer is an excellent tool to manage dependencies in PHP. It allows you to define a set of packages or libraries and it will figure out the right dependencies to install and with the right versions.
There’s a trend that grows bigger every day in the Drupalverse to try to reach out and use standard, or broader tools instead of Drupal-only tools, such as Drush make.

Composer vs Drush make

Drush make is a really useful tool to build Drupal projects, it allows you to rely on drupal.org and other sites to build your project which comes with a great set of advantages:

  • We don’t need to include and maintain the contrib modules and libraries in your codebase.
  • We can switch or include extra makefiles for different environments.
  • Flexibility to build your project from sources and switch versions with ease.
  • Maintainability and accountability. We’re aware of which version is used for every component and keep track of the changes (patches on these).
  • Drush make is included in Drush already, so you most probably have it available for your project.

Composer offers a non-Drupal way to do a set of similar actions, providing a composer.json declarative file instead. It provides a more robust dependency management feature - which is a manual action in Drush make - and provides an optional autoload.php file that could become handy for those projects using more OOP structures (so using it now will help you getting ready for Drupal 8 as a side effect).

Additionally, the composer update command, by using the composer.lock file, makes sure that the dependencies are always on track on every environment, including the specific versions required, so you can opt for not removing the contents prior to deploying new changes and just rely on the updates.

Packagist

On the other hand, Drush make is tightly related with drupal.org for providing the code, whereas composer is a more generic utility and will use packagist instead.
Luckily, and thanks to the efforts of webflo, derhasi and winmillwill among others, there’s a Drupal Packagist site now, that we can rely on to make our composer.json files simpler - more on this later.
You can follow the Drupal packagist project in github, and this issue to improve the sync between drupal.org and Drupal Packagist.

How to include modules, libraries and themes in composer

By using Drupal Packagist, you can rely on most of the packages there and simply use this line in composer.json

And then require the packages directly, without the need to define them.

Or depend of a git tag or hash:

But composer leaves you the option to completely redefine a package in case you need it, this could be that the version is not in Drupal Packagist yet, or the dependencies are not accurate.

Or even checking out from git - this will make the process slower, but allows you to use custom modules in different repositories too.

Drupal

By using the plugin custom installer, we can use custom strings to define the destination for your modules, themes, libraries… see the “drupal-module” as a package type above.

There’s also an official composer plugin for this that supports a similar structure: installers

Also, we’re able to keep/ignore certain paths when we do composer install/update, so our custom code is not affected by the package dependencies. For that, we need to include the composer preserve paths plugin.

What about patches

Any given Drupal project build will inevitably result in finding bugs and missing features in the modules and libraries used. The right thing to do is to build patches and contribute them back using the issue queue of Drupal.org (or a github Pull Request if the module code lives there) or if we’re lucky, maybe someone already fixed the issue and posted a patch we can use.

For including patches in our project, we can use either the composer patches plugin from netresearch or jpstacey’s composer patcher project.

One way to do this is to declare the patches as a new repository:

And include it in the require or require-dev section of our file:

What if I hacked the module

There are some cases where we find hacked modules (modules where the code has been directly edited by a developer, rather than extended or patched in a way that complies with Drupal coding standards — not ‘hacked’ in a security sense), most likely to happen if we take over the project from someone else, because the reader of this article would know that’s a bad practice :).
Let’s say that for a number of reasons, a module that we’re using is hacked and a number of the other modules depend on it. The normal workflow from composer would be to look for a dependency and if it’s not declared, because we’ve added this hacked module to the repo itself and we’re not pulling it from anywhere, composer will break the process due to unmet dependencies.
We can still get over this, but it is a little painful, we can use the “provide” element to declare that we’re providing that package in our repo already and then we need to update all the packages that are depending on the hacked one.

Say for this example we use entity reference, rules and entity modules:

And then we move entity to our codebase because it is hacked, we need to declare that our composer.json file provides this package:

But if we run composer install, both entityreference and rules point to a version of entity in packagist, so it will still download the dependencies, see this github issue for more details.
We need to declare the dependent packages and replace the dependencies:

The mynamespace/entityreference package doesn’t have a requirement to entity, so we’re good to go.

Example will all the above together

Here are a couple of gists with the examples used in this post:

Resources

There’s an extensive number of resources out there that can be really useful to get a good idea of what’s going on and what can be useful, here are a few:

Thanks to Christian, ciss and J-P Stacey for reviewing this post.

Drush is a command line shell and Unix scripting interface that automates may administration tasks for Drupal. The new drush version 4 adds commands. You can read the documentation to explain more. There is also the drush.org web site at drush.ws. Look for examples at:<drush path>/examples/

Overview of steps

  1. Add composer's bin directory to the system path by placing export PATH='$HOME/.composer/vendor/bin:$PATH' into your ~/.bash_profile (Mac OS users) or into your ~/.bashrc (Linux users).
  2. Install latest stable Drush: composer global require drush/drush
  3. Verify that Drush works: drush status
Drupal

1. To install Composer on Centos, Red hat or Fedora

Follow the instructions put together by idroot

Step 1. First let’s start by ensuring your system is up-to-date.

yum -y update

Step 2. Installing Composer.

Download and install Composer by executing the following command:

curl -sS https://getcomposer.org/installer php

Once the process completes, you can make the ‘composer.phar’ file executable by running the following command:

chmod +x composer.phar

Now use the following commands to make composer available globally for all users in your system, which can be used for all php applications on that system:

mv composer.phar /usr/local/bin/composer

You can also check the version of composer by running bellow command:

composer -V

To install drush

Download the current version from http://drupal.org/project/drush

and run tar -xvzf drush-7.*.tar.gz

Drupal

Then create a symbolic link to drush:

# sudo ln -s /opt/drush/drush /usr/local/bin/

If you cannot create a symbolic link you can create an alias to drush:

# echo 'alias drush='php /opt/drush/drush.php' >> ~/.bash_profile

Test Drush

# drush status

Learn more about Drush

# drush topic

To Create a new Drupal 7 (D7) install using Drush

Use the following to install and setup drupal 7 fast.

Download Drupal Software

# drush dl drupal

You may want to rename or move the directory contaning the drupal software

# mv drupal-7.0 /www/drupal

Create a new mysql database for the Drupal site

Create a new mysql database using phpMyAdmin

Create a new site

# drush site-install standard --db-url=mysql://drupal7:[email protected]/drupal7

Add to Apache Config

# vi conf.d/drupal7.conf

Optionally configure drupal to run from a subdirectory on the web server i.e. /drupal7

vi /www/drupal/.htaccess

Uncomment the line RewriteBase / and change the path to the sub directory you are running drupal from for example RewriteBase /drupal7

Drupal 7 Drush Composer

Login to the new site as admin/admin

http://localhost/drupal7

Change the Admin password

Select Menu people->admin->edit or use the drush command:

# drush user-password admin --password newpassword

Download and enable modules

# drush dl views ctools
# drush enable views ctools
y

Update Drupal core. For example, 6.14 to 6.15

# cd ~
# drush dl drupal
# rm -r ~/drupal-6.15/sites/
# mv ~/drupal-6.14/sites/ ~/drupal-6.15/
# rm ~/drupal
# ln -s ~/drupal-6.15/ drupal
# drush update

Check modules status

# drush statusmodules

Install Drupal 7 With Composer

Drush can now update itself

Drupal 7 Composer Autoload

# drush selfupdate

Subject