
Many sites are built around their content, especially Drupal sites. To manage this content, a strict editorial workflow is often highly desirable to make sure the content is drafted, reviewed, published, updated, and archived when ready.
In this tutorial we'll:
- Discuss the various components you'll need to define before you can start building a custom editorial workflow
- Provide an example editorial workflow plan
By the end of this tutorial you will better understand the use case for content moderation, and be able to create an editorial workflow plan for your use-case.
In order to enforce that an editorial workflow is applied to a specific content type you need to update the workflow's configuration. Then, depending on your needs, you may also need to configure new user roles, giving them permission to transition a content item from one state to another.
This process works for any Content Moderation type workflow -- including the Editorial workflow that Drupal provides and any custom workflows you've created.
In this tutorial we'll:
- Update a workflow so that its rules are applied to a content type
- Review the list of permissions provided by a workflow and see how we can set things up to restrict certain users to only perform specific transitions
By the end of this tutorial you will be able to configure a workflow so that it applies to one or more content types, and configure permissions so only users in a specific role can transition content items from one state to another.
When building views of moderated content there are some important things to be aware of. One is the difference between choosing Content or Content revisions as the base for your view. You should also know about some fields and filters added by the Content Moderation module.
In this tutorial we'll:
- Understand when, and why, to choose Content revisions as the base for your view instead of Content
- Learn about the fields, and filters, added by the Content Moderation module
- Learn how to update the view at admin/content/moderate that comes with the Content Moderation module to make it work with any workflow.
By the end of this tutorial you should understand the important concepts necessary to create views of moderated content.
What Are Revisions?
FreeDrupal has had revisions for a long, long time. However, they have often been under-utilized. Understanding how revisions work and how the Content Moderation module works with them is important to for being able to take full advantage of the systems features.
In this tutorial we'll:
- Explain what the different types of revisions are
- Understand when, and how, revisions are created
By the end of this tutorial you should have an understanding of what each type of revision is, how they're created, and how to work with them.
The Workflows and Content Moderation modules allow an editorial team to put any type of content administered in Drupal through a customized editorial workflow and moderation process. Workflow states, such as draft, ready for review, or approved are defined using the Workflows module. The ability to attach moderation states to entity bundles -- a common example being content types -- is configurable by the Content Moderation module.
Both modules have stable releases and are perfectly safe to use in production.
In this tutorial we'll:
- Learn about the use case for Workflows and Content Moderation modules
- Define the role that each module performs
- Define some common terms you'll need to understand when working with these two modules
By the end of this tutorial you will have a good understanding of what the Workflows and Content Moderation modules are, what different functionality they provide, and the permissions made available by the modules.
Every Drupal module needs a *.info.yml file; the basic structure of a form controller class and related routing is the same for every form; and much of the code required to create a custom content entity type is boilerplate annotations and extending base classes. Wouldn't it be nice if there was a way to automate some of that repetitive work? Drush can be used to speed up module development by generating scaffolding code for event subscribers, forms, services, module files, routing, and much more. These generators are provided by the Drupal Code Generator project. They're neatly bundled up in Drush under the drush generate
command.
Before Drush 9, there were no code generators in Drush, but the Drupal Console project provided them. That project and its code generators, have languished since the release of Drupal 9. While it can still be used, and is often referenced in tutorials about Drupal, we much prefer the code generated by Drush at this point.
In this tutorial we'll:
- Learn about the Drupal Code Generator project
- Learn how Drush integrates with this project
- Demonstrate the
drush generate
command and its options
By the end of this tutorial, you'll know how to use the drush generate
command to speed up development for your Drupal modules.
A multisite Drupal installation allows you to host multiple, separate websites while relying on the same set of code. Large organizations often rely on a multisite installation to cut down on the operational upkeep of multiple sites. Hosting a multisite in Docker poses several additional challenges. Fortunately, the process is not dissimilar from configuring a bare-metal server to run a multisite.
In this tutorial, we'll:
- Outline a multisite's additional requirements for Docker containers.
- Configure alternate, local domain names to resolve each site.
- Learn how to configure a multisite to use alternate domain names.
This tutorial teaches you everything you need to know about using the tutorials on Drupalize.Me.
Drush is the command line shell and Unix scripting interface for Drupal. The most common way to install Drush is to install it on a per-project basis using Composer. We'll walk through the steps to do that, as well as how to set up the Drush Launcher tool (to make it possible to execute Drush commands without having to specify a full path to the executable).
In this tutorial we'll:
- Install Drush
- Verify it worked
By the end of this tutorial you'll have Drush installed.
Installing Drupal using the instructions in this tutorial will give you a working Drupal site that can be used for learning, or real-world project development.
Before you can work on a Drupal site locally (on your computer), you'll need to set up a local development environment. This includes all the system requirements like PHP and a web server, that Drupal needs in order to run. Our favorite way to accomplish this is using DDEV.
In this tutorial we'll learn:
- How to install and configure DDEV for use with a Drupal project.
- How to use DDEV's integrated Composer to download Drupal and Drush.
- How to install Drupal inside DDEV so you can access the site and start doing development.
By the end of this tutorial, you should be able to set up a local development environment for learning Drupal or working on a new Drupal project.
Standardized documentation is crucial to a project, whether it is just you or an entire team working on it. In this tutorial we're going to look at:
- Standards for
@docblock
comments - Standards for inline comments
- Why standards for documentation and comments are as important as standards for the rest of your code.
By the end of this tutorial you'll know how to add inline documentation for all the PHP code that you write for Drupal.
Formatting standards cover things like the use of whitespace, how to format control structures, and other aspects that affect your code's appearance and format.
In this tutorial we’ll talk specifically about standards regarding formatting. This is by no means an exhaustive list of PHP syntax rules, but rather is focused on formatting standards for Drupal.
By the end of this tutorial you'll know about the most common Drupal code formatting standards as well as where to find more information when questions arise.
Translations have their own special functions in both Drupal 7 and 8, and there are some rules for standardizing how they are used that make things clearer for everyone.
In this tutorial we'll look at:
- When to use, and when not to use, translation utilities to output translatable strings
- How placeholders work in translatable strings
- Tips for creating links inside of translatable strings
By the end of this tutorial you should know when, and how, to make strings in your code translatable using Drupal's translation utility functions.
Once you know what code standards are and why you should use them, you need to learn how to implement Drupal coding standards in your projects. This tutorial will walk through some of the steps you can take to make this as easy as possible. We'll cover:
- Configuring your editor or IDE to warn you of coding standards violations
- Setting up the Coder module and phpcs to scan and review your code
- Performing team code reviews
By the end of this tutorial you should be able to configure your development environment and implement processes in your workflow that help to ensure your code meets Drupal's coding standards guidelines.
Drupal core uses object-oriented programming (OOP). This method of programming introduces new coding standards to the project. In this tutorial we'll cover the Drupal coding standards that relate to object-oriented PHP code.
By the end of this tutorial you should know how to implement the Drupal coding standards related to OOP, and where to find more information when you've got questions about the standards.
Before you dive into using coding standards it makes sense to understand exactly what they are and why they’re important, generally and specifically in the Drupal community. In this tutorial we will look at:
- What coding standards are
- Why following coding standards is a good idea
- Where coding standards come from
By the end of this tutorial you'll have a better understanding of what coding standards are, and why you should be adhering to them when you write code.
Every Composer project is made up of a few standard files and directories. This tutorial provides an overview of the anatomy of a Composer project, and the essential files and directories used by Composer, including:
- What are composer.json and composer.lock files?
- What is in a composer.json file?
- What is the /vendor directory?
By the end of this tutorial you should be able to recognize the standard files and directories in a Composer project and know what they are each used for.
This tutorial demonstrates the value of using Composer. This demonstration will employ the most basic use case of using Composer to create a new, non-Drupal application that writes a message to the system log. It will encompass the fundamental concepts of Composer installation, requiring (installing) a new dependency, autoloading it, and implementing it.
In this tutorial we'll:
- Install Composer
- Use Composer to start a new project
- Use Composer to require a 3rd party dependency
- Use the required code in an example application
By the end of this tutorial you should be able to explain the value of Composer, and have Composer installed and working on your local machine.
This tutorial provides an overview of the concept of an "artifact" and provides step-by-step instructions for deploying a Composer-managed Drupal application to a hosting environment.
In this tutorial we'll:
- Define what an "artifact" is
- Look at how to use Composer and a build process to create and deploy an artifact
- Talk about the benefits of this approach
By the end of this tutorial you should have a general understanding of the steps required in order to deploy a Composer-managed project into production.
You will inevitably encounter Composer issues that require troubleshooting. This tutorial aims to provide some general troubleshooting advice for common Composer issues.
In this tutorial we'll look at:
- Common issues you'll encounter when using Composer
- Solutions to these common issues
By the end of this tutorial you should have some ideas of how to solve common issues that you might encounter when using Composer to manager your application's dependencies.