Drupal 8.8.0 introduced a bunch of new features intended to make it easier over the long-term to maintain a Drupal project using Composer. In doing so it establishes some new best practices, and moves into Drupal core solutions that were previously maintained by the community. This is all good news. But, it means if you're using Composer to update from Drupal 8.7.x or lower to. Using Composer to build your Drupal 7 projects Published on Vie, - 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. Check Drupal 7 site for existing content and modules. Please check that stable Modules in Drupal 7. In this video Tom Friedhof shows you how to properly use Composer Manager in both Drupal 7 and Drupal 8. He describes the nuances of Composer Manager betwee.
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
- 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).
- Install latest stable Drush: composer global require drush/drush
- Verify that Drush works: drush status
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
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
# 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
Uncomment the line RewriteBase / and change the path to the sub directory you are running drupal from for example RewriteBase /drupal7
Login to the new site as admin/admin
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
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
Drush can now update itself
# drush selfupdate
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 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.
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.
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:
Drupal 7 Composer Install
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:
Drupal 7 Core
Thanks to Christian, ciss and J-P Stacey for reviewing this post.