Skip to content

Instantly share code, notes, and snippets.

Last active October 6, 2021 07:55
Show Gist options
  • Save raphaellarrinaga/b07da86b1177ab6d7a21c01099d99485 to your computer and use it in GitHub Desktop.
Save raphaellarrinaga/b07da86b1177ab6d7a21c01099d99485 to your computer and use it in GitHub Desktop.
[Drupal install & config process from scratch] #tags: drupal, drupal8, config

// Update 2021

composer create-project drupal/recommended-project myproject -n or

composer create-project drupal/recommended-project:^8.9 myproject -n

cd myproject
lando init --source cwd --recipe drupal8 --webroot web --name myproject
lando start
composer require drush/drush drupal/admin_toolbar
drush si --db-url=mysql://drupal8:drupal8@database/drupal8 --account-pass=content -y
drush en admin_toolbar admin_toolbar_tools
drush uli -l

// Create .lando.yml. lando init --source cwd --webroot web --name drupal9 --recipe drupal8 --option php=7.3

Drupal installation & update with phing and composer template

I Create a git repo

II Download composer template

Dll from and see the doc to install with phing in it Don't git clone otherwise you inherit the git file and stuff

III Launch

composer install

IV Create from with minimal config (read the config from dist file)

It's used by phing

V Install the website

$ ./vendor/bin/phing install

VI Set up tools for the development environment

$ ./vendor/bin/phing setup-dev

VII Make the base configuration and export it

./../vendor/bin/drush cex

Export your config to make drupal config files available for an eazy first installation for others

IX Check gitignore

Drupal basic site building

Not recommended modules

  • Devel, UI submodules (Views UI, Field UI, etc) should be disabled. You need to use them on a dev instance and then migrate necessary configurations.

Install modules

  • If multilingual website : 4 multilingual modules to install depending on the config needed (Configuration Translation, Content Translation, Interface Translation, Language)
  • syslog & activity tracker for on-production logs
  • datetime range : to get a "from…to" formatted date. Watch out, it could be depricated in the future
  • pathauto
  • honeypot
  • simple_sitemap
  • recaptcha : don't use it, deprecated -> mollom (recaptcha ok)
  • field group
  • Advanced CSS/JS Aggregation
  • Redirect - allows a site administrator to add 301 redirects for old page URLs.
  • (Update manager) - it’s a very helpful module which can inform you about any security updates for your modules and the Drupal core.
  • (Elysia Cron) - extends Drupal standard cron, allowing a fine grain control over each task.
  • (Rabbit Hole) - hides unpublic nodes.
  • (Security Kit) - reduces the risks of exploitation of different web application vulnerabilities.
  • also : components, ui_patterns, admin_toolbar, admin_toolbar_tools, responsive_image, paragraphs, Paragraph view mode, advagg, metatag, analytics, inline_entity_form, ds_chains
  • (Site Settings and Labels)
  • (video)


  • install module
  • configure patterns in admin/config/search/path/patterns
  • for most content types, use a global config with pattern [node:content-type:name]/[node:title]
  • for content types that gets an entity reference (eg article type news), use a token for an entity reference in the path, eg [node:field_article_type:entity]
  • carreful not to use an token which is an object
  • /!\ in settings, "Update action" chose Create a new alias. Leave the existing alias functioning. to avoid 404 pages when changing the alias

Layout modules





  • @todo configure email path matcher + obfuscator
  • @todo configure linkit + media to link to a media file
Redirect module

/!\ If it's a website redesign, check old website analytics and redirect url with redirect module to avoid 404. Make 301 redirections to keep google referencement Later, check the logs to see what 404 are logged and redirect to the correct page

Content type configuration

  • activate revisions if necessary but hide it for the user -> via hide revision field module
  • wysiwyg: most of the time it's better to activate full html if it's not a website that requires a wide range of user contribution
  • files: "File directory", never use the date, better chose something like "content_type_name/field_name"
  • files: don't fill max upload size, leave it to the server
  • for images, don't user banner as a name or directory name because addBlock addon filters it


  • if english is the default language, thing about switch to another language as default language (and then come back to english if needed) to get a path like /en/something otherwise you don't get the langcode, just www.domain/something
  • we don't translate paths (eg, team/equipe) because it's easier to maintenant but worst for the referencing
  • language detection : never chose "browser" because it can bypass user language selection
  • in taxonomy fields, uncheck "user can translate that field", it's likely to be used for tags but almost never make sense


  • user fields : in admin/config/people/accounts/fields/user.user.user_picture, use a correct "file directory" path like user/image
  • user fields : remove file size limit, leave it to the server
  • in admin/config/people/accounts, "REGISTRATION AND CANCELLATION" > "Who can register accounts?" chose "Administrators only" most of the time

Basic production checklist

  • Disable contact form permissions if it's unused
  • Obfuscate email addresses
  • Enable CSS/Javascript aggregation
  • Configure cache
  • Install + configure Google Analytics
  • Define recaptcha as default challenge for webforms /admin/config/people/captcha
  • Test webforms submissions
  • Redirect full pages if they should not be accessible from search engines (mostly for one pages websites)
  • Update entities drush entity-updates
  • Check Drupal status /admin/reports/status
  • Enable CSS/Javascript aggregation
  • Remove unused themes
  • Uninstall development modules (devel, kint, webprofiler, ...)
  • Activate Internal Page Cache, Internal Dynamic Page Cache, Use gzip compression. See

Updates for sites based on composer

composer update drupal/core --with-dependencies
drush updatedb
drush cr


Updates for sites based on drush

Local environment

STEP 1 : Access the root folder of your site cd ../mon_site/www eg. cd /home/username/Sites/tiltfactory/www

STEP 2A : To update the Drupal core use the following : git fetch --all && git reset --hard origin/master && cp .htaccess .htaccess_BACK && cp robots.txt robots.txt_BACK && drush up drupal -y && rm -Rf .htaccess && rm -Rf robots.txt && rm -Rf .gitignore && mv .htaccess_BACK .htaccess && mv robots.txt_BACK robots.txt && drush updb -y && drush cc all

STEP 2B : To update one or more modules use the following : drush up module_name_1 module_name_2 module_name_3 -y && drush updb -y && drush cc all eg. drush up backup_migrate date i18n -y && drush updb -y && drush cc all

STEP 3 : There are no unit tests. The site has to be verified manually. Use the site logs as a helper Home > Administration > Reports > Recent log messages (eg.

STEP 4 : Once the site is verified and everything seems ok, commit and push your modifications git add . git commit -m "[security update] Drupal 7.41 + 3 modules" git push or use the graphic interface

Production environment

STEP 5 : Access the root folder of your site cd /home/mon_site/www

STEP 6 : Backup the database. ! ! ! Do not use a zipped file ! ! !, lately, Backup and Migrate seems to have an issue with certain sites. Dunno why.

STEP 7 : Put the site in maintenance mode.

STEP 8 : Apply the modifications, update the db, clear the cache and rebuild the access rights git pull && drush updb -y && drush cc all && chown -R my_user:users /home/my_site

STEP 9 : Verify manually the site. Use also the sites logs.

STEP 10 : Put the site in live mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment