Advertising sustains the DA. Ads are hidden for members. Join today

Glossary

Last updated on
29 August 2022
DRD
Short for Drupal Remote Dashboard refers to the DRD module.
DRD Site
The Drupal site that has the main DRD module installed and offers the dashboard.
Agent
The agent is the DRD Agent module and refers to the code which is installed on all the monitored remote Drupal sites. Note: of course you can also monitor the DRD Site itself, which is not really remote but falls under the same category.
Remote Site
All the Drupal sites that are monitored by DRD, each of them has to have the Agent installed and enabled.
Dashboard
The dashboard is the content that the DRD module displays to the administrators. It comes with several pages like a list of hosts, list of cores, list of domains, list of projects and all other pages like details about the DRD Entities.
DRD Entities
DRD is build around entities such that you can use all the Drupal APIs that are available (e.g. fields, views, rules, etc.), to enhance the functionality. The entity types coming with DRD are hosts, cores, domains, projects, majors, releases and requirements - all individually explained below.
Host
A host is a server, virtual or physical. By default a host can be recognised just as a container that helps you to group Drupal installations together but it is recommended to define a host entity for each host or entity that you also manage in real live. In advanced environments you can define the full paths for Drush and DrupalConsole for each host, which will then provide more enhanced functionality for all cores and domains on that host. Also, if you enable SSH support on your DRD site you can provide SSH credentials on a per host basis which will also enhance the feature set available for those hosts, their cores and domains.
Core
A Drupal installation on a host, each host can and usually does have multiple Drupal installations. Each core hosts at least one Drupal site but can also host multiple sites at once - it depends on your requirements and setup and DRD does not force you to go for one or the other philosophy. Each core has a Drupal core version and any number of additional projects (modules and themes) that are either available "globally" for each contained domain or on a per-domain basis, depending on where you've installed the files.
Domain
A Drupal domain hosted inside of a core. DRD is able to recognize all the domains and it doesn't really matter how they are configured. However, if you wanted to help DRD to better deal with your setup, you should refer to the configuration section for more details.
Project
This is a project like Drupal core, module or theme. Each project has a number of releases and those are grouped together as major versions such that the update status information for each project can be determined and displayed for any number of different major versions, i.e. for each Drupal core separately and even within each core version there may be multiple major versions like e.g. 7.x-1.1 and 7.x-2.0 for a module with major versions 1 and 2 for Drupal 7 in this particular example.
Major
A major version of a project. This is a DRD entity that just links releases to their related projects. Those are not really visible at the front end but play a signifiant role in the background of DRD functionality.
Release
A release within a major version of a project. Each release has individual update status information and of course many different release of each project can be installed on all the domains that your DRD is monitoring.
Requirement
All the items from the status page of any Drupal site. For now, DRD collects all the requirements from all of the remote sites and uses them to determine the status information but doesn't do anything else with them. That may be changing in the future.
Headers
DRD communicates with all the Agents through HTTP requests using the Guzzle library (provided by Drupal 8 core). For each request it adds a number of headers internally and you can also define additional headers that will be added to each request if required. This allows you e.g. to also use DRD even if your remote sites are behind Basic Auth or require a proxy. You can define such headers either on host, core or domain level and DRD grabs the most specific setting for each of the defined headers.
Action
Actions are provided by DRD and depending on their functionality can be executed on the DRD system globally or on hosts, cores or domains. Those actions are developed as plugins and can also be used together with the Rules module or with one of Drupal's CLIs, e.g. Drush and DrupalConsole.
Queue
When you execute Actions from the UI, they are not executed directly. Instead they get queued and will be executed by cron or other triggers, that work on Drupal's queue. This has been done to make sure that your interface stays responsive and longer running tasks never lock it up. If you want to have more control over the DRD specific queue it is recommended to install the Queue UI module. However, if you execute the actions via one of the CLI tools, those won't be queued but executed directly.

Help improve this page

Page status: No known problems

You can: