►
From YouTube: 2022/10/27 Backdrop Weekly Dev Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
it's
October
27
2022,
and
this
is
the
weekly
backdrop
developers
meeting.
We
get
together
every
week
to
talk
about
things
that
are
happening:
development
wise
in
the
world
of
backdrop.
My
name
is
Nate
Lampton
I'm,
quick
sketch
on
the
internet,
calling
from
Oakland
California
I'm
a
core
committer
for
the
backdrop,
project
and
I'm
joined
here
by
five
others
we'll
do
kind
of
around
the
room
introductions
and
let
everybody
if
you
would
introduce
yourself
where
you're
from
or
where
you're
calling
from
and
any
you
know,
job
role.
A
Introduction
of
anything
like
that,
they
want
to
say,
let's
start
off
with
Greg
and
then
we'll
go
to
Luke.
B
A
Thanks
Greg
Luke
and
then
Tim.
A
Thanks
Luke,
chairman
and
Jen.
D
Hi,
my
name
is
Tim
Erickson,
I'm,
Saint,
Paul
team
in
the
forums
of
GitHub
and
really
excited
or
happy
about.
The
recent
backdrop
live
and
excited
about
our
new
community
meetings
that
we'll
be
doing
starting
in
two
weeks.
Talk
to
you
later
or
that's
all.
A
Thanks
Tim
Jen
and
then
Kevin.
E
Jen
Lambton
joining
from
Oakland
California.
That's
it.
C
B
A
All
right
all
right
well
welcome
everyone.
It's
Glenn
glad
to
have
everyone
here
before
we
get
into
General
discussion.
Jen
will
do
the
little
Community
update.
E
A
Yeah
and
actually
before
we
go
into
General
discussion,
Tim
I
know
you
just
had
a
community
meeting,
but
can
you
give
us
just
a
quick
recap
on
backdrop?
Live
just
for
people
that
watch
this
meeting.
D
Sure
I
think
we
had
a
pretty
good
turnout.
It
wasn't
our
busiest,
but
we
had
a
good,
solid
participation,
a
lot
of
good
topics.
Unfortunately,
I'm
not
sure
what
else
there
was
a
lot
of
information
dumped.
So
I
don't
know
what
to
pick
out
if
anybody
else
has
anything
to
share,
but
we
do
have
a
couple
of
sessions
that
were
that
were
recorded
and
I
haven't
even
thought
about
getting
them
online.
Yet
so
we'll
try
to
get
those
up.
It's
just
a
few
of
them.
D
We
did
do
our
background
for
beginners
trap,
which
was
a
new
thing
and
I
think
we
think
that
went
pretty
well,
we
had
a
good
turnout
for
it,
and
people
seemed
to
respond
well,
so
yeah
I
don't
know.
If
anybody
else
has
any
real
highlights,
they
could
mention
them.
D
Even
better
I
I,
I
guess
the
last
thing
I'll
say
is
that
we're
probably
going
to
do
our
next
backdrop
live
in
about
six
months,
so
a
little
further
a
little
more
spacing
between
the
moving
forward.
So
but
thanks
everybody.
A
Yeah
great,
you
know
another
thing
we
haven't
made
any
other
announcements
other
than
at
backdrop,
live
of
our
new
core
committer
Joseph
Flatt
has
joined
the
leadership
team
as
new
court
committer
to
the
project
his
handle
is
Joseph.
We're
really
happy
to
have
Joseph
on
as
an
additional
reviewer
and
committer
for
the
project
he's
already
made
at
least
one
commit
I
know
and
that
one
commit
actually
is
very
exciting.
Actually
I'll
talk
about
that
in
a
second,
but
we
have.
A
We
have
some
other
things
to
do
logistically
like
we
should
probably
write
a
blog
post
talking
about
our
current
leadership
team
I
know:
we've
had
some
change
UPS
like
even
the
PMC
had
a
is
down
one
person.
For
example,
while
I
was
onboarding,
Joseph
I,
also
cleaned
up
or
cleaned
up.
A
That
sounds
so
great
I
I
reached
out
to
a
previous
core
committer
Jeff
Saint
Pierre,
who
hasn't
been
active
in
the
backdrop
world
for
a
couple
of
years
now
and
just
asked
if
he
was,
you
know,
still
interested
in
maintaining
his
access
and
he
politely
wrote
back
said
he
missed
us
guys
missed
us
folks,
but
that
he
should
probably
you
know,
have
his
have
his
access
taken
away
because
he
wasn't
using
it.
So.
E
C
A
Of
yeah
Pfizer
has
a
large
Drupal
base
as
I
understand
it
so
but
yeah
so
yeah.
We
should
I
mean
thank
you
Jeff
for
all
of
your
service
in
the
past
and
welcome
Joseph.
Thank
you
for
your
service
in
the
present
and
the
past,
so
yeah
some
change
over
in
the
leadership
team.
But
that's
that's
great.
A
Let's
see
oh
yeah,
so
the
one
thing
that
Joseph
committed
last
week
was
one
of
my
favorite
issues,
issue
5245,
which
was
supporting
PHP
CS
work
that
Indigo
Zella
has
been
putting
together
for
the
past
couple
of
months
that
now
all
pull
requests
filed
against
core
automatically
get
validated
against
a
set
of
our
coding
standards.
It's
not
100
comprehensive.
A
At
this
point,
we've
started
a
new
repository
that
includes
the
basic
coding
standards,
rules,
tabs
versus
spaces
and
obvious
syntax
errors,
things
of
that
nature
and
we're
working
on
expanding
out
that
repository
kind
of
as
we
go,
but
that
new
syntax
checking
is
now
active
against
all
pull
requests
that
are
filed
against
core
and
if
there's
syntax
issues
in
your
pull
request,
then
GitHub
will
now
politely
give
you
a
little
code
comments.
Saying:
hey!
A
You
got
to
change
this
to
that,
so
hopefully
that
will
reduce
the
amount
of
time
that
we
spend
just
correcting
each
other's
like
typos,
and
things
like
that,
which
should
be
nice,
so
I'm
very
excited
about
that.
52
45
we're
not
exactly
sure
how
well
it's
going
to
work.
There's
only
been
a
couple
of
pull,
requests
come
in
and
so
far
the
Big
Green
as
far
as
I've
seen
so
I
haven't
had
issues,
but
yeah
I'm
excited
to
see
how
that
that
affects
our
core
development
processes.
A
We
also
have
a
follow-up
for
PHP
Stan,
which
does
something
similar
issue.
A
5467
is
PHP
Stan
and
that
work
is
still
continuing
and
it
does
something
different
rather
than
syntax,
highlighting
it
will
be
able
to
do
things
like
tell
us
if
we're
using
deprecated
functionality
that
doesn't
exist
in
PHP
8.1
or
something
like
that.
So
that
will
be
a
similar
but
different,
slightly
different
tool
in
that
it
analyzes
our
code
for
things
like
actual,
like
classes
that
don't
follow
correct
dependency.
Trees,
like
actual
like,
if
this
code
were
to
be
executed,
potential
problems.
A
B
I
think
the
Drupal
has
that
as
well,
so
it
it
actually
does
spell
tick,
oh
so
so
yeah
and
you
can
specify
words
that
you
know
you
add
them
in
the
dictionary,
and
you
know
the
correct
spelling,
I
think
RG
piano
mentioned
something
about
in
an
irrelevant
issue
about
the
word
resizable.
If
it
is
EA
or
just
precise,
above
just
with
a
name
and
I
did
a
search,
and
there
was
like
17
instances
with
the
just
a
thing
and
three
instances
of
yeah.
B
A
A
You
go
yeah,
but
it's
very
very
well
covered
in
that
issue.
So
thank
you
for
filing
that
yeah.
That's
that's
neat,
okay,
yeah!
So
that's
those
are
the
announcements
and
everything
yeah
backdrop
live.
I
agree.
A
It
was
was
a
great
event,
yeah
lots
of
news
and
lots
of
the
way
I
had
several
new
people
come
into
the
community
who
have
persisted
for
the
best
week
so
far
and
that's
been
really
exciting
to
you
know,
get
get
in
those
new
people
and
thanks
so
much
Tim
and
Jen
for
organizing
and
running
that
conference,
as
always.
A
Okay,
all
right.
So
the
only
item
that
we
had
in
the
Forum
post
for
this
week
under
Forum
dot,
backdropcms.org
there's
under
the
events
section,
there's
always
a
a
post
there
to
solicit
ideas
for
topics
for
these
meetings.
A
Kevin
who's
joining
us
today
and
Tim
went
back
and
forth
a
little
bit
wanting
to
talk
about
distributions
or
something
similar
to
distributions
with
a
different
name
and
that
spins
out
into
all
kinds
of
questions
it
has
been
a
while,
since
we've
discussed
this
topic,
there's
been
a
long
issue
for
I,
don't
know
since
the
beginning
of
backdrop
about
distributions,
but
yeah
I'll
turn
it
over
to
Kevin
to
kind
of
frame.
A
What
the
need
is
for
for
him
and
kind
of
what
he
would
like
to
see
so
and
then
we'll
kind
of
go
from
there.
So
take
it.
Take
it
away.
Kevin
yeah.
C
So
we're
looking
at
this
from
two
different
approaches.
So
it's
really
Tim
stalker
from
the
University
of
Colorado
Denver
campus,
who
is
looking
at
migrating
Express
sites.
So
webexpress
is
the
service
that's
used
at
Denver
and
Boulder,
and
there
are
roughly
2500
of
those
Drupal
7
sites
that
is
built
as
a
packaged,
install
profile,
slash
distribution,
but
it
really
isn't
maintained
on
drupal.org
it
uses.
You
know
a
custom,
devops
solution.
C
You
can
run
the
drush
make
Command
and
package
it
yourself,
but
we
don't
actually
use
that
packaging
functionality
on
dribble.org
and
I
am
super
excited
that
we're
Neil
drum
just
agreed
to
turn
that
functionality
off
on
drupal.org
at
the
end
of
next
month.
C
So
so
that's
going
to
die
so
I
think
it
would
be
for
the
same
reasons:
I
want
it
to
die
on
drupal.org
I
think
it
would
be
foolish
to
implement
the
same
thing
in
backdrop
now
so
I'm
looking
at
backdrop
for
individual
sites
that
aren't
built
on
that
install
profile
that
were
just
one-offed
over
over
time
and
so
I'm
working
with
Tim
to
try
to
help
him
with
the
the
web
Express.
But
because
we're
going
to
build
this
these
sites
on
Pantheon,
we
can
use
the
Upstream
functionality
to
manage
Distributing
the
install
profile.
C
So
we
talked
about
a
couple
of
things
that
might
make
our
lives
easier
in
the
interim
to
build
the
install
profile
file
rather
than
have
the
user
try
to
enable
a
super
module.
After
installing,
that
has
to
run
through
three
different
dependencies
go
back
run
through
the
next
three.
It
would
take
an
awful
long
time
to
use
the
project
installer
to
add
all
of
the
the
projects
that
the
install
profile
will
end
up
creating.
So
we
don't
necessarily
need
backdrop
to
change
anything
in
the
way
their
things
are
structured.
C
Now
we
have
everything
we
need
to
determine
which
projects
we're
using
have
already
been
ported.
Joseph
flat
was
really
helpful
in
tracking
down.
If
we
want
to
build
our
own
version
of
project,
installer
listings
like
how
that
would
work,
I
I
thought
I
was
going
to
be
really
really
slick
and
go
in
there
and
make
that
configurable
only
to
realize
it
already
was
so
I
was
like.
Well,
how
do
you
feed
it?
A
Wow
so
you're
taking
approach
of
potentially
running
your
own
project,
server
kind
of
like
similar
to
backdropcms.org
yeah.
C
So
once
when
Jen
showed
me
the
how
the
project
installer
can
work
on
a
Dev
instance
on
Pantheon,
that's
kind
of
one
of
the
things
that
the
current
webexpress
service
offers
through
some
custom
code,
we
have
a
project
on
drupal.org,
called
profile,
module
manager
that
enables
site
owners
who
can't
install
other
modules
to
be
able
to
install
approved
bundles
of
functionality,
but
rewriting
that
functionality
in
the
devops
pieces
that
go
with
it
doesn't
really
make
any
sense
when
the
infrastructure
to
do
something
very
similar
already
exists,
and
the
university
has
already
licensed
Pantheon
for
several
of
the
the
units.
C
So
we
already
have
that
devops
web
Ops
infrastructure.
So
we
don't
need
to
reinvent
that
part,
so
just
be
creating
bundling
the
config
exports
instead
of
using
features
like
we
did
in
in
Drupal
7,
but
the
like
amount
of
work
we
put
into
all
of
those
custom
Solutions.
The
fact
that
it
just
it's
already
there
is
is
brilliant,
so
yeah.
So
we
have
all
those
pieces
figured
out,
but
timid
asked
me
about
recipes
and
so
I'm
working
on
that
initiative.
C
That's
one
of
the
things
that
got
dropped
from
the
badcamp
presentation
is
the
mistake
we
made
with
Drupal
8
at
CU
was
just
assuming
that
our
use
case
would
be
taken
care
of
and
not
being
involved
in
the
initiatives.
My
computer
is
doing
something
really
weird
here.
Sorry
I'm,
not
on
the
monitor.
C
Sorry,
if
I'm
blinking
out
here,
my
computer's
trying
to
figure
out
which
monitors
are
available,
but
the
so
I
was
given
an
time
to
actually
participate
in
that
initiative
and
Alex
Pott
is
really
doing
the
majority
of
the
development.
But
recipes
are
interesting
and
I
didn't
realize
that
backdrop
also
had
recipes
or
we're
starting
to
have
recipes,
but
the
the
difference
in
Drupal
is
that
their
recipes
are
entirely
yaml,
but
it's
yaml
that
can
be
run
as
part
of
the
installation
process.
C
So,
unlike
distributions
the
packaged
install
profiles,
we
are
breaking
up
the
install
experience
from
the
managing
updates
after
the
thing
has
been
installed,
which
has
been
a
pain
point
for
the
last
decade,
really
with
with
Drupal
7
install
profiles.
So
as
far
as
the
conversations
and
backdrop,
there's,
obviously
a
need
to
distribute
pre-configured
example
configurations
for
different
use
cases
how
you
do
that,
though,
is
like
there.
There
is
yet
to
be
a
you
know,
perfect
example
of
how
that
should
work
anywhere.
C
So
there's
lots
of
room
for
for
experimentation,
but,
like
I
said
in
some
of
these
issues,
this
is
obviously
a
a
very,
very
much
an
edge
case
where
you
know
we
happen
to
have
a
large
number
of
sites
that
are
built
on
the
exact
same
code
base.
We
have
a
way
to
do
this.
That
doesn't
require
backdrop
to
change
anything,
but
if
you
want
to
have
the
discussion
around
doing
more
of
this
in
backdrop,
I'm
more
than
willing
to
participate
in
those
discussions
and
add
my
my
experience
with
doing
it
in
different
ways.
B
B
We
also
started
gathering
information
about
the
installation
profile
and
there's
like
two
a
little
bit
less
than
less
to
check
two
and
a
half
thousand
installations
of
backdrop
and
every
single
one
that
reports
back,
not
all
of
them
report
back,
they
don't
have
Telemetry
enabled,
but
those
that
have
a
Telemetry
enabled
they
all
report
the
standard
installation
profile
being
used.
Having
said
that,
that
might
be
because
not
everyone
from
D7
started
moving.
B
Yes
right,
so
so
just
wanted
to
point
that
out,
as
we
do
have
it
as
a
measure
and
ask
you
Kevin
this,
this
Express
profile
that
you
have
is
it
does
it
have
sensitive
information
that
you
cannot
share,
or
is
it.
C
It's
on
dribble.org,
but
we
just
don't
package
it
and,
like
I
mentioned
the
bad
cap
session,
the
it
there
are
more
installs
than
what
we
run
at
the
University.
However,
it
says
all
over
it.
This
is
just
for
inspiration
or
to
see
how
we
solve
some
of
these
problems.
C
The
university
doesn't
support
using
it
outside
of
our
own
use
case,
so
we've
found
them
in
the
wild
from
time
to
time,
and
it's
always
interesting
what
parts
of
it
people
have
chosen
to
enable
running
the
debug
module
on
your
production
sites
for
reasons
we
can't
today,
but
yeah.
So
it's
it's
all
out
there
all
the
pieces
of
it,
but
the
thing
that
really
resonated
me
from
from
Zach's
Stanford
presentation
was
that
they
didn't
have
to
retrain
the
users,
and
so
we
have
at
the
boulder
campus.
C
We
have
over
a
thousand
sites.
There's
3
700
content
editors,
that
if
we
radically
change
the
way
they
build
and
maintain
sites
all
at
once.
That's
a
that's,
a
pretty
large
group
to
try
to
retrain
on
how
to
use
paragraphs
or
layout
Builder
or
whatever
new
layout
paradigms.
We
come
up
with
so
we're
trying
to
keep
things
as
similar
as
possible
and
that
and
be
able
to
spin
up
additional
sites
that
follow
these
same
patterns
so
but
yeah
everything's
out
there.
C
It's
both
both
the
drupal.org
version
with
the
drush
make
file
and
then
the
GitHub
repositories
where
we
actually
work.
Those
are
all
public
as
well.
All.
B
Right,
cool
and,
and
then
it
seems
that
you
need
to
figure
out
the
last
details
or
or
a
few
remain
things,
but
have
you
decided
moving
forward
to
just
sort
of
like
move
away
from
profiles
with,
with
with
the
capabilities
I
mean
that
that
backdrop
provides
and.
C
So,
in
configuration
and
stuff
like
that
yeah
this
is
the
like
what
I
need
to
do
and
what
I
want
the
university
to
do
are
two
different
things.
So
I
just
have
two
sites
at
the
system
level
now
I'm
not
responsible
for
the
Thousand
D7
sites,
I
left
behind
I'm
trying
to
help
that
team,
because
I
feel
kind
of
bad
about
that
so
yeah.
C
So
that's
where,
like
my
path
forward,
you
guys
have
done
a
great
job
about
you
know
documenting
how
to
evaluate
a
site,
and
you
know,
compare
what
you
know
what
needs
to
be
done
and
prep
the
site
for
that.
So
I'm
working
on
that
for
the
two
sites
that
I'm
working
on
and
then
Tim
stalker
has
a
150
or
so
sites
that
are
built
on
this
same
install
profile
and
so
he's
doing
the
same
thing.
So
we
don't
have
to
move
those
sites
to
a
a
distribution
or
install
profile.
C
But
if
we're
going
to
continue
to
launch
new
sites,
they
need
to
be
launched
and
configured
the
exact
same
way
every
time,
and
so
that's
what
the
install
profile
process
gave
us,
but
no
right
now.
So
I
created
the
the
project.
I
just
created
a
fork
of
the
standard,
install
profile
and
started
building
that
out
to
see
what
what
still
worked
and
what
didn't
work
there
and
I
believe
I
have
to
put
that
in
core.
Is
that
correct?
C
C
Can
I
still
put
modules
in
the
profile
directory
I
can
then
the
question
comes
up,
should
I
still
put
modules
in
the
profile
group,
so
that's
where
Alejandro
works
for
CU
Boulder,
but
then
has
been
building
backdrop
sites
on
his
own
independent
of
the
university
and
so
Tim
and
I
are
going
to
get
together
with
him
and
get
more
feedback
on
okay,
like
let's
not
just
make
assumptions
about.
This
is
how
we
did
it
in
Drupal.
Let's
make
backdrop
work
the
same
way,
so
we
are
open
to
reevaluating.
All
of
this.
B
Yeah,
there's
there's
a
few
things
that
come
to
mind,
although
the
reason
why
I
asked
before,
if
the
profile
is
available
is
just
so
that
I
can
experiment,
but
there's
a
few
things
that
have
gotten
into
backdrop
that
make
may
make
things
easier
like
we
again,
we
recently
had
some
sort
of
duplicate
module,
detection
and
I'm
thinking.
Now,
how
do
you
remove
because
I
think
there
was
a
module
in
Drupal
that
helped
you
like
profile,
remover
or
something
like
that?
That
would
help
you
profile.
B
B
Maybe
we
could
make
things
work,
but
if
people
want
to
move
away
from
profiles
because
it
is
a
pain,
then
we
can
work
towards
you
know
helping
them
out
by
by
not
right
having
backdrop
blow
up
if
they,
so
this
is
yeah.
C
This
is
where
composers
so
having
I
used
to
think
that
having
the
different
levels
of
the
same
module
at
different
versions
was
very
useful.
Now
I
think
it's
super
crazy
to
have
duplicate
code
in
your
build,
but
without
composer
I,
really,
don't
know
how
an
individual
instance
would
get
ahead
of
the
profile
or
run
a
patched
version
of
something.
So
that's
one
of
the
things
in
with
the
composer
and
an
upstream
configuration
like
the
standard
Pantheon
build.
C
We
can
have
our
supported
upstream
and
then
the
customizations
that
each
individual
projects
does
the
project
can
Trump
the
the
Upstream,
but
they
do
it
in
composers.
So
the
build
only
ends
up
with
one
version
of
the
code
in
there
per
per
build
and
then,
if
we
get
back
in
sync,
then
they
can
remove
the
patch
sure
the
override
forward
or
backwards
whatever
they're
doing
so.
That's
where
I
don't
know
with
how
much
more
stable
backdrop
is.
If
we
would
ever
even
need
to
do
that.
C
B
Yeah
I
mean
at
the
end
of
the
day
everyone
like
everything
that
has
the
manager
a
handful
of
sites
like
we
in
gov
CMS,
have
a
module
that
specifically
like
it
has
no
code.
It
only
has
dependencies,
so
we
enable
it
so
that
the
dependencies
can
be
enabled,
and
then
we
disable
it
which
is
yeah
yeah.
So.
D
Well,
so
part
of
why
I
would
suggest
that
we
talked
about
this,
was
that
we've
got
somebody
Graham
in
our
Forum
is
trying
to
write
a
book
about
getting
started
with
background
and
he's
doesn't
like
the
term
distribution
in
my
first
reaction.
Well,
it
doesn't
really
matter
because
there
isn't
really
anybody
used
we're,
not
really
using
distribution.
So
why
worry
about
that
term?
And
then
right
away?
Kevin
says:
oh
I'm,
launching
a
distribution,
so
so
I
thought.
C
Yeah
I
I,
don't
know
it
doesn't
have
to
be
the
way
it
was
before,
but
you
do
have
distributions
listed
on
backdropcms.org
with
the
disclaimer
that
they're,
not
you,
know,
indexed
or
listed
in
the
in
there,
and
so
that's
where,
like
we're
willing
to
you
know,
go
in
whatever
Direction.
You
know
you
guys
think
is
is
best.
But
let
me
ask
you
this
with
recipes
and
kind
of
what
you
were
doing
Tim
with
the
the
I
can't
remember
what
was
the
recipe
that
I
was
talking
to
you
about?
C
You
were
yeah,
so
I
mean
Drupal,
so
one
of
the
issues
with
the
the
core
initiative
is
to
rewrite
unami
as
a
recipe,
instead
of
as
a
a
install
profile,
and
that
to
me
makes
a
lot
of
sense.
But
what
this
is
going
to
unlock
inevitably
is
having
more
demos.
C
So
there's
been,
you
know
countless
attempts
to
do
a
demo
framework.
Aquia
ran
and
install
profile.
That
was
nothing,
but
you
know
spinning
up
Drupal
in
different
configurations
for
these
different
sales
demos,
but
the
you
know.
The
challenge
has
always
been
that
when
you
do
that
and
Nami
has
this
issue
as
well.
C
If
you
wanted
to
build
a
restaurant
site
and
you
decided
to
use
unami
as
the
base
you'd
have
a
really
bad
time,
because
it's
not
designed
to
be
automatically
upgradable,
and
so
that's
where
you
know
the
lesson
learned
from
distributions
on
drupal.org
was
with
drush
make.
They
were
really
easy
to
build.
You
just
go
into
an
existing
site,
you
exported
the
drush,
make
you
got
all
the
dependencies
and
then
you
started
capturing
everything
in
features
and
built
your
install
profile,
and
you
were
done.
C
However,
updating
those
was
more
difficult
and
then
updating
them
in
the
use
case
where
people
could
take
them
and
go
whatever
Direction
they
wanted,
and
you
would
really
have.
No
idea
was
infinitely
more
complicated
than
supporting
individual
contrib
project
because
you
just
didn't
know
what
they
had
built
on
on
top
of
what
you
had
given
them.
C
And
so
that's
we're
kind
of
interested
in
what
you
guys
were
thinking
with
recipes
and
how
those
would
work
and
if
that's
kind,
of
the
model
for
capturing
a
bundle
of
feature
functionality
that
we
want
to
be
able
to
talk
about
with
end
users.
C
D
So
your
recipes
just
we,
we
realize
that
we
have.
We
could
create
sort
of
feature-like
things
with
just
config
files
right
that
that
just
was
possible
in
background
and
the
idea
was
for
simple
things
like
you
want
to
add
an
FAQ
there's.
You
can
drop
a
few
config
files
into
your
site
and
and
you've
added
that
content
and
again
it's
the
nearest
comparable
thing.
D
I
think
in
triple
was
a
feature,
although
this
is
far
from
it's
not
nearly
as
complicated
as
that
and
then
when
I
started
playing
with
those
I
started
them
well.
First
of
all,
there
was
there
was
one
or
two
bugs
that
was
preventing
that
from
happening,
so
we
we
got
that
to
work
just
as
a
module
right,
so
recipes
aren't
a
different
type
of
thing
in
background,
yet
they're
just
modules.
The
original
idea
was
that
they
would
be
config.
D
Only
modules
modules
have
just
added
some
config
files,
but
once
I
started
playing
with
that,
I
realized
wow.
You
know
this.
This
feature
isn't
very
good.
Unless
it,
you
know,
like
requires
a
module.
So
then
so
then
I
just
added.
You
know
because
it
was
a
module.
I
could
add
a
dependency,
so
in
some
of
my
feature
in
some
of
my
recipes,
I've
included
dependencies
and
then
in
some
of
them
I
said
well,
you
know
what
this
this
recipe
would
be
a
lot
nicer.
D
If
there
was
some
sample
content
when
you
launched
it
so
then
I
used
PHP
to
add
a
little
bit
of
sample
content,
and
now
recipes
are
really
just
modules
that
that
you
know
I've
been
thinking
about
them
as
modules
that
don't
really
add
any
new
functionality.
They
they
basically
Recon.
D
You
know,
add
configuration
to
your
site,
maybe
some
content
and
maybe
some
even
a
little
bit
of
styling,
but
but
I
don't
know
if
that's
the
right
definition
of
recipes
from
what
I
understand
you
know
we
we
keep
talking
about
what
are
the
limitations
of
this
module
when
we
come
up
with
the
things
that
I
think
you're
trying
to
address,
one
is
they're,
not
uninstallable.
Once
you
install
them,
you
just
have
them
to
well.
I!
Think!
That's!
That's
the
big.
D
C
A
D
Sure
they're
not
on
install
only
on
the,
on
the
other
hand,
I
didn't
really
Envision
recipes
as
things
that
you
would
update
right.
You
would
install
them
and
they
would
make
changes
to
your
site
and
then
you'd
be
done
with
them,
and
so
like
the
original
idea
with
the
recipe
was
you
couldn't
you
could
enable
it
and
then
you
could
disable
it
and
it
would
continue
to
work.
But
then,
when
I
started,
adding
some
other
things
to
it
like
dependencies
and
others
I
realized.
D
D
If
our
original
idea
was
the
right
idea,
I
mean
I
think
we
would
love
something
like
what
Drupal
is
calling
recipes
but
I
think
there's
a
lot
more
infrastructure
work
or
a
lot
more
tools
that
would
have
to
be
built
that
were
like
I'm,
not
personally
able
to
build
the
tools
that
would
help
figure
out
how
to
uninstall
the
recipe
that
just
that
seems
like
a
much
more
complicated
problem
and
I'm,
not
sure
if
we
have.
You
know
the
other
enough
people
interested
in
this
right
now.
D
C
Momentum
I
mean
your
description
of
recipes
is
what
we
built
at
Boulder
for
bundles,
which
is
just
a
module
naming
convention
for
custom,
feature
exports,
plus
a
secure
permission,
configuration
to
capture
the
permission
changes,
but
that's
also
how
we
managed
updating
those
collection
of
features
is.
We
would
have
a
forms,
bundle,
a
news
bundle,
an
advanced
design
bundle
and
we
start
people
with
a
core
CMS
configuration
and
then
as
they
needed.
C
If
they
needed
a
new
section
of
the
site,
they
could
turn
that
at
on,
but
they
would
be
able
to
discover
those
recipe
collections
through
our
own
version
of
of
project
browser
that
and
we
would
have
the
permissions
set
up,
that
all
of
our
all
of
our
defined
roles
would
get
their
proper
permissions.
For
that.
A
Well,
I
I.
We,
let's
see
we've
got
15
minutes,
I'm
I'm
really
curious,
and
this
is
a
total
pivot,
because,
okay,
so
recipes,
that's
the
state
of
them
as
we
have
them
now.
We
talk
about
recipes
fairly
frequently,
actually
like
at
least
like
it.
I
mean
we've
been
talking
about
this
for,
like
the
last
three
years
on
and
off
yeah
like
Tim,
says
the
momentum
like
the
interest
is
there,
but
like
the
the
ambition
to
actually
do
it,
it's
is
limited
but
yeah
what
I?
A
What
I'd
like
to
ask
you
touched
on
real
briefly,
is,
if
composer
does
factor
into
this
in
any
way
and
there's
been
an
issue
issue,
2257
support
using
backdrop
with
composer.
That's
been
open
for
a
long
time.
C
C
So
we
have
you
have
the
Joel
from
aten
ported,
the
the
simple
saml
PHP
auth
module.
There
are
some
issues
with
that
module
I've
opened
a
couple
and
offered
to
help
get
that
to
a
1.0
release,
but
it
it
actually
functions
but
like
that's
where
I
I
don't
know
if
I'm
crazy,
like
I'm,
always
gonna
approach
things
from
a
composer
perspective
currently,
and
so
that's
where
like
for
me,
like
I
I,
can
figure
out
how
to
build
these
pieces.
I
don't
know
I,
don't
think.
C
There's
anything
that
truly
depends
on
composer,
but
composer
just
makes
our
you
know
grabbing
those
external
libraries
easier
for
things
like
the
authentication,
adding
the
Sim
links
where
they
need
to
go
to
add
the
certs
and
everything
for
that
configuration.
So
we
already
we're
just
modeling
our
D9
configuration
and
making
the
changes
required
to
work
with
a
more
D7
like
module
to
get
that
to
work
so,
but
we
could
easily
do
that
a
dozen
other
ways.
So.
A
A
A
Think
we've
seen
where
composer
is
useful
and
we've
also
seen
how
the
broader
PHP
system
interacts
with
composer
and
from
what
I've
seen
I'm
pleased
that
at
least
like
composer,
it
seems
like
it's
an
option,
but
not
required
for
almost
all
API
sdks
that
I've
seen
so
like
various
things
like
I,
don't
know,
Facebook,
SDK
or
or
stripe
SDK
like
you
know
they
have
these
PHP
libraries
that
let
you
integrate
with
their
products
and
all
of
them
have
composer
support.
A
So,
if
you
want
to
say
composer
install,
you
know
stripe
API,
you
can
do
that,
but
they
also
all
include
Auto
loaders
of
their
own.
That
are
just
like.
If
you
just
want
to
include
this
autoloader
file
and
not
use
composer
composer,
then
that's
also
an
option.
So
I'm
really
happy
that
that's
the
case,
because
it
gives
projects
like
ours
the
option
of
not
using
composer
yet
still
using
third-party
dependencies.
A
A
A
That
seems
like
installing
stuff,
with
composer
is
pretty
expected
that
you
can
install
just
about
anything
and
I
was
I
was
reading
beforehand,
because
I
thought
we
were
going
to
get
into
this
this
meeting,
and
now
we
are
I
guess
about
about
WordPress
and
where
which
direction
they're
kind
of
going
with
this,
and
it's
interesting
because
they
have
the
same
kind
of
not
only
the
same
challenges
that
we
do.
A
You
know
they're,
you
know
all-inclusive
monolithic,
CMS
essentially,
but
also
they
have
the
same
philosophy
as
us
that
they
want
to
make
sure
that
WordPress
is
accessible
to
as
many
people
as
possible
and
they
don't
want
to
introduce
a
command
line
dependency
ever
like
that's,
never
never
can
be
a
requirement
of
Wordpress,
so
the
in
WordPress
land.
It
needs
to
remain
at
the
very
least
optional.
A
But
it's
also
interesting
that
you
can
install
WordPress
with
composer
but
I
guess
you
can
also
install
backdrop
with
composer
in
the
similar
fashion
that
there's
you
know
a
separately
maintained
repository
that
includes
a
composer.json
file
and
we
put
backdrop
up
on
packages.
Wordpress
actually,
apparently
is
maintaining
their
own
version
of
packages
for
all
plugins
and
themes
and
everything
which
is
yeah
definitely
more
comprehensive
than
ours
like
because
right
now
we
only
support
the
backdrop.
Packages
repository
only
includes
really
backdrop
core.
It
doesn't
include
contrib
modules.
D
C
I
think
an
important
perspective
to
look
at
with
that
is
security,
Audits
and
then
number
of
tools
that
are
built
to
essentially
use
the
Project's
manifest
files
to
determine
whether
it's
including
code
that
isn't
secure,
and
so
that's
where
I
think
in
the
interim,
just
having
the
version
of
PHP
the
version
of
backdrop,
the
version
of
simple
sample
PHP
is
enough
for
our
security
team
to
be
like,
okay.
Well,
what
you
add
after
you
do,
the
install
is,
is
you
know
up
to
you
and
depend
on
the
backdrop's
own
reporting
for
security
updates
there?
C
A
E
E
I
think
that's
the
absolute
worst
thing
that
can
happen
to
open
source
because
then,
once
a
developer
has
a
patch
for
a
problem.
They're
never
checking
to
see
if
there's
a
security
problem
with
that
patch
they're,
never
checking
to
see
if
anyone
has
ever
updated
that
patch
and
as
long
as
the
patch
applies
to
the
module.
That
project
is
never
getting
any
more
attention.
You're.
C
E
But
like
never
get
any
changes
in
the
patch
you're
running
will
apply
for
10
years,
even
though
there's
a
massive
security
vulnerability
in
your
patch,
and
you
wouldn't
know
that
if
you're
never
checking
the
issue
to
see,
if
there's
any
issues
with
it,
so
there
is
some
work
going
on
in
the
Drupal
Community
about
this.
Like
composer
causes
Less
open
source.
E
Issue
where
they're
trying
to
put
like
better
documentation
in
the
composer
messaging
so
that
it
will
be
like
this
is
not
the
most
recent
comment
on
your
issue
anymore,
stuff,
like
that
to
try
and
prompt
developers
to
look
at
issues.
But
it
is
I
think
a
problem
that
we
need
to
would
think
would
need
to
figure
out
with
composer.
C
A
Well,
anyway,
yeah
I,
guess
you
know
we
don't
need
to
to
get
into
it
any
further,
I'm,
not
sure
that
we
actually
can
because
we're
running
out
of
time
during
this
meeting,
but
yeah
I
I
think
it's
it's
an
interesting
thing
to
evaluate
yeah
I'm,
not
sure
that
we'll
really
land
anywhere
different,
especially
as
far
as
core
itself
operates.
I,
really
don't
Envision
us
adding
dependencies
one's
managed
via
composer
anytime
soon,
but
yeah.
A
The
use
case,
I
I,
think,
is
interesting
and
the
ones
that
would
be
most
likely
to
that
we
see
are
people
managing
their
backdrop.
Sites
with
composer,
so
yeah
and
I
know
that
that
opens
up
all
kinds
of
issues.
Things
like
our
project,
installer,
for
example,
Kevin
is
saying
it's
so
great.
A
You
guys
have
project
installed
that
only
works,
because
we
don't
have
dependencies
in
our
modules
right
as
soon
as
a
module
has
a
dependency,
that's
externally
managed
or
installed
via
composer
that
module
doesn't
work
via
the
project
browser
anymore
and
so
I
mean
that's,
that's
a
blessing
and
a
curse.
Stripe
module
again
is
a
great
example.
It
bundles
the
entire
stripe
API,
and
so
when
you
install
the
stripe
module,
it
actually
works.
E
A
B
A
C
Then
the
issue
that
keeps
coming
up
in
in
Drupal
is
front
end
dependencies
with
with
recipes,
and
you
know
updating
the
modernizing
distributions.
Like
we're
reliving
the
same.
You
know
wysiwyg
plug-in
arguments
we
had
10
years
ago.
C
The
you
know,
even
the
initial
install
profile
packaging
didn't
allow
third-party
dependencies
and
we
were
still
had
rules
about.
You
know
adding
10k
of
JavaScript
in
your
module
if
it
ever
existed
anywhere
before
Drupal
and
so
yeah
I
mean
how
useful
is
a
automatic
update.
If
you
can't
update
the
front
end
dependencies
that
go
with
the
project.
C
So
there's
a
lot
of
discussions
happening
around
that
as
well.
No,
you
know
Concrete
Solutions,
a
lot
of
people
have
lots
of
opinions,
and
so
it
takes
a
long
time
to
get
any
kind
of
coalescer
on
any
kind
of
consensus,
so
we'll
see
where
that
goes,
but
yeah
as
far
as
yeah
like.
If
we
convert
our
bundles
to
recipes,
they
would
still
be
opinionated
in
that
they're
designed
to
work
with
the
theming
that
goes
along
with
the
the
install
profile.
Now.
Can
we
create
generic
versions
of
this
functionality?
C
Sure
we
probably
could
do
that
as
well.
Can
we
do
that
in
the
time
we
have
to
migrate
all
these
sites?
Probably
not
so
that's
where
I
don't
know
if
we
should
keep
those
like
create
backdrop,
recipe
modules
that
we
don't
put
in
backdrop
or
we
put
them
out
there
with
a
disclaimer
like
we're
doing
now
on
drupal.org.
That
says
this
is
only
going
to
work
with
the
express
install
profile
which
is
really
only
designed
to
work
for
this
one
use
case.
E
A
Know
it's
like,
and
the
other
options
are
a
lot
of
work
and
not
necessarily
better
and
introduce
new
problems.
So
yeah
we've
got
problems
with
what
we're
doing
right
now,
like
the
out
of
date,
dependencies
for
example,
and
there's
problems
with
switching
that
you
know,
create
all
kinds
of
new
issues
and
so
yeah
the
the
decisions
that
we've
made
right.
Now,
though,
there's
clear
reasons
for
sticking
with
them
project
browser
working,
for
example,
is
the
most
compelling
reason.
E
A
Update
Manager
for
that
manner
that
matter
that
update
manager
also
updates
your
dependencies
as
long
as
your
dependencies
are
bundled.
It
is
interesting
like
we
like
contrib
kind
of
decide,
there
is
still
I.
Think
there's
I
can't
remember
what
it's
called
composer
dependencies
module,
or
something
like
that
that
if
you
want
to
use
composer
and
have
it
exposed
through
the
backdrop
UI
for
your
dependencies
are
up
to
date.
A
There's
also
like
that
option
and
a
lot
of
modules
also
like
they
bundle
a
copy,
I
think
stripe
does
this
again
they
bundle
a
cop,
oh,
they
bundle
copy,
but
they
check
the
vendor
directory
and
like
if
there's
something
in
the
vendor
directory,
then
they
take
that
one
instead.
A
So
there's
all
kinds
of
like
you
know:
contrib
is
kind
of
experimenting
a
little
bit
with
different
ways
of
managing
their
dependencies
and
I.
Think
that's
also,
you
know
great.
It
would
be
nice
if
it's
not
great,
that
they
do
it
in
different
ways,
but
it
is
great
that
they're
trying
to
figure
out
what
works
so.
D
A
Okay,
yeah
any
closing
thoughts
from
anyone
else.
B
A
Well,
Kevin
thanks
for
joining
Justin,
thanks
for
for
joining
here
at
the
the
tail
end,
but
yeah
we're
we're
gonna,
wrap
up,
and
thank
you
so
much
everybody
for
for
being
here
today
and
thank
you
out
there
for
for
watching
all
right,
bye.