►
Description
Configuration management in Backdrop CMS - Backdrop Mini-Camp
Twin Cities Drupal Camp, 2019
By Jen Lampton
A
B
A
A
A
One
of
the
things
that
you
can
do
with
config
files-
if
you
don't
want
to
manage
them,
if
get
as
manage
them
using
backdrops
user
interface,
which
is
what's
built-in,
there's
a
way
that
you
can
do
an
export
of
an
individual
file.
So
if
you
make
a
change
on
a
local
site
and
need
to
deploy
it,
you
can
make
a
change
on
a
local
site,
use
this
interface
to
pull
out.
This
is
what
Nate
did
this
morning.
I,
don't
know
some
custom
block
content.
A
Here
we
go
whatever
your
skills
are
and
you
can
deploy
that
to
another
site.
You
can
also
do
an
export
of
your
entire
site.
So
if
you
spend
a
whole
week,
building
content
types
and
views
and
doing
a
whole
bunch
of
different
stuff,
you
mean
your
your
whole
site
at
once,
and
if
you
do
an
expert
here,
it'll
deliver
to
you
a
tarball
and
when
you
get
onto
your
other
site,
let's
see
this
is
Chrome,
so
this
is
actually
my
live
site.
You
can
then
import
using
the
same
interface.
A
So
it
gives
you
a
way
to
do
a
single
file
or
a
whole
lot
of
files.
There's
a
currently
an
issue
to
do
collections
of
files,
which
would
add
something
more
like
feature,
so
you
can
be
like
here's,
a
content,
type
and
view
package
together.
Here's
one
more
thing
about
calling
them
rust
beats
right.
Now
we
can
only
do
an
individual
file
or
entire
site.
A
We
can't
do
a
subset,
but
we
want
to
be
able
to
make
it
so
that
you
can
do
subsets
too
through
the
user
interface
I,
however,
only
have
one
site
where
I
manage
config
to
the
user
interface
and
its
Pantheon
site
and
I'm
doing
a
Pantheon
site
to
the
user
interface,
because
Pantheon
makes
it
hard
to
manage
your
config
in
version
control.
You
can't
have
a
writable
directory,
that's
not
your
files
directory,
and
so
you
have
to
put
your
config
files
in
your
files
and
so
because
you're
managing
is
part
of
your
files.
A
It's
easiest
to
just
let
them
be
treated
like
files
and
not
have
them
in
version
control,
because
your
files
is
never
in
version
control,
but
there
are
some
workarounds
with
Fantan
you
where
you
can
commit
your
staging
directory
and
not
your
active
directory,
and
it's
fine
and
I've
done
that
a
some
sites
there
too,
but
once
I
use
UI
all
the
other
sites.
I
manage
one
of
two
ways.
A
This
is
my
personal
site
I'm
using
an
example,
because
I
am
one
person
that
maintains
this
site
and
I
have
a
very
specific
workflow
about
how
I
do
it,
and
this
is
actually
on
this
website.
Tim
reminded
me
that
I
wrote
this
blog
post
yesterday
and
I'd
forgotten
that
I'd
written
it
before
that,
but
it
basically
explains
what
my
file
system
looks
like,
where
the
configuration
files
are
in
relation
to
the
web
root,
which
is
usually
outside,
but
right
next
to
it
and
how
I
have
two
directories
and
there
both
of
them
are
named
active.
A
So
when
you
install
backdrop,
you
get
one
directory
called
active
and
one
directory
called
staging,
and
that
works
great
for
a
single
site.
When
you
have
multiple
sites
and
you
need
to
switch
configuration
between
the
two
of
them,
what
I
end
up
doing
is
having
a
directory
for
each
instance
of
the
site,
so
this
particular
site
I
have
one
copy
on
my
laptop
I.
Have
one
copy
on
a
sir
I:
don't
have
a
beta
site
and
on
a
dev
test,
it's
just
two
sites.
It's
not
very
complicated,
I
feel
like
I.
A
Don't
need
all
the
different
layers
if
I
break
it,
that's
fine
I'll
figure
it
out
and
fix
it,
I'm
the
only
one
that
cares
and
usually
I,
don't
care.
So
it's
fine
low
risk.
So,
in
this
case,
I
have
two
directories.
One
of
them
is
def
active.
This
is
the
directory
that
my
local
site,
my
dev
site,
is
using
as
its
active
directory.
The
other
directory
proud
active
is
the
one
at
my
production
site
is
using
its
active
directory.
A
The
alternate
ones
are
staging
on
each
direction
on
each
site,
and
so
when
I
do
a
git
pull.
This
is
what
I
call
the
figure
8
method
I'll
ssh
into
my
live
server
and
I'll.
Do
a
git,
pull
and
it'll
pull
the
contents
of
the
live,
deaf
actor
vamp
rod
active
over
and
because
the
site
uses
opposite,
one
strips
for
staging
and
directory
staging
and
active
it'll
switch
them.
So
I
can
make
a
change
on
productive
production,
pull
it
config.
Sync
change
on
local
pull
config
sync
in
it.
A
It
just
moves
all
of
the
files
around
exactly
where
they
need
to
be
so.
This
seems
kind
of
crazy.
I
figured
I'd
do
a
demo,
so
you
can
see
what
it's
like
so
here
on
my
live
site.
I
know
what
to
be
change.
Oh
wait,
I
know,
I,
just
didn't,
update,
I,
think
113
113,
one
and
I
ran
the
updater
and
I
think
they're.
Just
looking
at
this
another
window,.
A
A
B
A
Okay,
so
I'm
currently
logged
into
my
live
server.
You
can
see
area
of
my
doctorate
directory
right
next
to
my
config
directory.
I
also
happen
to
keep
a
patch
file
for
every
one
of
my
sites,
so
if
I'm
running
any
patches,
I
can
keep
track
of
them,
but
we're
gonna
go
into
config,
and
here
you
have
dev
active
and
live
active.
So
on
my
production
site,
if
I
run
a
get
status,
you
can
see
that
there's
one
change
to
the
live
directory,
and
this
is
the
addition
of
log
date
format.
A
So
in
the
latest
update
that
I
run
in
a
live
site
it.
The
update
script,
changed
a
config
value
in
this
file,
so
this
is
pretty
common
where
you'll
deploy
some
changes
to
run
configuration
now,
your
live
site
has
configuration
changes
that
aren't
in
version
control,
so
I'm
going
to
go
ahead
and
add
that
file
I'm
gonna
commit
it.
A
A
If
I
do
a
pull,
it
should
I'll
pull
down
more,
but
that's
fine.
It
did
pull
down
the
change
to
the
system
core
file,
which
is
what
I
want,
and
so
now
on.
My
local
site
I
can
run
to
is
my
local
site.
I
would
be
bigger
here
to
configuration
development
configuration
management,
so
it's
showing
these
same
things
are
out
of
sync.
A
A
Yeah
we'll
see
what
happens
so
I'm
assuming
that,
because
this
is
coming
from
the
live
site.
This
is
what
I'm
running
on
a
live
site,
and
this
is
actually
what
I
want.
When
I
run
this
synchronize
what's
gonna
happen,
it's
gonna
copy
all
of
the
config
files
from
the
live
directory,
which
my
local
site
is
using
the
staging
or
on
whatever
database
changes
are
necessary
and
then
it'll
copy
them
into
the
dev
active
directory.
A
Here
we
go
import
all
right
so
now,
if
I
do
a
git
status
on
my
local
environment,
it'll
show
that
the
live
directory
is
empty
because
what
it
does
when
it
does
that
config
sync
is
empty
out.
Whatever
your
staging
directory
is
so
I'm
gonna
check
that
out,
because
I
don't
care
about
that
and
then
I'm
gonna
look
at
what's
actually
changed.
So
it's
copied
those
three
files
from
my
live
folder
into
my
dev
folder,
so
I'm
going
to
add
them.
A
B
A
A
A
Okay,
then
I
can
go
to
my
live
server
pull
and
it
should
pull
in
that
system
core
file
and
the
other
ones
that
we
just
synced
it
just
totally
fine
cuz.
They
were
there
anyway
and
then
here's
the
system
core
one.
You
need
to
add
a
color
thing
on
this
terminal:
nope,
that's
fine!
Okay!
So
now,
if
I
go
back
to
core
it.
A
Should
show
only
the
change
in
that
one
file,
so
this
should
show
well
geez
Oakland
California
became
Oakland
California
USA.
It
did
also
add
some
default
values,
which
is
essentially
nothing
for
all
of
the
site:
logo,
attributes,
site,
favor,
icon
information,
whether
it
should
be
in
my
theme,
if
it's
uploaded,
if
there's
a
path,
so
a
bunch
of
nothing.
A
Essentially
that's
okay,
I'm
fine
with
that,
so
I'm
gonna
go
ahead
and
close
this
and
I'm
going
to
import
here
and
now
what
it'll
do
is
it'll
copy
all
the
files
from
my
dev
active
directory
into
my
live,
active
directory
and
so
I
do
get
status.
It
should
show
the
dev
active
directory
is
now
empty,
because
it's
deleted
that
so
I'm
going
to
check
that
out.
A
A
A
No
changes,
that's
the
figure,
8
method.
I
find
it's
really
fast.
If
there's
only
one
developer,
so,
as
you
add
more
than
one
developer,
it
gets
really
confusing
because
you're
like
wait,
was
it
your
dev
active
or
was
it
my
dev
active
and
then
you
start
overwriting
each
other
and
it
gets
really
complicated.
So
when
there's
more
than
one
developer,.
A
I
usually
have
a
live
active
directory
in
the
same
way
that
we
had
on
a
single
developer,
but
instead
of
having
a
dev
active,
that's
in
version
control,
I
have
a
dev
active,
that's
ignored
and
then
I
have
a
staging
directory.
That's
in
version
control,
and
this
way
every
one
of
the
sites
is
running
off
of
the
same
staging
directory
for
staging
and
their
own
copy
of
the
Active
Directory
for
that
site.
A
So
you
can
also
have
like
a
beta
live
active,
a
test
live
active
it
don't
you
know,
dev
server
live
active
or,
however
many
sites
you
have.
You
can
have
individual
folders
that
contain
code
in
order
to
understand
how
to
manage
this,
we've
actually
documented
it,
because
there's
gonna
be
a
lot
of
people
who
are
working
on
our
community
site.
A
But
when
you're
working
with
it
shared
people
in
a
shared
environment
and
the
live
site
running
off
of
one
directory,
it's
best
to
let
backdrop
manage
the
contents
of
that
directory
and
everyone
who's
working
on
this
site
will
make
commits
into
the
staging
directory,
and
so
it
doesn't
matter,
who's
been
working
on
the
site.
If
I
do
a
git
pull
I'm
gonna
pull
in
the
latest
of
everything
into
staging
directory
and
I'll
be
able
to
sync
my
local
site,
with
its
local
config
directory
to
the
staging
directory.
A
The
only
time
this
gets
messy
and
I've
done
this
with
Kevin
a
couple
times
and
accidentally
over
it
in
his
changes,
is
when
somebody's
trying
to
take
the
live
sites.
Current
configuration
and
put
that
into
staging.
You
have
to
be
really
careful
when
you're,
comparing
the
dips
of
those
files
and
make
sure
that
there
isn't
one
file,
that's
changed
in
both
places
and
the
DOS
changes
are
getting
merged
adequately.
So
I,
usually
in
a
perfect
world,
would
not
change
the
live
site
until
after
it
look.
A
If
you
have
a
view
right,
don't
change
the
view
on
live
if
you're
changing
the
view
on
your
local
site,
only
change
it
in
one
place,
and
then
you
won't
run
into
that.
So
there's
some
step-by-step
instructions
here
on
how
to
set
up
your
local
in
site
when
you
do
a
git
pull-
and
this
isn't
this-
for
this
repository
you'll
actually
get
a
setting
some
PHP
file
that
contains
the
directory
set
up.
That's
different!
So
there's
information
here
about
like
hey,
you
need
to
create
a
setting,
HP,
Thal
and
your
local
site.
A
When
you
start
working
make
sure
that
your
staging
is
in
sync
and
then
when
you're
done,
you
also
manually
copy
the
contents
of
your
dev
a
directory
into
staging,
and
then
you
manually
review
each
of
those
config
file
changes
to
be
like
yes,
I
did
want
to
change
this
view.
No
I
didn't
want
to
change
the
system
core
settings
to
dis
a
CSS
segregation,
whatever
it's
there's,
always
something
in
there
where
you're
like.
A
This
is
the
kind
of
thing
that
I
do
all
the
time
and
it
totally
makes
sense
in
my
head
and
I,
don't
realize
until
I
say
it
out
loud
how
complicated
it
is
like.
Oh,
this
is.
This
is
harder
than
harder
to
say
than
I
thought
it
would
be,
but
yeah
I
love
working
with
configuration
and
files.
It
definitely
what
it
took.
Some
getting
used
to
in
the
beginning,
a
bunch
of
people
have
different
ways
they
like
to
manage
it.
I
think
Jeff
has
a
different
way.
A
He
likes
the
management,
he
wrote
a
blog
post
and
how
he
does
it.
I,
remember
his
blog
post
URL,
but
it's
in
Gator,
if
you're
interesting.
Looking
at
that.
B
A
A
See
how
that
would
be
really
helpful,
especially
on
something
like
backdrops
EMS
network
that
has
a
bunch
of
people
working
on
it,
but
nobody's
working
all
the
time.
So
when
you
do
go
to
touch
it,
it's
been
a
really
long
time
since
you
works
on
it
last
having
something
that
would
be
a
command
that
would
be
like
hold
on
the
latest
files
pulled
on
the
database.
Sync,
your
config
with
the
latest
database
behavior
just
to
get
to
like
a
starting
point
and
they'd
be
like
okay.
A
Here's
a
clean
starting
position
go
and
then,
when
you're
done,
if
you
wanted
to
do
the
manual
review
you
could,
but
you
could.
You
could
also
just
be
like
make
it
ready
to
deploy
and
it
could
even
do
like
a
comparison
with
like
pulling
down
from
live,
making
sure
nothing's
changed
that
you
also
change
and
they
look
like
throwing
air
and
be
like
you.
A
Both
have
modified
X
view
or
whatever
it
is,
but
yeah
I
could
see
how
that
would
be
really
helpful
and
for
something
like
this,
where
we
have
sanitized
database
backups,
driven
who's
working
on
backup
sites,
you
could
even
have
it
like
copy
a
new
version
of
the
database
on
that
initial
one
where
it
would
be
like
hey.
We
know
where
this
file
lives.
A
A
Yeah
yeah
yeah:
that's
why
I
ended
up
creating
these
read.
Nice
was
actually
because
we
originally
started
with
figure.
Eight
and
people
are
like
this
is
really
confusing
and
I'm
like
well
I'm,
gonna
change
it,
but
I'm
gonna
change
it.
Anyone
who
has
worked
on
it
a
month
ago,
it's
gonna,
be
really
lost
like
a
massive
it's
different
now
so
I
wrote
it
all
down
like
okay
Jack
a
minute.
Well,
hopefully
we
can
keep
this
up
to
date
when
we
change
it
again.
A
Next
time
but
yeah
having
at
having
it
like
a
even
having
it
built
into
trash.
I
think
it'd
be
really
helpful.
We're
like
if
there
were
backdrop,
CNS,
org,
helper,
commands
and
rush.
We
might
get
a
whole
bunch
more
contributors
of
actions
revisit
or
if
they
go.
I
want
to
fix
that
and
I
can
just
run
this
command.
Megan
of
access
to
the
code
base.
I
can
do
whatever.
That
would
be
really
cool,
also,
potentially
really
dangerous,
but
really
cool.
B
B
A
Yeah
and
I
think
that's
also.
Some
of
the
Pantheon
quotes
there.
Resistance
to
having
anything
we
web,
writable
and
files
directory
is
that
nothing
should
ever
change
in
production
and
I
feel
like
that
makes
sense.
If
you
have
an
active
development
team
who
can
support
every
change
that
needs
to
be
made
by
doing
a
configuration
and
deploy,
but
our
audience
is
not
the
kind
of
people
that
have
an
active
development
team
that
can
support
every
change.
That
needs
to
be
made,
and
that's
why
backdrop
has
user
interfaces
right?
A
It
has
this
administrative
tool,
that's
really
powerful
and
lets
you
do
anything
like
make
configuration
changes
and
I.
Think
it's
just
not
a
good
match
to
have
your
environment,
be
so
locked
down
that
you
can
never
make
a
change
of
production
to
a
software
tool.
That's
intended
to.
Let
anybody
make
any
changes
in
production,
but
yeah
I
mean
I,
understand
it's
a
best
practice,
but
I
feel
like
that's.
B
A
B
B
B
A
That
would
work
too
I
really
like
having
in
version
control,
though
there's
just
something
that
I
find
a
lot
more
comforting
about,
knowing
that
it's
always
in
version
control,
rather
than
like
only
the
times
that
anyone
exports
it
ends
up
in
version
control.
I,
think
part
of
it
is
because
of
my
paranoia
about
the
WordPress
hack,
where
you
can
just
log
into
the
server
and
see
what's
been
changed.
Being
able
to
do
that
on
a
production
gives
me
some
confidence
like
I
know.
A
The
only
thing
that's
changed
is
this
one
line
in
the
system
core
file
and
I
can
handle
that,
but
yeah
also
I.
Also
with
my
experience
on
Pantheon
like
not
having
the
production
copy
in
version
control
makes
me
a
little
nervous.
So
I'm
like
what
happens
if
you
lose
it
cuz
now,
there's
nothing
there
for
you
to
export,
because
it's
gone.
A
A
Yeah
but
I
think
I
think
that
the
point
that
Jeff
and
I
are
going
on
here
is
that
if
you
commit
only
to
staging,
it
makes
everybody
who's
running
rapid,
like
whether
it's
production
or
anyone
else
who's
running
it
or
on
a
beta
server
or
whatever
can
have
the
ability
to
run
the
sink
and
get
up-to-date
and
I.
Think
that
that's
really
valuable
and
that's
probably
the
most
important
part
of
it
is
having
the
stage
in
parking
version
control
and
that's
what
the
folks.
The
Pantheon
also
recommended
us
to
do.
A
They're
like
you,
can
pull
the
staging
version
staging
directory
out
of
the
files
directory
and
commit
that,
and
you
can
use
that
for
the
deployment
workflow,
because
you
know
Pantheon
electable
read
from
that
Palace
directory.
It
can't
delete
them
because
they
can't
write
them.
But
it's
fine,
because
I
always
check
out
that
directory
again
anyway
and
leave
the
files
in
there
backed
up
doesn't
care
if
there's
files
in
there
or
not.
So
if
panting
I
can't
delete
them,
that
doesn't
matter
works
just
fine.
So
it's
the
same
kind
of
root
thing.
A
A
A
It
earlier
in
the
schedule,
but
then
we
had
to
move
everything
around
I
was
like
I'm,
not
sure
I
wanted
this
at
naptime,
but
yeah
I've
also
had
people
who
have
come
to
Drupal
7
from
backdrop
and
not
even
thought
about
configuration.
Just
use,
Drupal
use,
backed
up
the
same
way.
They
use
Drupal
I,
just
I'm
like
I'll,
just
save
the
forms
and
do
the
things
and
export
database
in
as
long
as
every
time
you
export
the
database,
you
bring
the
config
files
with
you
as
though
it
was
part
of
database.
That
also
works.
B
A
Yeah,
that
is
something
I
didn't
mention.
Is
that
anytime,
you
do
a
database
dump
or
import,
whether
it's
when
you're,
first
starting
or
if
he
would
spend
a
couple
months
and
you're
starting
over.
You
want
to
get
both
the
database
and
that
can
think
config
live
directory
or
wherever
that
live
big
files
are
stored,
whether
you
have
to
do
a
virtual
or
easier
interface,
export
or
what-have-you
and
those
both
import
together.