Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Sep 22 2020
Sep 22

At DrupalCon Global 2020, Tag 1 Consulting CEO Jeremy Andrews and Managing Director Michael Meyers talked about the upcoming Drupal 7 and Drupal 8 end of life. In their talk, they discussed:

  • What Drupal “End of Life” (EOL) means
  • When it happens, and how D7 and D8 differ
  • Why widely used versions are retired
  • Practical implications and your options
  • What Drupal vendor Extended Support (ES) Is
  • Why ES only covers D7, and not D8
  • How ES operates, and what it covers

[embedded content]

What Drupal “End of Life” (EOL) means

When a version of Drupal reaches EOL, the Drupal community will no longer work on it or provide free support. Core development stops entirely - no new features are added, no bugs will be fixed. The core issue queues will be locked, you will be prevented from adding anything to Drupal 7 & 8 Core on Drupal.org.

While Drupal 6 Core is locked, contrib is still open. Drupal 7 & 8 will likely do the same, so you can update your modules. Very few 6.x modules were updated after the Drupal 6 EOL, and many maintainers closed their branches as well. Expect that most contrib module owners will close their 7 and 8 branches.

In addition to the issues queue, the testing infrastructure will most likely be decommissioned. The PHP versions supported by these versions of Drupal are also EOL. Each D7ES vendor has a member on the security team, but the Drupal security team will no longer be proactively involved in reviews. This may mean less secure code unless you participate in a D7ES program, or manually track patches as they become available.

When is the EOL date?

Drupal 7 reaches end of life in November of 2022.It was originally scheduled for November of 2021. The date was extended due to the large user base, and the difficulties stemming from the global coronavirus pandemic.

Drupal 8 reaches end of life on November 2, 2021. While it may be confusing that Drupal 8 reaches EOL before Drupal 7, Drupal 8 is dependent on Symfony 3, which reaches the Symfony community’s EOL at that time.

Why widely used versions are retired

There are many reasons to retire older software.

  • Legacy: Drupal 7 is 10 years old, and will be ~12 by EOL in Nov. 2022
  • Bandwidth: Developers can’t support Drupal 7 and 8 while building Drupal 9 and 10
  • Interest: Developers don’t want to focus on 10 year old technology
  • Innovation: Improvement through innovation is the best for Drupal as software

Drupal 7 and 8’s end of life is a challenge. Rebuilding your website on new technologies (which also have their own EOL schedules), can be expensive and time consuming. Drupal 8 to Drupal 9 is an easier upgrade, making its EOL less problematic for users.

Practical implications and your options

Drupal 7 users have several options. The higher cost options are:

  • Don’t migrate. This is a bad choice, because it leaves your website vulnerable to attack, potentially losing data.
  • Migrate to Drupal 9. This is a good choice, keeping your site up to date with a similar ecosystem.
  • Move to a new CMS. Similar in cost to a Drupal 9 migration, with the added cost of training your teams on new technologies.

Lower cost options are:

  • End of life your website.
  • Turn your website into a static website.
  • Keep running Drupal 7, and work with a Drupal 7 vendor in the Extended Support (D7ES) program.

What Drupal vendor Extended Support (ES) is

D7ES ensures Drupal 7 remains secure and safe to run. Companies approved to offer D7ES must provide at least the following services:

  • Security patches for D7 core, including vulnerabilities that are reported for supported versions of Drupal
  • A specific list of contributed modules will be identified, and security patches will be provided for them
  • Vendors must make a commitment to offer these services for at least 3 years; at a minimum, you should receive D7ES through 2025
  • All patches created by D7ES vendors must be open source - if a D7ES vendor fixes any problem with D7, they are obligated to release the fix
  • Vendors must have an active member on the Drupal Security Team

The more the community supports this effort, the more vendors will offer it, and the more fixes they’ll be able to provide. Official vendors are vetted by the Drupal Association and listed on the D7 Vendor Extended Support page. Drupal 7 ES does not follow a formal release schedule, and your website must be on the final EOL version of Drupal 7 in order to participate in the vendor programs.

