►
From YouTube: Backdrop Weekly Aug 17th
Description
Today’s development agenda: http://bit.ly/2hPMmlq
A
All
right
we
are
on
air,
it
is
Thursday
August
17th.
Thank
you
guys
for
coming.
This
meeting
is
a
check-in
on
active
development
tasks
for
back
job
CMS,
clicked
update
from
the
PMC.
We
are
still
working
on
signing
and
returning
our
contracts
to
get
our
fiscal
agreement
in
place
with
the
Conservancy.
A
B
Okay,
yeah
I'd
be
happy
to
talk
about
it.
Okay,
so
1.17
came
out
yesterday
we
coordinated
the
release
with
Drupal
that
there
was
extra,
wasn't
the
drupal
of
seven
released
yesterday,
but
there
was
a
views
release
yesterday
for
Drupal
7,
and
so
the
security
fix
that
we
included
correspondent
to
the
new
release
of
views,
and
we
also
fixed
one
of
an
issue,
and
that
was
exclusive
to
backdrop
that
was
introduced
in
1.7.
B
So
it's
great
to
knock
out
a
couple
of
those
security
fixes
in
1.72
also
has
a
bucket
of
other
just
small
bug,
fixes
here
and
there
and
so
yeah.
It
was
great
to
get
that
up
and
big
big
big.
Thank
you
to
John
and
Jeff
for
pretty
much
running,
that
entire
release
from
the
merging
to
the
tagging,
to
the
releasing
to
the
release,
notes
sing
to
the
security
man
spinning.
So
that
was
awesome.
I,
don't
think
that
I
would
have
we
pushed
that
change
out
to
the
panthéon
upstream
and
docker
images.
B
We
also
had
this
is
the
first
security
announcement
and
we
got
to
use
the
fancy-pants
new
security
announcement,
functionality
on
backdrops
new
messed
up
org,
and
so,
if
you
have
a
user
account
backed
web
CMS
to
work,
you
can
sign
up
for
security.
Malin
was
but
in
your
profile
and
that
automatically
went
out
yesterday.
So
that
was
awesome
to
see
that
go
off
and
fire
and
have
all
of
that
stuff,
automated,
so
very
cool.
B
Ok,
so
that's
at
one
point:
seven
two,
which
means
all
of
the
items
that
are
slated
for
the
next
bug
fix
release
that
aren't
in
1/72
are
now
candidates
for
being
concluded
in
173.
The
next
bug
fix
release
and
we'll
see
how
this
goes.
You
know,
with
the
release
of
1.8
coming
up
in
less
than
a
month.
1.73
may
be
the
last
bug
fix
release
for
1.7,
and
if
we
don't
have
another
bug
fix
release
before
September
15th,
then
1.73
will
come
out
at
the
same
time
as
1.8.
B
Does
this
count
the
last
maintenance
release
of
the
1.7
branch
sort
of
got
a
bunch
of
minor
little
issues?
We've
been
going
through
and
kind
of
picking
these
up,
picking
up,
long-standing
issues
issued
1200
fixed
the
way
the
captions
are
handled.
That
is
just
getting
a
little
reroll
and
then
we
think
that
will
likely
be
complete
a
whole
bucket
of
cross
ports
from
Drupal.
We've
got
issue
2013,
that
is
for
Drupal,
7.50
and
previous
versions.
B
If
that
one's
more
than
halfway
done
and
there's
probably
some
new
PRS
there
that
are
probably
ready
for
review
as
well,
and
then
we
have
three
more
cross
supporting
issues
that
are
issued.
27,
74,
75
and
76
and
I
won't
go
through
all
of
those
individual
ones,
but
it
would
be
nice
as
always
to
kind
of
keep
up
with
the
minor
fixes
that
are
happening
on
the
Drupal
site
as
well.
B
B
B
The
first
item
that
we've
gotten.
That
list
is
lamp
relationships,
which
is
this
your
21
34
no
new
activity
on
this.
Since
last
week,
though
I
don't
know,
I've
been
giving
some
thought
to
the
way
that
we
handle
that
particular
issue
that
I'm
torn
between,
like
going
with
what
we
have
here,
which
is
something
we
talk
about
a
lot
put
together
last
release,
and
it
looks
really
pretty
good.
First
is
some
new
thoughts
that
I've
been
having
a
great
this
so
anyway,.
A
B
Blue,
have
you
written
down
you
it
no
I,
haven't
and
that's
why
I
was
like
I,
think
I'll
probably
hold
off
on
just
verbalizing
them
and
instead
write
them
all
down.
B
B
Are
you
I
did
that
after
broadcast?
Oh
sure,
we
can
go,
that's
fine
yeah,
that's
stirred
drink.
That
could
be
fun
day.
Okay,
let's
continue
on
1.8,
though
so
1.8
we're,
also
working
on
improving
the
media
handling
in
general
and
specifically
around
files
and
images,
and
there's
a
metaphor
that
at
14
48
is
within
that
category
include
making
files
into
proper
field
to
both
entities.
30
are
entities,
but
making
them
feel
double
is
issued,
26
32
and
that
one
is
in
a
needs.
B
B
So
if
we
want
to
iterate
and
just
get
edit
completed,
that
one
is
a
really
good
candidate
to
knock
out
right
away,
especially
27
96,
so
that
one
we
could
probably
complete
immediately
and
then
we're
coming,
adding
a
file
which
is
issued
2633
and
that
issue
needs
some
additional
work.
Yet
we
also
have
another
issue
worth
calling
out
issue
1380,
that
is
adding
support
from
multiple
file
upload,
and
the
most
recent
suggestion
in
here
is
that
we
port
a
report.
B
It's
just
JavaScript
additions
to
the
existing
file
widget,
so
that
could
be
a
way
for
us
to
achieve
multiple
file
upload
without
doing
a
huge
amount
of
refactoring
I
looked
at
the
the
underlying
approach
and
it
looks
pretty
good,
but
it's
a
little
bit
concerning
because
it
like
requires,
like
a
database
table
to
track
in
progress,
uploads,
so
I'm,
not
totally
sure
about
the
repercussions
of
implementing
that
approach.
Yeah.
C
C
C
B
A
A
B
B
B
A
Fine,
so
I
was
just
thinking
if
we
could
get
a
eyes
on
that.
That
might
be
something
that
would
be
easy
to
get
into.
One
point:
one
point:
eight:
if
it
looks
like
it
needs
considerable
work,
we
should
bump
it,
but
because
it
is
closed,
I
figured
we'd,
add
to
the
list
and
see,
and
so
just
so
you
guys
know.
A
I
went
through
the
some
of
the
issue
kids
this
morning
and
started
trying
to
like
reorganize
things
that
we
don't
I,
don't
think
we're
going
to
get
done
in
time,
but
the
things
that
look
like
we
might
get
time
I
just
added
to
this
list.
That's
of
these
two
are
in
the
second
one.
Module
filter
updates
is
just
a
usability
improvement
where,
if
you're
on
the
modules
page
and
you
filter
for
something,
and
then
you
enable
it
when
the
page
reloads,
the
filter
is
lost.
B
A
A
B
A
C
B
Speaking
of
which
I
should
also
add
that
we
had
a
bunch
of
issues
that
were
marked
ot
BC
that
come
from
the
last
bug
fix
release,
so
it
definitely
has
been
some
really
fantastic
module
or
issue.
Reviewing
that's
been
going
on.
Particular
Opie
has
just
been
going
to
town
on
our
to
be
sitting
issues
and
that's
really
appreciated.
So
thank
you
very
much.
B
B
B
A
If
we're
not
gonna
do
it
on
time,
we
need
to
figure
out
what
the
neck
like
when
we
should
next
consider
doing
it.
I
don't
know
if
that
means
like
okay,
well
right
now
we're
doing
1.8
if
January
1st
becomes
1.9.
Does
that
mean
that
2.0
happens
at
the
next
release,
which
would
be
the
15th
or
are
we
gonna
push
it
a
whole
year
and
then
not
do
it
until
January
and
you're,
saying
and.
C
I'm
still
I'm
still
of
the
mind
that
we
should
release
2.0
when
we
actually
have
some
substances
substitutive
changes
because,
like
you
know,
we
have
a
lot
of
stuff
about
how
our
API
won't
break.
So
it
doesn't
break
within
a
release,
but
we
will
make
breaking
changes
when
we
go.
A
major
release,
so
I
feel,
like
explains
people.
Okay,
we're
doing
a
major
release,
but
there's
no
breaking
changes
is
gonna,
be
kind
of
weird.
C
A
D
A
C
A
C
C
A
Drop
one
at
point:
one
six,
four
five
2.0
I
mean
I
like
we
have
a
good
product
like
right
now.
You
know
a
lot
of
the
exciting
things
that
people
want
can
probably
be
done
in
the
one
point.
X
cycle
yeah,
but
I
think
that
if
we
say
it
back
up
forever,
we
aren't
gonna
get
as
many
adopters
because
everybody's
like
oh,
it's
still
on
version
1
well.
B
Yeah,
it
sounds
a
lot
like
have
you
ever
heard
of
it.
There
was
an
old
database
system
before
sinkhole
became
popular
called
db2
and
DB
1
never
existed.
They
actually
started
out
and
called
it
db2,
because
nobody
would
ever
trust
a
1.0
product
at
that
time,
so
they
just
called
it
baby.
Just
because
that
was
better
marketing
or
like.
C
C
A
C
C
C
A
Maybe
what
we
should
do
is
say
we're
not
going
to
do
2.0
in
January.
First,
we'll
know
for
sure
on
September
1st
and
then
say
have
the
conversation
at
bag
camp,
which
is
going
to
be
before
January
1st
and
then
we'll
decide
a
bad
camper
shortly
thereafter,
whether
we
should
re-evaluate
for
the
next
release
or
push
out
a
year
and
reevaluate,
and
hopefully
we
know
what
backdrop
to
means
that
will
give
us
the
insight
to
figure
out
how
long
it'll
take
us
to
get
there.
Yeah.
C
B
Cycle
like
no
matter
what
like,
even
if,
even
if
those
minor
releases,
have
hardly
anything
new
in
them
because
of
our
because
of
our
focus
long,
as
you
point
out
like
we
shouldn't,
continue
delivering
on
that
every
four
months
cycles,
so
we
don't
ever
end
up
in
a
situation
of
like
you
know,
people
getting
frustrated
because
their
changes
are
never
actually
released.
Oh
that's.
A
A
A
A
C
You
know,
I
could
also
be
convinced
that
maybe
every
tenth
release
should
be
a
major
release
yeah
and
that
we
should
just
go
go
through
our
backlog
of
breaking
changes.
We
want
to
make
and
just
make
them
yeah,
but
I.
Just
I
just
feel
like
adoption
is
like
still
so
low
and
there's
still
so
few
sites
using
backdrop
and
we're
still
hoping
for
so
many
Drupal
sites
that
we
don't
want
to
break
things.
Yeah.
B
B
That
moves
us
into
just
general
discussion,
which
is
almost
where
we
were
already,
but
but
let's
roll
back
around
to
relationship
handling,
so
continuation
on
the
discussion
in
2134.
So
when
so,
this
is
doing
adding
relationships
to
layouts
that
right
now,
when
you
have
a
context
like
a
piece
of
content
or
node
or
a
user
or
taxonomy
term,
you
have
the
ability
to
do
stuff
like
put
a
condition
on
a
block.
B
B
So
that
would
be
a
really
awesome,
powerful
change
but
the
and
it
would
match
to
what
we
had
previously
seen
in
Drupal.
7
using
panels,
but
the
one
I
was
thinking
about
doing.
Instead,
this
is
where
we
might
go
down.
A
rabbit
hole
is
instead
of
specifying
relationships
at
the
layout
level.
We
could
add
relationships
at
the
block
level.
So
every
time
you
added
a
block
at
the
very
top
of
the
add
block
dialog,
we
would
show
a
drop
down
for
contextual
blocks
or
something
like
that
and.
B
What
appeared
again
would
let
you
change
further,
so
basically
you
could,
as
you
were,
adding
blocks,
you
would
be
able
to
change
as
many
as
far
down
as
you
wanted
to
from
the
add
block
interface
and
every
time
you
selected
another
level
in
the
chain.
The
list
of
add
blocks
would
change
the
context.
That
is
the
the
most
the
bottom
most
relationship.
Basically
I
like
that.
C
I,
like
that
idea
like,
if
I
understand
what
you're
saying
I
like
handling
that
at
the
block
level,
because
if
you
make,
if
you
have
a
bunch
of
blocks
that
are
using
those
and
you
change
the
relationships
of
the
whole
layouts
and
all
the
blocks
would
break
yeah.
So
this
is
a
good
way
to
like
change.
What
what
relationship
you're,
using
or
something
like
that.
Unlike
for
a
lot
of
blocks
that
haven't,
go
back
to
layout,
changing
the
whole,
adding
or
relationship
or
changing
relationship
which
could
theoretically
break
other
blocks.
So.
B
And
it
also
what
makes
it
so.
That's
the
connection
between
relationships
and
what
relationships
actually
do
is
right
in
the
same
place,
where
you're
actually
adding
blocks
as
opposed
to
putting
it
on
the
settings
page
where
you
kind
of
have
to
think
ahead
and
be
like
what
relationships
am
I
going
to
need,
because
you
might
not
know
that
you
need
the
users
bio
field
before
you
start
placing
blocks,
and
so
it
puts
the
functionality
closer
to
the
configuration
which
would
be
a
big.
A
big
win.
I
worry.
C
About
it's
a
bit
confusing,
it
might
be
potentially
confusing
to
people
who
don't
understand
what's
happening
so
I.
Think
that,
like
looking
at
the
user
interface
and
I,
don't
know
if
we
want
to
go
so
far
as
like,
maybe
doing
testing
or
asking
people
with
to
take
a
look
and
see
if
it
makes
sense
with
fresh
eyes.
C
B
None
of
that
is
even
a
possibility
because
there's
no
context
in
the
first
place,
so
it
kind
of
saves
you
from
like
it's
a
little
bit
more
of
a
gradual
introduction
where
the
homepage
and
default
layouts
don't
have
these
these
problems
or
these
complexities,
and
then
it
was
only
once
you
start
overwriting
node
level,
ok,
like
a
custom,
a
layout
at
node,
/
%.
That
starts
appearing
okay.
That.
C
C
Which
also
shows
this
is
kind
of
like
a
marginal
benefit.
Is
it's
a
heading?
It's
only
like
a
certain
number
or
small
number
of
layouts
would
have
this
but
yeah.
It
would
say
it
would
save
a
lot
of
a
lot
of
like
creating
a
views
and
stuff
to
do
the
relationships.
Mm-Hmm
yeah.
So
it's
definitely
worth
adding
yeah
okay,
unless
someone
has
other
feedback
on
that,
does
anyone
have
any
feedback
on
where
to
put
the
thing
or
I
really.
A
Like
that,
putting
the
thing
at
the
block
level-
I
wonder
if
it
if
like,
where
the
layout
actually
gets
it,
that
relationship
gets
attached
should
be
at
the
layout
level
or
at
the
block
level.
Just
for
like
caching
regions.
I
know
they
talked
a
little
bit
about
like
there
being
a
static
cache
and
that's
nothing
access
to
whatever
it
is.
That
was
loaded.
A
A
C
Here's
here's
okay!
This
is
what
I
wanted
to
get
into.
It's
we're
not
talking
about
where
to
put
it
in
the
user.
Interface
is:
where
are
these
relationships
defined
like
in
terms
of
the
data
architecture?
How
do
we
know
that
a
node
is
linked
to
a
user
and
and
I
would
say
that
it
should
not
be
part
of
the
lab
system
at
all?
It
should
instead
be
part
of
the
entity
API
and
that
entities.
B
A
Well,
I
would
think,
like
anything
that
has
a
database
record,
could
provide
a
context
and
not
all
things
that
have
a
database
record
been
injured
for
entities
right
so
like
you
could
have
like
a
unique
identifier
and
then
load
whatever
the
thing
is,
and
I
don't
want
that
thing
available,
but
it
does
not
clearly
has
to
be
an
entity.
Well.
C
I
would
I
would
I
would
say.
Maybe
we
could
create
a
list
of
examples
of
how
that
what
other
things
we
list
to,
like
you
know,
I'm
thinking
mostly
in
terms
of
entities
and
I,
think
that
we
should.
We
should
see
how
these
entities
are
linked
in
the
entity
API
and
how
we
could
more
explicitly
define
the
relationships
between
core
entities
and
how
custom
entities
can
define
it
so
that
yeah.
C
A
A
Oh,
if
you
want
to
put
a
block
on
the
page
that
lists
like
all
of
the
other
nodes
and
the
note
queue
that
this
node
is
on,
like
you
want
to
have
note,
cute
relationship
and
no
queue
is
not
an
entity,
but
it
has
a
unique
identifier,
and
you
can
do
that
for
noted
queues
that
are
simple
cues
that
have
like
a
unique
identifier
or
nodes
keys
that
are
sub-q.
That
use
like
a
taxonomy
term
as
an
identifier
and
there's
a
lot
of
way
that
you
can
build
relationships
between
things
like
there's.
A
C
C
C
A
Already
have
an
API
for
this
I.
Don't
I
really
understand
why
this
is
an
issue.
I
mean
I.
Think
that
question
was
where
are
this
like,
because
we
have
a
context:
I
don't
know
need
a
context
as
an
object
or
if
it's
just
an
array
of
data,
whatever
point
it
gets
passed
to
the
layout,
but
we
already
have
a
thing
called
a
context
and
adding
a
relationship
to
a
panel.
Just
your
layout.
Sorry
just
gives
you
another
context.
A
If
you're
on
the
node,
you
know-
and
you
already
have
a
node
context
available-
you
add
a
relationship
to
the
author.
You
know
have
two
contexts
available.
One
of
them
is
the
node
of
one
of
them
is
the
author.
Yes,
those
things
can
the
enemies,
and
if
those
entities
have
fields,
then
we
get
benefits
like
blocks
that
have
fields,
but
any
kindred
module
could
add
any
additional
contacts.
That
is
or
is
not
an
entity,
and
it
can
have
any
number
of
blocks
that
depend
on
that
context.
A
C
Just
not
sure
I'm,
just
not
sure
when,
like
so
like
the
flag,
mods
or
something
it's
just
going
to
define
the
law
like
it's
gonna,
like
you
know,
you're
selecting
the
block
type,
one
of
those
is
going
to
be
show
the
flags.
You
know
I'm,
not
sure
why
flags
or
something
like
that
would
need
to
find
an
additional
context,
because
it's
already
defining
the
blocks
within
the
current
context.
C
A
B
Just
back
a
little
bit
to
give
you
guys
a
little
bit
more
context
into
our
current
architecture.
So
there
is
a
Hockley
context
info
that
deals
with
context
and
for
the
entities
that
are
in
court,
that
are,
that
supported
node
user
and
term
term.
There
is
a
single
class
called
entity
layout
context
that
supports
all
entities
globally
and
so
basically
that
there
is
a
hook
or
hopefully
a
context
info
clip
for
the
most
part.
All
of
them
all
use
the
same
implementation,
which
is
provided,
which.
A
B
And-
and
the
important
in
theory
have
something
that's
not
an
MD
but
yeah.
It's
like
there
aren't
any
examples
of
that
court
at
porridge
and
really
any
great
ideas
about
what
those
things
could
be.
But
if
the
possibility
is
there
with
contexts-
and
we
probably
do
the
same
thing
for
relationships,
yeah.
A
B
C
Don't
know
I
just
feel
like
I
just
feel
like
in
terms
of
like,
because
I've
been
obviously
with
the
entity
reference
stuff
been
doubling
it
to
the
entity.
Api
and
I
feel
like
it'd,
be
good
to
more
explicitly
define
the
relationships
between
different
entities
inside
O's
inside
of
the
entity
API
and
who
move
move
the
remove
the
relationships,
okay,
min
and
move
the
relationships
between
core
entities
into
the
entity
API
into
custom
entity.
C
So
if
you
were
just
to
define
the
relationship
in
the
entity,
API
between,
like
your
NID
like
like
you
know,
attribute
or
you
ideas
from
you
say,
this
is
a
reference
to
this
other
entity
type
more
explicitly
the
entity
API.
Then
maybe
you
don't
have
to
define
separate
like
layout
relationship
context
or
something
like
that
when
you're
to
set
it
up
it
just
automatically,
is
handled
and
handled
by.
C
B
C
If
you're
creating
a
new
entity,
types
of
reference
is
another
entity,
type
you'd
need
to
say:
okay,
I'm,
just
sort
of
the
relationship
and
views
then
you're
like
okay.
Now
I
need
to
set
up
the
same
exact
relationship
in
layout,
whereas
like
if
you're
just
two
defines
of
relationship
once
in
the
entity
API,
then
you
wouldn't
have
to
do
it
specifically
for
views
and
layout
separately,
yeah.
C
C
C
A
C
This
is
sort
of
a
question,
and
you
know
this
might
be
one
of
those.
This
might
be
one
of
those
backdropped
2.0
things
like.
Maybe
we
have
it
defined
both
in
layout
and
use
the
relationships
in
those
like.
Maybe
we
just
put
it
in
the
layouts
module
for
now
but,
like
you
know
as
part
of
2.0
move
like
the
relationships
of
things
into
lower
down
in
the
data
architecture.
Well,.
A
I
think,
like
that's,
the
kind
of
thing
like
in
entities
would
be
really
easy
to
have
it
like
the
entity.
Api
provides
all
these
things
with
like
a
flag
just
like
you're,
creating
an
entity
and
you
can
be
like
do
you
want
to
thread
even
use
relationship?
Yes,
no,
you
want
to
try
to
layout
relationship,
yes,
yeah
yeah,
getting
on
those
values,
those
things
low
gear
or
not
appear
as
needed,
but
I.
Don't
think
that
means
we
should
like
limit
the
API
to
only
work
with
entities.
Oh
yeah.
A
Limited
use
case
wise
to
like
are
any
relationships.
This
kind
of
limited
use
case
and
putting
it
in
core
I
think
is
good
for
things
like
entities,
because
those
are
majority
use
case,
but
you
know
kicking
that
from
chicken
trip.
It's
also
totally
fine.
If
we
have
the
thing
like
we
have
an
hour,
it's
like
we
have
this
thing
that
works
for
all
entities
and
theoretically
it
could
work
for
other
things
too,
and
letting
them
figure
out
how
to
do.
It
is
fine
I.
C
Thought
yeah
anyway,
so
the
long
and
short
of
it
is
I
think
that
we
have
a
sort
of
user
interface
user
experience
issue
of
where
to
define
these
relationships
within
the
thing.
But
then
I
also
think
that
we
have
like
sort
of
a
back-end
how
to
store
what
the
relationships
are.
Data
architecture
issue
you.
A
Now
that
all
happens
at
the
layout
level
yeah-
and
we
just
don't-
have
a
UI
for
it.
But
if
our
UI
is
gonna
be
anything
to
the
block
level
and
we
actually
think
architectural,
it
would
better
to
have
those
be
stored
at
the
block
level.
Is
that
going
to
require
an
API
change,
and
does
that
I
mean
we
shouldn't
put
in
layout
relationships
until
backup.
B
A
B
A
A
That
gives
us
a
little
more
freedom
in
terms
of
1.8.
We
have
something
that's
kind
of
there,
but
it
hasn't
had
any
attention
since
the
last
release.
Would
you
be
interested
in
bumping
this
21.9
and
playing
with
the
idea
of
removing
the
relationships
to
the
block
level
instead
of
doing
it
at
the
layout
level,
and
that
would
give
us
some
time
to
like
proof
of
concept
that.
C
B
B
I
know
that's
why
I
should
look
at
things
they
do
for
soon
it
oh
well!
Well,
anyway,
it's
an
idea,
and
one
thing
definitely
needs
a
pianist.
We
need
to
write
that
all
down,
because
right
now
it's
not
reflected
in
the
issue,
so
we'll
continue
leaving
it
here,
and
we
saw
that
we
can
give
it
a
status
update
next
week
and
maybe
officially
bump
it
at
that
point.