Moving Drupal Blocks on Mobile: When to Use CSS, Regions, or Separate Placements

By Greg Nowak. Last updated 7 August 2026.

A Drupal block can work perfectly in a desktop sidebar and become practically invisible on a phone. Contact prompts, campaign messages, filters, login controls, and newsletter forms often end up below the content that was supposed to generate the inquiry or help the visitor complete a task.

The technical question is how to move the block. The more useful business question is how to improve the mobile journey without leaving editors and developers with a fragile layout. In most cases, the safest answer is one of three options: reorder one rendered block with CSS, add a theme region, or create a separate placement for genuinely different mobile content.

Start with the content requirement

Do not begin by creating a “mobile” region. First decide whether mobile visitors need the same content in a better position, a different structural position, or different content altogether. That distinction keeps a modest layout adjustment from becoming unnecessary Drupal configuration.

Requirement	Recommended approach	Main risk
The same block should appear earlier on mobile	Reorder existing layout wrappers with CSS	Visual and keyboard reading orders may diverge
The block needs a distinct position in the page structure	Add a theme region	Incomplete region definitions can disable existing placements
Mobile needs shorter copy or a different offer	Create a separate block placement	Editors must maintain two versions
Editors need per-page layout control	Use Layout Builder or an established component pattern	Pages can drift without layout governance

A decision matrix for choosing the smallest reliable Drupal block change.

Option 1: Reorder one block with CSS

If the content and behaviour remain the same, keep one block placement. This preserves its Drupal configuration, cache behaviour, form state, analytics hooks, and personalization. The theme changes only the position of the surrounding layout region.

For example, a desktop page may place the main content beside a sidebar, while the mobile layout should show the content first, a featured call to action second, and the remaining sidebar last:

@media (max-width: 767.98px) {
  .layout-shell {
    display: flex;
    flex-direction: column;
  }

  .region-content { order: 1; }
  .region-featured { order: 2; }
  .region-sidebar-first { order: 3; }
}

The breakpoint above matches a common Bootstrap boundary; it is not a universal Drupal value. Use the breakpoint already established by the site’s theme and test where the actual layout stops working. If the theme uses Bootstrap 5.3, its responsive order utilities may be enough. Otherwise, a small rule in the theme stylesheet is clearer than adding another module.

Drupal breakpoint YAML is only required when Drupal itself needs breakpoint metadata—for example, when configuring responsive images. A CSS-only layout change does not need a new THEMENAME.breakpoints.yml entry.

Keep the source order meaningful

CSS order changes visual presentation, not DOM or keyboard focus order. A visitor may therefore see the CTA before a form while a keyboard or screen-reader user reaches it afterward. Start with a sensible source order and use CSS only for modest adjustments. If the mobile design requires a radically different sequence of interactive elements, change the template structure instead.

Option 2: Add a dedicated theme region

A new region is appropriate when the block needs a real structural home—for example, a campaign message immediately below the header across a defined set of pages. Add the region to the theme’s existing region list in THEMENAME.info.yml:

regions:
  mobile_after_header: 'Mobile after header'

That snippet shows the new entry, not a complete region definition. When a theme declares any regions, Drupal expects it to declare every visible region the theme needs. Preserve the existing entries or previously placed blocks may become disabled after the cache rebuild.

Print the new region in page.html.twig or the appropriate page template variant:

{% if page.mobile_after_header %}
  {{ page.mobile_after_header }}
{% endif %}

Retain Drupal’s hidden page_top and page_bottom output in html.html.twig; modules can depend on it. Rebuild caches with drush cr, then open admin/structure/block, select the active front-end theme, and place the block in the new region. Block placement is theme-specific, which is an easy detail to miss during agency handoffs.

When separate desktop and mobile placements are justified

Separate placements can be useful for simple editorial content: a detailed desktop promotion in the sidebar and a shorter mobile prompt near the top. Give both versions clear administrative names and assign page, role, or content visibility rules in Drupal.

Avoid duplicating forms, exposed filters, cart controls, login components, or personalized blocks unless their behaviour has been tested carefully. Rendering two instances can introduce duplicate element IDs, confusing validation, extra server work, or double-counted analytics. For functional components, one block with a better source position is generally safer.

If both editorial blocks are rendered and CSS controls their viewport visibility, add stable wrapper classes through the theme and document them:

@media (max-width: 767.98px) {
  .block-desktop-only { display: none; }
}

@media (min-width: 768px) {
  .block-mobile-only { display: none; }
}

Do not try to make Drupal’s server-side visibility rules detect viewport width. Viewport presentation belongs in CSS; Drupal visibility rules are better suited to routes, content types, roles, and other information the server actually knows.

A practical release checklist

Confirm the business goal and intended mobile sequence before changing templates.
Test narrow, intermediate, and wide layouts—not only one phone-sized screenshot.
Check keyboard focus, screen-reader reading order, forms, and analytics events.
Verify authenticated, personalized, and cached versions where applicable.
Export Drupal configuration and document the region, breakpoint, selectors, and rationale.

The best solution is usually the smallest one that keeps the page understandable in both the browser and Drupal administration. If a block move is part of a wider redesign, platform cleanup, or agency delivery, Greg can help turn the requirement into a maintainable implementation plan.