drupal-blocks

Reusable Drupal blocks require region-agnostic machine names, code-based storage, and explicit caching guidance. Design blocks with portable naming conventions that omit region and block_ prefixes, mirror field structures to node/paragraph standards, and document view modes and caching expectations to ensure consistency across environments.

Use concise, region-independent machine names and admin labels that avoid prefixes tied to deployment context. Omit region and block_ designations in naming to ensure blocks remain portable when moved between sites or environments without requiring reconfiguration.

Structure block fields to mirror node and paragraph field patterns, maintaining consistency across content types. Define explicit view modes for each block display variant and document which view modes apply to specific contexts, enabling reuse across different page layouts.

Define explicit caching expectations for each block type, documenting cache invalidation triggers and lifetimes. Avoid UUID-bound content and region-specific dependencies to ensure caching logic remains valid when blocks are reused or deployed to new environments.

Yes. Code-based block storage ensures portability and version control. Store block type definitions, configurations, and plugin code in your codebase to maintain consistency across environments and enable reliable deployment without database synchronization.

UUID-bound content ties blocks to specific entities or references, breaking reusability when blocks move between sites or environments. Design blocks with content-agnostic references and configuration to remain functional across contexts without external entity dependencies.