新启用的Debian 10 系统，按照以往的操作方式使用 composer 安装 Drupal 时出错，错误信息是：
Failed: [RuntimeException] git was not found in your PATH, skipping source download
运行 apt install git 即可以安装 git 了。
现在再运行 composer 命令，会提示你输入你在 drupal 官网的用户名和密码，这样 composer 就可以继续运行下去了：
在使用composer require安装Drupal模块或者主题的时候，有可能会安装失败，Composer报错如下：
在启用了facets模块的Facets Range Widget子模块后，你会在Drupal后台的状态报告页面看到一条警告：
在内存1GB（分配给PHP的最大运行内存是128MB）的Linode VPS上运行Composer安装Drupal模块，没有得到成功的提示，只是提示KILLED。
通过修改分配给PHP的运行内存把PHP内存由128MB提高到256MB以后，报错具体了一点：
在Linode VPS上面使用Composer安装Drupal网站的时候，大伟哥看到一长串黄色的警告：
Drupal越来越倾向于使用Composer来管理代码库了，好多模块不使用Composer都不容易安装成功。那对于以前下载上传又手动安装配置的Drupal网站，怎么样才能搭上Composer的快车呢？大伟哥经过对Drupal文档的学习和实际测试，发现很容易就可以免票上车了。上了车之后再回头看，才知道阻碍我们拥抱Composer的，不是Composer真的复杂难学，而是习惯的力量和对未知事物的恐惧。我们要始终意识到这样一个事实：Composer是来帮我们的，不是来制造麻烦的。
使用Composer可以方便地管理Drupal核心版本和模块版本的更新，那如果是已经有Drupal的补丁解决了你急需要解决的问题，而Drupal核心团队或者模块作者还没来得及或者压根不想把补丁打包进新的版本呢？使用Composer追求自动化的你一定不想在Composer每次更新版本之后，还要再次手动给Drupal打补丁。既然用了Composer，那就让Composer全部代劳吧，连补丁一块儿。
要想让Composer干好这活， 得给它额外安装个工具，叫composer-patches。安装很简单，在项目根目录里require一下就行了：
Composer真香，使用composer是会上瘾的，大伟哥已经决定把所有的Drupal网站都使用Composer来接管了。不过最近在阿里云ECS上使用Composer来安装依赖的时候，遇到了这样的错误：
新工具的掌握并没有通常想象中那么难，在一边学习一边实践的过程中，我们更加体会到，学习composer不是负担，它就是帮我们获取想要的库文件的工具。
现在，我们在上次创建的新项目中，安装另外一个好用的命令行工具——Drush。Drush 就是Drupal Shell，理解了就很容易记忆。
熟悉的思路，熟悉的过程：先切换到www-data用户，然后进入项目文件夹，最后运行composer require drush/drush：
经过前面对composer的安装和调试，我们终于可以用www-data用户的身份运行Composer来管理Drupal文件了。
虽然有好几种办法使用composer来安装Drupal，但是现在Drupal官方推荐的方法却只有一种，那就是使用drupal/recommended-project这个composer模版。