Why I built it
In many Drupal setups using the Dashboards with Layout Builder module (or similar), you create dashboards made up of blocks that display live-data: charts, metrics, feeds, system status, etc. While the blocks update when the page reloads, often there is a need for real-time or near-real-time updates without forcing a full page refresh.
So I built dashboards_auto_refresh to fill that gap: to enable dashboard panels (blocks) to auto-reload their markup/content at a specified interval, excluding certain blocks if desired, and providing a clean endpoint to fetch updated markup for each block.
In short: keep the dashboard page loaded, but refresh the blocks inside it continuously. This improves the UX for dashboards showing time-sensitive data, without reinventing everything or building a custom front-end polling/dashboard system.
What it does
Here are the core features of the module:
It provides a mechanism to automatically refresh specified blocks within a dashboard layout. (From the README: “Automatically refreshes specified blocks within dashboards.”) GitHub
It allows excluding certain blocks from refreshing (based on their block IDs) so you don’t reload everything — only what makes sense. GitHub
It exposes a configurable controller endpoint to fetch the fresh block markup (rendered server side) so the JavaScript polling logic can swap it in. GitHub
It integrates with the dashboard page by attaching a JS library and doing preprocessing (block attributes) to mark which blocks are auto-refresh enabled.
It is built in PHP (Drupal module) plus a JS behaviour (polling) to trigger the periodic refresh.
It is designed to work with dashboards created via “Dashboards with Layout Builder” (or similar) and leverages Drupal’s block system.
So from a user/admin standpoint: once the module is enabled (in modules/custom etc), you configure which blocks or dashboard pages should refresh, define the refresh interval, and the behaviours automatically keep those blocks fresh.
How it works – Code snippets
Here are some key parts of the implementation to illustrate how it’s done.
Block preprocessing
In dashboards_auto_refresh.module there is a hook implementation:
This ensures each block that should auto-refresh gets a data-dashboards-auto-refresh="true" attribute and a unique ID so the front-end JS can identify it and call the controller.
Attaching the JS library
Still in the module file there is something like:
This attaches the polling JavaScript library to every page (or only dashboard pages if conditional) so the client-side behaviour is available.
Controller endpoint for fetching block markup
In src/Controller/DashboardsAutoRefreshController.php something like:
This disables page caching for the refresh request (so you always get fresh markup), then uses Drupal’s block plugin system to build/render the block directly, and returns the markup to the caller.
JavaScript polling logic (polling.js)
The JS behaviour collects all panels with data-dashboards‐auto‐refresh="true", then does:
Thus at a configured interval (e.g., every 30 seconds) each eligible panel is refreshed by fetching fresh HTML and swapping the innerHTML.
Summary
By building dashboards_auto_refresh, you’ve created a lightweight extension that brings real-time behaviour to Drupal dashboards made with “Dashboards with Layout Builder” (or similar). It keeps your dashboard UI alive and dynamic without drastically changing the stack. Blocks eligible for refresh get marked up, a server endpoint is provided for fetching fresh markup, and client-side JS polls and swaps in updated content.
This is especially useful in contexts where dashboards show live metrics, system status, or data streams, and you want a “dashboard stays open and updates” experience rather than “refresh the whole page”.