►
From YouTube: Backdrop Weekly 10/6
Description
Today’s development agenda: http://bit.ly/2dvlqkH
A
All
right,
we
are
on
air
just
october,
sixth,
happy
thursday,
everyone
backed
up
day
as
usual,
we're
going
to
do
a
run-through
of
most
important
tasks.
To
do
for
backdrop,
at
beginning
of
the
meeting
wage
like
I
was
section
where
we
do
updates
from
the
pmc,
we
don't
have
any
official
updates
this
week,
but
we
have
been
trying
to
figure
out
how
to
manage
the
inclusion
of
new
core
features,
and
I
didn't
know
if
we
should
spend
any
time
talking
about
that
in
this
meeting
or
not.
A
All
right
guess
not
so
the
the
problem
space
was
just
that,
both
with
the
addition
of
new
layouts
in
backdrop
14
and
the
addition
of
the
new
theme
in
backed
up
15.
We
ran
into
this
issue
where
we
weren't
really
sure
whether
this
should
exist
in
contributes
project
or
if
the
feature
should
exist
in
a
feature
branch
and
so.
B
A
Trying
to
figure
out
how
to
make
it
easier
on
maintain
errs
and
contributors
in
the
long
run,
to
add
big,
crazy
questions
like
this
and
so
I
know.
Gregory.
You
pointed
out
that
the
only
way
we
can
get
a
working
sandbox
for
those
things
right
now
is
to
have
it
eat
in
the
core
queue
as
a
pull
request,
and
that's
really
easy
to
do.
If
you
have
a
future
branch,
but
might
also
pointed
out
that
some
of
these
projects
don't
actually
need
to
be
employed
West
against
core
for
testing,
they
could
be
a.
A
A
So,
if
there's
a
way
that
we
can
make
it
easier
for
contributors
to
work
on
these
features,
either
through
policy
or
just
through
practice,
I
think
it
will
be
good
to
think
about
that.
So
we
don't
need
a
policy.
That's
fine!
B
Like
my
concern,
just
you
know,
since
I'm
going
to
downloaded
on
the
issue
of
my
concern
is
just
that
there's
already
so
many
issues
flying
around
there's,
so
many
pull
requests
that
then,
if
we
added
like
feature
branches,
it
would
just
add,
like
a
whole
nother
dimension
of
complexity.
To
like
you
know
all
of
the
stuff
on
github
and
then
you're
sort
of
like.
Oh,
is
this
applying
to
which
branch
and,
what's
already
in
there
and
just
make
it
even
more
complicated
to
figure
out
what's
going
on?
Thank
you.
C
C
For
the
most
part,
everybody
makes
pull
requests
against
one
dead
x
because
it's
the
default
branch,
and
so,
unless
you
know
what
you're
doing,
making
a
pull
request
against
a
different
branch
is
actually
a
little
bit
tricky
because
you
need
to
not
just
hit
the
make
pull
request
button,
but
you
need
to
then
click
Edit
for
requests
and
then
change
the
branch
that
it's
against
so
actually
making
poor
request
against
the
feature.
C
Branch
could
be
a
little
bit
trickier
for
other
contributors
than
then
making
poor
requests
against
the
default
branch,
but
I
think
that's
kind
of
what
we
want.
If
we
went
down
that
route,
that's
the
weapon
x
would
still
be
default.
It
wouldn't
really
cause
any
additional
confusion
any
more
than
we
have
people
making
poor
request
again.
It's
like
the
one
at
40,
13
or
12
/
branches,
which
has
pretty
much
never
accidentally
happened,
which
is
good.
C
Yeah
I
can
see
your
concern
there,
Mike
I'm
not
and
I,
don't
think
it
would
cause
too
much
more
of
a
problem
than
than
what
we've
got
already
the
poor
requests.
Also,
the
poor
requests
Q
is
not
doesn't
receive
a
lot
of
traffic
other
than
from
the
maintainer
zai.
Don't
think
like
looking
through
the
list
of
power
costs
itself.
I
think
that
most
of
the
noises
envy
is
in
the
issue
tracker,
which
you
might
be
right.
Making
more
noise
in
the
issue.
C
Tracker
might
be
problematic,
I,
don't
know,
we've
already
got
over
a
thousand
open
issues
right
now,
I'm
wondering
if
that
little
ya
know
I
run
it
better
that
we
have
a
record
of
what
we're
working
on
then
just
trying
to
keep
it
in
our
heads.
That's
not
going
to
help
I
do
like
the
idea
of
having
a
feature
branches
for
a
lot
of
reasons
that
it
it
does
keep
all
of
our.
C
It
keeps
all
of
our
workflows,
the
same
kind
of
that
it
all
in
it
is
all
in
one
place.
We
do
get
the
benefit
of
sand
boxes
and
automated
testing
without
doing
any
additional
infrastructure
work,
and
it
does
set
us
up
in
a
place
that
makes
it
so
that
the
will
call
them
provisional
maintained
errs
the
people
that
would
be
granted
commit
access
to
the
core
repository
just
so
they
can
merge
into
their
feature
branch
without
it
tional
review,
and
then
we
do
the
review
when
it
gets
merged
into
into
the
main
line.
Branch.
C
I
think
that
that
would
set
us
up
well
for
prepping.
Those
provisional
maintained
errs
to
become
a
long-term,
maintain
errs
for
the
overall
project,
which
our
leadership
page
on
unbox
up,
CMS
norges
long
been
set
up
in
a
way.
That's
we're,
hoping
to
have
a
large
number
of
court
committers
with
the
smaller
group
of
pmc
members
that
are
actually
guiding
the
project,
so
basically
empower
people
to
be
working
and
maintaining
these
subsystems
themselves
rather
than
needing
to
go
through.
The
bottleneck
of
you
know
three
or
four
people.
A
So
there's
also
the
other
issue
of
like
you
know
how.
How
do
you
use
the
thing
before
it's
ready
where,
if
it's
a
contribute,
esta
it
that
way?
And
if
it's
in
a
future
branch,
it's
much
harder
like
the
only
testing,
we're
gonna
get
our
for
people
who
are
using
sandbox
or
people
are
working
on
issue
itself
and
I
mean
I
think
this
is
also
something
that
will
vary
from
project
to
project
like
depending
on
what
we're
working
on.
But
there
are
some
things
that
you
can't
use
without
changes.
A
Other
changes
to
core
I'm,
not
sure
if
this
is
true
of
entity
reference
Mike,
but
in
my
mind
there
are
entity,
api
functions
that
are
missing
from
core
that
we
would
need
to
add
back
in
I.
Don't
know
if
that's
actually
the
case
anymore,
not
they
could
have
been
in
already,
but
I
know
it's
specifically
for
basis
like
we
needed
to
make
it
a
bunch
of
changes
to
places
other
than
basis,
and
so
trying
to
be
able
to
text
that
in
its
end
state
it
will
eventually
need
to
be
a
poor
request
again
score.
A
I
don't
know
when
that
needs
to
happen.
Do
we
need
to
do
that
when
we
decide
we're
going
to
work
on
this
crazy
feature,
or
do
we
need
to
do
that
a
month
before
release
I,
don't
know
if
that
matters
I,
don't
know
that
we
need
to
policy.
We
can
just
play
it
by
ear
for
any
given
feature
or
something
like
basically.
A
B
I
would
say
yeah
if
we
do
it,
but
I'd
say:
maybe
the
future
branches
are
going
to
be
more
important
if
we
actually
do
any
refactoring
of
things
just
to
test
a
bunch
of
different
changes
to
core,
but
we
aren't
really
doing
any
of
that,
because
that
would
sort
of
break
backwards
compatibility.
So
so
ya,
like
like
here's
an
example
for
the
reference
module
I,
am
making
some
additions
to
the
entity
info.
B
A
B
A
C
Cool
yeah
I
think
you've
got
a
good
point
Mike
and
that
that
sort
of
refactoring
is
what
we've
run
up
against
in
almost
every
module.
We've
moved
into
court
path,
auto,
for
example,
needed
to
be
merged
into
path
module
date.
Module
had
a
bunch
of
stuff
that
needed
to
be
moved
into
in
includes
because
I
actually
provided
an
API
like
all
data.
Api
is
now
just
in
date,
dot
Inc,
for
example,
a
link
module.
We
did
some
small
room
factoring
there
as
well
like
I.
C
Think
working
in
contribute
is
a
great
starting
point,
but
I
think
that
the
longer
that
we
can
have
it
in
a
feature
branch
actually
seeing
in
the
integrated
against
core
version
the
better.
But
I
do
think
that
the
plan
of
having
the
conversion
like
fully
functional
and
working
first
is
a
good
plan
and
then
getting
that
into
a
feature
branch
as
soon
as
possible,
so
that
we
can
actually
do
that
work
of
integrating
it.
C
Branch
for
a
longer
period
of
time,
so
contribute
is
great,
get
it
to
a
point
that
it's
working
and
also
make
it
so
that
people
can
use
it
on
their
existing
backdrop
websites.
But
then
the
feature
branch,
I
think
is,
is
a
good
idea.
As
a
preliminary
step
before
we
do
any
kind
of
large-scale
merging
into
court.
Just
working
in
a
single
poll
request
sometimes
can
just
be
a
little
bit
hectic
just
because
it
takes
so
many
rounds
of
iteration
to
get
it
actually
ready
with.
F
The
button
thing
with
contrib
is
that
it
doesn't
have
tests
enabled
so
we
don't
know
if
we're
breaking
things
and
it
doesn't
have
sandboxes.
So
you
have
the
dilemma
of
which
thing
is
easier
for
less
tech-savvy
people
using
the
core,
oh
cool
request
that
gets
them
automatic,
sandboxes
or
setting
up
local
environments
and
installing
the
contributor
they
can
test.
You're,
not
police,
doesn't
feature
brands
that
it
they
get
they
get.
The
automated
there
is.
There
is
a
feature
request
for
enabling
sandboxes
for
the
trip
as
well.
A
That's
a
good
point,
both
automated
tests,
which
will
help
developers
and
the
automated
San
Marxist,
which
will
help
testers
our
only
available
in
court
and
I-
think
that
that's
also
fine
if
we
continue
to
do
the
leg,
build
it
in
converse
as
long
as
we
get
the
feature
branch
early
enough,
we
can
make
use
of
like
oh
I,
didn't
realize
this
random
test
was
failing,
or
you
know
now,
I
can
get
more
eyes
on
it.
I
don't
think
it
necessarily
like.
We
need
to
put
reference
into
a
feature
writer
right
now,
like
I.
A
Don't
think
this
is
ever
going
here,
but
I
think
the
sooner
the
better
and
yeah
I
think
we
also
might
want
to
think
about
enabling
contributes
to
turn
on
testing,
as
well
as
enabling
kinship
projects
to
turn
on
automatic
sandboxes,
and
that
might
even
be
something
that
like
if
we
have
a
module
that
is
in
candidate
for
core
that
exists
in
confers.
We
can
say
these
two
things
need
to
be
enabled
for
that
project
ahead
of
time.
You
know
once
we
get
those
abilities
to
do
that.
C
Let's
say
somebody
does.
Somebody
wants
a
future
branch
that
and
it's
large
and
it's
a
large
enough
issue
that
it
necessitates.
It
then
great.
Let's
make
them
a
committer
teach
them
on
how
to
commit
to
the
future
branch,
and
then
that
would
be
that,
like
I,
think
that
we
really
want
to
encourage
people
to
use
feature
branches
for
large
features
whenever
possible
and
get
those
people
in
power
to
commit
to
it.
A
A
E
We
make
a
release
candidate
releases
against
the
feature
branch.
You
know
say
we
had
a
one
dot,
60
branch
you
make
and
like
gonna
ways
to
contribute
to
backdrop.
Cms
dialog
page
have
a
download
rc1
so
that
people
can
download
that
version
and
test
in
that.
You
know
months
that
we
do.
The
teacher
freeze.
C
We
we
can
make
tags
from
any
branch.
I
think
I'd
prefer
to
see
all
the
tanks
coming
out
of
the
name
line
branch,
though
that
could
be
confusing
in
the
event
that
feature
branch
wasn't
actually
merged
before
the
final
release
that
an
RC
one
might
have
a
feature,
but
then
it
didn't
actually
get
merged
into
one,
not
XO,
then
the
final
version
didn't
have
it.
That
would
be
a
little
bit
confusing,
but.
A
C
C
A
C
Well,
there's
not
much
that
I'm
actually
going
to
be
reporting
here,
but
the
next
item
on
the
agenda
is
infrastructure.
Those
are
items
around
bankruptcy,
ms,
that
aren't
the
software
itself,
mostly
things
like
our
websites
and
the
tools
that
we
use,
like
github,
Jeff
you're.
Actually,
the
first
item
on
the
agenda
here
talking
about
backdrop
CMS
on
pantheon
and
drush
updates,
which
I
I
feel
like
we've,
been
making
some
progress
in
this
area
and
I'd
like
to
hear
there's
been
any
updates
this
week.
C
E
Updates
this
week,
you
have
have
made
some
progress
up:
Jen
and
I
both
put
a
thing
in
the
issue:
22
Greg,
to
have
a
look
at
the
data
we've
collected
and
see.
If
you
can
see
anything
on
his
side,
the
site,
local,
is
working
when
you
issued
rush
commands
against
your
Pantheon
site,
so
it's
being
picked
up
in
that
way,
but
through
the
dashboard.
What
Jen
and
I
have
experienced
is
that
it's
not
responding
to
checking
the
box
to
clear
cache
or
run
update
dot,
PHP.
A
Actually,
laughs,
yeah
and
Greg
just
hasn't
responded
yet
since
the
last
time
we
told
him
about
it,
you
anything
everything
was
working
more
like
well,
we
think
it's
working
too,
but
it's
not
working
so
I,
don't
know.
What's
going
on,
I
think
maybe
just
another
another
Pope
on
that
to
see
what
he
like
he
just
might
have
had
any
time
this
last
week
to
look
at
it.
The
other
folks,
probably
next
steps
there.
C
C
E
C
C
Okay,
let's
see
next
item,
we
have
a
third
of
making
task
lists
for
every
release
that
we
put
out
and
Gregor
convicted
on.
151
is
task
list
that
has
some
items
checked
on
it.
It
was
just
funny
because
I
think
maybe
this
is
for
150
and
they
got
pushed
one
by
one
like
we
don't
have
the
release
tank
jet,
for
example,
I'm
not
quite
sure
what.
C
Maybe
I
mean
I:
did
this
checklist
actually
be
accurate,
because
I
think
that
it
was
for
150
I
like
151?
We
definitely
haven't
tagged
yet,
but
the
box
is
checked
so
anyway.
I
think
it's
great
that
we
should
start
using
these
checklists,
but
I
think
maybe
we
should
uncheck
everything
or
frame
using
this
for
151
I
think
maybe
he
just
started
when
I
vehicle.
A
Issues
that
are
all
done
and
then
there's
coaster,
these
issues
that
are
not,
and
so
things
like
sending
the
newsletter
I,
it's
all
related
to
150.
Then
we
need
the
point
release,
not
the
bug-fix
release,
but
we
aren't
doing
it
until
151
is
out
so
I,
don't
know
which
milestone
it
should
be
under.
But
the
issue
is
415.
A
A
C
A
A
B
Silly
question,
but
could
we
possibly
have
two
different
Pantheon
up
streams
available
for
people
to
use
either
like
backdrop
stable
or
backdrop
like
you
know
beta,
or
something
like
that,
so
that
if
people
want
to
be
able
to
update,
like
you
know
on
as
soon
as
possible,
they
could
use
one
upstream
and
then,
if
they
are
more
concerned
about
stability,
they
can
use
the
other.
So.
A
C
C
A
So
I've
trimmed
this
down
to
only
talk
about
the
three
most
important
things.
Every
meeting
those
are
currently
the
showcase
section
which
I'm
planning
on
working
on
today,
I
at
least
want
to
get
it
to
a
point
where
the
layouts
are
ready
for
review.
Even
if
the
theming
isn't
great
and
I
think
probably
anyone
else
to
pick
a
theme
changes
if
they
wanted
to
take
it
from
there
and
a
documentation
is
the
next
most
important
thing.
A
Tom
is
doing
excellent
job,
revealing
all
of
our
fantastic
documentation
he's
going
through
and
fixing
all
of
our
grammar
and
syntax,
and
he's
setting
up
really
good
rules
about
how
we
should
be
using
capitalization
in
different
places
and
I
can't
wait
to
see
like
a
beautiful,
consistent
documentation
area.
It's
going
to
be
great,
but
we
also
want
to
work
on
a
forum.
A
That's
number
three
on
our
list,
so
if
we
can
get
the
ad
showcase
section
at
least
close
enough
in
documentation
section,
we
should
be
done,
maybe
even
as
early
as
next
week.
Maybe
maybe
not
we'll
see
how
it
goes.
Then
we
can
put
all
of
our
effort
and
setting
it
performs
so
that
people
can
have
a
place
to
talk
about
back
up.
That's
not
github
and
that's
for
maybe
I
was
low
estate.
C
C
Potentially
that
could
be
going
into
that
could
be
going
to
151.
Most
of
those
look
like
half
of
them
looks
like
look
like
damn
poll
requests,
which
is
great
I'll,
go
through
those
today,
hopefully,
and
give
them
get
them
merged
in
the
timeline
for
15.
Everyone,
I
think,
is
pretty
much
going
to
be
as
soon
as
possible.
I
think
what
we
may
do
is
go
through
the
current
pull
request
list,
merge
them
all
and
then
get
151
out.
C
The
things
that
are
holding
up
the
151
release
actually
there's
a
whole
lot
to
talk
about.
Then
there's
the
important
bug
fix
bug,
fixes
section
here
in
the
agenda
in
which,
once
we
get
these
issues,
fixed
them
will
make
151
or
soon
as
we
any
of
them
fixed,
we'll
make
one
by
one
go
out,
and
one
of
them
is
images
are
not
being
able
to
be
inserted
into
custom
blocks.
D
C
2219
that
pull
request
has
already
been
merged
and
it's
in
the
latest
10
X
branch.
So
hey,
that's
great.
That's
probably
the
one
of
the
largest
items
that
we
found
me
151.
The
next
item,
the
homepage
layout
menu,
is
not
set
to
a
drop-down.
I
found
this
to
be
super
confusing
when
I
was
trying
to
make
the
animated
gifts
for
the
release
notes
for
air.
For
that
further
release
announcement.
That
issue
is
20
to
22
and
I.
C
Think
that
we,
like
generally
filed
a
pull
request
that
fixes
the
issue
we
needed
an
update,
how
it
looks
like
that's
already
been
done
to
so
we'll,
probably
much
that
it
in
later
today,
because
it's
it's
looking
good
once
that's
in
and
we
go
through
the
remaining
items
that
already
have
that
already
have
four
requests.
That
will
probably
be
the
151
release,
so
that
could
happen
pretty
much
as
soon
as
we
get
through
that
that
queue
there's
a
couple
of
issues
that
we've
got.
C
No
fear
of
things
to
take
a
look
at
the
Installer
module
doesn't
allow
you
to
upload
a
an
archive
directly
through
the
UI
that
is
issue
19,
20
and
I.
Think
yeah
this
one.
This
one's
actually
been
plaguing
us
for
quite
a
while.
It's
a
little,
it's
not
just
a
little.
It's
quite
tricky
to
figure
out
what's
happening
there,
there's
something
funny
between
the
uploading
of
a
file
and
it
being
in
a
dialogue
and
paying
through
ajax,
which
that's
a
whole
mess
of
complexity,
3
kind
of
difficult
things
to
handle
all
together.
C
Lastly,
it's
been
requested.
We
tried
to
make
this
happen
before
the
1.5
release,
but
couldn't
figure
out
how
to
do
it
and
that's
how
to
make
the
hero
block,
have
a
full
bleed
left
to
right
in
the
bases
theme
and
that's
issued
2190
and
there's
a
couple
of
different
approaches
that
have
been
proposed
in
the
issue.
But
we
haven't
reached
anything
like
consensus
around
how
that
problem
should
actually
be
solved
or
if
it
is
even,
is
possible
for
us
to
solve
in
the
1.5
release
at
all.
C
So
there's
a
lot
of
interesting
discussion
going
on
there.
If
anyone
has
a
chance
to
take
a
look
at
the
implementations
and
express
their
opinions,
then
we're
kind
of
soliciting
ideas
there
in
that
issue:
2190,
that's
it
for
the
1.5
release
and
how
things
are
going
there.
The
next
item
on
the
agenda
is
the
1.6
release,
which
is
the
release
that
comes
up
january,
fifteenth
2017.
C
As
we've
discussed
the
past
couple
of
weeks.
We
will
be
implementing
a
feature
freeze
on
january
first,
which
just
means
that
we
won't
be
pulling
in
any
new
features
after
that
date
will
be
using
that
two
week,
time
period
to
kind
of
stabilize
and
get
the
1.6
release
full
are
completed
with
making
sure
that
we
get
all
the
bugs
results
before
that
the
final
release
comes
out
so
items
for
the
1.6
release.
We've
got
some
items
that
are
holdovers
from
the
1.5
release
that
didn't
make
it
improving
the
rich
text.
C
Editor
we've
been
iteratively
doing
this
as
we
go
along,
but
there's
still
a
lot
of
items
left
to
accomplish.
There's
a
meta
issue
at
1087
that
contains
a
bunch
of
ideas
of
things
that
we
can
do
to
improve
the
rich
text.
Editor
experience
and
I
won't
go
through
all
of
them
individually,
but
as
always
we're
still
or
as,
as
has
been
the
case,
we're
still
looking
for
anyone.
C
The
next
item
is
reference:
module
reference
module.
We've
done
a
bunch
of
work
on
making
a
generic
reference
module
that
can
reference
any
type
of
entity
in
core
issue,
for
that
is
1301
Mike's
been
doing
the
most
amount
of
work
on
it.
Do
you
have
any
things
you'd
like
to
bring
up
this
meeting?
Mike
yeah.
B
I
think
Jen's
right,
so
we're
going
to
have
to
scale
things
back
and
just
have
the
field
be
able
to
reference
only
one
type
of
entity
at
a
time
creating
the
field
and
letting
people
select
the
different
entity
types
is
fine,
but
if
you
wanted
to
actually
create
a
view
of
all
of
the
all,
the
items
like
you
know,
referenced
by
this
module
or
by
this
field,
it'd
be
hard
because
they
don't
have
a
common
base
table.
So
that
might
be
a
bit
too
hard.
B
So
I
guess
for
this
release
are
just
going
to
have
a
reference
one.
You
know
in
the
field
configuration
you
have
to
select
what
type
of
entities
reference
and
then
it'd
only
be
able
to
reference
that,
but
we
can
leave
it
open
that
if
we
figure
out
how
to
reference
multiple
entities
and
handle
it
with
views,
we
can
add
that
on
later.
C
Have
you
or
have
we,
I
should
say,
come
up
with
any
kind
of
a
solution
for
how
we're
going
to
deal
with
taxonomy
term
references
right
now,
because
we've
already
gotten
one
reference
module
in
court
for
taxonomy
terms,
and
once
this
generic
solution
becomes
available,
will
that
deprecated
taxonomy
term
references
or
we
just
hang
out
with
them
both
or
the
1
1
dot
x,
release?
Well.
B
The
thing
is:
is
that
the
actual
field
itself
is
there's
basically
nothing
to
it
all.
This
is
a
database
table
with,
like
you
know,
the
entity
type
and
the
ID.
All
the
complexity
comes
in
around
the
widgets
used
to
select
it
like
the
autocomplete
and
stuff
like
that
of
youth
integration
and
basically,
all
the
bells
and
whistles.
So
what
we
might
want
to
do
is,
like
you
know,
auto
auto
completes
already
in
Coors
like
the
type
of
field
so
yeah.
C
A
I
so
I
looked
at
this
a
long
time
ago.
I
don't
know
where
things
are
now
or
were
the
result
will
be,
but
it
looked
like
it
should
be
pretty
straightforward
to
write
an
upgrade
path
from
the
current
taxonomy
table,
format
to
the
new
entity,
reference
kind
and
then,
as
long
as
we
have
the
same
like
widgets
or
whatever
we
can
just
switch
them
over
for
each
field.
A
Instance
yeah,
it's
I,
don't
think
it's
very
complicated
in
terms
of
the
differences
between
where
we
are
and
where
we're
going
to
be
so,
I
think
if
we
wanted
to
just
leave
all
of
the
old
code
there
and
market
deprecated
and
then
have
the
upgrade
path
point
all
of
the
new
stuff.
That
would
be
a
good
solution
for
not
breaking
api's
by
getting
everybody's
data,
all
cleaned
up
in
preparation
for
the
future
yeah.
C
Okay,
so,
let's
see
other
features
for
1.6,
adding
a
file
/
media
entity
solution
is
issued
1448
and
how
far
we
take.
This
probably
just
depends
on
how
much
enthusiasm
there
is,
for
this
feature,
I
think
at
the
very
basic
level.
What
we're
hoping
to
include
is
adding
a
view
and
pages
for
editing
file
entities
directly.
That's
probably
the
primary
focus
of
that
issue
right
now,
as
that
gets
built
out.
That
may
also
start
to
expand
to
things
like
you
know,
when
you're
uploading,
an
image
or
using
the
rich
text,
editor
reusing.
A
Of
this
is
a
bug
fix
for
the
problem
right
now
we
have
with
embedding
images
in
blocks
right
if
you
delete
that
block
you're,
never
going
to
be
able
to
delete
that
image,
it's
always
on
the
file
system.
So
if
somebody
upload
something
that's
potentially
dangerous
or
what
ever
you
can't
ever
get
rid
of
it,
because
there's
no
interface
for
removing.
A
Onto
the
server
delete
the
file
and
delete
it
from
the
files
table,
which
is
kind
of
an
issue
and
I
think
this
sooner,
we
can
get
an
interface
that
allow
people
actually
control
their
files
the
better
and
then
we
can
also
leverage
it
for
a
bunch
of
other
things
like
they
talked
about
a
file
browser
so
that
you
can
actually
look
at
the
stuff.
A
It
would
be
great
to
just
get
the
UI
piece
and
fix
the
bug
and
then
once
we
have
that
in
it'll
be
easier
to
add
all
the
little
pieces
in
the
future.
C
That's
a
really
kind
of
simple
example,
but
there
are
lots
of
other
persons
where
there's
a
lot
of
common
configuration
across
lots
of
different
layouts.
And
how
can
we
make
it?
So
that's
it's
easier
to
update
all
of
those
at
the
same
time.
So
we
have
two
issues,
both
kind
of
taking
different
approaches
to
solving
this
problem.
C
One
of
them
is
20
to
45
and
20
to
45
is
about
making
it
so
that
you
can
reuse
individual
blocks
across
multiple
different
layouts,
like
basically
like
a
shared
instance,
or
something
like
that
and
there's
also
1886,
which
is
instead
of
just
sharing
individual
block.
You
might
be
able
to
reuse
an
entire
region
or
an
entire
group
of
blocks
both
of
those
really
interesting
topics
and
how
we
solve
them.
C
Whether
some
of
them
might
actually
be
able
to
be
salting
contribs
would
need
to
be
implemented
as
part
of
core,
but
all
of
them
so
far
are
all
just
brainstorming
about
how
we
can
make
that
experience.
A
lot
better
for
site
builders,
so
right
now,
mostly
brainstorming.
But
if
anybody
wants
to
take
a
stab
at
implementation,
either
can
trigger
a.
C
I'm
have
it
that
would
be
great,
let's
see,
and
lastly,
for
1.6
we're
hoping
to
kind
of
hammer
out
kind
of,
but
actually
am
routes
some
system
for
providing
an
entity
that
doesn't
have
a
URL
like
an
entity
like
a
I,
keep
saying
this,
even
though
it's
not
probably
will
call
it.
But,
like
a
block
you
know,
a
block
is,
could
be
an
entity
but
I'm
backdrop.
It's
not
it's
config,
but
it
could
be
an
entity
that
is
filled.
C
The
bowl
customizable,
that
is
piece
of
content,
doesn't
have
a
URL,
something
that
could
just
be
used
for
like
sliders
and
other
pieces
of
content
that
are
never
shown
as
a
standalone,
but
only
used
within
views.
So
that
issue
is
issue
100
and
how
we
approach
that
might
be
an
entity
that
doesn't
have
a
URL
or
it
might
be,
making
it
so
that
nodes
have
the
possibility
of
not
having
a
URL,
so
they
could
be
used
for
that
purpose.
That
is
issue
100,
the
status
of
which
looks
like
we're.
C
Mostly
still
in
discussion
here,
looks
like
Daryl.
You
posted
an
item
to
that
that
we
could
just
port
and
Rab
a
whole
module,
for
example
yeah.
This
is
exactly
the
two
two
sides
of
the
argument
that
we're
looking
at
whether
or
not
it's
like
you
know,
find
a
way
to
make
nodes,
not
have
you
or
else
the
rabbit,
hole
or
making
something
else
entirely
different
from
nodes
that
don't
have
URLs
in
the
first
place,
and
we
still
haven't
actually
reached
a
decision
on
that
which,
which
way
we
want
to
go
well.
A
Me
oh
I
was
gonna
say
this
would
be
a
great
discussion
topic
for
at
dad
camp
if
we're
all
going
to
be
there
in
person
and
talk
about
the
pros
and
cons
of
each
and
also
figure
it
out,
like
the
future
direction
of
backdrop
to
might
help
lead
into
this.
If
we
want
to
move
forward
into
a
more
like
envy,
rich
world,
then
setting
up
something
like
beans
might
be
the
right
approach.
A
But
if
we
want
to
move
into
a
simpler
like
triple
six
style
world,
where
taxonomy
terms
become
nodes
and
blocks
become
notes,
then
maybe
just
a
setting
on
the
note
is
the
way
to
go.
But
I
think
that
there's
like
a
really
big
conversation
that
we
have
to
have
around
like
the
future.
That
might
be
hard
to
do
in
an
issue
queue
so
I
yeah,
but.
B
I
was
going
to
make
one
point:
is
that
the
argument
about
whether
to
use
nodes
or
not
might
not
have
anything
to?
Perhaps
we
shouldn't
even
think
about,
like
the
URL
part
of
it
I
think
the
question
is:
is
we
should
look
at
the
other
attributes
on
the
node
base
table
because
nodes
have
authors
and
created
times
and
stuff
like
that?
So
the
question
is:
would
these
other
types
of
of
entities
like
these
pages
entities
have
the
same
attributes
as
the
nodes?
B
C
Yeah,
and
actually
now
that
we
have
things
like
methods
for
URI,
for
example,
we
could
even
conditionally
change
what
the
URI
is,
instead
of
assuming
that
it
snowed
/.
Whatever
note
/
node
ID
with
that
method
could
actually
return
different
values
based
on
whether
or
not
it
supposedly
has
a
URL
or
not,
and
anyway,
yeah
more
discussion
to
be
had
on
on
that.
That
item
for
sure
Darrell
did
you
want
to
add
something
as
well.
D
No
I'll
do
I
was
going
to
say
that
the
solution
that
I
I
presentable
using
rabbit
hole.
It
is
a
more
simple
solution,
but
but
I
see
the
benefit.
I
have
your
own
awesome
entities,
but
again
this
is
a
longer
discussion.
I
guess
we
have
to
sit
down
and
think
about
the
protein
content
by
now,
which
one
is
best
yeah.
C
C
That's
with
like
these
items
in
particular
to
be
tackled
for
the
next
release,
you
can
always
check
out
the
issue
tracker
for
1.6
issues
that
are
include
more
things
than
than
what
we've
just
mentioned
here.
The
reason
one,
you
should
add
all
right,
it's
real
quick
that
does
it
for
the
1.6
releases.
Let's
do.
F
A
community
growth
update
from
Gregory,
oh
yeah,
just
just
real
quick
for
the
wild
sex
appeal,
the
the
mess
that
we
have
nests
I,
always
call
it
that
with
the
menus
and
the
bread
cramps
thing
I.
I
know
this
is
way
too
deep
for
me.
I
would
like
to
get
it
sorted,
but
I
can
only
touch
that
so
far.
My
PHP
skills
are
good
too.
That's
that
the
user
facing
text
I
have
to
delve
into
the
menu
system
and
how
it
work.
F
A
Would
like
to
chime
in
on
the
fact
that,
like
breadcrumbs
and
menus
are
super
weird
in
Drupal
and
half
in
since
triple
seven
and
I.
Think
that
that's
something
that
a
lot
of
more
basic
sites
rolling
on
really
heavily
is
getting.
That
structure
done
correctly
and
I
would
also
love
to
see
a
focus
on
getting
that
made
less
weird.
But
it
is
going
to
be
really
hard.
F
C
C
Okay,
upcoming
events,
we
have
a
calendar
of
upcoming
events.
You
can
check
it
out
to
backdrop,
CMS,
org,
slash
events.
The
big
item
that's
coming
up
is
the
Bay
Area
drupalcamp,
which
is
October
20th
to
the
23rd
suds
coming
up
real
soon
in
two
weeks,
and
that
will
be
exciting
too,
because
we've
got
multiple
backdrop,
events
happening,
we
have
an
all
day
training
and
we
have
an
all-day
summits.
C
There's
also
a
bunch
of
other
events,
but
you
can
check
out
the
website
for
that
and
there's
also
an
ical
feed
that
you
can
get
linked
from
that
page.
That
includes
all
of
the
events
as
well
as
you
can
get
a
feed
for
these
meetings.
If
you
want
to
add
those
to
your
calendars
that
you
know
when
they
are,
then
there's
a
feat
for
that.
C
A
Coloma
asked
in
chat
and
if
we
could
put
a
more
obvious
link
to
the
reddit
somewhere
because
we're
starting
tues
an
issue
queue
that
shouldn't
be
issues
in
the
issue.
Queue
and
I
asked
look
where:
where
should
we
put
it?
Does
anyone
have
any
ideas
of
how
we
can
encourage
people
to
discuss
in
the
discussion
area
and
post
issues,
an
issue
area
or
how
to
actually
manage
that
in
a
way
that
makes
sense.
C
A
F
F
The
the
main
issue
is
the
one
with
the
with
the
home
page
layouts,
not
having
the
drop
the
primary
navigation
as
it
dropped
down,
and
this
one
brought
out.
Another
issue
with
with
the
profiles
like
we
needed
a
I,
an
update
hoop
for
for
for
the
standard
profile
and
then
that
folder
is
outside
for,
and
people
upgrading
usually
replace
the
core
folder,
but
they
leave
that
outside.
F
C
We
could
manage
it
an
API
compatible
way,
so
we
can
in
theory,
if
so
it's
it's
kind
of
so.
Profiles
are
weird
because,
unlike
modules,
themes
and
layouts,
there's
no
ability
to
have
like
multiple
locations
profiles
right,
not
only
live
in
one
place.
They
don't
have
the
ability
to
be
like,
like
multi-site
profiles,
isn't
a
isn't
a
thing,
so
you
couldn't
have
profiles
inside
of
the
sites.
You
know
my
name
directory
or
sites
example.com
directory
or
in
Drupal
7
land
sites
default
profiles,
for
example
our
sites
all
profiles.
C
Those
directories
aren't
supported.
Basically,
so
that's
why
profiles
are
not
like
other
things
that
can
exist
in
multiple
locations,
because
the
never
had
that
ability
to
be
in
multiple
places,
but
we
could
change
that
and
make
it
so
that
they
would
be
treated
the
same
way
because
a
root
directory
profiles
would
override
the
core
directory
of
profiles,
so
it
actually,
if
we
just
moved
it
and
people
that
existing
sites,
it
would
be
able
to
act
exactly
the
same
because
as
they
operated
did
their
core
folder.
C
F
Some
yeah,
I
know
that
I
realize
that,
but
then
see
now,
we
need
to
put
on
a
break
out
of
jail
talk
in
the
core
standard
profile,
so
new
uses
goodness
like
the
ones
that
upgrade
by
replacing
core.
They
would
have
the
update
hook
being
in
the
bore
profile,
but
then
the
if
they
do
not
delete
the
standard
profile
from
the
root
folder.
The
update
hook
will
never
fire
because
I.
C
Are
just
run
on
installs,
but
profiles
are
actually
considered
to
be
modules.
They
have
an
entry
in
the
system
table
and
their
dot
install
file
can
be
loaded
to
do
updates
if
the
profile
needed
to
update
its
information.
Somehow
and
the
the
thing
that
we're
actually
facing
right
now
is
that
the
homepage
layout
is
owned
by
the
standard
profile,
but
there's
a
bug
in
the
home
page
layout
that
we
want
to
fix.
So
we
need
to
have
an
update
hook
in
the
standard
profile
that
fixes
the
bug
in
the
configuration
at
the
home
page.
C
E
B
F
B
Yeah,
that's
like
so
install
profiles.
All
they
do
is
do
a
bunch
of
configuration
and
add
elements
and
enable
modules
and
stuff
like
that.
We
can
see
directly
have
multiple
ones.
We
have
like
a
blog,
install
profile
that
does
all
this
stuff
set
ups
to
set
up
a
blog
and
then
have
a
forum
profile
that
sets
up
all
the
content,
types
and
reference
fields
and
stuff.
You
need
to
do
a
forum,
so
I
mean
make.
These
are
equations
that
configure
sort
of
the
big
paw
new
like
connect.
C
So
maybe
we
should
rework
that
existing
pull
requests
to
move
the
update
hook.
We
can't
move
it
into
layout
module
because
layout
module,
because
it's
a
module
t
gets
turned
on
during
the
upgrade
from
Drupal
7.
We
can't
actually
put
update
hooks
in
it.
Otherwise
it
will
cause
update
whp
to
be
run
are
required
to
run
multiple
times.
Somebody
needs
to
live
in
system
module
in
the
event
that
we
want
to
update
that.
So,
ok,
that's
a
good
les.
F
Last
thing
before
we
go
out
because
this
is
related
if
the
primary
menu
was
a
block
copy,
like
the
the
feature
that
we
suggest
for
20
to
45
issue,
we
wouldn't
be
having
that
issue
because
then
all
the
settings
will
be
copied
across
the
layouts
and
we
wouldn't
be
having
that
issue
in
the
first
place.
Yeah.
A
It's
gonna
be
really
hard
to
write.
Just
thinking
out
loud
here
to
write
an
update
hook
for
block
copy
like
I.
Don't
think,
there's
any
way
we're
going
to
be
able
to
determine
after
the
fact
whether,
like
a
header,
it
should
be
copy.
There
should
be
a
duplicate.
So
if
we
do
have
Italian,
would
that
just
be
like
a
new
feature
that
new
sites
would
get
copies,
but
existing
sites
would
have
to
manually
swap
out
their
instant
single
instances
for
copy
instances,
yeah
that
wasn't.
F
C
In
this
case,
it's
also
worth
noting
that
we're
really
just
fixing
a
problem
that
we
have
in
the
1.5
Oh
installation
of
new
sites
like
existing
sites.
Don't
have
this
problem
because
this
feature
didn't
exist
before
they
upgraded
so
they're,
actually
all
correct
and
using
their
current
default,
which
is
a
hierarchical
menu,
even
though
a
long-term,
if
you're
upgrading,
you
should
not
be
using
that
because
it's
really
terrible,
but
that's
the
only
option
that
we've
ever
had
before
so
now.
Yeah
existing
sites
are
completely
unaffected
by
this.
C
C
Okay,
any
other
questions
comments,
anything
okay,
that's
it,
then
we're
going
to
hang
on
after
the
line
to
talk
about
if
we
want
to
adjust
the
agenda
for
next
week,
but
you're
not
obligated
to
stay
on.
Thank
you
guys
so
much
for
joining,
and
thank
you
everybody
for
watching.
We
really
appreciate
it
as
always,
and
we'll
see
you
next
week,
all
right
guys.