►
From YouTube: Backdrop Weekly - October 22nd, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
we're
live
today
is
thursday
october
22nd,
and
this
is
our
weekly
developer
meeting
a
lot
of
cool
stuff
that
happened
since
our
last
meeting
since
last
week
was
bad
camp,
but
before
we
get
to
the
agenda,
let's
start
with
some
introductions
greg.
Can
we
speak
with
you.
B
C
C
D
Hey
I'm
nate
lampton
in
oakland,
california
and
yeah.
We
have
a
bunch
of
new
issues
for
118,
I'm
excited
to
start
going
through
them.
I
haven't
been
paying
attention
to
who's
next,
so.
A
I
am
also
excited
about
all
of
the
activity
in
118
and
joseph.
Would
you
like
to
introduce
yourself.
F
I'll
look
into
the
camera.
My
name
is
kim
erickson,
I'm
coming
to
everyone
from
deerwood
minnesota,
and
I
want
to
update
everybody
on
the
turkey
they're
still
running
back
and
forth
past
my
window
hold
up.
F
There's
a
rafter
of
turkeys,
running
by
my
witness,
excited
about
1.18
and
let's
get
going.
Is
that
everybody.
A
I
think
so,
okay,
all
right,
exciting
news.
Since
our
last
meeting
people
have
been
very
busy
and
can
trip,
we
have
a
handful
of,
I
think,
there's
like
12
new
kinship
projects,
including
web
form,
teleform
web
form,
layout
web
form,
structured
text,
roll
help,
price
parole,
ip
login
shortcut,
ubercart,
mini
cart,
block
views
b,
grid
image,
maximum
crop
and
spam
span.
A
So
thank
you
to
all
of
our
contributors
who
have
been
very
busy
making
modules
for
backdrop
or
themes
or
layouts,
and
I
want
to
turn
over
to
nate
to
talk
about
all
the
great
stuff
happening
in
core.
D
Thanks
again
so
117.2
is
the
next
bug
fix
release
and
we've
got
a
number
of
issues
that
are
moving
along
here:
they're,
not
very
fun
to
go
through,
though
some
of
them
have
been
stuck
in
review
state
for
a
couple
of
weeks,
and
I
will
just
quickly
read
through
the
issues
that
are
in
that
state
and
that
includes
transliteration
doesn't
respect
site
default
language.
That's
issue.
2637
text
update
for
the
administrative
descriptions
for
blocks
issue.
D
Forty
six
hundred
the
site
stuck
in
maintenance
mode,
issued
39.56
setting
a
reasonable
max
input
variables,
setting
issue
38
to
24.
D
yeah.
Those
four
issues
are
all
in
a
state
of
needs
review.
Some
of
them
have
received
updates.
I
saw
like
bw
panda,
updated
the
max
and
put
varus
one,
but
all
of
those
are
just
grinding
on
getting
reviewed
they're
all
in
good
places.
They
all
have
pull
requests
they're
all
pretty
far
along,
but
they're
just
like
having
a
little
bit
trouble
getting
over
the
last
little
bit.
D
That's
kind
of
similar
for
fixing
the
block
title
for
the
search
box
issue,
34
76
that
one's
back
to
needs
work,
but
only
on
terminology
updates.
Oh
and
this
views
or
behavior
fixing
issue
3415
is
also
one
of
those
ones.
That's
stuck
in
the
review
grind,
so
basically
everything
that
we
have
in
the
117.1
list
that
we
normally
bring
up
is
grinding
on
getting
enough
reviews.
D
I'm
sorry
117-2
list.
Thank
you.
So
that's,
I
don't
think
that's
very
exciting
to
cover
them.
I
really
just
need
time
put
into
reviewing
what
is
there.
D
We
also
have
this
discussion.
That's
happening
about
using
tugboat
qa
for
pull,
request,
sandboxes
issue,
43
51.,
it's
kind
of
confusingly
fixed
issue,
because
we
have
a
tugboat
configuration
file
in
the
repository
now,
but
it's
just
not
wired
up
to
anything
and
conceptually.
D
That
means
that
our
tugboat
or
sandboxes
would
be
start
being
created.
Had
we
had
an
account
I
reached
out
to
the
tugboat
team
and
asked
about
if
we
can
start
using
tugboat
for
our
sandboxes,
but
it
looks
like
by
my
calculations
of
how
much
space
each
tugboat
demo
uses
up.
We
would
only
be
able
to
generate
like
around
five
or
six
hundred
demo
sandboxes
before
the
account
filled
up
and
we
currently
have
over
hang
on.
I
was
gonna,
say
2000,
but
that's
how
many
issues
we
have
520
pull
requests
open.
D
However,
that
doesn't
rule
out
the
possibility
of
using
them
still
they
wrote
back
and
said
basically
there's
a
financial
cost
to
setting
up
dedicated
hardware
to
support
project
the
size
of
backdrop
that
would
incur
a
cost
of
about
two
hundred
dollars
per
month.
Their
discussion
that
they
would
like
to
have
with
us
is
it's
like
well.
D
Can
we
offset
that
cost
and
marketing
benefit
from
the
backdrop
community,
and
I
don't
know,
I
think
that
we
need
to
see
what
kind
of
things
that
they
are
looking
for,
that
we
could
provide.
You
know
backdrop
volume
wise
is
you
know,
I'm
not
really
sure
that
would
generate
200
of
advertising
revenue
for
anything
so,
but
but
still
that
the
door
is
still
open
there.
D
We
also
could
potentially
get
a
second
limited
account
that
would
cap
out
at
40
gigabytes,
and
then
we
would
just
have
to
be
like
you
know.
Maybe
a
little
bit
more
judicious
with
our
use
of
pull
request
sandboxes,
I
don't
know.
A
C
A
D
Yeah
well,
it
is
interesting
that
tugboat
tugboat
is
primarily
a
developer
tool,
so
developer,
seeing
tugboat
is
actually
a
beneficial
thing
and
seeing
it
on
github
and
seeing
it
demonstrated
it's
actually
like
a
live
demo
of
the
tool
itself,
so
it's
possible
that
even
just
the
act
of
using
tugboat
gives
them
some
marketing
value
right
away,
but
I
know
for
the
drupal
integration,
which
does
have
dedicated
hardware
and
infrastructure
for
it.
D
I'm
not
sure
if
the
drupal
association
actually
pays
anything
for
that
that
even
in
every
issue,
it
very
specifically
says
tugboat
qa
sandbox,
which
I
think
was
probably
part
of
the
negotiation
that
they
had
there,
that
it
wasn't
just
like
live
sandbox.
It
was
tugboat
sandbox.
You
know
so.
A
D
Correct,
okay,
I
I
think
I
mean
yeah
and
of
course
our
relationship
with
the
people
in
tugboat
is
quite
good
because
they're
all
derivative
from
lobot
and
they
work
there.
So
we
definitely
have
have
a
pretty
good
foot
in
the
door
there
to
start
conversations.
Okay.
The
question
I
have,
though,
is
who
should
we
have
talking
with
tugboat?
I
mean,
obviously
I
I
can
help
with
that,
but
if
we
want
to
have
some
other
representation
from
the
pmc,
I
think
that
would
be
a
good
thing
for
us
to
issue.
A
B
So
the
only
problem
is
time
difference
for
peter
that's,
but
but
if
the
communications
is
asynchronous
like
over
email
that
it
wouldn't
be
a
problem,
I
imagine.
D
Yeah,
we
also
could
yeah.
I
I
don't
know.
I
think
that
we
really
need
the
live
conversation
with
with
them
to
really
move
things
forward.
D
Or
maybe
I
can
set
up
an
invite,
gregory
and
I'll
check
in
the
time
with
you
first
and
then
I
can
kind
of
be
the
point
person,
because
I
can
also
see
their
calendars.
So
I
think
that
that
might
work
yep
okay,
so
you
me
and
the
tugboat
team.
F
A
D
You
know
yeah
not
to
mention
it.
It
actually
works
faster
than
tugboat.
As
far
as
spinning
up
a
sandbox
like
it's
really
impressively
fast
and
he's
also
doing
the
test.
Bot,
like
you,
know,
running
the
tests
on
against
php
and
php7,
and
our
only
problem
with
that
infrastructure
is
that
it
hasn't
been
getting
updated.
You
know
like
we
should
probably
be
running
php
7.4.
You
know
at
this
point
on
the
test
infrastructure
on
the
high
end,
two
on
the
low
end,
it's
five.
A
D
D
D
Yeah,
okay!
Well
anyway,
tugboat
yeah.
We
can
get
that
sorted
out,
but
yes,
you're,
right
jen.
We
should
also
be
communicating
with
core.
F
D
There
is
probably
already
an
open
issue
about
php
versions
as
well
that
we
should
coordinate
a
little
bit
between
the
public
issue
and
anything.
That's
in
the
pmcq
saying
that
something
is
happening
in
the
public
issue.
Okay,
but
I'm
not
actually
sure
what
open
issue
we
have.
D
Something
that
specifically
saying
up
increase
minimum
php
version
2x,
because
we're
going
to
have
more
than
one
of
these
over
time
see
34.90
is
an
issue
that
actually
is
kind
of
helpful
that
the
idea
on
this
one
is
that
it
throws
a
warning
on
the
status
report
if
you're
running
older
versions
of
php,
basically
just
to
nudge
people,
to
upgrade,
which
seems
like
a
good
idea
regardless.
But
this
probably
isn't
the
issue
that
that
we
need
to
like
bump
the
minimum
version
of
php54.
D
Okay,
anyway,
I'm
going
down
a
little
bit
of
tangent
and
we're
spending
a
lot
of
time
talking
about
117,
but
we
have
a
bunch
of
118
issues
that
have
been
fleshed
out.
We
had
this
big
discussion
over
118
issues.
Tim
started
a
great
forum
post
that
generated
some
interest
regarding,
like
what
people
are
interested
in
doing,
and
we
have
a
whole
bunch
of
new
advocates
and
new
issues
that
are
being
covered
now,
as
well
as
some
progress
on
telemetry.
So
we'll
start
going
through
these
mysql8
support
issue
4238.
D
We
got
a
whole
bunch
of
really
great
testing
from
various
community
members.
All
saying
that
it's
working
there
doesn't
seem
to
be
any
performance
impact.
They
also
noted
the
php
or
sorry.
My
sequel
8
is
like
a
lot
faster
than
my
sql
5.6.
So
that's
also
just
really
interesting.
Just
that
there's
a
really
positive
performance
benefit
to
using
the
latest
version
of
the
software.
F
D
I
think
that
they
only
said
I
wonder
if
there
are
performance
implications,
but
then
they
tested
it
and
they
found
that
it
was
quite
positive
rather
than
yeah.
So
so
yeah.
D
But
but
the
current
issue
now
is
that
people
are
struggling
to
apply
the
patch
or
get
the
repository
version
that
that
actually
includes
my
sql
8
support.
So
my
suggestion
at
this
point
is
that
we
should
merge
it
at
least
into
one.x
to
make
it
so
that
people
can
test
it
more
easily
and
then
there's
still
an
open
question
of
like.
Should
we
cherry
pick
it
into
117
as
well?
D
The
people
in
the
issue
are
of
the
opinion,
of
course,
that
that
we
should
put
it
into
117
because
they
don't
want
to
wait,
and
so
far
there
hasn't
been
any
new
issues.
Since
we've
had
a
wider
group
of
people
testing,
nobody
has
found
any
actual
bugs
in
the
implementation.
So
it's
all
looking
really
positive.
A
I
would
also
vote
for
putting
it
into
one.x
and
letting
it
sit
for
a
while
and
deciding
later
if
we
should
move
it
into
117,
like
maybe
we
don't
put
into
the
next
release
a
weight
one
just
so
that
everybody
who's
doing
all
of
their
testing
on
core
for
all
the
other
stuff
for
a
while
gets
their
hands
on
it
and
make
sure
it
works
like
even
if
we're
not
using
it
on
eight
making
sure
there
aren't
any
new
bugs
introduced
in
anything
else.
D
Well
I'll
go
ahead
and
move
that
into
rtbc,
based
on
the
feedback
that
we've
got
and
that'll
at
least
put
it
into
the
list
that
core
committers
frequently
look
at
okay
next
up
web
p
support
webp
is
a
new
image
format
that
is
a
replacement
for
jpegs
issue.
4509
is
the
issue.
Indexella
has
stepped
up
to
be
the
advocate
for
it
with
lauren
having
done
work
on
the
implementation,
it's
looking
really
pretty
good.
D
It
currently
needs
review
could
probably
be
moved
into
needs
work
because
it
doesn't
have
any
test
coverage,
but
there
was
a
question
there
of
like
how
do
we
test
something?
This
goes
back
to
the
test
belt
again
that
only
works
on
php,
7.1
and
higher
when
testbot
still
running
php7,
and
we
don't
need
to
hold
up
this
issue.
D
Let's
see
next
up
upgrade
user
interface,
4345
jen
you're
the
advocate
for
this-
I
don't
know
the
status
of
it.
So
I'm
anxious
to
hear
it.
A
There's
no
work
going
on
in
core,
yet
for
that
issue
I've
been
working
on
a
contrib
module
that
replaces
the
user
interface
that
was
written
for
drupal
8
with
something
that
will
work
for
backdrop.
That
basically
gives
you
a
user
interface
and
says,
connect
your
database
here.
So
it
allows
you
to
do
the
installation
first
and
then
gives
you
a
ui
that'll
do
the
upgrade,
rather
than
assuming
that
you'll
connect
your
backdrop
site
to
a
drupal
777
database
and
run
update.php.
So
it's
a
little
bit
more
helpful.
D
D
D
Yeah,
okay!
Well,
that's
interesting,
yeah,
we'll
see
if
that
actually
even
turns
out
being
practical,
but
awesome.
D
Let's
see
next
up
is
an
exposed
filter
for
the
media
library,
modal
dialogue
issue.
3293.
lauren,
is
the
advocate
for
this.
No
pull
request
yet
looks
like
he's
made
a
request
for
help
tim.
You
posted
this
edition
is
that
right
to
the.
D
F
D
Sure,
okay,
sorry
I
I
just
saw
your
cursor.
Maybe
that
was
it
okay,
so
it
looks
like
he's
literally
got
just
like
an
issue
where
he's
having
trouble
getting
it
working.
D
Okay,
so
there's
an
open
issue
there
regarding
like
something
with
the
way
the
ajax
requests
are
done.
I
think.
D
D
Next
up
issue:
4663
is
adding
a
break
point
configuration
setting
for
the
menu
block
that
when
you
squish
your
screen
down
or
use
a
smaller
device
on
a
certain
size.
The
backdrop
automatically
decides
when
to
replace
the
across
the
top
administrator,
not
administrative
across
the
top
navigation
with
the
hamburger
menu
and
that's
not
configurable
at
this
point
and
46.63
adds
a
setting
to
make
it
so
that
that
can
be
changed.
D
There's
a
lot
of
discussion
in
that
issue
regarding
more
complete
break
point
support
like
break
point,
module
type
thing
that
so
far
people
the
implementation
has
been
leaning
towards.
We
don't
really
need
another
module.
We
just
need
a
setting
because
it's
really
not
a
very
complex
thing
to
specify.
D
F
Issue,
so
I
just
want
to
mention
that
I
think
what
this
module
does
is,
if
you
select
that
you
change
the
breakpoint,
is
that
it
then
in
a
sense
overrides
some
of
the
css
and
I'm
just
wondering
if
that
has
any
implications
for
our
other
some
of
our
other
issues
about
overriding
css.
D
That's
a
good
question,
I
I'm
not
sure
yeah,
I'm
not
sure
I
haven't
even
looked
at
the
implementation
yet,
but
it
is,
there
is
a
pull
request
out
there
that
needs
review
and
or
wait
yeah
yeah
yeah
support
request.
D
I
I
honestly
just
a
quick
voicing
of
my
opinion.
I
think
that
this
makes
sense
to
have
it
be
a
setting
that
is
not
a
global
one,
because
the
concept
of
sites
having
three
break
points
or
something
like
that
where
everything
switches,
although
a
common
pattern,
doesn't
always
work
and
that
if
you're
writing
your
content
or
if
you're
writing
your
css
to
break
where
necessary,
there
isn't
just
like
three
break
points.
D
It's
all
like
where
the
break
point
makes
sense
that
things
are
changing
their
behavior
based
on
how
much
size
they
need,
and
so
I
I
think
conceptually
having
multiple
break
points
based
on
the
size
of
the
content
and
how
much
content
can
fit
on
the
screen
makes
a
lot
of
sense.
D
Let's
see
next
up
is
a
really,
not
sure
to
say
simple,
just
a
terminology:
one
change
the
name
of
fold,
html
text
format
to
raw
html
issue;
44.99
tim
you're,
the
advocate
on
this
one.
Can
you
give
us
an
update.
F
Sure
so
this
has
been
discussed
for
a
long
time
sort
of
problems
with
the
the
terminology
here,
people's
expectations
of
what
full
html
means
is
very
different.
We
even
when,
when
I
most
recently
posted
this,
you
know
I
got
some
feedback
like
oh,
I
don't
want
to
do
that
because
you
know
when
I
choose
full
html,
I
expect
to
see
a
wysiwyg
and,
and
there
that's
the
way
it's
supposed
to
be
and
we're
like.
Well,
that's
not
the
problem
is
that's
not
the
way
it
is.
F
You
don't
get
a
wysiwyg
with
full
html.
So
anyways
there's
a
lot
of
confusion
about
this.
I
think
that
the
big
thing
around
fixing
it
right
now
or
the
dispute
seems
to
be
around
the
machine
name
like
we
could
easily
change
the
user,
visible
name
from
full
html
to
raw
html.
F
There
has
been
debate
about
whether
or
not
if
we
did
that
we
would
have
to
change
the
machine
name.
Would
core
committers
commit
it?
Unless
we
we
changed
the
machine
name
and
if
we
did
change
the
machine
name,
would
that
break
old
sites?
So
I
think
that,
really
before
we
can
go
any
further,
we
need
kind
of
a
higher
level
decision
about.
F
A
Interesting,
my
fear
was
around
not
knowing
how
many
places
in
the
database
might
be
using
these
formats,
and
so,
if
we
change
something
in
config,
anything
in
the
database
that
had
a
filtered
text
field
would
have
referenced
the
old
name,
and
we
don't
have
a
good
way
to
like
pull
that
list
of
all
the
stuff.
That
would
need
a
database
update.
So
my.
C
A
C
A
D
No,
there
shouldn't
be
any
hard-coded
use
of
any
text
format
in
contrib
modules
at
all,
because
there's
already
like
api
functions
for
get
the
default
format,
get
the
fallback
format
and
you
shouldn't
ever
need
to
hard
code,
those
machine
names
into
a
contrib
module.
So
and
really,
I
think
you
you
can
even
delete
the
full
html
text
format
from
core,
so
you
can't
I
mean
as
a
contrib
module.
You
can't
even
count
on
that
format
existing
in
the
first
place.
If.
A
That
deleting
is
special,
though
it
used
to
just
be
marking
as
disabled.
So
even
though
you
can
delete
it,
it
probably
wouldn't
have
broken
your
modules
if
a
module
had
done
it
that
way
before,
because
it
was
there,
you
just
couldn't
use
it
because
it
didn't
ever
actually
delete
the
configuration
it
just
marked
it
as
disabled.
So
it
is
possible
that
someone
has
done
it
wrong
and
contrib
and
that
by
making
this
change
we
will
break
contribute,
but
I'm
not
necessarily
sure
we
need
to
worry
about
that.
D
Yeah,
but
getting
back
to
it,
I
think
that
we
just
need
to
make
this
affect
new
sites
like
affect
the
defaults
and
existing
sites
will
be
unaffected
when
they
update
to
the
newest
version
of
backdrop.
They'll
continue
having
a
format
named
full
html,
even
though
you
know
might
not
be
what
they
expect,
but
new
sites
will
get
raw
html
and
that's
it.
I
think
that's
a
good
approach,
sure
so.
D
F
So,
just
to
be
clear,
we've
got
a
lot
of
input
on
this
issue
because
it's
been
open
for
a
long
time
and
again,
I
think
most
people
either
don't
care
or
support
the
idea
of
changing
the
name
at
least
two
or
three
people
have
sort
of
come
down
hard
on.
We
should
not
change
the
machine
name
so
just
to
voice
their
concerns.
I'm
not
sure
why
they're
so
concerned
about
it,
but.
D
Every
field
table,
and
even
then
that
doesn't
get
all
of
them,
because
text
formats
are
used
in
configuration
like
views
blocks
right.
So
even
then
you
it's
there's
no
central
repository
at
all
of.
Where
is
this
text
format
used?
So
we
don't
really
have
the
ability
to
rename
it
act
on
an
active
site
at
all.
D
A
A
F
Yeah,
so
just
to
be
clear,
there
is
a
pull
request
for
this,
but
it
was
me
which
means
that,
basically,
it
was
like
a
search
and
replace
anywhere
the
words
full
html
appeared.
I
changed
it
to
raw
html
and
that's
really
all
I
did
so.
What
I
need
to
know
is
from
other
people
that
are
smarter
than
me
like
what
else
I'm
missing
other
than
tests
tests,
I
know,
are
something
that
are
going
to
be
affected
and
need
to
be
addressed,
but
is
there
anything
else
beyond
beyond
that
too?
A
I
think
that
so
changing
the
machine
name
in
the
install
profile
would
be
the
next
piece
on
there
and
then
I
would
ask
someone
to
review
in
the
sandbox
and
someone
for
a
quote
review
and
they'll
probably
catch
anything
else.
A
F
D
Looking
over
it,
your
pull
request
looks
like
it's
already
going
to
do
exactly
what
we
described
and
you
you
already
updated.
The
tests
looks
like
two
tests
are
failing,
but
it's
pretty
minor.
D
Okay,
let's
see
next
one
is
really
a
pretty
simple
overall
issue,
adding
a
link
sub
token
for
user
tokens.
When
we
display
a
link
or
the
user
account
name,
make
there
be
an
option
to
also
link
to
their
profile.
Page
issue
is
84.
gregory
you're.
The
advocate
for
this.
Do
you
have
an
update.
B
Yep
five
minutes
ago,
so
I
just
updated
the
pull
request:
screenshots
according
to
your
feedback,
nate
and
peters,
as
well,
just
a
final
call
for
teams
and
anyone
else.
That's
interested
just
have
a
look
at
the
awarding
of
the
description
and
we're
ready.
D
Great
yeah,
it
did
seem
really
close.
Then
we
even
kind
of
agreed
on
some
good
terminology
there
yeah
so.
D
Yeah,
that
would
be
great
okay
and
joseph.
You
added
advanced
caching,
hashtags
and
cache
max
age
issue.
41.27.
Can
you
give
us
an
update
sure.
E
So
I
started
working
on
a
port
of
the
d8
cache
module
last
week,
just
as
like
an
initial
figuring
out
what
it
does
and
how
much
I
can
like
integrate.
I
think
so.
I'm
skeptical
that
it's
actually
going
to
make
a
huge
difference
for
most
of
our
sites,
because
they're
all
really
small
and
it
seems
to
like
the
larger
your
site-
is
the
more
of
an
improvement
it
makes.
B
E
Yeah
and
one
of
the
big
things
that
hashtags
does
in
drupal
8
is
makes
it,
so
you
don't
have
to
clear
your
whole
page
cache
and
the
reason
that's
important
is
actually
just
because
rendering
tweak
templates
is
so
slow
and
so,
like
we've
kind
of
circumvented
the
issue
by
just
having
it
be
faster
out
of
the
box
but
yeah.
I
do
agree
that,
as
from
a
marketing
perspective,
it
would
be
a
good
idea
to
get
it
in.
D
Yeah
yeah,
I
think
you're
gonna
run
into
a
number
of
challenges
here,
so
but
I'm
glad
you're
taking
a
look
at
it.
One
of
the
compromises
that
had
to
be
made
to
allow
that
functionality
is
that
aaa
became
even
increasingly
even
more
than
was
before,
dependent
upon
render
arrays
for
absolutely
everything,
because
it
needed
to
track
the
caching
metadata,
as
well
as
the
css
and
javascript,
and
that
resulted
in
things
like
you
know.
D
In
our
code
base
backdrop
js
and
backdrop
ad
css
functions
might
not
work
correctly
in
combination
with
cash
types
or
in
combination
with
the
dynamic
page
cache,
and
so
I'm
not
I'm
not
sure.
If
actually
dynamic
page
cache
is
really
what
we're,
after
so
much
as
like
just
getting
the
cache
tags
like
into
the
headers.
D
D
Yeah,
that's
what
that's!
What
I'm
primarily
thinking
about
the
cache
tags
are
helpful
for
invalidation,
but
if
you
have
a
humane
invalidation
and
external
systems
like
varnish
yeah,
primarily,
I
think
that's
the
case
but
you're
right
that
it
would
also
help
the
normal
built-in
page.
Cache
could
start
clearing
caches.
D
Just
so
you
know,
drupal
7
had
a
thing
in
it
where
every
time
a
node
was
saved,
it
would
clear
the
entire
page
cache
and
that
that
obviously
makes
it.
So.
The
page
cache
if
you've
got
a
highly
active
site,
doesn't
do
a
whole
lot
and
backdrop
and
optimization
that
we
made,
as
we
just
simply
removed,
that
clear
all
caches
after
a
node
is
saved,
which
means
that
when
you
save
a
node
in
backdrop
with
the
normal
page
cache
it
takes.
However
long
your
cache
lifetime
is
five
minutes
by
default.
D
It
takes
five
minutes
for
that
piece
of
content
to
show
up
and
that's
the
way
backdrop
already
works
if
you
used
nginx
or
varnish,
because
it's
already
having
its
external
cache
and
so
really
we
made
backdrops
and
terminal
cache
act
the
same
as
an
external
cache.
By
making
that
change
plus
it
made
a
lot
more
efficient.
D
D
D
E
E
A
D
A
D
Yeah,
there's
a
what's
the
drupal
7
module,
that
is
it
purge
or
expires,
there's
something
that
that
basically
shoehorns
that
functionality
into
troops
right
well,.
E
D
Okay,
all
right,
well
that
those
are
the
issues
that
we
have
in
118
that
have
advocates
that's
very
exciting
that
we've
had
such
an
increase
in
focus
on
118.
Now
that's
117
is
out.
We
also
have
large-scale
initiatives.
Oh
and
luke
is
here
we
just
haven't
heard
from
him.
Yet,
but
first
we
have
there's
two
active
initiatives
and
the
first
one
is
telemetry,
which
tim
has
adopted
tim.
Do
you
want
to
give
the
update
on
telemetry.
F
F
F
I
did
it
in
the
wiki,
because
it's
kind
of
a
long
summary
with
a
bit
of
a
q
a
and
I
tried
to
go
through
the
entire,
very
lengthy
issue
and
some
and
sort
of
answer
all
the
questions
that
have
come
up
over
the
time
anyways.
I
my
plan
had
been
to
to
you
know,
get
this
summary
done
and
get
feedback
on
that,
so
that
we
could
start
looking
at
code
and
a
few
hours
later.
I
I
feel,
like
nate,
submitted
a
pull
request.
D
Go
ahead,
yeah
and
I
should
have
updated
the
issue
at
the
beginning
of
the
weekend
that
I
didn't
have
anything
else
happening
this
past
weekend,
and
I
thought
that
would
be
a
good
area
to
put
in
some
effort,
and
I
did
update
the
that
document
that
we
worked
on
together,
that
we
did
during
backdrop
live.
I
flushed
out
some
additional
implementation
details
in
that
document
before
I
started.
Okay
and
the
some
of
the
approaches
that
I
took
they're
not
necessarily
finalized,
but
I
think
they're
good
good
ideas.
D
Nonetheless,
there
has
to
be
a
server
component
and
a
client
component,
so
the
client
component
is
just
called
telemetry
module
and
the
idea
is
that
it
would
just
go
directly
into
core.
The
server
component
is
going
to
live
on
backdrop
cms.org.
You
know
that
receives
the
telemetry
data
from
the
individual
backdrop
installations,
and
we
needed
some
place
to
put
that
code
and
thinking
about
the
fact
that
project
module
runs
most
of
backdrop.org's
special
functionality
like
packaging
and
usage
statistics
for
the
number
of
installations
of
every
project.
D
It
made
sense
to
put
telemetry
into
project
module
as
well.
So
that
backdrop,
reports
project
module
essentially
as
the
place
that
stores
all
the
telemetry
information.
So
I
made
a
new
module
called
project
telemetry.
D
D
So
what
this
would
look
like
right
now
is
that
it
would
add
a
telemetry
tab
to
the
backdrop
project
page
and
then
you
would
see
information
about
everybody
that
was
running
backdrop
core,
but
in
theory
that
means
that
it
would
also
be
able
to
do
the
same
thing
to
contrib
modules.
The
contrib
modules
could
also
implement
hook,
telemetry
data
and
start
sending
information
to
backdrop
cms.org
and
also
have
a
telemetry
tab
on
their
project
pages,
which,
which
might
be
more
than
we
really
want.
D
There's
all
kinds
of
possible
privacy
and
data
concerns
that
if
we
start
allowing
everybody
to
collect
arbitrary
information
that
they
might
start,
I
mean
they
really
can
collect
anything
that
doesn't
have
to
just
necessarily
be
their
module,
but
contributed
mods
already
can
do
anything
they
want
on
your
site
whatsoever.
I
mean
they
can
scrape
all
the
information
and
send
it
off
anywhere.
I
mean
there's
some
definitely
a
certain
component
of
trust
there
and
if,
if
a
project
we're
doing
something
nasty
well,
that's
why
we
have
administrative
permissions
over
all
of
the
contrib
group.
D
We
could
remove
that
person's
access
and
disable
the
module
or
something
like
that.
But
nonetheless
this
does
open
up
some
new
concerns
and
that
initially
we
might.
We
need
to
add
some
kind
of
prevention
mechanism
to
prevent
backdrop
cms.org
from
recording
data
that
we
don't
intentionally
want
it
to
gather
because
holding
the
data
on
our
own
servers
could
get
us
into
all
kinds
of
well
trouble.
A
There's
a
solution
in
there.
I
added
a
comment.
I
think
bw
panda
also
came
with
the
same
solution
there.
I
recommend
comment
on
how
to
prevent
that.
So
it
was
nate's
idea.
I
don't
remember
what
it
was.
It
was
nate's
idea.
I
wrote
it
down.
Okay,.
D
But
there's
no
there's
no
user
interfaces
right
now,
like
I
mean
there
are
user
interfaces,
but
they're
not
really
suitable
for
showing
people.
D
One
problem
that
we
need
to
figure
out
is
how
to
visualize
the
data
that
we
collect
and
because
the
data
that
we
get
is
kind
of
arbitrary,
like
php
versions,
for
example,
you
know
they're
all
they're
highly
granular,
that
with
three
different
digits
in
them,
but
we
probably
really
only
kind
of
care
about
the
minor
version
you
know
php
7.1
versus
php
7.2,
and
that
means
that
we
need
some
kind
of
specialized
representation
for
that
data
and
I'm
not
quite
sure
how
to
proceed
on
that
particular
point
I
mean.
I
know.
E
A
Yeah
and
we
need
charts
anyway
for
the
usage
data,
if
we
already
have
open
issues
for
that.
D
Yeah,
I
think
that
there
should
be
a
another
project
module
either
that
or
project
usage
and
project.
Telemetry
should
just
say
if
module
exists,
chart
do
something
you
know,
but
even
then
getting
it
into
a
tabular
format
like
into
a
table.
We
don't
even
have
that
part
figured
out
yet
because
the
data
that
we
collect
is
just
the
raw
values
that
were
being
sent
and
we
need
to
aggregate
them
in
some
way
before
we
pass
it
to
a
to
a
charting
system.
A
A
D
Yeah
yeah,
and
we
could,
because
the
core
component
is
already
pretty
far
along,
assuming
that
this
approach
seems
pretty
good,
that
we
can
start
collecting
the
data
and
figure
out
how
to
format
it
later,
and
so
that
that
would
be
a
pretty
good
idea
to
to
possibly
like
move
forward
with
getting
what
we
have
approved
into
core
and
then
figuring
out.
What
to
do
with
the
data
later.
B
One
thing
that
I
wanted
to
point
out
is
that
once
we
rolled
out
this
change,
there
might
be
sites
that
do
not
update
themselves
or
do
not
do
that
very
often,
and
we
need
a
ideally
would
need
a
way
to
have
the
sites
pull
the
instructions
of
what
we
need
to
collect,
but
I'm
not
sure
sort
of
like
the
same
way
that
we
do
for
the
rss
speed.
I
think
that
that
provides
the
updates
the
available
updates.
B
So
if
we
have
the
mechanism
there
that
pulls
the
data
and
pushes
it
to
backdrop
if
we
want
to
pull
information
from
stale
sites,
which
could
be
many
like
I'm
thinking
of
old
sites
that
are
not
being
updated,
like
which
php
version
are
they
running,
are
we
gonna
break
them?
But
if
they're
we're
not
updating
them,
then
we
don't
need
any
specific
data
from
them
to
begin
with.
D
I
mean
we
could,
in
theory,
actually
turn
it
on,
but
I
don't
think
that
we
should,
for
the
same
reason,
why
we
don't
do
that
for
pretty
much
any
other
module
that
we
add,
like
their
site
stays
the
same
if
they're
just
updating.
I.
B
D
Like
that
so
yeah
it's
it's
kind
of
interesting
that
I
I
went
down
that
path
a
little
bit.
It
did
get
a
bit
gnarly,
but
the
current
implementation
shows
people
what
we
collect
and
shows
all
of
the
data
on
a
reports
page
and
then
it
just
right
now
says:
if
you
don't
want
to
send
information,
disable
the
telemetry
module,
so
it's
an
all
or
nothing
proposition,
and
even
all
of
the
like.
Okay,
like
problems
aside
of
getting
some
data,
but
not
all
of
it.
D
I
personally
felt
that
per
option
granularity
was
way
too
much
configuration
for
the
module
anyway,
like
I've
never
seen
something
say
like
you
know,
it's
probably
true
for
a
lot
of
other
products
that
just
like.
Do
you
want
to
track
a
track
or
not?
You
know.
A
A
But
I
do
think
it's
really
great
that
we
give
them
a
table
of
like
this
is
all
the
information
we're
going
to
collect
on
these
relative
values,
because
that'll
really
make
it
easy
for
people
to
make
that
decision
and
if
they
can
see
like
all
we
want,
is
your
php
version
and
your
module
list.
They'll,
be
like.
Oh
no
problem.
B
With
regards
to
something
that
was
mentioned
earlier,
how
granule
or
how
precise
we
need
the
php
version,
and
we
need
just
two
digits
so
there's
two
ways
to
address
that
we
can
groom
the
data
before
it's
sent,
so
we
can
collect
just
the
two
digits
and
send
it
out.
But
if
we
want
to
be
accurate
from
a
data
collection
point
in
case
we
need
extra
digits
in
the
future.
We
should
just
be
collecting
the
entire
php
string,
but
yeah.
B
A
B
So
so,
as
I
said,
the
more
data
data
wise
sort
of
like
correct
way
to
to
do
that
is
pull
all
the
data
so
that
we
have
them
and
then
what
we
do
with
that
is
flexible
over
time.
But
an
easy
solution
for
us
would
be
to
just
collect
what
we
need
to
like
display,
there's
pros
and
cons
to
both
things.
We
need
to
consider
good,
but
the
good
news
is
that,
as
it
turned
out
not
to
diminish
the
the
effort
that
you
put
to
this
nate.
E
I
think
so
I
haven't
looked
at
the
implementation
as
it
exists
at
all,
but
I
think
that
processing
the
data
on
our
side
and
then
only
displaying
it
if
we've
specifically
set
up
a
processor
for
that
particular
type
of
data
would
mitigate
abuse
of
the
system.
B
F
A
Yeah,
it
was
so
there
would
be
an
application
process
if
you
had
a
contrib
module
and
you
wanted
to
store
data
on
our
server.
You
would
say:
please
enable
this
for
my
module
and
then
an
admin
would
come
in
and
check
the
box,
and
if
that
box
wasn't
checked,
it
doesn't
matter
what
your
module
sends
to
backdrop
cms.org
it
just
immediately
gets
thrown
out.
C
F
So
what
is
the
next
steps?
Clearly,
there
were
some
decisions
about
how
to
manage
this,
how
to
display
it,
but
I
mean
is
it?
Does
it
work
already
mate
and.
D
Yeah
it
works.
I
think
that,
unfortunately
testing
it
is
complicated
because
as
a
server
and
client
component,
but
I
did
provide
instructions
on
how
to
do
that,
where
you
can
have
your
own
site,
be
one
site,
be
both
both
parts
at
the
same
time,
so
you
can
test
it
all
on
a
single
installation.
Do.
B
D
So
that's
we
have
that
same
consideration
with
project
usage
and
it's
just
using
database
tables
right
now
and
if
we
want
to
segment
it
off
at
a
later
point,
then
we
can
use
database
table
prefixes
to
just
put
it
into
some
other
yeah.
We
can
just.
F
Okay,
okay,
well,
the
last
thing
I'll
just
say
is
as
nate
did
you
read
through
my
summary
and
make
sure
that
my
summary
reflects
what
you
did,
because
the
value
of
my
summary
is
that
for
people
who
who
don't
sort
of
understand
the
module,
they
can
read
that
story
and
understand
it,
but
only
if,
if
it's
correct,
so
I.
F
It's
a
link
to
a
wiki
page
so
and
it's
also
in
the
in
the
very
top
of
the
issue
I
in
the
original
post.
I
put
it
right
at
the
top.
D
Yeah
I
haven't
read
over
this
wiki
page
at
all
yet,
but
I
can
do
that
too.
F
Well,
I
think
it
would
be
good
if
you
did
read
it
over
and
then
change
and
you
can
just
edit
it.
I
think
and
change
the
story
where
it
is
misrepresented
if
it
misrepresents
what
you've
actually
done,
because
I
think,
as
we
as
we
talk
about
this,
that
story
can
be
sort
of
helpful
to
people
who
want
to
understand
the
issue
and
what
we're
doing
yeah.
This
looks
great,
though
very
descriptive.
D
C
Well,
I
I'll
just
give
the
the
summary
that
they
can
can
digest,
which
is
the
the
action
item
I
made
for
for
myself
is
that
I
am
going
to
put
a
burn
down
list
before
the
end
of
today
on
the
the
the
forum
on
the
the
forum
post
for
ready
to
wear
outline.
What
I
believe
are
the
tasks
necessary
to
actually
complete
it.
C
F
D
All
right
anything
else
that
we
should
bring
up
before
we
close.