To learn more about Tag1’s extended support program, see Tag1 Quo - the enterprise security monitoring service.

Photo by Ankhesenamun on Unsplash

Sep 21 2020
Sep 21

In his Drupal4Gov webinar Using tools and Git workflow best practices to simplify your local development, Greg Lund-Chaix, Senior Infrastructure Engineer at Tag1, talks about some of the ways that teams struggle when they become successful and need to learn to scale. He recommends using some basic tools to make your workflow easier. The right tools in your environment can prevent big problems down the line with merge conflicts, code committed to the wrong branch, or other mistakes.

Git is one of the most common version control systems in use today. With a few tools, and a few best practices, you and your team can make your local environments easier and safer to use.

[embedded content]

Rebasing

Learn to rebase. When you’re working on a feature it might take you a few hours, to several days or weeks. The longer you take working on a branch, the more chances your branch is out of sync with the rest of the code base. The cleanest way to prevent problems is to rebase. Rebasing checks where your branch diverged from main, pulls in all the changes, and replays your changes on top of them. Rebasing prevents cluttering up your commit history, too.

Here’s an example of how Greg works:

[laptop] ~ $ git checkout feature123-amazing-stuff
[laptop] ~ $ git pull --rebase origin main
[laptop] ~ $ git add my_amazing_module.module
[laptop] ~ $ git commit
[laptop] ~ $ git pull --rebase origin main
[laptop] ~ $ git push -u origin feature_branch

Greg starts his day by checking out his feature branch. Greg always works in feature branches, as one of his core four rules. He can’t be sure if anyone has committed code since he last checked this branch, so he rebases his branch against the main branch on his codebase’s origin. Everyone else’s changes are pulled in, and Greg’s changes are added back on top of them. Now, if someone has made changes to the same files Greg has, he’s able to see the conflicts before they go into the main branch. A pull --rebase does not add a merge commit, and keeps your commit history cleaner.

Now, Greg knows his changes are clean. During the day, he adds and commits more changes. Just before the end of the day, he rebases again, ensuring his code is as clean and safe as possible before he finally pushes it at the end of the session.

Git prompts for sanity

Anyone who has ever worked on a command line has felt the pain of doing something in the wrong directory, deleting the wrong file, or moving something to the wrong place. Your command line prompt can be a helpful indicator for where you are, what you’re doing, and the status of your local repository.

Git includes a script for showing your repository status in your command prompt. Download the git-prompt.sh file or look for it in your git source, and customize it to your needs. This prompt file does several helpful things:

  • Tells you what branch you’re on
  • Adds a red percent (%) sign when there are untracked files in the repository
  • Adds a red asterisk (*) when there's a changed file in the repository
  • Adds a green plus sign (+) when a file has been added using git add

These indicators flag that there is some change that has not been committed. This may be expected, but it may also be a sign that something has gone wrong - for example, if your indicators show up when you’re on the main branch.

Greg made a secondary script available for prompts, which indicates where you’re making the changes: locally, or on a server. If this might help you, download the servertype-prompt.sh script for yourself. This script depends on git-prompt.sh. Whether or not that prompt displays is an indicator for where you’re working.

Sniff your code

Unlike the more traditional network sniffer, which analyzes your packet traffic on the wire, a code sniffer reviews your code and checks it against a predefined standard. PHP_CodeSniffer “tokenizes PHP files and detects violations of a defined set of coding standards.”

Drupal developers are often familiar with the Coder module, written by Tag1 Senior Architect Doug Green, checks your Drupal code against coding standards and other best practices.

To include these in your codebase, add the following lines to your composer.json file.

composer require --dev drupal/coder
composer require --dev dealerdirect/phpcodesniffer-composer-installer

For a full tutorial on installing Coder and PHP Codesniffer, see Installing Coder Sniffer on drupal.org.

Coder module is designed to work with PHP CodeSniffer, making it easy to integrate with your continuous integration platform. Setting your team up with this kind of integration enables automated coding standard reviews on every pull request.

