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/modulesdoes not work on Backdrop. Unlike Drupal, Backdrop has nosites/alllayer 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 downloadfrom your shell. Connect as your shell user,cdinto the site directory (as its own command — the limited shell refusescd … && …one-liners), and:SHbee download webformIt fetches the newest release from the Backdrop project server straight into your site's
modules/folder. Thenbee enable webformand 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:
-
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.SHrm -rf modules/webform -
Download the port, from the site directory:
SHbee download webform -
Enable it and run the database updates:
SHbee enable webform bee updb -yThis 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
- Your Backdrop site, day to day — bee, configuration and what BOA already handles.
- Upgrading from Drupal 7 — the module compatibility report that tells you which gaps you'll have.
- Modules BOA manages — the Drupal-side module policy, none of which applies here.