►
From YouTube: Backdrop Weekly - Feb 14
Description
Today’s development agenda: http://bit.ly/2UNjA3e
A
All
right
we
are
on
air,
it
is
Thursday
February
14th,
and
this
is
meaning
to
check
in
on
active
development
tasks
for
backup
CMS
getting
started
with
new
projects.
This
week
we
have
the
translation,
template
extractor,
which
I
think
is
related
to
all
Olaf's
work
on
the
localization
server,
which
is
great
and
use
your
import,
which
I
think
is
something
we'll
Aaron
ported
in
the
last
week.
So,
thanks
to
everybody
who
worked
on
those
modules,
I'm
happy
just
been
coming
along
website
related
development
tasks,
backdrops
EMS
network.
A
We
discussed
at
length
in
the
design
meeting.
So
if
you
want
to
watch
that
meaning
you
can
see
updates
there.
In
short,
the
changes
I've
made
per
module
things
and
layouts
how
to
bug.
Last
week,
so
Nate's
been
working
on
helping
me
fix
the
search
thing
which
I
will
try
and
test
today,
and
hopefully
we'll
get
those
done
soon
and
the
home
page
demo
button
is
also
having
some
issues,
but
we
hope
to
get
that
done
soon
as
well.
A
Translations
sites
Olaf,
has
been
amazing.
For
the
past
few
weeks,
he's
been
creating
all
of
the
translation
strings
for
the
various
versions
of
backdrop,
recent
versions,
backdrop
which
I
think
is
great
and
I-
know,
there's
a
ticket
assigned
to
me
right
now
to
set
the
order
of
versions
which
I
will
take
a
look
at,
but
yeah
I
just
wanted
just
a
quick
shout
out
to
him
for
all
the
amazing
work
on
getting
the
translations
are
up
and
running.
A
B
B
B
All
projects
could
not
be
downloaded
occasionally,
depending
on
which
AWS
slash
github
server
you're
getting
connected
to
when
when
using
update,
module
or
the
installer
module-
and
we
fix
that
problem
in
3488,
so
both
of
those
two
things
taken
together
really
drastically
improved
the
reliability
of
being
able
to
install
projects
through
the
UI
and
also
apply
module
updates
the
view
I/o
and
court
dates.
So
those
are
all
very
important
fixes
that
was
glad
to
see
released
him
in
112.
B
Let's
see,
we
also
fixed
a
regression
related
to
using
grids
in
views
that
was
switched
to
using
CSS
grid
on
new
views,
but
legacy
views
should
have
continued
using
the
table
format
for
backwards
compatibility,
but
that
accident
only
was
broken
and
so
3494
corrects
that
problem,
so
that
existing
views
that
we're
using
the
table
based
one
will
continue
to
use
the
table
based
ones
after
they
update
also
RTL
issues.
We've
been
totally,
as
general
say,
on
fire.
B
Our
RTL
issues
that
we've
had
an
excellent
contributor
come
in
putting
backdrop
into
Arabic
on
his
site
and
I
piled
a
whole
bunch
of
issues
related
to
Arabic
displaying
oddly
on
various
pages,
and
so
we
fixed
all
five
of
the
ones
that
hit
filed
previously,
and
there
was
actually
some
in
112
one
as
well.
All
five
of
those
have
been
corrected,
but
then
you
found
another
one
right
after
we
made
it
release,
so
you
just
yeah.
We
have
to
keep
on
top
of
these
things.
I
also.
C
B
Excellent,
so
yeah,
all
of
those,
the
ones
that
we
know
about
are
the
ones
that
we
had
pull
requests
for.
We
merged
all
of
those
in
and
they're
in
112
there's
a
few
new
ones
that
you
can
find
if
you
search
for
RTL
and
github,
and
one
in
particular
that
is
very
broken,
is
the
screen
for
managing
what
buttons
are
placed
in
seek
editors,
toolbar
is
really
horribly
broken
and
that
is
on
in
34,
I'm,
sorry,
3504.
B
B
B
B
This
issue
regarding
security
releases.
Sometimes
we
have
situations
where
a
security
release
is
put
up
for
two
versions
of
backdrop:
the
previous
version
and
the
current
version,
but
if
you're
using
the
previous
version,
that
would
be
1.11
right
now,
even
if
there's
a
security
fix
that
fixes,
the
problem
in
1.11
is
totally
secure.
The
update
module
still
pesters
you
saying,
you're
insecure.
B
You
need
to
update
to
112,
which
is
not
actually
true,
so
the
issue
that
we
have
here
is
we
would
like
to
make
it
so
that
backdrop
to
better
support
having
previous
versions
that
are
fully
patched
versions
that
are
considered
secure,
even
though
they're
not
the
latest
feature
version
of
backdrop,
so
that
issue
is
3524
where
we're
having
some
discussions
about
making
it's
an
update.
Module
is
smarter,
but
we'll
also
need
to
provide
more
information
in
the
update
feeds.
From
backdrop.
B
Been
discussing
in
the
PMC
q
how
long
backwards
we
should
officially
support
security
releases
by
convention.
Right
now,
we've
been
always
patching
the
current
release
and
the
previous
release
we're
considering
maybe
making
it
go
to
releases
backwards,
so
that
would
be
one
full
year
of
coverage,
but
we
have
not
actually
reached
conclusion
on
that
at
that
point.
Yet
so,
let's
see
how
long
back
is
under
discussion,
but
having
support
for
running
an
older
version
that
is
fully
patched
is
what
this
issue
is
about,
which
we
need
to
support
pretty
much
in
any
any
case.
B
Let's
see,
we
also
have
an
issue.
If
you
had
options
element
installed
in
1.11
or
earlier
in
the
update
to
112,
we
have
some
conflicting
function,
names
that
currently
cause
fatals.
There's
a
workaround.
You
can
just
delete
the
options,
element,
module
out
of
your
codebase
and
then
proceed.
You
run
update
PHP
and
everything
is
fine,
but
we'd
like
to
make
it
so
that's
you
know
you
don't
run
into
fatal
errors.
It
seems
like
that
would
be.
That
would
be
preferable.
B
Let's
see
a
long-standing
issue,
if
you
clone
a
layout,
it
breaks
the
new
layout
that
was
created
and
it
breaks
the
layout
that
you
started
from.
Apparently
that's
issue
2673,
there's
a
pull
request
file
there,
but
it
needs
to
test
to
cover
the
use
case.
A
similar
thing.
We
have
a
pull
request
for
this
issue
that
if
you
create
a
node
upload
a
file
to
it
and
then
delete
the
file
out
from
under
backdrop
that
may
cause
a
PDO
an
exception.
B
A
Have
a
question
about
our
test
process
in
general,
I
mean
this
issue
about
layouts
being
broken
has
been
broken
for,
like
more
than
he
more
than
two
three
years.
Just
like
that,
it's
like
kind
of
a
serious
bug
I,
was
wondering
if
we
could
adopt
a
process
of
like
if
we
have
a
super
serious
bug
and
it
has
a
fix,
put
the
fix
in
and
then
put
the
test
in
later,
rather
than
like,
say.
A
Well,
sorry,
the
software
is
broken,
so
we
don't
have
tests,
even
though
we
have
like
a
working
fix
sitting
around
for
it
is
that
and
I
know
that,
like
as
a
core
developer,
you're
like
oh
I,
want
everything
to
be
tested,
so
we're
not
sure
where
broking
breaking
it
in
the
future,
which
makes
sense
but
I
feel
like
because
our
philosophy
is
like
we
don't
really
care
about
core
developers.
We
care
about
the
people
who
are
dealing
with
the
problem.
A
B
Yeah
I
I
think
we
might
be
able
to
make
some
exceptions
if
there
were
situations
that
were
difficult
to
test
I.
Don't
think
this
actually
qualifies
is
something
that's
difficult
to
test.
There's
dozens
of
tests
already
they
cover
layout
functionality
and
same
with
file
functionality
and
I.
Think
that
I
mean
saying
that
this
is
for
the
benefit
of
core
developers.
It's
not
really
for
our
benefit,
it's
to
make
it
so
that
we
don't
accidentally
break
people's
sites
in
the
future
by
making
a
change
like
it's
for
already
broken.
A
A
Only
like
super
serious
issues
right,
like
like
I,
think
we
should
have
some
kind
of
qualifier.
It's
like
how
broken
is
the
thing.
Do
we
need
to
like
one
and
you
as
part
of
Albert,
would
get
to
make
that
call
on
like
reviewing
issues.
You
were
hurt,
or
you
know,
Jeff
or
whoever,
but
I
think
that
it
would
be
good
to
not
have
this
be
our
standard
procedures
like
everything
needs
a
test.
A
I
think
it
would
be
something
like
okay,
this
is
pretty
serious
and
I
think
we
can
we
be
if
we
can
also
have
some
process.
That
would
be
like,
if
there's
an
issue
that
got
in
because
it
was
serious
and
it
needed
a
fix.
Like
the
follow-up
issue
for
the
grantee,
the
test
remains
in
the
like
next
milestone
indefinitely
until
it
gets
added.
So
it's
something
we
did
talking
about
just
that
I
think
like.
A
Maybe
this
isn't
the
best
issue
to
like
bring
this
up
one,
because
it's
kind
of
a
gray
areas,
whether
it's
like
that
serious
above
but
I,
think
just
the
discussion
around
like
how
we
handle
tests.
We
might
need
a
separate
scenario
for
what
happens
we
have
something
is
broken
and
been
broken
for
a
long
time
when
we
have
fix-
and
we
just
don't
have
a
test
for
it.
What
what
is
our,
what
is
our
take
on
that,
and
is
it
going
to
be
different
for
them
circles.
B
Right
well,
if
we
can
come
up
with
some
criteria,
I
mean
making
criteria.
Itself
is
even
kind
of
difficult,
because
it's
kind
of
subjective
as
to
like
how
bad
the
problem
is
or
how
hard
the
test
is
to
write
and
so
I
mean
thus
far.
We
have
basically
been
doing
that
that
it's
it's
kind
of
discretionary
like
does
this
new
tests
or
not
I.
B
Remember
like
most
recent
example
was
the
downloading
a
module
from
github
/
AWS
was
a
problem
with
backdrop,
HTTP
requests
and
there
wasn't
any
reasonable
way
to
test
that
functionality
and
the
break
was
pretty
bad
and
so
I
posted
in
that
issue.
I,
don't
think,
there's
any
reasonable
way
to
test
this.
You
know
sorry
I'd
like
to
include
it
and
that's
what
we
did
and
both
of
these
have
taken
the
opposite
stand
saying:
test
coverage
is
fairly
trivial.
We
need
tests
on
these,
so
I.
Don't
think.
B
A
A
bug
is
worse
than
not
having
a
test
like
this
bug
is
worse
than
not
having
test
for
it.
So
we're
saying
we're
gonna
limit
the
software
because
we
don't
like
it
just
seems
like
the
wait
there
of
like
what's
important
is
silly
like
I
agree
to
like
in
general,
we
should
always
have
tests
for
everything,
but
like
yeah,.
B
A
So
I
think
a
better
fix
where
this
would
probably
be
remove
the
clone
button.
If
clone
button
breaks
your
site
like
that,
we
should
do
that
first
and
then
later
we
can
add
the
clone
functionality.
If
it's
not
gonna
break
your
site,
but
I
think
like
leaving
a
broken
feature
and
that
we
know
is
broken
that
we
haven't
fixed
for
is
silly
yeah.
A
B
A
Agree
with
your
like
there's
no
way
to
test
this,
then
obviously
we
shouldn't
block
that
on
an
issue
but
I
also
think
like
like,
if
it's
much
less
likely,
that
a
test
don't
ever
get
written
if
it's
hard
and
we
put
the
thing
in
without
the
test.
But
if
the
test
is
easy
and
if
the
thing
without
the
test,
that
makes
it
more
likely
the
test
we
got
written
right.
B
Okay,
less
likely
yeah
and
both
of
the
current
cases
like
layout
tests
are
hard,
but
there's
lots
of
examples
to
work
from
the
field
test
or
the
file
upload
test
is
actually
both
has
working
examples
and
isn't
very
difficult
to
test.
So
I
think
I
think
both
of
these
could
be
done
if
we
put
in
the
legwork.
Basically.
A
On
that
everything
that's
covered,
I
think
that's
fine,
I
mean
I,
think
maybe
it
would
be
good
to
create
a
PMC
issue
around
like
I
own.
Maybe
it's
not
necessary.
Maybe
just
like
leave
every
issue
up
to
core
developers,
but
I
don't
know
we
should
have
some
some
way
of
like
bringing
them
to
your
attention
to
be
like
hey.
This
is
a
major
issue.
A
B
Speaking
of
labels
and
the
way
that
we
use
them
and
just
our
general
process,
so
we
have
this
new
label
that
we
added
for
milestone
candidate,
anything
that
we
adds
it's
like
discretion
about,
needs
tests
or
not
like
having
that
label
like
we
should
document
the
process
for
actually
really
an
issue
and
getting
it
resolved.
You
know
like
what
all
of
that
goes
through.
Do
we
have
something
like
that
already,
maybe
I'm
just
missing
it
like
about
what.
B
Yeah
actually,
like
I,
mean
maybe
there's
just
an
assumption
here
that
we're
using
github,
and
so
how
do
you
get
something
fixed
at
backdrop
is
well,
let's
get
hub,
it's
the
same
as
most
other
things
on
github,
you
file
an
issue
and
you
file
a
pull
request
and
we
review
it
and
if
we
like
it,
we
merge
it
right.
But
you
know
our
process
isn't
quite
that
straightforward.
There's
all
of
these
requirements
for
certain
things
that
should
be
documented
around
like
well.
B
First
of
all,
the
fact
we
have
a
separate
issue
queue
from
mark
from
our
pull
request
and
that
there
should
be
an
issue
for
every
pull
request,
type
thing.
You
know
every
now
and
then
we
do
get
the
random
person
that
files
a
pull
request
within
an
issue.
For
example
like
is
there
documentation,
saying
that's
not
how
we
do
things
yeah.
B
Anyway,
the
policy
of
requiring
tests
or
if
tests
are
required
being
at
the
discretion
of
core
maintainer
Ziff
that
becomes
our
policy
just
a
place
where
we
should
put
that
even
before
we
make
the
final
decision
like
we
should
have
a
place
to
you
know.
Dump
this
information
I
was
worried
about
that
with
milestone.
Candidate
still
seems
to
be
an
issue
that
we've
kind
of
adopted
a
policy-
that's
not
written
down
anywhere.
A
A
And
it
includes
every
core
issue:
has
every
pork
or
SS
have
an
issue,
but
that
I
think
might
be
the
only
place?
That's
written
I
think
we.
It
might
be
good
to
have
a
designated
issue
queue
page
for
shooter
page
the
talks
about
of
tags
and
the
process
for
like
when
you
have
a
poor
request
at
these
labels.
Someone
will
review
it
if
it
needs
work.
It'll
get
the
labels
changed
back.
If
it's
approved,
it'll
get
marked
RTP
see
then
it'll
get
a
core
committee
review
and
then
yeah
not
sure
not
yeah
yeah.
B
All
of
that
everything
that
you
just
described
is
not
obvious.
Like
normal
github,
behavior
yeah,
it's
ripple
behavior
and
it's
actually
normal,
like
you
know,
issue
tracker,
behavior,
JIRA
and
what-have-you,
but
so
I.
Don't
think
people
would
be
surprised
by
that,
but
still
it'd
be
helpful
to
walk
through
the
entire
process.
Yeah
yeah.
B
A
Anything
I
want
exclusive
in
this
developer
notes
section
on
backups,
you
must
org,
where
we
have
they're
like
submitting
a
Corp
or
West
saying
I,
think
that
might
be
a
good
place
for
how
to
use
the
issue
queue.
B
A
B
A
B
Yeah,
even
just
making
an
issue,
maybe
I
mean
how
to
use
the
issue.
Queue
might
be
fine
or
if
you
wanted,
because
all
of
these
are
the
ones
are
kind
of
action
driven
operating,
moving
submitting
we
to
do
submitting
port
issues,
you
know
and
then
just
have
them
be
separate
things
you
know,
and
so
instead
of
this
submitting
court,
pull
request,
saying
having
this
little
note
at
the
top.
B
B
B
This
one
in
particular,
is
related
to
the
admin
toolbar.
That's
sometimes
it
just
covers
up
the
contextual
link
cogwheel,
and
so
it's
in
discussion
there
as
to
how
we
can
correct
that
I.
Don't
think
that
we've
reached
kind
of
a
conclusion
really,
if
even
what
the
problem
space
is
other
than
we
can't
get
to
the
contextual
link.
So
that
issue
is
in
discussion
with
various
ideas
being
tossed
about
trying
to
figure
out
how
we
can
correct
that.
B
Ok,
let's
move
on
to
113
113
is
the
next
release
of
backdrop.
Next
minor
release
of
backdrop
that
includes
new
features.
It
will
be
coming
up,
May,
15th,
2019,
thus
far,
I,
don't
think
113
actually
contains
much
of
any
changes
from
112
yet,
but
we
have
some
some
issues
that
we'd
like
to
push
forward
during
this
release
that
we
can
go
over
this
one,
this
one
we've
added
back
onto
the
agenda
telemetry.
B
Do
80
fold
yeah
how
about
that
so
issued
the
idea
here
is.
We
would
like
to
start
collecting
anonymous
information
about
the
configuration
of
people's
back
drop
sites
and
then
aggregating
them
on
factor
of
CMS
org,
the
most
obvious
one
that
everybody
that
we
would
like
to
collect
to
something
like
which
version
of
PHP
are
you
running?
That
would
be
really
useful
to
help
inform
decisions
about
how
far
backwards
we
need
to
support
versions
of
PHP,
for
example.
So.
B
Right
now,
telemetry
like
sending
information
to
backtrack,
CMS
tar,
the
work
is
tied
to
updates.
So
when
you
check
for
updates,
you
send
to
back
top
CMS
org
information
about
what
modules
you're
running
and
then
factor
up
CMS
org
aggregates
that
information
that
makes
that
publicly
available
and
right
now
sending
information
to
bankruptcy
and
I
start
org
about
what
versions
of
modules
you're
running
and
getting
a
list
of
modules
like
getting
the
updates.
C
Most
of
the
discussion
was
around,
as
you
said,
the
the
beat
of
the
Installer
module,
where
it
asks
for
consent
to
check
for
updates.
And,
yes,
as
you
said,
we
shouldn't
when
people
opt
out
of
taking,
they
might
opt
out
of
taking
for
dates
because
of
the
fact
that
they
don't
want
to
send
data.
So
we
should
just
allow
them
to
decide
with
the
one
of
the
other
independently
and
then
other
things
that
could
we
could
gather
data
for
is
like
certain
settings
for
modules,
weeks
modules
in
core
are
enabled
or
not.
C
B
Yeah
I
think
I
mentioned
this
in
the
issue
as
well,
that
the
check
for
updates
checkbox,
like
once
we
separate
out
like
send
anonymous
information
to
backdrop
CMS
org,
if
we
separate
those
two
checking
through
updates
good
question,
it's
just
always
beyond,
because
that's
just
ridiculous.
Of
course
you
want
to
check
for
updates.
Maybe
you
just
want
to
do
it
anonymously.
B
So
yeah,
that's
that's
great,
so
the
question
is:
where
do
we
start
implementation
here?
It
is
going
to
require
you
know
some
place
to
send
the
data
back
top
CMS
org
as
well
as
you
know,
building
the
place
that
actually
pulled
and
collects
all
the
information
and
then
sends
it
and
so
I
think
the
most
natural
thing
for
this
would
be,
of
course,
a
separate
module.
B
Yeah
we
could
even
I
mean
you.
We
could
even
write
the
entire
thing,
the
entire
module
without
it
actually
sending
data
anywhere
like
we
could
go
ahead
and
start
the
entire
process
of
saying
you
know:
here's
the
module,
here's
it
collecting
all
the
data,
here's
the
checkbox
on
the
installer
page.
We
could
do
all
of
those
things
and
just
where
it
actually
sends
the
data
we
could
then
just
have
that
be
a
mock
for
now,
just
like
it
wouldn't
actually
send
it.
B
It
might
like
print
to
the
messages
area
and
say
I
sent
this
I
here
is
where
it
will
send
this
message.
You
know
rejection.
Maybe
the
message
is
there:
isn't
the
right
place
like
watchdog
might
be
better
because
it'll
probably
be
done
on
cron
chops,
for
example,
yep,
so
yeah
I,
don't
think,
there's
any
reason
for
us
to
delay
the
part
that
is
most
accessible
to
developers,
which
is
writing
the
module
code.
B
Once
we
have
an
idea
of
the
kind
of
data
we
need
to
send,
then
we
can
build
the
receiving
end
on
factor
of
CMS
org
and
again,
like
that
receiving
end
can
also
be
built
just
entirely
separately
as
another
module,
and
then
the
actual
deployment
process
would
be
well
now
we
have
to
put
that
module
in
backups.
In
that
start,
org.
C
B
Yeah
for
sure
and
and
the
receiving
end
is
a
little
bit
more
nebulous
kind
of
like
the
update
feed
is
in
the
update
feed
provided
by
project
module
on
backdrop.
Cms
org
is
a
module,
but
it's
got
a
lot
of
special
situations
going
on
there
like
it
has
a
funny
cache
layer
on
it
and
it
has
a
separate
domain
update,
stop
backdrop
CMS
dot
org.
That
is
then,
does
some
fancy
stuff
to
make
it
so
that
we
could
potentially
separate
that
out
at
some
point.
B
But
for
now
it's
all
just
from
backdrop:
CMS
org,
so
the
receiving
end
could
get
OH
complicated
because
we
want
to
make
it
so
that
that
receiving
end
could
be
switched
out
for
something
else
at
some
point
in
the
future.
Without
updating
the
every
version.
Every
backdrop
install
that's
out
there,
so
it'll
end
up
looking
something
similar
to
update
module.
That's
I
think.
C
We're
talking
about
it
I
thought
that
maybe
this
could
not
even
be
part
of
the
Installer,
see
how
we
have
this
issue
about
making
the
two-minute
Installer
or
the
very
simplified
one.
One
thing
would
be
that
the
checkbox
can
go
away
because
automatically
checking
for
updates
would
be
happening.
Anyways
because
that's
a
monomers
and
what
we
can
do
is
we
can
have
a
one
time
message
showing
up
saying
this
is
how
much
so?
Where
does
it
a
can
you
do
you
feel
like
helping
us
collect
data,
and
that
would
be
a
one-off
decide?
C
B
C
B
B
B
B
B
If
we
were
to
not
collect
that
information
from
a
public
perception
standpoint
like
we
wouldn't
have
any
way
of
knowing
how
many
backup
sites
there
are
or
we
we'd
have
a
lot
lower
numbers
than
we
would
otherwise,
because
it
wouldn't
be
nothing,
it
would
be
tracked
by
default.
Yeah
yeah
wait,
which
I
saying
all
of
that
I
am
realizing,
I,
think
you're
right
that
you're
from
an
ethical
standpoint.
B
We
shouldn't
be
counting
anybody
by
default,
but
I,
but
I
think
we
could
compromise
on
that
and
have
it
be
like
show
the
option
for
if
we,
if
we
leave
it
in
the
Installer
as
it
is
like
I,
don't
have
any
ethical
problem
so
that,
like
it's
already
or
I,
don't
think
there
are
any
ethical
problems
with
that.
It's
already
there.
It's
not
turned
on.
B
B
So
one
way
or
the
other
on
that,
though
yep,
whichever
way,
is
easiest
to
implement
yeah
speaking
of
things
that
could
be
done
directly
as
Corp
or
request
or
not.
Let's
transition
to
the
next
issue,
which
is
dashboard,
dashboard,
is
issued
for
95,
and
this
one
has
a
pull
request
that
adds
a
dashboard,
a
new
dashboard
module
to
backdrop
cord.
A
Sorry
so,
let's
see
where
we
are
a
dashboard
is
that
we
have
a
working
version,
but
it
probably
needs
some
cleanup
for
a
core
inclusion,
but
since
it
didn't
make
112
Dhokla,
it's
sort
of
reimagining
the
whole
problem
space
and
he
said
he
wants
to
come
up
with
some
more
blocks
that
are
a
little
bit
more
informational
rather
than
utility
focused.
So
like
more
statistics
and
less
here
are
all
the
links
you
need
to
do
stuff.
A
I
think
those
blocks
will
be
great,
but
I
did
add
some
feedback
in
the
issue
that
the
module
DS
were.
The
dashboard
was
adapted
from
was
one
I
wrote
for
Drupal
6
in
triple
7
called
total
control,
and
the
block
that
he
thought
was
most
redundant
was
actually
the
most
used
block
in
the
Drupal
6
in
Drupal
7
versions,
so
it
might
be
good
to
before
we
decide.
You
know
what
the
default
layout
is
just
take
a
look
at
all
the
blocks
that
are
provided
and
see.
A
Do
we
need
all
of
them
turned
on
by
default,
or
should
we
just
provide
them
there
as
options
for
people
to
use?
So
it
would
be
great
if
we
could
get
more
people
just
giving
it
a
test
and
seeing,
if
all
of
the
things
they
expect
to
be
there
on
a
dashboard
or
there
or
is
there
anything
major
missing
and
for
the
stuff
that
is
there?
C
Having
said
all
that,
there
was
a
consensus,
I
think
on
that,
or
on
that
we,
if
it's
ready
as
a
module,
we
should
include
it
with
113
and
additional
blocks
or
changes
to
the
existing
blocks
and
what
these
default
or
not
can
come
up
at
play.
Their
versions,
yeah,
has
mean
I,
think
it's
an
exciting
feature
to
have
it's
much
better
than
then
we
directing
people
to
the
user,
edit
page
the
profile
and
it
fades
when
they
login
everything.
A
B
Right,
let's
see
other
issues,
these
are
things
that
have
been
in
progress.
The
last
two
things
have
been
in
progress
for
a
little
while
yet
kind
of
continuing
to
iterate
on
functionality.
It's
already
in
court
and
111
I'm.
Sorry
in
112
we
added
core
functionality
for
config
translation,
but
it's
not
applied
to
all
of
the
core
files
yet
and
so
issue.
B
34
55
is
starting
to
apply
the
pattern
of
using
the
new
api's
and
adding
information
about
what
strengths
are
translatable
into
config
files,
and
so
there's
poor
request
there
that
needs
review
that
adds
site
settings,
including
site
name
and
the
anonymous
the
label
for
anonymous
users.
I've
started
doing
a
code
review
on
that.
The
more
eyeballs
would
be
helpful
there.
Herb
module
is
the
one
who
carried
the
configuration,
translation
torch
to
the
finish
line
for
112,
and
so
now
he's
going
through
the
core
files
and
using
this
new.
B
Once
this
pull
request
gets
to
a
workable
state
and
is
merged,
it
will
kind
of
establish
the
pattern
that
that
needs
to
be
applied
throughout
the
rest
of
core
I.
Don't
think
that
these
are
going
to
be
very
technically
challenging
thanks
for
people
to
implement,
they
just
need
a
template
from
which
they
can
base
this
pattern,
then
we'll
just
apply
it
everywhere
throughout
call
of
core
and
eventually
would
encourage
that
to
be
applied
throughout
trip
as
well.
B
It's
possible
that,
once
these
patterns
are
established,
that
we
can
also
do
things
like
add
some
new
rules
to
like
the
code
or
upgrade
module
to
help
people
upgrade
from
Drupal
7.
To
backdrop
to
make
it
so
that
if
you're
wrapping
T
around
a
variable,
we
would
say
hey,
you
might
want
to
check
out
config
translation
instead,
because
using
config
translation
makes
it
so
that
we
can
extract
those
strings
with
the
Pio
TX
module.
B
B
That's
what
that
issue
is
about
further
thought
on.
That
would
be
helpful.
There's
also
the
113
issue
tracker
check
out
the
113
milestone.
There's
lots
of
issues
in
there
that
we've
got
slated
for
113,
some
big,
some
small,
but
that's
those
four
items
are
all
that
we've
got
slated
for
the
agenda,
so
that's
all
I've
got
so
general
discussion.
Jen
are
these
items
that
we
have
in
the
agenda
up
for
discussion.
A
C
C
So
basically
the
proposal
there
is
to
create
a
new
form,
API
type
of
permissions,
which
would
allow
allow
people
to
just
enter
a
an
array
of
permissions.
And
then
what
that
does
is
renders
an
array
of
users,
sorry
a
table
of
users
and
permissions
and
region,
and
you
can
embed
that
in
any
form.
So
we
started
adding
such
forms
almost
everywhere
that
they
are
needed,
like
the
contact,
module
and.
A
A
good
filter,
module
node,
there's
a
bunch
of
stuff
that
has
them
now
and
when
we
did
contact
module
up,
we
pointed
out
that
the
we
were
really
pulling
in
CSS
and
start
from
node
modulus
implementation.
But
Gregory
was
saying
he
would
be
great
if
we
can
make
this
a
standalone
form,
API
element
that
you
could
just
implement
in
your
module
and
it
would
automatically
attach
all
the
assets
that
we're
necessary
and
whoever
appropriately
for
the
site
that
you
are
on,
so
we're
not
doing
we're
doing
it
from
scratch.
A
Every
time,
if
we
have
more
components
like
this,
that
are
more
developer-friendly
for
implementing
their
own
modules,
we're
gonna
end
up
with
a
much
better
contribs
face
because
I
feel
like.
Oh,
you
can
just
add
conditions
like
calling
this
function
and
giving
it
the
dimensions
to
the
module,
which
I
think
is
a
fantastic
idea.
I
think
we
talked
about
it
in
the
design
meeting
too
I,
don't
know
Nate
how
hard
adding
a
new
form
API
when
they
called
form
out
of
element.
C
B
Yeah
yeah,
making
this
simpler
would
definitely
be
good
and
I'm.
Looking
at
one
of
the
examples
where
we
added
it
to
contact
module,
yeah,
which
actually
isn't
a
tremendous
amount
of
code,
like
I
mean
it's
harder
than
it
should
be
probably
or
harder
than
it
could
be.
But
what
really
makes
me
uncomfortable
here
is
that
there
is
odd
leakage
into
like
user
modules.
B
Like
JavaScript
and
user
modules
theme
functions
like
it's
like
it's
a
it's
coupled
in
a
way
that
is
likely
to
break
because
it's
it
is
making
it
so
that
every
place
that
we
need.
This
permissions
forum
is
doing
a
lot
of
the
same
work
that
it
has
the
exact
same
assumptions
built
into
it.
So
if
we
were
ever
do
something
to
modify
like
a
JavaScript
file,
we'd
have
to
change
it
in
like
six
places
which
I
don't
like
plus
any
control
would
just
be
busted
if
they
tried
to
do
this
same
thing.
B
Hesitant
about
elements
is
that
this
is
not
a
generic
like
form
element,
you
know
it's
not
like
what
form
API
is
made
for
in
terms
of
like
you
know,
oh
I
want
a
better
file
field
upload
or
I
want
a
like
options.
Element
is
a
good
example
where
that
sort
of
thing
is
a
reusable
thing
for
inputting
data.
A
B
Right
yeah,
which
is
its
kind
of
similar
like
a
way
to
pull
requests
recently,
that
Joseph
filed
for
a
color
module
that,
when
a
theme
wants
to
provide
color
fields
like
there's
a
function
that
says
like
add
the
color
fields
to
my
form
and
then
you
get
to
assign
where
in
the
form
it
lives.
And
so
that's
like
a
compromise
that
it
has
the
code
reuse
of
having
all
be
centrally
managed
by
one
place
without
making
it
be
a
form.
Api
element
that
is
accessible
anywhere
I'm.
B
B
Yeah
yeah,
and
so
the
permissions
form
API
element
would
be
not
useful
outside
of
backdrop.
You
would
never
put
it
on
the
front
end
of
your
website,
for
example,
but
other
form
API
elements
you
might
use
them
for
other
purposes
like
you
know,
searching
and
for
filling
out
registration
forms
and
things
like
that.
Yeah.
C
A
C
A
A
On
the
right,
there's
already
I,
just
don't
know
what
it
is.
Is
it
like
like
inform
API
is
there
way
you
can
add
like
a
a
special
render
or
something
for
an
individual
elements
like
you
had
a
markup
element
or
something
there's
some
way
you
could
have
it
built
form
elements
inside
like
I
feel
like
there's
something
there.
That
would
do
this
that
you
could
still
add,
like
the
pound,
attach
to
get
your
assets
and
the
pound
validate
and
like
special,
submit
handling
or
whatever
you
need.
A
A
So
I
think
maybe
there's
some
helper
functions.
Gregg
or
you
could
do
this
too,
where
like,
if
you
have
a
helper
function,
that
you
can
pass
in
all
of
your
strings
for
user
roles
or
permissions,
whatever
they're
the
helper
function
could
build
all
this
stuff
around
it.
A
And
then
you
could
have
a
second
helper
function
that
matches
that
handles
the
saving
of
these
permissions,
where
you
could
patch
it
pass
in
the
entire
form,
values,
array
and
the
names
of
the
permissions
or
yeah
the
permissions,
and
then
it
would
loop
through
them
to
locate
them
and
whatever
structure,
matched
the
builder
structure
and
save
them
appropriately.
So
it's
not
quite
as
clean
as
having
like
a
form
API
element
that
it
would
do
it,
but
I
think
we
can
still
sort
of
provide
the
same
utility
like
developer
assistance
functions.
C
C
A
You
could
enter
your
baladi
wherever
you
needed
it.
You
could
add
another
function.
That
would
be
like
you
know,
back
drop
process,
permissions
matrix
and
it
would
search
through
the
form
tree
for
the
exact
pattern
of
the
thing
that
it
built
earlier,
find
all
the
permissions
and
save
them
all
appropriately
and
then
returned
to
you
at
the
end.
So
I
think
we
can
sort
of
build
the
utility,
but
it's
not
gonna,
be
as
clean.
C
A
C
C
Cool
a
sarah
palin
accident
fighters,
and
then
I
know
that
we
have
exceeded
the
time,
but
when
we
started
a
little
bit
later,
just
just
something
related
to
telemetry.
This
is
sort
of
like
an
idea,
but
I'm
not
sure
how
you
guys
feel
about
it
would
config
config
files
per
user
for
specific
settings
as
as
in
with
check
boxes
where
which
field
sets
are
open
or
closed
or
stuff
like
that
or
how
the
admin
menu
is
configured
with
something.
So
if
you
have
a
lot
of
admins,
maybe
they
prefer
the
admin
menu.
For
example.
C
This
is
a
new
space.
Some
of
them
prefer
they
have
been
better
to
be
sticky,
some
of
them
don't,
but
now
apparently
have
a
system-wide
setting
and
the
single
what
you
call
it
site
admin
that
decides
what
to
set
it
to
then
the
rest
of
the
site.
Users
have
that.
So
was
thinking
that
maybe
we
can
have
some
sort
of
pair
user
settings
that
could
be
stored
in
config.
Mm-Hmm
can
remember
settings
per
user.
D
D
B
B
We
would
generally
consider
it
to
be
content,
something
it
lives
in
the
database
because
it's
not
guaranteed
to
be
the
same
user
across
different
environments.
So
a
config
file
for
like
user
ID.
Ten,
for
example,
wouldn't
be
safe
to
move
across
environments
because
user
ID
ten
might
be
different
on
the
dev
environment
than
it
is
on
the
production
environment.
So
you
can
start
changing
config
for
not
necessarily
the
same
person.
So.
A
B
Think
putting
config
files
for
any
kind
of
content
that
another
config
files
for
any
kind
of
unique
ID
is.
Is
it
very
is
something
that
we
should
pursue
just
because
you
could
have
like
potentially
hundreds
of
thousands
of
users
that
shouldn't
be
managed
through
config
files?
That
should
just
be
a
part
of
their
user
profiles.
B
You
know
like
in
the
database,
so
a
field
there
are
properties,
it's
like
you
know,
on
the
user
profile
form
saying
you
know
administrative
options
or
something
like
that
where
they
check
or
uncheck
something,
and
then
she
just
distorted
the
rest
of
these
or
information
in
the
database.
Probably
so
so
you're
thinking.
E
C
E
B
E
C
A
Use
it
on
the
way
out
like
for
something
like
an
admin
menu
setting,
that's
tough,
because
you'd
have
to
override,
but
where
it's
implemented
right
in
a
menu
somewhere.
When
did
that
then
use
rendering
you'd
have
to
say?
Okay,
you
know
ignore
that
thing
you
just
pulled
from
bacon.
Instead
go
get
it
from
this
users.
Yeah
come
on
all.
B
C
It
could
be,
it
could
be
for
for
the
things
like
the
the
admin
menu
thing
was
sort
of
like
the
first
use
case.
That
came
to
mind,
but
we
have
certain
fields.
It's
in
the
admin
user
interface
that
are
by
default,
collapsed,
but
people
might
frequently
need
to
change
the
things
that
are
within
them,
so
that
you
have
to
could
like
constantly
visit
that
page.
Expand
that
check
the
setting
do
something
submit
the
form,
whereas,
if
the
status
the
collapsed
or
expanded
status
of
specific,
for
example,
field
sets
could
be
remembered
across
across
sessions.
B
Kenny
here:
okay
yeah:
let's,
let's
leave
it
to
this,
you,
okay,
let's
call
it
a
meeting
where
we're
way
over
time.
Yeah.
Thank
you,
everybody
for
you
for
joining.
Thank
you!
Everybody
out
there
for
watching
yeah.
It's
we're
still
moving
along
and
lots
of
things
keep
on
back
dropping.
So
thanks.
Everybody.