Moving Drupal Blocks on Mobile: CSS, Regions, and Safer Tradeoffs

By Greg Nowak. Last updated 2026-07-06.

A Drupal block that works well on desktop can become nearly invisible on a phone. A newsletter signup, contact CTA, filter panel, login box, or campaign message may be useful in a sidebar, but on mobile it can fall below the content that actually creates the inquiry, sale, or support outcome.

The practical question is not simply “how do we move this block?” It is “how do we improve the mobile journey without creating a maintenance problem for editors and developers later?” On current Drupal sites, the answer is usually simpler than older tutorials suggest. You do not need a breakpoint management module just to change layout. Drupal breakpoint files matter when Drupal itself needs breakpoint data, such as responsive image handling. If the change is only visual layout, start with theme CSS.

Choose the smallest reliable fix

Before adding regions or duplicate block placements, name the real business problem. Is the same content appearing too late? Does mobile need a shorter version? Do editors need control per landing page? Those are different implementation decisions.

Mobile requirement	Best fit	Watch out for
Same block, better reading order	CSS flex or grid ordering	Visual order should not confuse keyboard or screen reader users
Block belongs in a new structural spot	Add a theme region and place a block there	Region changes need template updates and cache rebuilds
Mobile needs different copy or a simpler CTA	Separate mobile block placement	Avoid duplicating complex forms or personalized output
Editors need page-by-page control	Layout Builder or a content-managed layout pattern	Define governance so every page does not drift

A practical decision matrix for moving Drupal blocks on smaller screens.

Option 1: Keep one block and reorder it with CSS

If the content is the same, keeping one block placement is usually the cleanest route. It preserves the existing block configuration, form behavior, caching, analytics hooks, and personalization logic. The theme simply changes where that rendered region appears at a mobile breakpoint.

For example, a desktop layout might show content beside a sidebar, while mobile should show the main content first and the sidebar CTA immediately after it:

@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 exact selectors depend on the theme, but the rule of thumb is stable: reorder layout wrappers, not the business logic behind the block. If your theme already uses Bootstrap 5.3, responsive flex and order utilities can handle simple cases. If not, a small theme stylesheet is usually enough.

There is one important accessibility caveat. CSS ordering changes visual order, not the document or focus order. That is fine for modest presentation changes, but it can become confusing if a keyboard user, screen reader user, and sighted mouse user experience the same page in different logical sequences. Keep the source order sensible, then use CSS to make a good source order work better visually.

Option 2: Add a dedicated mobile region

Sometimes a visual reorder is not enough. A mobile CTA may need to appear directly below the header, while the desktop version still belongs in a sidebar. In that case, create a dedicated theme region and place a mobile-specific block into it.

Add the region to THEMENAME.info.yml:

regions:
  header: Header
  content: Content
  sidebar_first: Sidebar first
  mobile_after_header: Mobile after header
  footer: Footer

Then print that region in the relevant page template, usually page.html.twig or a page template variant:

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

Be careful here: once a theme declares regions, it is responsible for the regions it needs. Do not accidentally remove existing regions from the theme definition, and do not remove Drupal’s hidden page_top and page_bottom output from html.html.twig, because modules may depend on them.

After the theme change, rebuild caches with drush cr. Then go to admin/structure/block, select the active front-end theme, and place the block in the new region. Block placement is theme-specific, so checking the correct theme saves a lot of false debugging.

When duplicate block placements make sense

Drupal allows multiple copies of a block, each with its own configuration and visibility rules. That is useful for plain editorial or promotional blocks: one long desktop block in the sidebar, one shorter mobile block near the top of the page.

I would be more cautious with forms, exposed filters, cart widgets, login elements, or personalized components. Rendering two versions can create awkward validation, tracking, cache, or state issues. For those, one rendered block plus CSS reordering is usually safer.

If you do use separate desktop and mobile placements, use Drupal visibility rules for page logic, roles, and content sections. Use CSS for viewport display rules:

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

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

How I would ship this

Start with the mobile user journey, not the region list.
Use CSS reordering when the content is the same and only the sequence changes.
Add a mobile region when the block needs a genuinely different structural position.
Duplicate simple content blocks only when the editorial benefit is clear.
Document the breakpoint, region name, and reason for the decision in the handoff notes.

That keeps the implementation understandable for the next developer and practical for the people running the site. If this block move is part of a broader Drupal cleanup, redesign, or agency delivery plan, Greg can help turn the layout decision into a clean, testable implementation plan.