Learning tasks for Developers

Useful guides, resources and code examples to learn software usage that is required for this project.

Useful 8.x cheatsheets

Drupal books

Suggested Drupal 8.x books for advanced developers.

Using Composer

Drupal 8.x supports (and promotes) usage of Composer. Core and contrib projects may require external libraries that can be attached to the Drupal app using composer.

Composer uses a specific file named composer.json that keeps the configuration in one place as also as composer.lock that locks the dependencies of a project to a known state (specific versions).

Composer can install libraries from Packagist - The PHP Package Repository as also as any other package hub that supports composer.

// Show available composer commands
composer list
  • Common composer commands for a PHP project are:
// Creates a basic composer.json file in current directory.
composer init

// Installs the project dependencies from the composer.lock file if present,
// or falls back on the composer.json.
composer install

// Adds required packages to your composer.json and installs them.
composer require

// Updates your dependencies to the latest version according to composer.json,
// and updates the composer.lock file.
composer update

// Removes a package from the require or require-dev.
composer remove

// Dumps the autoloader
composer dump-autoload

// Create new project from a package into given directory.
composer create-project

// Validate a composer json
composer validate

// Show the installed packages
composer show --installed

// Show details about a package
composer show doctrine/annotations

// Check that there is a newer version available
composer show -a "drupal/core"

// Check why composer won't install something
composer why-not "drupal/core:8.3.6"

// Check if we have a version of 'php/reflection' in our lock file that is too high for another package
composer why "php/reflection"

  • Example of adding requirements of the address module:
// Go to the Drupal root

// Add the requirements abd update composer.json
composer require commerceguys/intl
composer require commerceguys/addressing
composer require commerceguys/zone

  • Example of a Drupal build made by composer:
// Set the source of Drupal packages
composer config repositories.drupal composer https://packagist.drupal-composer.org

// Download drupalcommerce/project-base
composer create-project drupalcommerce/project-base <PROJECT_FOLDER> --stability dev

Building with Features

This is an example of a workflow using Features and Core Configuration Management (CMI) in D8. It assumes that you are using 3 development environments Development, Staging and Production.

Creating initial config:

  1. Use Features to organize your config into modules
  2. Push feature module code into git repo
  3. On Staging server pull the repo, enable all the modules. Initial config will be loaded
  4. On Staging, use CMI to export all config
  5. Pull both code and config export to production
  6. On Production, import all config

Making a change to Feature(s):

  1. On your Development, update the feature code, push to your repo
  2. On Staging, pull the code and import/revert the feature
  3. Once tested, use CMI to export all config
  4. On Production, pull code and config
  5. On Production, import all config

Create a multilingual website

Create a multilingual installation with Dummy content and inspect the database.

Use this distro: drupal.org/project/multilingual_demo

Play with git and VCS

Git essentials and how git works:

Useful git cheatsheets:

Interactive tools to learn git commands and terminology:

CLI tools (shortcuts) you can (should) use:

  • git-flow. A method as also as a collection of commands for successful git branching and development.
  • (Optional) git hub. A tool to help create pull requests, compare commits, view issues and make your life on GH better.
  • (Optional) git extras. Some useful git aliases/wrappers for humans (summary, undo, ignore, changelog etc).

GUI Clients you can use.

Git GUI clients are mostly used to see visual graphs of the commits, to solve conflicts, to browse repos etc.

Rewriting git history

Many times, when working with Git, you may want to revise your commit history for some reason.

This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely – all before you share your work with others.

Rewriting git history may cause unpredictable issues and really big headaches so here are some useful manuals you should read before going on as also as a decision diagram that helps you decide what to do.

How to handle a git mess Download as pdf

Configure git

See the online docs. Here are some basic information.

To configure git globally run git config --global --edit

  • Enable rerere
  • Do not let git to auto-convert CRLF line endings into LF (autocrlf)
  • Do not track filemode
  • Use the git push with simple option

Example of a global .gitconfig file (part of):

  autocrlf = false
  safecrlf = false
  ignorecase = false
  editor = /usr/bin/subl -n -w
    filemode = false

  default = simple

  autosetuprebase = always

  renames = copies

  ui = true

  enabled = true
  autoupdate = true

  tool = <YOUR_GIT_DIFF_GUI>

Debug Drupal

Useful resources:

Drush (Drush)

Drupal Console (Drupal Console, Drupal console cheatsheet)

Drupal modules

PHP debug and testing

Database debug


Drupal console commands:

Code review (for Drupal)

Drupal IDE


Drupal 8.x configuration system

