Acquia Developer (D10) key terms

A structured PHP array that describes output to be rendered by Drupal's render system, using keys like #theme, #markup, and #cache. It is lazy, cacheable, and alterable before being converted to HTML.

The set of cache tags, cache contexts, and max-age values attached to render arrays and responses that tell Drupal how output varies and when it must be invalidated. Correct metadata is essential for safe caching.

A string identifier attached to cached data that names the underlying content or configuration it depends on, such as node:5. When that dependency changes, Drupal invalidates every cache entry carrying the tag.

A declared variation axis, such as user.roles or url.query_args, that causes Drupal to store separate cached copies per value. Missing contexts leak personalized content; excess contexts fragment the cache.

A core caching layer that stores fully assembled pages with placeholders for uncacheable parts, then substitutes those parts per request. It lets anonymous and authenticated pages be reused while keeping personalized fragments correct.

A core performance technique that sends a cached page shell first and streams placeholder replacements for uncacheable content later over the same response. Perceived load time improves because the main layout arrives immediately.

A file using the Twig syntax that produces themed markup in Drupal's theme layer, with autoescaping and a restricted set of allowed functions, filters, and tags. Templates are discovered by naming convention and can be overridden per theme.

A theme or module function named for a theme hook, such as mytheme_preprocess_node, that runs before a Twig template renders and adds or alters variables available to that template.

An additional, more specific theme hook name offered as an alternative template, such as node__article or block__footer. Suggestions let themes target narrow cases without duplicating broad templates.

A named extension point, conventionally prefixed with the module name, that Drupal invokes so modules can react to or alter core behavior. Implementations are discovered by function naming or attributes and cached in the registry.

Drupal's dependency injection registry that maps service names to class definitions and instantiates them as shared objects. Services are declared in a module's services.yml file and requested through the container or injected into controllers and plugins.

A design pattern where an object receives its collaborators from outside instead of constructing them, expressed in Drupal through create() methods and container injection. It improves testability and lets services be swapped.

A swappable, annotated or attributed class managed by a plugin manager, used for blocks, field types, formatters, and many other extensible components. Plugins are discovered by scanning declared namespaces and configured per instance.

The service responsible for discovering, instantiating, and caching plugin definitions for one plugin type. Developers usually obtain it from the container and call createInstance() with a specific plugin ID.

A definition of a kind of data object in Drupal, such as node or taxonomy_term, including its bundles, base fields, storage, and handlers. Entity types are declared in code and managed by the entity type manager.

A named subtype of a content entity type, such as an Article content type under node, that carries its own fields and display settings. Bundles let one entity type serve multiple content models.

A field defined in code as part of an entity type or bundle rather than through the UI, so it exists on every installation and cannot be deleted. Base fields are declared with a BaseFieldDefinition in the entity class.

A field created through the user interface or configuration import, stored as configuration and attached to a bundle. It can be exported, edited, and deleted without code changes.

Drupal's system for exporting site configuration to YAML files and importing it into another environment. It supports reviewable, repeatable deployments of settings that are not content.

An entity type whose instances are stored as configuration rather than content, such as views, roles, or content types. Config entities are exported with configuration management and are not fieldable in the usual content sense.

A numbered function in a module's .install file, such as mymodule_update_9001, that runs once during database updates to migrate data or schema. Update hooks carry changes that configuration import cannot express.

The ordered set of automated stages, typically build, test, artifact creation, and deploy, that moves code and configuration from a repository to an environment. Acquia pipelines run these stages from a Git branch.

Acquia's hosted Drupal environment offering per-environment infrastructure, Git-based code deployment, and tooling for databases, files, and logs. Environments are typically separated into development, staging, and production tiers.

Acquia's continuous integration and delivery service built on GitLab, providing automated testing, artifact builds, and deployment to Acquia environments. It is configured through a pipeline definition in the repository.

A browser-based development environment provided by Acquia that runs against a cloud application's branch, with the codebase and tooling preconfigured. It avoids local setup drift but is not a substitute for production configuration.

An intermediary server, such as Acquia's Varnish layer, that caches HTTP responses in front of the Drupal application and serves repeated anonymous requests without invoking PHP. Correct cache headers determine what it can store.

An object returned by permission checks that records allowed, forbidden, or neutral plus cacheability metadata and the reason. Access results are combined across hooks so modules can grant or deny without overwriting each other.

A per-session value embedded in state-changing forms and links so the server can verify the request originated from the site. Drupal generates and validates these tokens through its form and routing APIs.

Drupal's structured system for building, validating, and processing forms as render arrays, with automatic token checking, submission handlers, and reusable element types. Forms are classes or functions returning an array with a form ID.

A programmatic query builder for finding entity IDs by field conditions, used instead of raw SQL so storage and access behavior stay consistent. Results are typically loaded afterward through the entity type manager.

Drupal's wrapper over PDO that provides a query builder, tagged queries other modules can alter, and support for multiple database drivers. It discourages raw SQL and encourages parameterized conditions.

The older Drupal mechanism where plugin classes carry docblock annotations read by the plugin manager to build definitions. Drupal 10.2 and later also support PHP attributes as the preferred alternative.

A service class registered in services.yml that listens for Symfony events, such as kernel request or response, and runs code when they fire. Subscribers replace several procedural hooks for request-lifecycle work.

A cached index of which modules implement which hooks, built by scanning code. It must be rebuilt after adding a hook implementation, which is why clearing caches is required during development.

The command-line interface for Drupal used to clear caches, run database updates, import configuration, and generate boilerplate code. Acquia environments expose it for remote commands against a specific environment.

A contributed module pattern for keeping some configuration active only in certain environments, such as development modules or API keys. It complements configuration management by dividing config into environment-specific sets.

A named rendering unit, such as item_list or table, that maps to a Twig template or theme function and accepts a defined set of variables. Modules declare theme hooks so other code can render consistent output.