►
From YouTube: Backdrop Weekly Sept 21
Description
Today’s development agenda: http://bit.ly/2y9Msbo
A
All
right
we're
on
air.
It
is
Thursday
September
21st!
Thank
you,
everybody
for
joining
our
meeting
today.
This
is
a
meeting
to
check
in
on
development
tasks
for
backdrops
CMS
quickly.
Before
we
get
into
dev
tasks,
we
should
all
now
have
the
final
copy
of
the
software
Conservancy
fiscal
sponsorship.
Agreement
I
sent
our
copies
off
last
week.
A
But
hopefully
we
will
get
that
document
signed
and
returned
to
our
fiscal
sponsor
and
then
will
be
able
to
be
under
their
umbrella
and
we're
hoping
that
we'll
be
able
to
announce
that
at
our
next
next
newsletter.
It's
not
the
one
that's
coming
out
about
1.8,
but
the
one
after
that,
so
a
month
from
now,
we
should
have
that
all
taken
care
of,
but
that
doesn't
mean
they
need
to
get
all
of
our
copies
of
that
document.
A
A
I
think
for
corn
we're
looking
at
using
select
and
there
is
a
control
person
what
it's
a
little
bit
more
robust.
It
doesn't
just
handle
multiple
select
elements,
but
I
could
also
replace
our
autocomplete
Cora's
autocomplete
has
got
some
kind
of
old
crafty
code
running
it,
so
the
the
Select
in
decor
will
be
a
little
bit
more.
More
in-depth
of
a
change
then
chosen,
which
is
just
multiple
select
but
yeah.
Both
are
good,
solid,
Drupal
solutions
to
that
problem,
so
I'm
happy
to
have
them
in
backtrack.
A
Let's
talk
about
backdrop,
since
we
just
had
a
release,
manager
colleague
or
we
released
backdrop
version
173,
which
was
a
bug-fix
release
along
with
the
new
feature,
release
1.8
point
Oh
last
Friday
I
think
they
went
out
around
10:30
p.m.
if
you're
looking
at
github
timestamps.
Those
are
translated
based
on
where
you
are.
A
More
tests
or
markup
changes
went
into
one
point
8.0.
Instead,
so
we
were
able
to
get
a
bunch
of
aesthetic
improvements
into
one
point
eight.
So
if
you
updated
one
point
eight
and
you
go
check
out
like
the
admin
config
page,
there's
no
icons
there.
That
page
is
responsive.
It
had
kind
of
a
general
aesthetic
boost.
A
It
would
be
good
if
we
could
kind
of
clean
up
all
this
file
management
stuff,
that
we
were
working
on
for
1.8
and
trying
to
put
it
all
together
and
get
it
into
1.9,
and
if
1.9
could
be
like
a
file
handling
media
focused
release.
That
might
be
a
big
win
for
a
backdrop.
So
we
have
three
issues
in
particular.
One
of
them
is
the
ability
to
edit
an
existing
file.
A
There
are
some
confusion
about
what
you
expect
to
happen
when
you
edit
a
file
and
what
actually
happens
when
you
edit
a
file
using
like
file
entities
edit
having
a
pretty
big
disconnect,
and
so
we
need
to
figure
out
how
to
clean
up
that
user.
Experience
that
when
somebody
edits
a
file,
it
does
what
they
expect.
Not
what
Drupal
and
backdrop
think
it
should
do
so,
there's
just
kind
of
some
experience.
Cleanup
we've
gotta
fix
there.
A
In
particular,
there's
kind
of
an
interesting
multi-step
form
that
came
from
file
entity,
module
that
I
think
we'll
want
to
replace
with
an
AJAX
system
so
that
when
you
upload
a
file,
it
can
determine
what
time
type.
It
is
then
ask
you
the
correct
follow-up
questions:
they
son,
what
type
of
fields
you
have
attached
to
those
file
types
rather
than
having
to
go
through
a
multi-step
form
workflow,
and
if
we
can
do
that,
we'll
also
have
that
built
into
the
file
upload
tool
in
both
places.
So
I
think
both
of
those
are
really
solid.
A
First
attempts,
but
we've
got
some
more
work.
To
get
them
in
I
would
love
to
see
them
in
byte
1.9,
but
we're
gonna
need
some
more
human
testing,
as
well
as
some
more
refactoring
before
that
I'll
be
ready
just
so
that's
kind
of
where
we
are
with
1.8
a
possible
plan
for
1.9.
Another
thing
that
we
should
talk
about,
too
is
translation
and
internationalization.
A
Right
now
in
backdrop
were
sort
of
in
the
same
place
as
we
were
with
Drupal,
with
the
exception
that
we
don't
actually
have
translations
yet
and
we're
working
on
a
translation
server.
But
that's
also
not
quite
ready,
so
I
don't
know
if
it
would
be
good
to
talk
about
what
our
plan
is
for
translation
in
backdrop
1.
If
there's
more,
we
can
do
before
backdrop
or,
if
there's
stuff,
that
we
need
to
be
changing
about
the
way
backup
handles
translation.
A
B
Just
wanted
to
say
that
these
are
huge
undertaking,
because
it's
like
it's
a
very
complex
problem
and
we
are
short
on
had
so.
It
shouldn't
disappoint
us.
If
it
takes
us
long,
I
mean
everybody's
trying
to
help
as
much
as
they
came.
There
are
some
low-hanging
fruits
that
we
can
have
I.
Just
don't
have
the
time.
There's
small
issues
like
adding
a
language
button
in
the
WYSIWYG
ckeditor,
which
is
like
that
the
respective
paths
has
been
already
accumulated
either
d-h
or
reset.
B
C
C
A
Yeah
I
think
there's
definitely
a
lot
of
little
things.
We
can
do
in
one
dot,
X,
whether
it's
a
contributor
core,
but
I
would
love
to
figure
out
like
for
people
who
are
translating
their
sites
like
what
the
biggest
pain
points
are
just
that
we
can
kind
of
get
them
on
a
list
of
like
these
are
things
we
need
to
consider.
A
Fixing
and
I
think
we
can
make
a
lot
of
a
lot
of
improvement
a
little
bit
at
a
time,
but
if
there
is
something
that's
like
fundamentally
weird
that
needs
refactoring,
we
should
think
about
what
that'll
mean
for
a
backdrop
to
as
well.
I
guess
if
we
are
coming
up
on
deciding
when
to
create
a
backdrop
to
we're
trying
to
figure
out
what
API
breaks
are
necessary.
If
that
is
something
that's
important,
that
should
be
on
our
list
of
something
to
consider
for
factor
of
two.
A
So
I
don't
know
for
people
who
are
doing
sites
and
other
languages.
If
there
is
anything,
that's
a
showstopper
right
now
that
would
prevent
you
from
doing
a
site
on
backdrop.
That's
the
thing
that
we
should
look
at
first
and
that
might
just
be
translation
server.
If
we
get
translations
ever
done.
Maybe
everything
else
is
not
so
important.
B
Well,
not
exactly
specific
things,
but
there's
always
being
a
discussion
about
whether
CMS's
and
joyfull
will
activate
specific,
should
be
multilingual
from
the
ground
up
as
in
instead
of
having
to
enable
modules,
it
should
be
like
inner
default.
English
language
should
be
lucky,
translation
should
be
enabled
by
default,
and
English
should
be
a
translation.
That
is
the
default.
It's
just
adding.
That
was
on
top
of
that.
It's
just
this
the
the
argument,
the
opposite
argument,
atop,
that
is,
it
adds
complexity.
B
C
A
Like
that
option
we
have
if
we
can
get
that
working,
that
might
cover
the
majority
of
our
use
cases,
but
I,
don't
know
what
the
needs
are
number
wise
for
having
something
be
more
than
one
language
on
the
box.
It
would
be
good
to
know,
especially
if
our
audience
are
people
who
are
more
likely
to
need
that
we
can
check
I.
Guess
our
user
statistics
for
translation
modules.
A
I,
don't
know
we
need
to
know
specifically
the
ones
in
core
I
guess
who's
got
them
on,
but
yeah.
We
can
also
measure
the
performance
and,
if
there's
a
specific
problem,
we
can
troubleshoot
and
diagnose
what
that
problem
is
too
so
I
think.
Knowing
whether
we
need
it
would
help
us
figure
out,
if
there's
a,
we
should
turn
it
on
and
if
we
should
turn
it
on,
there's
a
performance
problem.
We
can
fix
that
I.
B
A
C
A
B
A
A
B
A
Reference
this
weekend,
it's
actually
not
ready
to
be
used.
Yet,
as
it
says
on
answering
me
page,
it's
like
don't
use
this
so
I
think
we
should
and
I
have
a
good
project
to
play
with
it
on
I
have
a
Drupal
7
project
that
needs
to
get
updated.
The
backdrop
that
has
both
entity
reference
and
references
module
haunted.
So
I
thought
it
would
be
a
perfect
candidate
for
an
upgrade
path
from
both
of
those
and
because
I'm
using
the
two
different
modules.
A
And
this
look,
how
sort
of
different
feature
sets
we
could
try
and
see
what
features
are
necessary
like
the
ability
to
choose
a
list
of
entities
from
a
view
right
stuff,
like
that?
That's
missing
from
reference
module
but
I
did
add
a
flag
to
the
view
on
backdrop,
see
my
sword
since
less
than
you
asked
so
that
we
can
sort
modules
by
whether
they're
promoted
or
not.
We
don't
have
anything
in
core
that
specifically
looks
for
that
and
colours
it,
but
I
think
that
we
could
definitely
add
that.
A
B
On
that,
what
what
you
said
may
be
promoted
is
not
the
best
word
or
like
a
concept,
because
promoted
would
mean
it's
ready
to
try
it
out.
It's
more
like.
We
need
to
help
to
flesh
out
any
problems
its.
We
need
to
convey
that
it's
experimental
and
it's
like
something
that
is
I,
don't
know
core
candidate
or
something
like
that.
Yeah.
A
What
we're
asking
like,
if
that
working
install
the
module,
is
something
that
would
install
its
where
user
interface
it
needs
to
be
in
a
state
where
people
can
like
it
needs
to
be
stable
enough,
that
the
people
are
gonna.
Use
that
aren't
gonna
have
serious
issues
with
it.
That
might
be
true
of
reference.
I,
don't
know,
I
haven't
tried
to
install
it
with
installer
and
see
what
we
get,
but
maybe
we
just
need
to
update
the
readme
file.
So
it's
not
so
scary,
so
I
don't
want
it
to
be
like
here.
A
It
could
just
be
another
read
about
something
but
yeah
I,
don't
know
what,
where
we
are
with
that
in
terms
of
next
steps
like
I
feel
like
the
website
in
terms
of
our
site.
Building
stuff
is
ready.
Someone
will
need
to
look
at
the
way
back,
Jeff
ingests,
that
data
on
the
project,
install
our
page
and
see
I
mean
I,
think
it
just
pull
straight
from
the
feed
I
don't
know,
but
but
there's
something
about
like
when
you
type
a
search
query
in
its
gonna
match.
A
B
B
B
B
A
Okay,
well,
if
there's
around
the
search,
it
sounds
like
we
have
opportunity
to
fix
the
problem
with
a
search
and
add
the
sort
for
projects
that
are
featured
or
promoted
or
whatever
and
I
think
you're
right.
We
can
change
that
language,
but
because
we
already
have
that
promoted
flag
in
core,
that's
what
we
should
use.
We
should
just
make
sure
that,
what's
conveyed
to
the
user
is
more
honest
about
what
the
state
of
that
project
is.
A
A
A
And
then
we
realize
that
the
bigger
problem
was
that
drupal,
since
the
beginning
of
time
has
had
a
page
of
documentation
that
tells
people
that
you
can
update
kim
trip
after
core
and
only
in
drupal.
Seven.
Was
this
core
mechanism
built
in
allowed
modules
to
run
their
updates
between
core
updates
and
the
documentation.
Page
on
drupal.org
have
never
told
people
that
now
you
it's
not
safe
to
run.
A
So
there
are
a
couple
of
possible
solutions
and
I
think
we
came
up
just
with
three
actionable
items
that
we
can
do.
One
of
them
is
when
backdrop
gets
to
a
place
where
it's
update
needs
to
be
run
in
a
particular
order,
and
it
can't
do
it.
It
should
tell
people
that
it
can't
do
its
update,
because
right
now
it
just
completes
like
nothing
is
wrong
and
it
doesn't
even
throw
any
kind
of
air
it.
Just
accidentally
doesn't
work
anymore
when
you're
done
joint
update.
A
So
that's
one
thing:
that's
pretty
easy
for
us
to
do.
We
can
detect
when
that
happens,
and
we
can
set
a
message.
Another
thing
we
can
do
is
you
know,
don't
remember
the
second
one.
Oh
we
can.
When
you
go
to
start
your
update,
it
can
tell
you
if
there's
files
that
are
missing
so,
for
example,
if
you're
upgrading
from
Drupal
to
backdrop
and
you're
on
the
update
page
and
there's
no
contribs,
there
backdrop
gets
that
a
message
at
the
top
of
the
page.
A
That's
like
hey,
some
of
your
friends
seem
to
be
missing
and
it
doesn't
have
to
be
a
blocking
message
that
would
like
prevent
people
from
updating.
So
if
you
want
update,
you
still
can,
but
at
least
it
would
let
you
know
like
hey
your
contribute,
this
button,
which
might
break
everything
you
might
want
to
put
your
modules
here
so
that
you
don't
break
everything.
So
we
can
warn
people
ahead
of
time
and
then,
if
they
do
it
in
the
wrong
order
in
they
get
to
a
place.
B
A
Two
steps
of
notification:
we
can
do
one
before
they
get
into
a
problem
and
the
other
one
after
they
get
into
the
problem
and
then
notice
they
get
after
they
get
into
the
problem
will
say
sorry
you
have
to
run
your
update
again,
so
we
definitely
want
the
one
before
so
we
don't
get
to
the
one
they
have
to
doctor,
but
then
there's
the
third
thing
that
we
could
do,
which
was
take
all
of
this
data
that
we're
deleting
from
backtrack.
That's
not
compatible
with
how
backdrop
works
and
shove
it
into
a
storage
state.
A
So,
for
example,
we
could
use
the
state
system
which
isn't
great.
We
could
use
database
table,
which
is
probably
the
best
place
to
put
it
where
we
could
have
some
kind
of
mapping
from
what
Drupal's
role
ID
used
to
be
to
backdrops
role,
name
or
triples,
taxonomy
vocabulary
ID
to
backdrops
vocabulary,
name
like
any
of
this
stuff
that
is
not
compatible
with
how
backdrop
works
that
we
had
in
drupal
and
a
kinship
mantle
might
need
could
be
stashed
into
one
of
these
locations
so
that
if
I
can
trip
module
needs
that
data.
A
While
it's
running
its
update,
it's
there,
the
database
is
available
while
it's
running
its
update
and
it
can
grab
it.
The
one
thing
we
should
absolutely
not
do
is
put
that
value
into
a
configuration
file
that
contains
data
the
backdrop
does
use
and
that
kinship
developers
can
use
because
they
might
get
that
wrong.
A
That's
not
safe
in
a
place
where
people
trust
data
is
generally
not
a
good
idea,
and
if
we
have
some
files
that
have
data
and
some
time
files
that
don't.
It
also
creates
kind
of
an
inconsistency
for
people.
When
they're
reading
configuration
to
know
whether
that
value
is
going
to
be
available
or
not
we're
all
of
other
config
files,
they
have
all
the
values
they're
all
the
time.
Our
config
system
isn't
really
engineered
in
a
way
where
sometimes
it
should
have
a
value,
and
sometimes
it
shouldn't.
A
A
But
if
you've
already
started
upgrading
your
site,
it
does
prevent
you
from
meeting
to
throw
it
out
and
start
all
over
again,
which
is
good,
so
I
think
as
long
as
we
notify
people
that
that's
not
the
right
way
to
do
things
ahead
of
time,
so
they
have
some
warning.
So
when
you
were
an
update
by
PHP,
if
people
still
choose
to
do
it,
that
way,
that's
fine
and
if
we
can
make
it
so
that
they
can
do
it
that
way
without
hurting
themselves.
That's
even
better!
A
So
there,
these
three
issues,
I,
don't
know
what
their
numbers
are,
but
they
should
be
recent
ones.
In
the
backdrop,
cork,
you
could
use
some
feedback.
We
definitely
could
use
some
help
with
the
language
around
like.
How
do
you
warn
people
in
a
way
that
it
is
both
not
terrifying
and
useful
in
both
instances
that
hey,
you
need
to
update
is
kind
of
bad
news
to
deliver?
How
do
we
say
that
friendly-
and
maybe
you
want
to
put
your
controls
in
here
before
your
an.
C
A
And
then
also,
if
you
have
a
contributes,
this
data
that
has
been
deleted
from
backdrop,
in
particular
anything
haven't,
do
a
taxonomy
or
anything
having
to
do
with
users,
because
we
know
those
are
two
places,
we're
missing
keys.
Let
us
know
what
you
want
that
database
table
to
look
like
like
we
might
need
one.
That's
like
legacy
user
roles
and
one
that's
legacy
taxonomy
term.
Another
place
where
this
is
coming.
It
come
up.
A
couple
of
times
is
with
views
because
these
used
to
be
stored
in
the
database,
another
and
config
files.
A
There
could
be
any
number
of
other
places
in
the
switch
to
config,
where
we
had
to
change
from
auto
increment
IDs
to
memes
any
one
of
those
is
going
to
need.
One
of
these
also,
so
anyone
who's
working
in
Kunshan
runs
into
this
problem.
We
can
create
these
legacy
datastore
tables.
We
just
need
to
know
what
format
they
should
be
in
for
each
given
one
in
terms
of
convenience
for
those
kinship
projects.
So
please
lay
in
on
those
issues.
I.
B
A
It's
because
we
don't
know
everything
like
we
cannot
possibly
know
everything.
Every
contract
module
ever
needs.
You
thank
you
for
updates.
We
know
for
sure
the
data
that
we've
deleted
right,
like
the
Royal
ideas
and
the
vocabulary
IDs,
but
there
could
be
anything
that
any
controls
like,
oh
by
the
way
before
you
do
whatever
I
want
to
do
something
else,
and
that
doesn't
necessarily
have
to
do
with
these
IDs
like
it
could
be
anything
in
court
and
because
that
hook
has
been
around
since
the
beginning
of
Drupal
7.
A
A
A
Unfortunately,
the
way
that
we're
all
ideas
worked
is
that
if
it
was
a
number
in
Drupal
7,
it's
also
a
number
in
backdrop.
It's
just
a
string
number
instead
of
an
integer
number
and
it's
not
an
auto
increment
anymore.
So
in
PHP,
that's
kind
of
hard
to
test
for
because
it
is
messy
if
we
had
actually
changed
the
name
to
like
roll,
our
ID
or
whatever,
then
that
we
made
maybe
could
have
done
that,
but
and
someone
could
also
create
a
roll
whose
name
is
like
12.
A
And
what
data
you
don't.
The
only
part
that's
required
necessary
for
core
is
checking
to
see
if,
like
the
schema,
is
the
way
you
want
it
before
you
change
it,
which
is
what
we
already
do
with
like
the
hook
update
last
removed,
which
would
check
to
see
if
your
blue
updates
had
been
run.
If
we're
done
doing
other
things
after
that,
just
preventing
errors,
but
there's
a
lot
more.
We
can
do
that
would
help
the
user
right
where
it's
like.
A
Oh,
if
you
did
things
the
wrong
way,
we
can
test
for
that
and
depending
on
what
the
module
is,
what
you're
testing
for
will
probably
be
different
to
none
of
the
ones
that
I
did
were
around
rural
IDs
that
were
all
around
vocabulary
IDs,
but
there
was
a
lot
of
that
where
it's
like
Drupal,
also
introduced
a
vocabulary
name
halfway
through
the
soundex
cycle,
so
there's
kind
of
a
lot
of
testing.
You
have
to
do
around
vocabulary,
IDs
to
just
from
that
so
yeah.
A
B
A
In
one
seven,
three,
no
one,
seven
two
we
accidentally
broke
drop
buttons
in
some
locations
and
in
back
drop
1.8
we
put
in
a
fix
that
should
have
fixed
them,
I'm,
not
sure.
If
one
and
one
seven
three
I
think
half
of
it
went
into
one
seven
three
to
fix
the
brokenness,
but
then
we
put
in
something
I
mean
we
haven't
put
it
in
yet
I,
don't
know,
but
they're
not
broken
right
now,
in
one
seven,
three
or
in
one
eight
I
think
there
is
under
some
circumstances,
on
the
views
UI
on
very
small
screens.
A
The
buttons
will
look
like
overlap,
the
heading
of
the
view
section,
and
we
have
two
recommended
fixes
for
that
in
a
pull
request.
One
of
them
is
just
making
views
instead
of
three
columns
making
it
two
columns
would
solve
the
problem,
so
changing
the
way
that
page
responds,
and
then
there
was
another
one
that
involves
refactoring
the
code
a
little
bit
so
that,
rather
than
being
position:absolute,
the
drop
button
was
floated
right
so
that
when
it
bumped
into
the
thing
it
would
stack
so
I
don't
think
either
of
those
solutions
have
been
committed.
A
All
right:
well,
if
you
guys
don't
have
anything
else,
I
think
we
should
rock
this
meeting
and
return
to
our
regularly
scheduled
to
issue
Q
deep
dive,
and
we
can
check
in
again
next
week.
I
think
we
should
review
with
everyone
again
next
week
the
plan
for
doing
media
for
one
nine
and
maybe
a
focus
on
translation,
whether
it
is
in
core
itself
or
getting
translations
server
ready,
so
that
people
who
need
multilingual
sites
have
an
easier
time
with
that.