Here are some facts about the new Drupal 8.x core configuration (“config.”) system.

  • Config. is made to work for deployment not for packaging.
  • All modules, themes and distributions (Drupal projects) have the same type of configuration (under /config/* folder).
  • <project_name>/config/install has the required config. <project_name>/config/optional has the optional config. (may not be installed).
  • Configuration files are of yml type.
  • A config. file name should be unique.
  • Config. is a group of key-value data.
  • Configuration is decoupled from modules after installation. After installation the Drupal system “owns” the configuration.
  • There are 2 types of config. storage: Active (currently used from the website) and Staging.
  • We can have multiple config. stores (not only 2).
  • Active storage is stored on the database by default.
  • Active storage on the database is using UUIDs for each configuration setting.
  • The tables that are created on the database are cache_config, config.
  • By default Drupal creates the Staging folder inside the public files folder.
  • We can override the paths for the config. storage (usually on settings.php).
  • All config. is tracked by default.
  • Diff. is availble to inspect the changes.
  • Config. is saved per content entity.
  • Config. can be individually imported/exported.
  • Config. synchronization requires all files to be present (missing config. files or settings will delete the configuration!)
  • Core config. system is working for the same only Drupal installation.
  • Exported config. files with UUID cannot be reused on another installation.
  • Always use the Config. API to export/import config. Do not edit files or database entries manually.
  • We can “override” a config. setting on the fly in the settings.php file.
  • We can see an overview (Report) of the config. changes at example.com/admin/config/development/configuration/report
  • Useful modules that can export, import or manage config. are features, config_update, config_devel, config_sync, config_tools, config_share.

Drush and Drupal console commands for configuration management

Tool Command Alias Description
drush config-edit cedit Open a config file in a text editor. Edits are imported into active configuration after closing editor.
drush config-export cex Export configuration to a directory.
drush config-get cget Display a config value, or a whole configuration object.
drush config-import cim Import config from a config directory.
drush config-list cli List config names by prefix.
drush config-pull cpull Export and transfer config from one environment to another.
drush config-set cset Set config value directly.
drush config-merge cm (External plugin) Merge configuration data from two sites. See docs and source code at github.com/drush-ops/config-extra
Tool Command Alias Description
drush features-add fa, fe Add a config item to a feature package.
drush features-components fc List features components.
drush features-diff fd Show the difference between the active config and the default config stored in a feature package.
drush features-export fex, fu, fua, fu-all Export the configuration on your site into a custom module.
drush features-import-all fra, fia, fim-all Import module config from all installed features.
drush features-list-packag fl Display a list of all existing features and packages available to be generated. If a package name is provided as an argument, then all of the configuration objects assigned to that package will be listed.
drush features-status fs Display current Features settings.
Tool Command Alias Description
drush config-added-report cra Display a list of config items that did not come from your installed modules, themes, or install profile
drush config-diff cfd Display line-by-line differences for one config item between your active config and the version currently being provided by an installed module, theme, or install profile
drush config-different-report crd Display a list of config items that differ from the versions imported from your installed modules, themes, or install profile. See config-diff to show what the differences are
drush config-inactive-report cri Display a list of optional config items from your installed modules, themes, or install profile that are not currently in your active config
drush config-list-types clt List config types
drush config-missing-report crm Display a list of config items from your installed modules, themes, or install profile that are not currently in your active config.
Tool Command Alias Description
drush config-devel-export cde, cd-em Write back configuration to module”s config/install directory. List which configuration settings you want to export in the module”s info file by listing them under “config_devel”
drush config-devel-import cdi, cd-im Write back configuration to module”s config/install directory. List which configuration settings you want to export in the module”s info file by listing them under “config_devel”
drush config-devel-import-one cdi1, cd-i1 Write back configuration to module”s config/install directory. List which configuration settings you want to export in the module”s info file by listing them under “config_devel”

Examples of drush commands related to configuration.

// Get config of specific yml files
drush config-list | grep views

// Edit a config file with an editor
drush cedit views.view.content

// Install partial config from a folder
drush cim --partial --source=/path/to/my/install/config

// Install a new site from a config folder
drush si --config-dir=/path/to/my/install/config

// config-merge example, see more at:
// https://github.com/pantheon-systems/drush-config-workflow/blob/master/docs/git_workflow.md
drush @dev config-merge @stage --git --message="Move config from @dev to @stage"

Useful browser extensions and plugins

OOP - how to

See Drupal 8 - Background & Prerequisites

Also oop_examples

  • Definitions (Namespaces, Dependency Injection, Annotations, Plugin, Factory, Interface etc)
  • Best practices
  • Examples
  • IDE in the rescue


Docker allows you to package an application with all of its dependencies into a standardized unit for software development.

Docker resources can be found at Awesome-docker, A curated list of Docker resources and projects.

You can use Docker with many ways while developing. Some common scenario usages are:

  • Test git branches and/or functionality (using the UI or the Drupal testing system)
  • Take backups of the system (eg get the database of the build)
  • Automate Continuous Integration (CI)
  • Automate Continuous Delivery (CD)
  • Reproduce issues and errors and share them with the team
  • Test Drupal core or contrib modules updates