►
From YouTube: Backdrop Weekly Dev - 2021/07/01
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
folks,
it
is
july
1st
2021.
A
This
is
the
weekly
backdrop
developer
meeting
where
we
get
together
every
week
and
talk
about
pressing
issues
that
are
facing
the
backdrop
project
primarily
around
development
tasks
and
issues.
I
will
do
some
quick
introductions.
A
My
name
is
nate
lampton,
I'm
quick
sketch
on
the
internet,
I'm
core
committer
and
that's
all
oh
and
I'm
in
oakland.
California,
let's
see
tim,
can
we
get
an
update
from
you.
B
Sure
my
name
is
tim
erickson,
saint
paul
tim.
I
am
ian
dear
with
minnesota
and
I'm
busy
a
little
bit
busy
with
backdrop
live,
which
is
a
week
from
tomorrow.
C
Robert
I'm
robert
lang,
a
bud
folder
on
the
internet,
I'm
in
altadena
california
spending
time
on
box
things
and
the
reason
I
started
just
about
a
minute
ago
was
because
a
bobcat
walked
by
my
window
about
10
feet
away.
D
I'm
just
in
christopher
said
I'm
in
denver,
colorado
and
just
help
out
with
infrastructure
when
I
can
and
I've
been
reporting
some
modules
recently.
A
D
A
All
right,
that's
it
for
those
of
us
present
today.
The
structure
of
this
meeting
is
is
currently
in
flux.
We're
trying
different
things,
trying
to
make
these
meetings
more
efficient
and
effective
tools
for
the
community.
A
One
thing
we
did
differently
this
week
is
that
we
posted
we
created
the
agenda
a
week
beforehand.
So
at
the
end
of
last
week
we
created
this
week's
agenda
posted
to
the
forum
forum.packtrapcms.org
and
then
solicited
requests
for
additional
changes
like
to
the
agenda
that
could
be
added
throughout
the
week.
A
Add
a
couple
of
different
approaches
to
that
and
godzilla
posted
a
couple
of
comments
that
were
in
the
forum.
I
took
those
comments
and
put
them
into
the
agenda
so
that
we
can
discuss
them
today
and
robert
went
through
and
added
some
things
directly
into
the
agenda,
which
you
can
add
stuff
directly
to
the
agenda.
If
you
just
ask
to
be
added
to
the
folder
on
it's
on
google
docs,
and
then
you
can
edit
the
documents
directly.
A
So
that's
pretty
exciting,
because
that
seemed
to
have
worked
pretty
well.
I
got
a
chance
to
look
through
all
of
the
issues
before
the
meeting.
There's
lots
of
things
have
been
added
like
eight
or
ten
different
issues,
so
we'll
be
going
through
all
of
those.
Today
and
tim,
you
wanted
to
mention
a
couple
of
things
related
to
the
recordings
as
well
about
on
the
meetings.
B
Okay,
just
really
briefly
let
people
know,
since
recording
meetings
has
been
a
big
discussion
lately
that
something
has
changed
with
youtube
we
used
to
just
by
the
way
we
named
our
meetings
that
they
would
automatically
get
put
into
playlists
and
we
had
a
playlist
for
the
outreach
meetings,
a
playlist
for
the
dev,
the
design
meetings
in
a
playlist
for
the
dev
meetings.
B
Apparently,
that
feature
has
been
removed
from
from
youtube,
and
so
for,
like
the
last
three
or
four
months,
I
think
our
meetings
have
not
been
getting
sorted
into
those
playlists,
which
meant
that
we
had
like.
We
have
like
a
screenshot
of
the
most
recent
dev
meeting
on
the
on
backdrop.org,
and
it
was
still
showing
a
meeting
from
like
three
months
ago,
because
none
of
the
new
meetings
had
been
automatically
put
into
that
directory
like
we
thought
they
were.
B
So
I
just
wanted
to
mention
that
one.
So
people
see
that
problem.
They
understand
why
two,
if
people
have
ideas
for
how
to
solve
that
other
than
we
can
manually
each
week,
add
our
our
recordings
into
the
playlist.
We
just
have
to
remember
to
do
that
and
I
guess
if
people
notice
that
they
haven't
been
added
to
the
playlist
and
they
don't
have
permission,
they
could
just
ping.
You
know
us
and
zulu,
but
we
could
remember
to
do
that
so
otherwise
they
do.
They
still
show
up
on
the
in
the
list
of
the
videos.
A
Okay,
yeah
thanks
for
the
heads
up,
so
if
you
visit
the
channel,
all
of
the
videos
are
still
there,
except
for
some
of
the
ones
that
have
disappeared
recently
and
that's
a
whole
different
thing.
A
Okay,
yeah
thanks
for
the
heads
up
tim,
so
I
guess
after
meetings
we'll
need
to
make
sure
that
we
put
them
into
the
playlists
again.
Did
you
already
go
through
the
old
ones
and
put
them
all
into
the
playlist
again.
A
Sorry,
you
haven't
you're
you're,
muted,
again,
okay,
you
know
I.
A
Okay,
all
right,
so,
let's
see
we
don't
have
any
updates
from
the
pmc
today
contributed
projects
with
three
new
contributed
modules.
In
the
past
week,
viewport
module
user
picture
field,
module
and
image
link
to
file
module
thanks
folks
for
doing
the
porting
of
these
new
contrib
modules
that
come
in
at
a
city
clip
pretty
much
every
week,
let's
see
backdrop
cms.org.
A
We
actually
have
a
number
of
issues
to
discuss
today.
One
recurring
issue
that
has
been
on
the
agenda
for
a
while
is
that
we're
trying
to
make
it
so
that
we
can
add
additional
data
in
info
files
of
modules
and
then,
when
the
packager
runs
that
we
would
take
the
value
from
the
dot
info
files
out
of
the
module
and
then
apply
it
to
nodes
that
are
on
backdrop
cms.org
for
like
categorization,
for
example,
the
issue
is
487
and
we
made
deployments
to
backdrop
cms.org
with
the
code
changes
there.
A
Doc
belmont
has
been
testing
out
the
in
production
functionality
of
adding
additional
data
to
info
files
and
is
finding
that
we're
getting
some
errors
on
the
production
site
and
the
values
aren't
actually
getting
saved.
So
so
we
still
need
some
more
work.
There.
I've
moved
that
issue
or
he
moved
that
issue
back
into
an
open
state
and
we
probably
need
some
adjustment
and
debugging
to
figure
out
why
those
values
aren't
saving
correctly.
A
Let's
see,
then
we
get
into
several
issues
that
robert
put
on
the
agenda
for
this
week:
project
release
date
versus
postdate
issue
793.
In
the
backdrop
cms.org
issue,
let's
see
robert,
if
it's
okay,
could
you
describe
that
issue
and
the
the
changes
that
you
have
proposed.
C
Sure
the
just
like
I'm
gonna,
bring
it
up,
so
I
can
look
at
it
directly.
C
C
But
then
beyond
that,
we
came
up
with
a
couple
who
realized
that
there
were
some
problems,
some
other
problems
that
were
part
of
the
same
view
that
was
generating
all
that
data
that
the
because
the
post
date
was
actually
coming
from
a
view,
and
so
I
ended
up
rewriting
aspects
of
the
view
there
were.
There
were
a
couple
things
there's
a
table
that
had
a
heading
of
download
and
then
immediately
below
it.
The
link
was
titled
download
version,
and
so
that
was
redundant
and
pick
up
extra
space.
C
So
we
took
out
the
redundant
download,
the
recommended
releases
and
other
releases
were
treated
differently.
One
had
a
download
icon,
the
other,
didn't
the
the
other
releases
didn't
include
their
release
date.
C
So
rejiggered
the
view
so
that
now
it
shows
the
actual
release,
dates
for
both
the
recommended
and
other
releases,
remove
superfluous
word,
download,
load,
added
icons
and
then
over
in
the
right
sidebar.
Yes,
thank
you
over
in
the
right,
sidebar
removed
some
redundant
information
and
so
what
you're?
Seeing
now
at
the
top,
those
first
three
lines.
Other
releases
recommended
release
date,
that's
not
necessary
because
it's
it's
right
next
to
it
on
the
right,
and
so
we
just
start
with
cl
versions.
C
I'll
also
mention
that
I
have
in
mind
some
changes
to
this
section.
That's
got
the
subject,
the
heading
github.
C
We
do
want
to
link
to
the
project
page,
but
I
want
to,
I
think,
rather
than
calling
it
issue
cube,
call
that
make
it
more
prominent
and
say
report
issues
for
people
who
don't
understand
what
an
issue
queue
means
and
make
the
documentation
link
more
prominent,
because
it
looks
every
all
those
little
text,
things
under
github,
non-programmers
will
kind
of
say.
Well,
I
don't
I
can
ignore
that,
but
those
two
items,
the
issue
queue
and
the
documentation-
are
actually
pretty
important,
so
there'll
be
another
pr
coming
along
that
plays
with
those.
A
Yeah,
I
I
I
post
a
comment
here
as
well
saying.
Well,
I
mean
makes
sense
like
all
of
these
changes
seem
good,
there's
some
other,
like
there's
some
pretty
serious,
like
design
things
that
could
happen
on
this
page
to
improve
things
substantially.
These
pages,
I
don't
think,
have
been
specifically
designed
that
we
could
improve
them
quite
a
bit,
but
I
think
that
what
you've
done
here
is
a
good
fix,
because
it's
changing
the
content.
A
That's
on
the
page,
not
really
so
much
the
design,
and
it
seems
like
it's
all
all
beneficial
changes.
Don't
one
thing
that
makes
me
a
little
like.
I'm
not
sure
about.
That
is
the
cl
versions.
Thing
is
kind
of
not
floating
without
any
other
information
around
it,
but
but
I'm
I'm
not
opposed
to
just
baby
steps.
You
know
one
thing
at
a
time.
A
A
Totally
yeah,
that's,
I
think,
that's
a
great
set
of
changes
and
you
noted
in
the
issue
that
there's
three
separate
issues
that
have
been
filed
and
this
solves
three
of
them
all
in
one
fell
swoop,
which
is
great,
let's
see
yeah.
Does
anyone
else
have
thoughts
on
that
or
maybe
we
can
just
move
on
to
the
next
one,
because
I
think
that's
great
okay,
yeah.
The
next
next
item
on
the
agenda
is
also
related
to
backdrop
cms.org,
it's
issue
900n
or
sorry
796..
A
The
suggestion
here
put
forth
by
robert.
Oh,
actually,
that's
the
the
pull
request
number
the
issue
number
is
700
and
oh,
it
is
796
sorry.
So
the
request
is
that
we
add
the
markdown
filter
to
backdropcms.org
and
the
doc
site.
A
And
robert
wrote
up
a
long
explanation
of
why
it
would
be
beneficial,
jen
and
gregory
came
in
and
basically
also
agreed,
and
I
think
yeah.
This
has
got
a
lot
of
really
good
points
in
it
and
robert.
If
I
can
put
you
on
the
spot
again,
you
know.
If
you
could
summarize
the
arguments
here,
then
then
we
can
kind
of
have
a
discussion
now
about
the
pros
and
cons
of
doing
something
of
adding
a
new
text
format.
So
I'll
turn
it
over
to
you
again.
C
C
Here's,
the
new
markup
and
folks
who
comment
on
that
or
edit
it
and
so
forth,
and
it
makes
it
a
little
easier
because
you'll
be
using
the
same
text
in
in
your
issue,
posting
as
it
would
eventually
go
on
the
page
for
a
person,
who's,
editing
the
documentation
page
directly.
C
If
you
use
the
model
of
doing
your
composition
offline,
which
I
admit
I
do
it's
a
lot
easier
to
do-
that
composition,
offline
in
markdown
and
then
paste
it
in
rather
than
to
do
it
offline
in
you
know
the
htl
or
rich
text
which,
when
you
paste
in
is
not
necessarily
carried
over,
is
not
necessarily
converted
when
you
copy
and
paste
and
doing
one's
editing
directly
on
the
site
is
problematic,
especially
for
a
long
page,
because
you've
only
got
a
little
scrolling
window
on
the
site,
and
you
can't
when
you
save
it,
you,
when
you
save
a
version
that
you've
partially
written,
it's
made
a
permanent
change
to
the
site,
whereas
editing
offline,
you
can
edit
iterate
polish
and
then,
when
you've
got
it
really
nice
and
the
way
you
want.
E
A
So
my
past
experience
with
text
formats
has
been
especially
on
non-html
text.
Formats
has
been
pretty
negative
because
text
formats,
a
lot
of
them-
have
come
and
gone,
but
I
think
markdown
seems
to
be
bucking
that
trend,
because
with
tools
like
github
being
super
driven
by
markdown,
I
really
doubt
that
will
change
ever
and
backdrop
is
heavily
tied
into
github.
A
Our
community
members
are
all
using
get
up
for
everything,
so
it
does
seem
inevitable
that
the
people
that
are
writing
modules
or
writing
documentation,
they're
going
to
be
familiar
with
markdown
in
some
capacity
or
another.
So
this
kind
of
it
it
it's
a
different
thing,
I
think
than
before.
A
One
thing
that
makes
me
a
little
uneasy.
A
couple
things
make
me
uneasy
is
that
we
already
have
documentation,
that's
in
html
right
now,
and
there
could
be
it's
possible
like
a
little
miniature
battle
between
like
the
html
content
and
the
markdown
content
that
it's
like
you
know,
people
might
go
through
and
like
rewrite
stuff
into
markdown
just
because
they
prefer
it,
but
other
people
might
prefer
the
the
rich
text
editor
and
there's
some
content
that
may
lend
itself
to
being
better
in
the
rich
text
editor
than
in
markdown
as
well.
A
I
think
you're
you're
right
about
like
a
offline
content,
copying
stuff
back
and
forth,
like
it's
really
easy
to
use
text
file
and
it's
not
so
easy
to
copy
out
html
content.
You
can
paste
in
like
google
docs,
maybe
and
then
paste
it
back
in
and
it
gets
converted
adequately
back
and
forth,
but
it's
really
not
the
same,
but
there's
people
that,
like
to
just
edit
directly
on
the
web
page
without
copying
and
pasting
it
back
in
and
the
visual
editor
might
be
better
for
that.
A
So
there's
that
part
that
it's
kind
of
like
I'm,
not
quite
sure
what
to
do
about
that.
You
know
that's
if
we
give,
if
there's
a
choice,
people
will
have
certain
people
will
have
preferences
for
one
or
the
other,
and
then
that
can
actually
be
detrimental
to
collaboration.
If
they're
like
struggling
to
cooperate.
A
Yeah
I'll
pause
there
and
see
if
anybody
has
any
anything
else,
they
want
to
add
related
to
to
my
concerns
about
just
having
two
two
formats.
Two
options.
C
Well,
currently,
we
do.
We
have
two
options
already
on
both
sides,
but
they're
different,
because
on
one
side
it's
it's,
I
think
documentation
and
standard
and
the
other
side
it's
standard
and
something
else
so.
C
But
at
least
there'd
be
one
there'd,
be
the
one
that's
common
to
both.
I
guess
I
can
make
one
more
plug
on
the
markdown
side.
At
the
moment
we
seem
to
have
too
few
people
trying
to
edit
pages
rather
than
multiple
people
wanting
to
edit
the
same
page.
I
I
recognize.
C
A
There's
some
other,
I
mean
there's
other
benefits
too,
that
I
haven't
listed
like
release
notes,
for
example,
release
notes
and
the
project
pages
we
use
github
github.
A
Obviously
you
can
retrieve
with
the
api
the
markdown
version
of
the
readme,
but
what
we
do
is
we
github
conveniently
also
provides
a
rendered
version
of
the
html
in
html
or
sorry
rendered
version
of
the
markdown
in
html,
and
we
pull
the
rendered
version
and
put
it
into
backdropcms.org.
But
it's
like
kind.
D
A
If
you,
if
you
do
that
feature,
it
might
be
nice
if
that
used
the
markdown
version
instead
and
then
you
could
edit
the
node
on
backdrop,
cms.org
editing
the
markdown
instead
of
the
rendered
html,
but
one
thing
that's
kind
of
iffy
about
that
is
that
github
has
their
own
flavor
of
markdown.
That
is
like
nobody
else's
like
their
version
of
markdown.
Dare
I
say
is
better
than
everybody
else's
and
it's
not
an
easy
thing
to
reproduce.
A
So
so
they
have
things
like
you
know.
The
check
mark
box
lists,
you
know
their
their
their
table.
Support
is
better
than
other
people's
table
support.
They
added
video
rendering
recently
that,
if
you
put
in
a
video,
it'll
it'll
actually
render
out
as
a
player
and
nobody
else's
markdown.
Does
that
and
it's
not
really
a
fully
like
it's,
not
an
official
standard.
A
But
there
is
kind
of
the
possibility
that
the
things
that
we
pull
from
github
wouldn't
work
on
backdropcms.org
if
we're
using
a
different
rendering
system
between
them.
But
again
that
could
be
like
you
know,
a
minor
thing
that
well,
ultimately,
we
probably
need
to
allow
people
to
edit
their
descriptions
on
backdrop
cms.org
directly
right
now.
A
D
B
I'm
hearing
the
different
arguments,
I
think
and
understand
this.
I
don't
know
if
I
feel
strongly
either
way.
B
I
would
like
to
push
back
on
the
argument
about
most
of
us
being
comfortable
with
markdown
in
the
sense
that
we've
got
different
kinds
of
documentation
and
we've
got
sort
of
the
api
documentation
and
we've
got
the
forward-facing
documentation
and
somebody
in
the
drupal
community
that
was
often
involved
in
trying
to
help
people
contribute.
B
These
are
the
folks
that
aren't
going
to
be
familiar
with
markdown
and
as
simple
as
markdown
feels
to
some
of
us
that
have
used
it.
It's
a
it's
just
one
more
thing
that
I
think
scares
some
people
when
you
mention
it.
So
you
know,
I
don't
know
that
this
is
an
argument
against
adding
it
as
an
option,
but
I
think
it
is
a
caution
against
assuming
that
it
could
be
a
current
batch
of
editors.
B
Most
most
of
them
are
familiar
with
markdown,
but
especially
as
we
try
to
get
people
helping
with
the
user
facing
documentation,
I
wouldn't
assume
that
they're
all
going
to
choose
markdown
if
they
have
a
choice.
A
lot
of
them
are
going
to
want
to
just
work
in
a
rich
text.
Elevator
a
rich
texas
editor
because
that's
what
they
want
again,
almost
nobody
like
that
right
now,
that's
doing
that,
but
there
are
a
few
people
and
I'd
like
to
encourage
more
of
those.
B
A
Yeah
one
as
a
as
a
compromise,
and
I'm
not
sure
robert
will
like
this
or
anyone
that
likes
markdown,
but
it
would
be
nice
if
we
could
write
content
in
markdown
or
at
least
like
start
from
markdown
driven
content
and
get
it
into
the
editor
like
you
can't
copy
and
paste
markdown
into
cq
editor
out
of
the
box,
but
if
there
was
a
way
to
make
it
so
you
could
copy
and
paste,
or
maybe
I'm
mostly
just
talking
about
pasting
pasting
mark
down
into
the
editor
and
having
it
flow
into
html.
A
You
know
it
would
be
a
one-way
operation.
You
know
you
could
write
and
mark
down
and
then
paste
it
in
like
if
there
was
a
dialogue
for
like
paste,
markdown
or
something
that
kind
of
like
paste
from
word
that
did
the
conversion.
A
Then
that
could
be
a
useful
like
seek
editor
plug-in
and
it
wouldn't
involve
a
new
text
format.
C
There
are
online
third-party
tools
that
do
some
translation
too,
and
between,
like
you,
can
get
convert
mark
down
to
html
and
some
that
will
go
from
html
to
markdown
very.
C
B
B
It
you
know
like
I
I
if,
if
the,
if
we're
trying
to
encourage
more
people
to
like
contribute
more
actively
to
documentation,
this
might
be
an
issue
and
it
might
be
like
a
fixable
issue,
but
I
don't
know
if
it's
the
big
one
right.
It's
like
sometimes
I
feel
like
you
know.
We
need
to
step
back
and
look
at
the
big
picture
in
terms
of
how
it's
working
and
that's
where
it
sort
of
scares
me
a
little
bit
about
ending
up
with
this
documentation.
B
That's
half
rich
text
half
and
it
will
that
in
the
long
run
end
up
being
more
of
an
inhibitor
like
right.
Now
it
could
be
the
opposite.
Reducing
the
friction
for
developers
to
use
markdown
is
a
short-term
improvement,
but
then
we
might
find
ourselves
two
years
from
now
where
but
we've
got
a
different
kinds
of
documentation
and
other
people
are
afraid
to
participate,
because
that
scares
them
right.
B
E
A
Yeah,
I
also
wanna,
I
don't
know-
maybe
maybe
not
put
forward
a
consideration
of
like
maybe
it's
appropriate
on
one
side,
but
not
the
other
like
like
we
could
put
it
on
docs,
for
example,
where
it's
like,
not
quite
as
widely
used
and
leave
like
backdrop
cms.org
with
just
the
the
the
one
editor
of
the
seek
editor.
B
A
B
C
So
I
think,
putting
merging
the
dots,
an
api
on
the
single
side,
I
think,
was
a
very
good
thing,
happy
to
see
it.
If
we
were
deciding
between
docs,
docs.be.org
and
just
be.org,
I
would
favor
that
we
tried
dots
first
and
in
part,
I
think,
that's
also,
probably
where
we
get
more
programming
level.
Programmers,
contributing
dogs.
A
A
That's
true
for
something
like
mark
down,
because
markdown
we
need
to
have
a
renderer
and
it
renders
to
html
that
if
we
ever
did
need
to
remove
markdown
or
decided,
we
didn't
want
it
anymore,
like
we
could
render
the
html
save
the
html
and
switch
the
editor
to
seek
editor
and
markdown
is
such
a
restricted
format
compared
to
you
know
the
wide
world
of
html
that
we
could
render
it
and
save
it
into
html,
and-
and
we
could
go
back
from
it.
So
maybe
I
I
don't
need
to
be
quite
so.
A
Conservative
in
this
decision,
as
I
as
I
might
be
thinking,
because
it's
not
necessarily
permanent
just-
would
take
a
lot
of
work
to
undo,
maybe
not
even
a
lot
of
work,
but
some
work.
A
B
What
do
we
have
an
issue?
What
is
our
offline
feedback
to
this
been
it's,
I
feel,
like
I've,
heard
a
number
of
people
positive
about
this.
A
So
far,
we
only
have
jen
and
gregory
who
voted
yay.
That
sounds
great
starting
from
a
month
ago.
If
people
want
to
add
more
feedback
to
this,
the
issue
is
under
backdrop,
ops,
backdrop
cms.org
the
issue
queue
she's
796.,
and
it's
in
the
agenda
as
well,
which
you
can
get
to
from
the
forum
just
trying
to
like
make
it
so
people
can
actually
get
to
where
these
links
are.
A
Let's,
let's
robert,
if
it's
okay,
let's
move
on,
I
think
collecting
more
online
offline
feedback
actually
is
is
a
really
good
thing.
I'm
hoping
some
people
might
watch
this
discussion
and
you
know
get
some
thoughts
of
their
own
and
then
help
contribute
online.
I'll
also
wrote
write
a
comment
on
that
issue,
just
kind
of
weighing
one
way
or
the
other,
and
I'm
I'm
not
outright
opposed
to
it.
I
I
just
like
weighing
all
sides
of
the
you
know
options.
A
Well,
thank
you
for
filing
that
issue
and
for
the
discussion
we
have
more.
Let's
see
you
debugged
an
issue
with
the
recommended
release,
block
issue
799.
In
the
backdrop
cms.org
queue.
It
seemed
like
that
was
an
issue
with
project
module,
but
is
that
even
relevant
if
we
merge
that
other
pull
request
that
moves
the
recommended
releases
into
the
main
content
area.
C
I
think
the
issue
is
still
there
because
it
was
an
issue
related
to
caching.
So
it
would
just
be
we'd,
be
caching
a
different
view,
but
it
would
still
be
the
view-
and
I
think,
there's
still
issues
going
on
with
it.
So
it's
it
needs
more
work.
More
investigation.
A
Okay,
for
the
other
pull
request,
I
noticed
I
I've
reviewed
it
and
it
was
all
in
our
custom
code
or
in
the
theme,
and
so
we
can
merge
that
directly
into
backdrop
cms.org
for
for
debugging
purposes.
I
think
it's
great
that
you
just
make
the
changes
to
backdrop
cms.org.
A
We
have
the
tugboat
previews
so
that
we
can
actually
test
them
out,
which
is
helpful,
but
I
noticed
in
this
one
that
it
makes
just
makes
changes
to
project
module
and
doing
changes
to
project
modules
a
little
bit
tedious,
because
we
have
to
actually
make
a
change
to
the
contrib
module,
merge
it
in
and
then
upgrade
the
contrib
module
is
used
by
backdrop
cms.org.
So
it's
a
little
bit
of
a
circuitous
route
to
solve
an
issue
there,
but
yeah
project
modules
in
contrib,
and
we
run
the
latest
release
on
backdrop
cms.org.
A
It's
a
thing
that
actually
I've
been
thinking.
Maybe
that's
not
worth
the
effort
there
for
a
long
time,
because
who
else
uses
project
module?
You
know
like
at
one
point:
maybe
that
made
sense
in
the
world
of
drupal
that
you
know
project
modules
like
oh
anybody
can
use
the
issue.
Tracker
but
honestly
drupal's
issue
tracker,
I
don't
think,
is
really
a
strength
anymore,
since
it's
more
of
a
nuisance
so
anyway
that
so,
but
for
now
that's
still
the
process.
We
have
contrib
module.
A
We
have
to
update
the
contrib
module
first,
okay,
let's
see
forum
site
no
updates
there,
but
then
the
docs
site.
A
You
just
went
on
a
roll
here,
robert
with
issue
143
140,
136
and
137,
which
is
a
lot
of
different
issues.
A
I
was
really
intrigued
by
the
form
api
page
fix,
which
I
hadn't
realized
that
the
form
api
page
is
now
generated
by
code,
the
the
form
api
reference
that
big
table
up
at
the
top
saying
which
properties
apply
to
which-
and
you
just
made
some
minor
changes
and
fix
I'll.
Let
you
talk
about
all
the
changes.
Can
you
summarize.
C
It
actually
could.
I
did
I
skip
over
that
to
number
c,
because
I
can't
really
test
all
those,
because
none
of
because
there's
no
tugboat
builds
that
work.
So
every
pr
results
in
a
broken
boat
build-
and
I
mean
that
seems
like
getting
that
fixed-
is
a
higher
priority
than
addressing
the
individual.
A
C
C
Yeah,
I
don't
think
we
actually
have
an
issue,
although
peter
started
working
on
it
at
one
point.
But
no,
I
guess
it's
known,
but
not
an
issue
yet
and.
A
B
C
Yeah
I
mean
so
I
I
didn't
realize
that
it
wasn't
just
standard,
because
what
I
saw
on
the
regular
backdrop,
not
in
any
outfits
I
can.
I
guess
I
could
run
through
the
pr's.
A
Yeah,
it
looks
like
he
said.
Last
bw
panda
worked
on
this
was
five
months
ago,
so
it's
actually
been
been
a
while
the
issue
that
he
started
with
was
issue
number
80
on
backdrops,
I'm
sorry
on
the
doc
site
yeah.
He
said
it
was
working
back
in
january,
so
there
must
have
been
something
that
went
awry
between
now
and
then.
A
So,
yes,
we
should
file
a
new
issue
for
fixing
the
sandboxes
and
it's
possible
that
peter
might
hop
back
in.
He
might
not
even
be
aware
that
they
stopped
working,
so
he
might
be
able
to
help.
C
C
Maybe
he
closed
that
issue
out
and
closed
the
vr
out,
but
a
few
days
ago,
that
that
was
that
was
there
okay,
but
I
I'll
just
meanwhile
I'll
dive
into
the
the
pr's
so
number
143
again,
there's
just
a
ui
thing
spreading
out
properties
on
the
form
element,
edit
page.
So
when
you
are
adding
properties
to
a
form
element-
and
let
me
say
this-
this
software
built
form
api
table
is
just
a
wonderful
thing.
C
I
think
peter
put
that
together
and
it's
it's
fantastic,
but
this
is
just
little
tweaks
and
all
143
tweaks
does
is,
instead
of
putting
all
the
fields
in
a
single
vertical
column,
it
spreads
them
out
from
side
to
side
so
that
when
you
have
20
fields
in
a
row
that
you're,
adding
or
editing,
you
can
see
more
on
your
screen
and
a
lot
of
the.
A
Is
that,
oh,
it's
a
form
api
element,
wow
yeah.
Should
I
go
to
the
property.
A
Like
the
submit
yeah.
C
Okay,
so
you
see
here
for
each
property,
every
every
value
is
in
a
vertical
column
and
most
of
the
default
values
are
blank,
so
the
one
you've
got
highlighted
is
not
a
lot
of
them
are
blank
and
because
they're
so
spread
out,
you
can
only
see
a
little
bit
as
you
scroll,
and
so
the
change
in
143
moves
the
default
value
over
to
the
right.
C
So
things
are
at
least
on
on
big
screens
on
mobile.
It's
still
in
a
single
column
as
it
has
to
be,
and
so
that
means
you
don't
have
to
scroll.
E
Sorry
this
one,
this
143.
C
Yeah
and
there
we
go
so
on
the
left
is
what
it
is
now
and
on.
The
right
is
what
changed.
A
C
I
completely
agree
it
would
be
nice,
it's
not
obvious
how
to
I
mean
it's
not
simple
to
make
that
happen,
because
essentially,
what
we're
doing
is
pulling
both
of
those
fields
to
the
right
and
floating
them
to
the
right,
and
since
both
are
floating
you
know,
the
check
box
is
lined
up
with
the
form
so
to
get
them
lined
up.
You'd
want
to
change
the
order
of
the
two,
and
I
didn't
want
to
actually
go
that
far
so
yeah.
That
was
one.
A
Okay,
yeah
that's
great
and
let's
see,
then
you
also
had
well,
let's
see
we're
running
quickly
out
of
time
here
yeah.
I
think.
Maybe
at
this
point
we
have
a
lot
of
other
things
on
the
agenda,
but
we're
clearly
not
going
to
get
to
them
today.
But
it's
fine.
I
think
we've
had
great
discussions,
but
if
you
want
to
kind
of
summarize
and
wrap
up
where
we
are
with
these
things,
then
we
can
just
kind
of
end
it
after
you
have
to
get
through
those.
C
Yeah,
okay,
so
well,
let's
see
140.,
let's
open
that
up
again,
that's
the
pr
go
to
the
issue,
and
yes,
so
I
don't-
I
don't
have
a
before
after
picture,
but
in
the
form
api
table
itself.
There
are
lots
of
blank
rows,
rows
that
have
no
checks
whatsoever,
and
so
all
this
is
doing
is
hiding
those
empty.
C
C
C
C
Yeah,
so
really
the
first
table
is
input
elements
and
the
second
table
is
form
structure
elements
and
that's
actually
what
what
they're
called
in
hook
element
info
in
system
element
info
as
a
comment.
So
I'm
just
saying:
let's
change
the
labels
to
reflect
yeah.
So
so
that's
all
again,
another
small
change
and
last.
A
Right
yeah,
which
is
which
is
still
under
discussion,
yeah
yeah.
These
changes
all
look
great,
like
you
say
it's
a
little
bit
difficult
to
test
them
because
tugboat
isn't
there,
but
we
can
still
do
it.
The
old
school
way
where
we
we
pull
them
down
and
have
locals,
but
yeah
like
tim
says
that
is,
is
quite
tedious,
great
yeah.
These
are
all
look
amazing.
It's
great
to
have
some
updates
too,
to
the
usability
of
the
doc
site,
so
yeah.
A
Awesome:
okay!
Well,
we
have,
we
didn't
even
get
to
the
progress
reports
for
today
I
noted
I
think,
maybe
before
the
recording
that
indigo
zelda
added
a
couple
of
issues
to
the
forum
post
that
we're
not
going
to
be
able
to
get
to.
A
However,
I've
posted
online
to
both
of
the
issues,
issues
that
she
raised
and
there's
actually
been
progress
on
there
online.
So
hopefully
it's
okay
that
we
didn't
get
to
cover
them
today.
So
thank
you,
robert
for
all
of
the
discussion
points
today.
Thank
you
for
joining
thanks
for
adding
all
of
these
items
to
the
agenda.