Other useful tools

Pre-commit hooks can run checks for you before you make a commit locally. You can set up a hook to run codesniffer before you commit - if your codesniffer fails, your commit fails, too! This can prevent some of the more obvious mistakes from even making into your local code. See an example Drupal pre-commit hook by Marco Marctino (mecmartini), or full documentation at pre-commit.

Tig is a visual command line tool that lets you see commit and log information for your repository. It has an interface that enables you to walk the list of commits, and see the details more easily.

Users who are less comfortable or familiar with the command line may find a graphical interface to be friendlier. Many GUIs are available for Git. If you’re struggling with the command line, check out a GUI and make your life easier.

About Drupal 4 Gov

Drupal 4 gov is an open source community for developers and IT professionals with an interest in making the government more open to open source.

It encompasses many open source projects but we have our beginnings in the Drupal project.

Drupal4gov offers:

Photo by Grant Ritchie on Unsplash

Sep 14 2020
Sep 14

In his Drupal 4 Gov webinar Using tools and Git workflow best practices to simplify your local development, Tag1 Senior Infrastructure Engineer Greg Lund-Chaix talks about some of the ways that teams struggle when they become successful and need to learn to scale. One of his primary focuses for teams is helping them learn how to improve their development workflow.

Local development environments give developers the tools to quickly prototype and run their code, and make testing and debugging easier. You can use local environments to create code that can be pushed to the repository, and shared with the team easily and cleanly - enabling discussions and peer review early in the development process.

One of Greg’s key tenants is “No editing on the servers.” Working locally keeps mistakes from reaching the primary codebase. Using a local environment is a best practice.

Tag1 developers often use these two tools:

These tools are open source, extensible, and have many available integrations. They make it quicker and easier to create a local environment than using a tool like MAMP, or configuring your own setup with MySQL, Apache, and so on.

Tools like DDEV and Lando also ensure your local environment matches your production environment, preventing long troubleshooting sessions when something works locally, but not on production.

How to get up and running with DDEV

Here’s a quick guide to getting started with DDEV.

[embedded content]


  1. Install DDEV.
  2. From a command line, start with a basic Composer-ized installation of Drupal. Greg created a template repository you can use as a starting point. You can have as little as a directory for custom code, the composer.json file, and a README.txt file.
  3. Enter composer install. Composer will download and complete a basic Drupal installation.
  4. At the prompt, enter ddev config.
  5. The command prompt updates. DDEV checks the directory name, and assumes the project name is based on that directory. Update the name here if that is incorrect, or press the Enter key to accept the default.
  6. DDEV checks the contents of the directory. If you’ve installed Drupal, it recognizes the installation. You may also select a different Project Type from the list DDEV supplies.
  7. DDEV setup is complete. To run DDEV, type ddev start.

DDEV starts the Docker containers. If you have never run DDEV before, this may take a few minutes while it pulls the containers down from the repository. When ready, a message similar to this displays:

DDEV setup is complete when the `Successfully started` message displays.

Click, or copy and paste the link into your browser to load your new Drupal website.

Two commands, one Drupal website!

What next?

When DDEV runs for the first time, it creates the .ddev/config.yaml file in the directory. Git ignores this file by default; consider adding it to your repository. This ensures everyone who checks out the repository has the same configuration.

View the file in your choice of text viewers.

An example of DDEV's `config.yaml` file.

This file is customizable, enabling you, your developers, and your DevOps teams to make changes that ensure your local environment matches your production servers.

From here, Greg suggests using Ansible, Puppet, or another configuration management tool to deploy your code to production.

Now you should be able to run DDEV, and explore its uses!

About Drupal 4 Gov

Drupal 4 gov is an open source community for developers and IT professionals with an interest in making the government more open to open source. This blog was based on Greg’s Drupal 4 Gov presentation.

It encompasses many open source projects but has its beginnings in the Drupal project.

Drupal 4 gov offers:

Photo by Lysander Yuen on Unsplash

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web