This article aims to get developers coming from Drupal 7 to Drupal 8 up to speed on some of the changes introduced in Drupal 8 with the new Symphony framework. While some of the old favorites still exist, some have experienced change, and there may be caveats to which tools a developer will reach for in their tool-belt on a daily basis. Drupal 8 is one year old as of November 19th, so it's time to consider getting up to speed if you've been a contributor in the past or want to contribute in the future. If you'd like to learn first-hand I highly recommend installing the Acquia sponsored Lightning distribution using composer to try out these concepts yourself.
Lightning is a distribution which provides editorial tools taking advantage of Drupal 8's new functionality with focus groups leveraged on letting end users manage layouts, media assets including social embeds, and content moderation workflows. The recommended way to set up an environment on your development box is to follow the README.md file instructions:
Get StartedYou will need the following installed:
$ composer create-project acquia/lightning-project:^8.1.0 MY_PROJECT --no-interaction
Now that we've got that taken care of, here come those gotchas that I mentioned earlier. This is different from your standard drupal installation. You'll see the directory structure doesn't start with just typical Drupal files that your used to. These now live in ./docroot which is the location that your webserver will need to host. Drush is still handy, but now it bypassed in favor of composer for package management. Composer adds an extra capability that it is a dependency manager and it will retrieve the exact version that each installed project's maintainer specifies as "tested and works" for dependencies and libraries. All of the packages and project configuration is specified in ./composer.json. This can be updated, even between distribution releases by running
$ composer update Composer will maintain a composer.lock file and a vendor directory, as well as a libraries directory. The Lightning distribution specifies that Drupal modules will be installed at ./docroot/modules/contrib. Composer will even apply patches to modules as needed using cweagans/composer-patches.
Common drush commands that you won't need in your composer project:
The ~ operator is best explained by example: ~1.2 is equivalent to >=1.2 <2.0.0, while ~1.2.3 is equivalent to >=1.2.3 <1.3.0. As you can see it is mostly useful for projects respecting semantic versioning. A common usage would be to mark the minimum minor version you depend on, like ~1.2 (which allows anything up to, but not including, 2.0). Since in theory there should be no backwards compatibility breaks until 2.0, that works well. Another way of looking at it is that using ~ specifies a minimum version, but allows the last digit specified to go up.
$ drush cache-rebuildAdditonally, composer won't enable modules or apply database updates. You'll have to do this with the following two commands:
$ drush pm-enable
$ drush pm-update
Finally, if you're rolling your sleeves up and getting your hands dirty, there is a new module in the devel suite which replaces some of the functionality of dpm() (or dsm() for those of you who prefer it). Those functions still exist, however they are useful for outputting flat variables only. The krumo debugger has moved to a module named kint and is called by the same name. Use this for inspecting arrays, and objects in your desired method or function. It has the added feature of showing class methods if printing objects.