3. Wolfgang Ziegler // fago
●
More than 10 years of Drupal experience
●
Leading force behind the Drupal 8 Entity
Field API improvements
Maintainer of Typed Data API
●
Creator of Rules, Field Collection, Profile2
5. We are hiring!
Web Frontend EntwicklerIn (Javascript, PHP)
https://drunomics.com/jobs
6. German translation
● Active sprinting by the Drupal Austria
user group
● Three new committers are waiting to
approve your translations!
http://localize.drupal.org
● Discuss at drupal.slack.com
#localize-german
15. What happens?
● Compares requirements with current
state
● Downloads code and puts it into
./vendor
(or somewhere else)
● Generates a class autoloader
● Records versions in composer.lock
16. Composer update & locks
● composer update
– Update all the dependencies and
write new lock file
● composer install
– Apply what's recorded in the lock file
– Run update if there is none
17. Composer & VCS
● Commit composer.json
● For projects: Commit
composer.lock
● For libraries: Commit
composer.lock for tests
● Avoid commit vendor files
18. Versions & Composer
● Require versions like 2.1.*
● composer supports many different
version constraints
● Specify allowed versions, not
specific versions
22. Start a new d8 project
composer createproject
drupalcomposer/drupalproject
23. What does it do?
● Adds Drupal into the „web“ dir
● Adds folder structure, drush, Drupal
console, …
● Custom projects can add more stuff
and/or customize things
– Add Drupal modules & themes!
26. composer install all the way!
● Do not forget to run composer
install!
● After pulling changes, run it!
● Best: Add to deployment alias:
composer install &&
drush updatedb && ...
38. Fork & add your fork
● Alternative to patch files
● Works great with the Github pull
request workflow
● composer createproject
drupal/module path 2.2.0
● Add in the fork instead upstream
39. Adding in your fork
"require": {
"samson/yt": "devBRANCH as 2.0.0"
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/fago/yt"
}
],
41. Keep builds fast
● composer fetches either „dist“ or
„source“ packages
● Prefer „dist“ packages for fast
builds & cache use!
● Pre-configured in drupal-project
46. Avoid committing vendors!
● Smaller diffs & pull requests
=> easy to review!
● Keeps repositories smaller (only
custom code)
● Work with vendor repositories
without submodules
47. Builds & Deployment
1.Hosting takes care of it
2.Deployment tools like capistrano
or deployer (http://deployer.org)
3.Git-based deployments of build-
branches or build-repositories
50. Build branches
● We keep them in the same
repository
● Enables possible future
enhancements
51. Creating builds
● PHP-console script for creating
builds
● Takes care of updating pre-existing
build branches (think: build/master)
● Takes care of tags
● Takes care of vendor repositories
52. phapp cli
● Tool for managing PHP
applications
● Not yet many commands besides
„phapp build“
● https://github.com/
drunomics/phappcli
53. phapp build
● Custom build scripts via phapp.yml
per project
=> Allows adding things like npm
● Just build in place?
→ phapp build
● Build a branch?
→ phapp build BRANCH
54. Deployment updates
● Apply changes after code update
● Do not rely on special server
environments!
→ More reliable deployments!
55. Deployment script tools
● composer scripts
● Robo
● Drush, Drupal console
Add dependencies to the project!
56. Drush usage
● Composer must be executed
from the main project dir
● Support running drush there with
a drush.wrapper script
59. Why?
● Develop re-usable PHP libraries,
e.g. REST clients
● Feature modules for kick-starting
development
composer require
drunomics/dsk_media
60. Add your own packages
● Custom repositories at project
● Run your own packagist
● Use Toran Proxy
● Use satis & host static files
– Scans your repositories
– Re-run after every change
64. Handling libraries / assets
● Possible solutions:
– Add them via custom repostories
– composer scripts for running bower or npm
on project install
– fxp/composer-asset-plugin
– ...
