►
From YouTube: 2021/08/18 - Backdrop Weekly
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
Today
is
thursday
august
19th,
and
this
is
our
weekly
developer
check-in
meeting
for
bachelorette
cms
before
we
get
into
the
agenda
we'll
go
on
and
do
some
quick
introductions.
So
if
ever
you
can
say
what's
your
name
where
you're
from
and
if
you
want
to
share
something
with
us,
that's
not
currently
on
the
agenda.
You're
welcome
to
do
that.
I'll
go
first.
My
name
is
jen
lampton,
I'm
joining
from
oakland
california,.
A
Excited
about
some
of
the
css
improvements
that
are
going
into
backdrop
core
for
the
admin
theme,
let's
be
very
careful
about
that,
so
not
to
break
anyone's
sites,
and
that's
it
for
me.
How
about
justin?
Do
you
wanna,
introduce
yourself.
D
Luke,
I'm
luke
mccormick
and
san
ramon.
California,
I'm
very
excited
about
the
updates
to
backup
and
migrate,
and
so
I
I
hope
to
slide
those
in
later.
I
also,
even
though
I've
not
done
much
programming
lately
have
done
little
bits
of
programming
that
I'm
kind
of
am
you
know
hoping
to
get
into
backdrop,
so
I
maybe
want
to
try
to
bring
that
up
at
some
point.
E
I'm
robert
lang,
a
plug
folder
on
the
internet
from
altogether
california
and
I've
been
spending
time
on
backdrops
with
us.
scotland,
pass
it
down.
F
There
great
hi,
I'm
greg
I'm
joining
from
greece.
I
was
away
for
a
couple
of
months
and
back
now
to
the
issues
and
trying
to
consult
with
the
community
and
things
that
can
be
done
for
the
next
release,
pass
it
on
to
team.
A
G
In
here,
in
the
last
10
days
of
a
little
over
almost
two
weeks
of
this
release
cycle
see
if
I
can
help
shepherd
some
things
into
the
next
release.
H
Yeah
I'm
nate
lampton
from
oakland
california,
I'm
a
quick
sketch
on
the
internet
and
yeah
ready
to
get
into
things.
A
All
right,
so,
let's
see
this
week,
we've
had
one
new
contributed
project
released
and
that's
the
image
webp
module.
Thank
you
justin
for
your
work
on
that
and
luke
wants
to
add
his
enthusiasm
for
the
updates
to
the
backdrop
and
migrate
module.
A
H
Wonder
if
you
could
elaborate
on
what
that
is,
luke
and
it
looks
like
tim
smiling
as
well.
What
what
changes
have
occurred
there.
D
H
Awesome,
so
what
is
that?
What
does
that
look
like
now?
Is
there
a
release
of
backup
and
migrate?
That
includes
that
functionality,
there's
a
new
release
and,
and
what
what
happens
when
you
do
an
export
is
it
like?
C
Yeah,
that's
what
happens
so
there's
I
I
did
in
the
the
quick
like
there's
like
the
quick
export,
quick
backup
form
on
that
first
tab.
When
you
go
in
the
into
the
module
I
added
to
the
drop
down
menu,
so
you
can
export
it
lists
separately,
each
directory,
that's
in
the
settings.php
file
for
the
config.
G
Too
I
just
put
a
screenshot,
I
put
a
screenshot
in
zulu
and
it
looks
like
code
files,
there's
a
separate
options
to
export
config,
the
connective
config
or
the
staging
config
directory.
But
if
you
do
the
entire
site.
C
Prospecting
yeah,
oh
yeah,
that
might
be
something
to
address
in
another
ticket.
Oh
sure
we
could.
We
could
add
that
in
the
other
thing
I
was
thinking
about,
adding
was
you
know
having
it
having
an
option
to
grab
all
the
directories
that
once
instead
doing
them
separately,
but
it
seems
like
the
sites
only
have.
A
Yeah,
I
mean
you
with
a
default
install
of
backdrop.
The
staging
directory
will
always
be
empty.
So
when
you
do
a
backup,
all
you
really
care
about
is
live.
If
you're,
using
like
a
git
workflow
to
manage
your
configuration,
it's
pretty
common,
that
your
staging
directory
is
always
full
because
you're
always
comparing
a
diff
between
staging
and
live
and
pushing
staging
stuff.
A
I
don't
know
if
it's
important
to
back
up
the
staging
directory,
because
that's
not
representative
of
what's
actively
on
the
site,
but
I
think
it's
good
to
have
it
there
in
the
option
so
that
you
can
choose
it,
but
I
wouldn't
include
it
in
the
in
the
like
full
site,
backup
because
it
doesn't
really
have
anything
to
do
with
the
site
and
it
might
have
stuff
in
there
who
knows.
What's
in
there
might
not
be
a
recent
snapshot
of
what's
in
active
or
live
live.
F
Active
does
the
staging
anything
in
the
stadium
get
imported
in
that
situation
automatically,
you
would
have
to
trigger
it
yourself
right,
a
scene
coming
from.
F
In
general,
like
if
you,
if
you
restore
your
site,
including
the
staging
directory,
nothing
will
get
imported
automatically
right.
So
I
don't
see
any
harm
in
including
that
as
well
by
default,
because
it's
a
full
backup
of
what
it
is
or
was
on
your
other
side.
It
won't
like,
if
you're
moving.
F
F
D
You
had
to
you
had
to
know
the
different
pieces
and
set
them
up
and
orient
this
out
the
the
code
you
had
to
move
the
database
and
you
had
to
move
the
the
configuration
and
and
get
that
all
to
work
now,
if,
if
this
does
what
it,
what
what
it
the
release
center
does
like
like
now,
there's
actually
an
atomic
way
to
do
it.
You
make
a
backup
you
go
into
like
a
new
host,
that's
never
heard
of
backdrop
instead.
F
I
never
I
never
use
backup.
Speaking
of
next
steps
that
you
said,
I
never
use
backup
and
migrate,
because
I
don't
have
actual
sites
that
I
maintain,
but
but
it
has
always
like
the
the
idea
of
offering
the
a
very
minimal
sort
of
like
backup
and
migrate
functionality
import.
When
you
do
updates
upgrades
database
upgrades
has
been
floating
around
for
like
the
error
message.
Sorry,
not
the
error
message,
but
the
warning
that
we
throw
to
people
is
hey.
F
A
link
of
how
you
can
do
it
we'll
have
a
checkbox
that
say:
hey.
Would
you
like
us
to
take
a
backup
of
your
site
before
doing
anything
or
with
automated
updates?
That's
long
been
planned
right.
So
this
this
functionality
and
and
sort
of
like
having
a
precedent
of
what
needs
to
be
backed
up
being
done
by
a
contrib
module
would
help
towards
that.
But
hey.
These
are
things
that
need
to
be
considered
so
yeah.
G
H
Yeah
very
exciting:
let's
see,
let's
move
on
to
the
next
topic
here,
yeah
jen
mentioned
that
robert
had
been
doing
some
updates
to
backdrop
cms.org,
and
I
know
that
we
didn't
put
this
enumerate
what
they
were,
but
I'm
I'm
curious
just
to
hear
generally
what
kinds
of
changes
have
been
happening
on
backdrop
cms.org
and
what
things
we're
planning
on
on
tackling
in
the
future
robert,
if
you're
up
for
it.
H
If
you
could
kind
of
outline
the
kinds
of
problems
that
you've
been
looking
at
and
and
where
they've
been
moving.
E
Okay,
yeah
so
there's
some
a
recent
fix
or
improvement
to
how
the
recommended
releases
were
displayed
on
the
project
pages
and
that's
been
merged
in
and
is
working.
But
there
has
been
a
long-standing
problem
that
the
recent
releases
display,
whether
all
or
the
update
vanishes
randomly
from
from
modules.
E
So
you
go
to
the
project
page
for
a
module
and
there
are
no
releases
at
all
shown,
and
so
this
this
has
been
around
for
a
long
time
and
what
we
and
it's
an
ongoing
problem.
What
we've
learned
is
that,
first,
you
can
bring
them
all
back
just
by
clearing
the
cache
and
it
seems
to
be
narrowed
down
to
the
caching
of
one
particular
table
that,
for
some
reason,
seems
to
occasionally
be
stored
empty
rather
than
having
releases.
E
So
most
recently,
as
of
today,
put
in
some
instrumentation
to
check
when
that
table
is
generated
and
cached
and
see
if
it's
empty
and
at
least
we'll
and
then
throw
some
information
in
the
watchdog
log
so
that,
if
it
is
generated
empty
will
at
least
know
a
little
more
about
the
circumstances
under
which
it
happens.
Because
looking
through
the
code
is
not
it's
not
obvious,
why
why
it
doesn't
work
every
time?
E
So
that's
one
thing:
another
ongoing
thing
that
we
made
some
recent
changes
and
we'll
be
making
more
is
related
to
spam
accounts
on
backdrop
cms.org
we
had
been
getting
about
20
spam
accounts
per
day,
created
on
on
the
site
where
people
would
put
the
spam
content
in
their
profile
and
then
link
to
gambling
sites
and
this
and
that
and
so
to
made
some
changes
on
user
registration
to
put
the
biography
field
in
the
user
registration
form.
So
that
will
look
at
that
and
block
it.
E
If
a
kismet
says
it's
spam
and
that
has
been
happening,
but
only
for
a
few
most
of
the
sites
are
not
spammy
enough
for
most
of
the
accounts
are
not
spammy
enough
for
attisma
to
flag
so
that
they're
still
getting
through
it.
Where
doc
willmott
is
supporting
a
spambot
module.
We
looked
up
the
ip
addresses
for
some
of
the
spam
accounts
and
it
looks
like
about
50
of
them
are
in
the
stock
forum
spam
database.
E
That's
obviously
not
a
long-term
solution,
but
I
think
if
we
build
up
some
multi-layered
defenses,
we
should
at
least
be
able
to
get
the
number
down
to
only
a
handful
and
maybe
get
rid
of
them
all.
H
B
H
Yeah,
that
sounds
like
a
lot
of
a
lot
of
good
improvements
and
thank
you
for
your
diligence
and
cleaning
up
those
spam
accounts.
That's
that's
wonderful
that
I
mean
I
I
think
at
some
point,
we'll
probably
always
have
to
have
some
human
moderation
in
there.
So
thank
you
for
your
time
and
it
sounds
great
that
you
know.
We've
been
improving
the
tooling
a
little
bit
to
just
make
that
less
tedious
process,
because
there
probably
will
be
a
human
involved
for
quite
some
time.
So
awesome
wow,
that's
a
lot
of
great
stuff.
H
Let's
see,
I
think,
that's,
oh!
No!
No!
We!
We
have
another
topic
of
general
discussion
that
we
wanted
to
get
into
before
we
go
into
the
project
update
and
that's
an
issue
that
gregory
flagged
that
this
week
issue
5160
the
ability
to
have
javascript
test
execution.
H
F
F
Yeah
the,
why
is
easy,
there's
a
lot
of
things
that
we
update,
most
obvious
that
come
to
mind
is
ck
editor,
where
we
do
a
lot
of
manual
testing.
So
we
should
automate
that,
for
obvious
reasons,
things
that
we
might
miss,
but
also
you
know
save
time,
but
then,
because
recently
I
have
gotten
back
to
pull
requests
and
some
of
them
require
using
or
would
have
worked
better
if
they
used
states
and
states
misbehaves.
F
In
several
occasions
I
noticed
that
in
drupal
land
there's
a
lot
of
work
done
to
add
tests,
and
so
I
thought,
hey,
there's
a
whole
matter
of
you
know,
tests
being
added
for
for
every
possible
state
for
elements,
and
I
said:
could
we
backport
those,
but
all
these
depend
upon
the
javascript
automated
testing
framework
that
drupal
has
added
which
we
don't
have
so
this
is
why
the
discussion
is
happening
of,
should
we
add
it
and
then
I've
done
a
little
bit
of
resets
in
the
8.1
version
of
drupal.
F
They
introduced
a
specific
framework
that
was
based
on
phantomjs.
Now
they've
changed
to
something
else,
not
now
since
8.5
or
8.6,
and
now
they're
trying
to
deprecate
the
older
one
in
favor
of
the
new
one.
So
the
question
the
additional
questions
there
is
do
we
want
to
follow
their
example,
does
does
that
tie
up
with
our
code
base
and
would
that
be
the
most
beneficial
one
for
us?
Would
it
make
easier
to
backport
any
tests
from
drupal
land
to
cover
our
situations?
F
Things
like
that,
but
then
things
that
we
need
to
note
is
that,
as
it
is
simple
test
now
runs
with,
whatever
people
have
already
set
up
on
their
local
like
php
versions.
Basically
sorry
php
binaries,
but
testing
javascript
will
require
things
like
selenium
and
yeah
additional
things.
F
The
argument
there
is
that
we
don't
have
to
impose
any
such
complications
to
developers,
so
we
we
don't
have
to
require
any
such
tests
to
run
on
the
local
if
they
don't
touch
any
of
that
code,
but
we
can
set
up
our
automation,
our
ci,
to
actually
run
those
tests
for
them
to
ensure
that
nothing
is
broken.
F
H
Yeah,
there's
lots
of
things
have
changed
so
dramatically
on
the
on
the
like
javascript
testing
side
of
things
like
in
the
past
five
years
that
it's,
it's
really
kind
of
surprising,
yeah,
selenium
kind
of
kicked
off
the
like
hey,
you
can
execute,
you
can
have
a
browser,
do
something
in
an
automated
fashion,
but
selenium's
api
for
communicating
with
browsers
they've
created
it
as
a
standard
as
a
way
to
like
make
it.
H
So
chrome
in
particular,
is
kind
of
the
preferred
testing
tool
just
because
it
hardly
requires
any
additional
software
whatsoever
like
if
you
install
chrome
or
chromium
on
your
testing
environment,
then
you
can
pass
commands
directly
to
it.
H
As
long
as
like
chrome,
like
is
in
the
terminal
command
path,
which
makes
it
super
convenient
because
most
people
already
have
chrome
actually
on
their
computers,
and
so
the
amount
of
extra
installation
steps
that
is
required
is
like
super
minimal
and
that's,
in
my
opinion,
preferable
over
selenium,
which
selenium
can
still
be
used
in
the
same
way,
and
then
it
can
talk
to
any
browser.
Like
you
know.
H
Well
many
browsers,
I
should
say
as
like
a
a
a
light
abstraction
layer
in
between
like
receiving
the
commands
and
then
passing
them
off
to
the
browser.
I
I
think
yeah.
I
might
lean
a
little
bit
more
towards
the
like.
Let's
just
go
directly
against
chrome,
but
really
it
hardly
makes
any
difference.
As
far
as
like
the
writing
of
the
tests
and
the
sending
of
the
commands
to
a
browser
is
always
the
same.
H
Yeah,
I'm
excited
about
the
the
prospects
there
and
yeah
using
something
like
phantomjs
is
completely
unnecessary
at
this
point
that
was
you
know
before
browsers
could
receive
commands
like
there
were
these
other
third-party
libraries
that
kind
of
acted
as
though
they
were
browsers
that
were
basically
like
headless
web
browsers
themselves,
and
so
yeah
now
now
being
able
to
send
commands
to
browsers
stuff
like
that
is,
is
not
needed.
H
It's
better
to
be
using
a
browser
that
is
fully
maintained
and
is
actually
what
users
are
using
as
well,
so
you
get
identical
results
between
production
or
end
user
browsers
and
and
your
test
suite
so
yeah.
The
nice
thing
is
that
we
can
skip
over
this
javascript
test
space
entirely
just
go
right
to
what
they
call
web
driver
test
base.
That
seems,
you
know
like
a
reasonable
name,
yeah
and,
and
just
go
with
that.
I
I
don't
even
think
other
than
ensuring
that
chrome
is
installed.
F
Yeah
well
the
the
change
record,
for
that
does
have
some
instructions
there,
how
you
sort
of
like
they
provide
a
was
it
some
default
xml
file
that
configures
things
and
whether
you
can
choose
to
run
chrome
or
firefox
and
options
like
that.
But
this
can
be
in
documentation
that
we
can
have,
and,
as
I
said,
we
we
shouldn't
or
we
we
have
the
option
to
not
impose
these
tests
to
people
not
force
them
to
to
set
it
up
on
their
local.
F
F
F
H
Yeah
looking
at
this
change
record-
and
I'm
not
super
familiar
with
the
approach
like
how
like
the
complete
way
that
drupal
took
this,
but
I've
seen
the
change
record
that
it's
like
the
tests
are
being
executed
with
php
unit,
which
we
don't
use.
But
we
use
simple
test
which
is
still
in
triple
eight
and
nine
as
well.
Yeah.
H
And
yeah,
I'm
not
I'm
not
sure.
I
don't
think
we
want
to
get
into
that.
At
this
point,
I
think
that
we
probably
would
make
a
new
driver
for
for
backdrop
that
we,
the
testing
suite,
already,
has
like
a.
I
can't
quite
remember
what
the
two
ways
executes
are.
H
Actually,
I
think
there
might
be
might
be
three
there's
like
something
that,
like
imitates
like
doing
ajax
requests
as
one
of
the
drivers,
I
think,
and
then
the
the
main
one
that
he
uses
is
the
one
that
just
uses
curl
to
do
all
of
the
web
requests
and
backdrop
can,
you
know,
create
a
new
class
that
is
like
the
the
driver
for
using
a
web
browser
instead,
and
so
the
first
step
is
making
that
new
driver
for
simple
test
that,
instead
of
using
curl,
it
uses
chrome
driver
or
a
web
driver,
and
then
we
need
like
at
least
one
test
that
actually
uses.
F
F
So
can
I
thank
you
for
whenever
you
have
time
on
to
sort
of
like
outline
the
next
steps
in
details?
Nate,
just
you
don't
have
to
do
any
of
the
work
at
least
the
technical
direction.
Basically,.
H
Yeah,
I
think
what
I'm
going
to
need
to
do
is
look
at
drupal's
classes
and
see
like
if
there's
already
like
a
simple
test
version
of
this
web
driver
test
space
like
and
if
that
is
suitable
for
for
porting
or
if
we
need
to
make
some
kind
of
mixed
approach
where
it's
like.
H
I
think
the
the
javascript
test
base
probably
was
only
written
for
simple
tests,
and
so
that
actually
might
look
like
a
good
template
for
us
to
make
our
new
class,
but
then
the
implementation
we
might
need
to
pull
from
the
webdriver
approach.
So
yeah.
I
think,
there's
definitely
a
lot
of
code
here
that
we
can
probably
port
over,
but
it
might
not
be
a
direct.
You
know
one
to
one,
because
our
tooling
is
different.
F
Yep
all
right,
I
just
think
you
there
might
as
well
sign
it
to
the
issue
to
you:
okay,
yeah.
I
imagine
that
this
is
a
big
rather
big
undertaking
unless
we
have
one
of
those
moments
that
hey
it's
already
possible.
H
Yeah,
I
actually
don't
think
this
is
as
big
as
it
sounds.
At
least
the
initial
capability,
I
don't
think,
is
actually
very
tedious
as
long
as
we
get
github
actions
in
place
because
we
need
to
be
able
to
control
the
software,
that's
on
our
boxes
more
easily,
and
so
github
actions
is
kind
of
a
blocker
yeah
yeah,
let's,
let's
just
transition
that
talk
right
over
into
github
actions,
because
that's
on
the
agenda
for
this
week
as
well.
H
Well,
let's
see,
let's
also
mention
that
issue
is
5160,
that
javascript
testing
capability
for
anyone
out
there
listening
github
actions
using
that
for
our
tests.
We've
been
moving
this
direction
pretty
solidly
for
the
past
couple
of
weeks.
Now
the
issue
number
is
47.53
indigozala's
work
there.
We
think
that
we
have
the
pull
request
for
running
the
tests.
Pretty
well
figured
out.
It's
it's
executing
it's
running.
The
test
still
looks
really
great,
however,
oh,
and
we
also
solved
one
of
the
consistently
failing
tests.
H
The
bootstrap
page
cache
test
we've
solved
that
one
last
week
and
that
issue
is
now
also
out
of
the
way
the
only
real
blocker
it
looks
like
we
have.
Is
that
what
had
been
an
intermittent
failure
on
zen,
ci
related
to
locale
module
is
a
consistent
failure
on
github
actions.
So
we
don't
have
an
issue
yet
for
this
exact
locale
module
test
failures,
but
it
is
kind
of
covered
by
the
intermittent
test.
H
Failure
or
random
test
failures,
issue
1478.,
so
it's
mentioned
there,
but
the
actual
text
of
the
failure
is
in
the
github
actions.
H
Issue
4753,
and
I
think
that's
our
big
item
now
is
that
that
test
is
failing
so
frequently
on
github
actions
that
it's
required,
that
we
figure
that
one
out
in
order
to
switch
over
to
github
actions.
But
that
seems
like
that's
our
big.
Our
big
blocker
right
now
is
that
we
have
a
test
failure.
It's
just
two
tests.
It's
the
importing
of
locale
po
files
seems
to
be
failing
on
github
actions
and
yeah.
If
we
can
get
that
sorted
out,
that's
that's
our
big
thing
there.
H
To
get
switched
over
because
it'll
just
make
our
lives
a
lot
better
to
not
have
zen
ci
fighting
us
all
the
time.
F
H
Yeah,
I
know
this
issue
comes
up
all
the
time
about,
like
hey,
there's,
just
this
one
thing:
can
we
disable
or
comment
it
out
or
something
like
that,
because
the
return
on
the
value
is
a
lot
greater
than
the
thing
that
we're
commenting
out
and
as
this
isn't
official
policy,
but
I
think
is
a
pattern.
The
answer
to
that
is
always
no.
H
We
cannot
because
if
we
leave
something
for
later,
it
doesn't
get
done,
and
so
I
mean
this
probably
isn't
a
big
task
to
fix
this
issue,
but
it
could
be
like
a
frustrating
one.
You
know
and
that's
the
sort
of
thing
that's
like.
Oh
here's,
this
problem,
that
is,
requires
a
very
unique
environment
to
set
up
and
nobody
can
reproduce
it.
It's
the
exact
sort
of
thing
that
we
would
never
go
back
and
fix.
H
So,
even
if
the
situation
was
different,
I
think
the
answer
to
that
question
should
be.
We
have
to
fix
it
before
we
merge
something
it's
kind
of
like
the
equivalent
of
like.
Can
we
merge
something
in
without
tests?
You
know,
especially
if
it's
something
that
fixed
regression
and
then
we
had
to
wait
a
long
time
for
the
test
to
get
written,
but
otherwise
they
they
wouldn't
have
gotten
written
at
all.
So
yeah,
it's
frustratingly
the
answer
pretty
much
all
the
time,
but.
A
I
don't
know
something
weird
going
on
with
github
action.
It
would
be
good
to
make
sure
that
we
got
all
that
stuff
working
like
it
could
be
some
kind
of
you
their
know,
issue
or
who
knows.
F
Speaking
about
all
the
tests,
this
thing
about
the
time
zone
thingy
comes
to
mind
and
I
thought
that
we
had
it
figured
out
like
it
was
it
two
years
ago
or
something
like
that
and
every
now
and
then
it's
sort
of
like
not
as
often
but
it
still
creeps
and
I
go.
I
was
a
hundred
percent
sure
that
I
sorted
out
like
I've
tested
everything
I
don't
know,
maybe
when
we
move
to
github
actions
I'll
get
to
have
another.
Look
at
that,
but
yeah.
H
Yeah
well
anyway,
github
actions,
all
in
all,
looking
really
looking,
really
good
and
very
promising
the
local
module
test
is
is
where
our
issue
is
now.
F
Can
I
can
I
ask,
because
I've
been
away
while
things
have
been
progressing,
it
seems
to
me
that
we
are
splitting
the
the
amount
of
tests
in
three
sections
in
three
segments.
Is
that
happening
automatically
or
have
we
sort
of
like
grouped
and
grouped
the
tests.
H
So
back
back
when
we
were
evaluating
other
ci
providers,
when
we
were
on
travis
for
a
little
while
we
added
an
option
to
the
runtests.sh
script
that
could
automatically
split
things
into
into
fragments
or
into
into
percentages,
and
so
we're
using
an
existing
option.
That
just
says
run
the
first
third
run
the
second
third
and
run
the
third
third,
and
then
github
actions
has
a
matrix
capability.
That
says,
execute
the
same
set
of
scripts
with
these
different
combinations
and
we
specified
the
three
different
fractions
and
the
two
versions
of
php.
F
Yeah,
I
noticed
that
I
just
didn't
know
where
that
one
one
third,
two
third,
three
thirds
was
coming
from.
What
are
you
saying
that
this
was
a
pre-existing
option?
Ready,
okay,
cool
that
was
easy,
yeah,
okay,.
H
Yep
and
yeah-
I
had
forgotten
about
it
because
ella
was
like.
Oh
there
already
was
this
option
here
and
sure
enough.
H
Yeah
very
convenient:
let's
see
if
there's
anything
else
on
that.
Oh
just
that,
I
think
pretty
much
as
soon
as
we
get
that
figured
out.
We
will
move
swiftly
to
disables
nci,
once
github
actions
gets
turned
on
we'll
turn
off
zentia,
because
there's
so
many
actions
that
execute
now
that
it's
overwhelming,
like
on
the
pull
request
to
see
so
many
things
and
there's
also
a
follow-up
action
or
follow-up
task
that
there's
a
github
marketplace
add-on
that
collapses,
those
six
different
executions.
A
H
One
item,
instead
of
being
six
so
just
making
it
so
that
there's
not
quite
so
much
noise
on
the
on
the
pull
request.
Page.
F
We
we
also
have
a
meta
issue
for
linting
once
we
come
to
that
like
it
seemed
like
the
blocker
of
getting.
That
done
is
that
there
was
too
much
work
to
be
done.
Can
we
take
a
gradual
approach
when
it
when
it
comes
to
that,
as
in
you
know,
enable
the
linting,
but
for
specific
things
that
we
have
already
done
instead
of
having
it
failed,
because
the
entire
code
base
like
needs
like
it
would
be
a
huge
pull
request
to
get
it
all
done
in
one?
H
Yeah
I
we
can
definitely
like
some
of
the
options
that
are
out
there
only
lint
the
files
that
were
changed.
You
know,
so
that
would
be
a
good
way
of
proceeding
yeah.
We
definitely
can't
lent
the
entire
project
all
in
in
one
fell
swoop,
and
definitely
not
as
the
initial
pull
request.
H
We
may
even
do
something
like
enable
like
if
we
were,
if
we
could
get
linting
set
up,
it's
possible
that
we
could
automate
the
linting
process
like
on
the
pull
requests,
but
not
have
the
action
fail,
so
the
linting
would
be
there
and
tell
you
hey,
there's
some
issues
but
wouldn't
actually
block
the
merging
of
the
pull
request.
Something
like
that
because
we.
H
I
don't
think
I
don't
think
we'll
get
there,
at
least
in
in
the
initial
pass,
that
would
that
would
be
nice,
but
it
also
might
not
work
like
the
way.
We
might
hope.
A
We
want
we
want
the
results
of
the
like
pass
of
the
linter,
so
we
know
what
doesn't
adhere
to
standard.
So
we
don't
want
the
test
to
like
action
to
fail
if
it
doesn't
pass
so
that
way,
if
you're
working
on
a
change-
and
you
see
oh
there's
like
four
other
changes
in
this
file
that
are
going
to
fail,
the.
B
A
H
Yeah
all
right.
Well,
let's
see
we're
running
a
little
tight
on
time
here,
we'll
move
on
a
little
bit
here,
just
one
other
issue
for
119.4
that
we're
working
on
that
is
showing
a
lot
of
progress
is
issue.
3008,
brad
bulger's
issue
and
pull
request
that
he's
been
working
on
that
allows
sim
linking
the
document
root
has
been
moving
forward.
H
We've
figured
out
why
the
failures
are
occurring
on
zen
ci,
that
zentzei
itself
uses
sim
links,
and
the
tests
almost
seem
to
be
written
in
a
way
that
that
zen,
ci's,
sim
linking
may
have
been
set
up
just
to
get
the
tests
passing,
and
so
the
short
of
it
is
is
that
we
know
what
the
problem
is
now
why
the
tests
are
failing
and
we're
just
figuring
out.
What
exactly
is
the
right
solution
there?
H
As
far
as
sim
linking
goes,
brad's
pull
request
already
solves
the
major
problem
of
if
you
use
a
sim
link
for
the
entire
web
directory
route,
that
installing
and
updating
modules
now
works
correctly.
H
The
issue
that
we
have
now
is
deciding
whether
or
not
the
old
behavior
is
actually
correct
at
all.
So
it's
kind
of
interesting
like
taking
a
look
at
that
issue
and
seeing
like
if
your
hosting
situation
or,
if
you've
ever
set
up
a
site,
they
use
the
sim
links.
If
that
situation
applies
to
you
or
if
you
think
it's
a
reasonable
thing,
some
feedback
on
that
issue
could
be
helpful.
A
H
H
Okay,
let's
see
well
the
last
things
that
we've
got
to
discuss
today
is
that
it
was
mentioned
already
that
we
only
have
you
know
a
dozen
or
so
days
before
the
feature
freeze
of
1.20,
and
at
this
point
it's
that
time
where
we
figure
out
what
is
reasonable,
like
what
is
close
enough,
that
we
could
potentially
get
it
completed
in
the
next
10
days
and
start
working
towards
those
specific
issues.
H
I
think
that
this
one
and
I'm
pulling
it
up
now
hasn't
seen
any
updates
in
quite
a
while,
but
where
it
is,
is
it's
at
a
point
where
it
needs
testing
and
does
already,
I
think,
need
a
little
bit
of
extra
work
there
to
confirm
that
the
approach
is
all
okay.
H
H
Let's
see
another
one
that
is
completely
within
our
grasp.
Is
the
the
blocker
issue
for
making
recipes
possible
possible
issue
3224,
and
this
one
is
a
simple,
nearly
a
one-liner.
It's
like
one
and
a
half
lines
fix
to
make
it
so
that
config
import,
the
config
import
commands
are
run
when
a
new
module
is
installed,
and
so
the
only
thing
that
we
need
there
is
test
coverage
and
the
scope
of
test
coverage.
H
There
probably
means
making
a
new
test
module
that
includes
config
like
a
new
content
type
in
a
field,
probably
turning
that
test
module
on
in
the
testing
suite
and
then
making
sure
that
the
config
came
in.
It's
not
it's
not
a
huge
task
as
far
as
test
writing
goes,
but
yeah,
someone
familiar
with
the
process
of
making
test
modules
and
writing
a
test.
That's
the
component
there
that
is
necessary.
F
Today,
just
a
side
sort
of
like
issue:
we've
discussed
this
in
the
past,
I'm
not
sure
that
we
have
an
issue
for
it:
drupal,
8
and
beyond
control,
which
modules
are
installed
via
configuration
via
the
core.extensions.yaml
file.
We
do
not
do
that.
We
rely
on
the
database.
Would
we
want
to
do
that
we'll
allow
that.
H
I'd
have
to
think
about
it.
I
don't
I
don't
have
the
answer
to
that
right
now.
F
H
I
think
that
it's,
I
think,
it's
probably
technically
possible
for
us
to
do.
We,
unlike
the
white
drupal,
well
drupal's,
like
management
of
which
modules
are
turned
on
and
off.
You
know
they
got
rid
of
the
system
table,
but
it's
still
in
the
database
because
and
at
least
in
triple
and
all
config
is
in
the
yes
ultimately,
and
so
the
state
of
which
modules
are
turned
on
and
off
is
actually
still
in
the
database
just
in
a
different
spot
now.
H
So
I
would
imagine
that
our
approach
would
look
slightly
different,
that
the
config
files
that
are
present
there
probably
would
just
serve
as
a
guidance
for
how
to
manage
the
system
table
that
turning
stuff
on
and
off
would
just
update
the
system
table
to
match,
which
would
make
total
sense,
because
it's
the
same
thing
that
happens
for
like
field
creation,
that
you
can't
just
create
a
field
in
the
config
and
expect
it
to
work.
You
also
have
to
create
the
matching
database
tables,
so
this
kind
of
we
need
the
config
to
control.
H
What's
in
the
database
is
a
completely
reasonable
and
manageable
thing
for
backdrops
config
system
to
handle,
and
we
can
do
it
in
a
backwards
compatible
fashion
because
the
system
table
has
to
stay
there
because
there's
a
lot
of
things
like
hook,
installs,
for
example,
that's
at
the
module
weight
in
the
system
table
as
one
of
the
things
that
they
do
so
yeah.
It's
it's
possible
yeah.
F
A
Okay,
we
might
want
to
raise
a
new
one.
It
might
be
thinking
about
the
drupal
issue,
where
I
protested
loudly
and
lost.
A
Yeah,
because
I
think
I
think
we
would
have
to
think
about
doing
it
more
the
way
we
do
other
stuff
with
backdrop,
but
it
could
definitely
be
done
something
where,
like
you,
would
go
to
import
a
config
file
and
it
would
throw
an
error
and
say
sorry:
you
can't
uninstall
this
module
unless
you
do
a
manual.
It's
the
same
way
we
handle
fields
but
like
turning
stuff
on
isn't
risky,
so
we
could
have
like,
if
you're
turning
it
on,
we
can
do
that
we're
turning
up.
B
F
H
Yeah,
I
think
I
think,
in
the
land
of
drupal
this
got
into
the
uninstall
versus
disable
debate
too,
that
that's.
A
A
F
H
Yeah,
that's
what
we
do
for
fields
to
elaborate
on.
That
is
that
fields
can't
be
deleted
with
a
config
import,
but
what
you
can
do
is
delete
the
field
in
the
ui
needs
to
make
sure
that
all
of
the
the
data
has
been
cleaned
up
and
then
you
can
import
the
config
with
the
fields
missing
and
the
configuration
says.
Oh
that's
fine!
You
know
because
the
field's
already
gone.
F
So
I'm
referring
to
issue
5141,
where
it's
a
node
situation,
where,
if
the,
if
you
remove
all
the
content
types
from
your
site
and
then
you
try
to
create
a
new
content
type,
we
automatically
try
to
add
the
body
field
with.
F
A
F
Pass
from
one
issue
to
another,
so
there
was
a
previous
issue
which
was
raised
by
bw
panda.
It's
30
35,
where
we
added
the
ability
to
sort
of
like
override
programmatically
override
whether
the
body
field
is
created
or
not,
and
bw
peter
has
started
it
as
we
should
add
it
as
an
option
in
the
ui
and
then
nate
you
jumped
in
and
said
no,
we
shouldn't,
we
just
had
some
way
that
we
can
override
it.
F
A
F
Well,
the
I
have
I've
had
something
I'll,
maybe
I'll
raise
a
separate
ticket
as
an
alternative,
but
on
my
local.
The
way
that
I
have
it
working
is
that,
even
if
it
has
been
completely
removed
because
that's
a
situation
that
can
happen
ticking,
that
tech
box
basically
runs
a
function
that
we
have,
which
is
called
not
that
body
field
which
recreates
it
so
so
yeah.
F
F
Yeah,
I
guess,
but
if
you
already
have
the
thing
you
need
to
in
the
background
check,
if
it's,
but
we
could
check
and
then,
if
it's
not
there,
make
it
yep
anyway
I'll.
I
I've
been
working
on
my
local.
You
know
solutions
like
I'll
as
soon
as
I
have
a
something
workable
as
an
authority
I'll
throw
that
there
and
people
can
find
me
cool.
A
F
H
G
H
You're
heading
with
that,
but
I
think
that
adding
the
option
is
like
it's:
it's
adding
friction
because
the
user
has
to
make
that
decision
every
time
they
create
a
new
content
type
and
the
the
the
small
overhead
of
deleting
the
body
field
after
it's
been
added.
Doesn't
it's
not
really
that
great?
So
I
would
prefer
not
to
add
the
option
and
just
let
them
delete
the
field
again
manually
if
they
need.
B
H
H
Well.
Actually,
maybe
I'll
turn
this
over
to
tim,
to
talk
about
it
for
a
second
or
two.
G
H
Yeah,
that's
okay,
yeah,
so
we
have
some
preliminary
things
that
need
to
happen.
We
need
to
get
the
project,
module
changes,
merged
into
project
module
and
deployed
onto
backdrop
cms.org.
I
think
that's
like
something
that
needs
to
be
done
to
increase
the
ease
of
testing.
A
Okay,
well,
if
you
want
to
do
the
project
module
work,
I
can
work
on
getting
it
onto
the
backdrop.
Cms
org.
C
H
Yeah,
it's
not,
you
know
it's
literally,
just
updating
the
module
once
it's
in
project
module
and
then
I
think,
there's
an
outline
of
all
the
things
we
need
to
do
in
core
itself,
but
we
may
like
scope
down
our
ambition
there,
a
little
bit
like
we
could.
Potentially,
I
think
we
talked
about
this-
include
telemetry
module
in
core,
but
not
actually
turn
it
on
or
not
have
an
option
to
turn
it
on
something
like
that
and
then
it
would
literally
be
a
totally
voluntary
opt-in.
H
A
A
H
The
amount
of
work
that
it
does
the
telemetry
module
itself
is,
it
is
not
a
large
module
yeah,
it's
literally
just
like.
What's
the
php
version,
what's
the
my
sequel
version,
okay,
one
like
post
request,
you
know
on
a
daily
basis,
weekly
basis.
You
know
that
it
just
sends
the
data
out
to
somewhere
all
the
complexities
in
the
aggregation
and
display
and
storage.
That
is
on
backdrop,
cms.org.