Skip to content

Powered by Grav

Adding modules to your Backdrop site

Adding modules to your Backdrop site

Backdrop keeps this simpler than Drupal 7 did — one folder is yours, it already exists, and code you put there wins.

Where your modules go

sites/<yourdomain>/modules/ is the place. It's created writable for your shell and SFTP user on every site, no unlocking needed, and it's the last place Backdrop looks when scanning for modules — so anything you put there outranks the platform's own copies. Your uploads are never swept: the nightly housekeeping removes only leftover .tar/.zip archives (unpack, then let it tidy the wrapper), and none of BOA's Drupal module enforcement applies to Backdrop sites — nothing here force-enables or force-disables your modules.

Two places that look right and aren't:

  • sites/all/modules does not work on Backdrop. Unlike Drupal, Backdrop has no sites/all layer at all. The folder exists here (BOA keeps platform control files in it), and the panel's package listing will even report a module placed there — but Backdrop itself never loads code from it. A module uploaded there is a silent no-op.
  • The platform's root modules/ is BOA's. That's where the shared contrib bundle lives (today it delivers the Valkey/Redis cache module to every Backdrop platform — already wired, nothing to enable). It's maintained together with the platform; your additions belong in your site's own folder, which outranks it anyway.

One practical note: your site folder itself (the parent of modules/) isn't writable — you can't create sibling folders next to modules/. To replace a module, delete the old copy rather than trying to park it.

Three ways to get a module in

  • bee download from your shell. Connect as your shell user, cd into the site directory (as its own command — the limited shell refuses cd … && … one-liners), and:

    SH
    bee download webform
    

    It fetches the newest release from the Backdrop project server straight into your site's modules/ folder. Then bee enable webform and you're done.

  • SFTP upload. Put the unpacked module folder into ~/platforms/<NNN>/<platform>/<yourdomain>/modules/. Same place, same result.
  • Backdrop's own UI. Functionality → Install new modules works too, and writes to the same folder.

Not every Backdrop port is packaged the same way: most live on the Backdrop project server with proper releases (bee download finds those), a few exist only as Git repositories, and some Drupal 7 staples need no port at all — ctools is the famous example, whose Backdrop project page says it plainly: core has covered its tools since 1.0, and there is no reason to install it.

Filling a port gap after a Drupal 7 upgrade

The Drupal 7 upgrade leaves a module without a present port disabled on the copy, with its data tables kept. Filling that gap afterwards is a short routine — worked example with Webform, which has a full Backdrop port:

  1. Delete the Drupal 7 copy from the new site's modules/ folder — the conversion carried it over as files, and it must not sit next to the port. Your original is safe: the Drupal 7 site still holds it.

    SH
    rm -rf modules/webform
    
  2. Download the port, from the site directory:

    SH
    bee download webform
    
  3. Enable it and run the database updates:

    SH
    bee enable webform
    bee updb -y
    

    This is where the kept data pays off: the module's tables still carry their Drupal 7 schema, and the update run converts them — the port's updates apply from exactly where Drupal 7 left off, and your data comes out the other side as native Backdrop content.

Order matters: replace the code first, then enable. bee enable doesn't check compatibility — it will happily enable the leftover Drupal 7 copy on your Backdrop site, which plants a landmine that detonates on whatever page first touches the module's code. If that's already happened, disable it, replace the code as above, and update.

Where to go next

© 2026 BOA Documentation. All rights reserved.