►
From YouTube: 2022/06/23 - Weekly Backdrop Dev Meeting
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
Hello,
it's
june
23rd
2022,
and
this
is
the
weekly
backdrop
developer
meeting.
We
get
together
every
week
to
cover
mostly
technical
topics
that
the
backdrop
project
is
facing,
and
so
today
we've
got
a
little
group
here.
My
name
is
nate
lampton,
I'm
from
oakland
california,
and
I
go
by
quick
sketch
on
the
internet,
we'll
get
an
intro
from
tim
and
then
jen.
B
My
name
is
tim
erickson.
I
am
saint
paul
tim
on
the
internet
and
I
am
in
deerwood
minnesota
and
that's
it.
C
Chad
liamton
joining
from
oakland
california,
currently
working
on
updates
to
the
event
site
and
I
hope
to
have
a
release
for
google
analytics
today
too.
A
Great
thanks,
jen
joseph
and
then
we'll
finish
with
google.
D
E
A
Awesome
welcome
goku,
all
right
great.
Let's
see
we
usually
do
a
little
roundup
of
new
contrib
and
community
happenings
jen.
Do
you
wanna
give
us
a
little
summary.
C
Sure
so,
we've
had
four
new
kinship
releases
in
the
last
week.
New
modules
auto
purge
users,
which
is
a
module
that
we're
going
to
add
on
all
the
backdrop
sites.
It's
a
part
of
a
drupal
module
that
allows
you
to
set
requirements
for
like
how
long
it
can
be
if
somebody's,
never
logged
into
the
website
before
their
account,
gets
deleted
or
blocked,
and
then
for
people
who
have
been
deleted
or
blocked.
C
Module,
which
I
think
is
also
a
port
from
drupal
bw
panda-
has
been
working
on
entity
plus
cmi
module,
which
is
pretty
cool
it
arrives,
allows
you
to
save
entity
data
into
a
configuration
file.
So
if
you
wanted
to
use
an
entity
to
create
a
config
schema,
you
could
do
something
like
that.
It's
the
kind
of
thing
where
I'd
never
even
thought.
That
thing
was
possible
and
of
course,
stockholm
was
like
tada.
Look
what
I
built
and
then
my
mind's
just
like
what
it's
really
cool,
so
fun
thought
experiment.
C
I
can't
wait
to
see
how
people
use
it
and
then
avatar
module.
I
think
all
supported
from
drupal
also
came
out
this
week.
So
a
lot
of
activity
this
week.
Thank
you.
Everybody
who's
been
working
on
those.
A
Excellent
and
when
you
say
that
user
per
users
module
is
that,
for
you
said
on
backdrop
sites
you
made
on
backdrop,
cms.org
sites,
yes
yeah
great,
so.
C
We
have
we
sort
of
have
a
a
bunch
of
people
who
are
doing
manual,
maintenance
on
spam
accounts,
but
they've
just
been
blocking
them,
and
this
will
allow
us
to
set
up
automatic
rules
for
when
those
blocked
accounts
should
be
deleted.
So
we're
not.
We
don't
have
accounts
from
10
years
ago
that
have
been
blocked
for
forever
and
also
some
criteria
around
when
an
account
should
be
blocked.
C
So
if
it's
been
more
than
three
months
since
you
created
your
account,
you've
never
logged
in,
for
example,
we
could
have
something
like
that,
the
auto
blocks,
and
then,
after
a
year
of
no
use,
we
can
delete
or
something
like
that.
A
B
There
was
just
a
comment
in
zulu
that
I
think
we
got
the
credit
wrong
in
that
module.
The
rsg
piano
did
the
entity
config
one.
Oh.
A
Okay,
all
right,
let's,
let's
see
we
usually
go
to
a
forum
post
that
we
solicit
questions
throughout
the
week.
If
people
want
to
ask
questions
and
have
them
answered
during
these
meetings
asynchronously,
I
wasn't
here
the
past
two
weeks.
Were
there
any
questions
from
those
two
weeks
that
I
missed
nope.
C
A
Okay,
well
speaking
of
rg
piano,
probably
the
the
biggest
122
bug
fix
that
we
have
for
122.1
is
issue
5482,
that
rg
piano
has
been
working
on
along
with
doc,
wilmont
and
occasionally
I
have
been
hopping
in
there
issue
54.82
the
layout
relationship
plug-in
that
forms
a
relationship
between
a
node
and
the
author
of
that
node
is
not
working
correctly
and
there's
been
a
pull
request
at
5482
that
needs
review
in
testing
this
yeah
pretty
much.
A
The
big
thing
is
that
we
need
to
actually
write
a
comment
and
tests
on
github
itself,
but
I'll
verbally
say
the
state
of
it
that
it
needs
review
the
last
time
I
looked
at
it.
It
worked
great
and
it
has
excellent
test
coverage.
The
one
thing
I'm
still
trying
to
figure
out
is:
if
we
need
to,
we
started,
we
added
a
new
property,
the
menu
router
to
the
layout.
A
That
is
now
like
a
permanent
new
property
which
expands
the
complexity
of
the
layout
object
when
you
debug
it
and
I'm
trying
to
figure
out.
If
we
could
not
pass
in
an
extra
property,
I
I
think
it
might
be
possible
to
work
with
the
properties
that
we
have
already
without
adding
anything
new,
but
I
could
be.
I
could
be
wrong
about
that
and
I
need
to
go
back
and
revisit
it.
A
I'm
sure
there's
a
technical
reason
for
why
we
need
to
add
it
again,
but
I'm
thinking-
and
this
is
not
fully
formed
yet-
is
that
the
context
information
that
we
have
is
already
in
the
layout
already
and
I'm
just
wondering
why
we
need
to
have
it
in
two
places,
both
in
the
menu
router
and
in
the
list
of
contexts
that
are
in
the
object,
the
context
property.
A
So
I
know
that's
what
it's
maybe
I
shouldn't
have
talked
about
that
because
layouts
is
just
really
heady
especially
contexts
well
anyway,
that
that's
kind
of
the
hold
up
there
is
that
this
going
to
take
some
time
to
unravel.
If
an
alternative
is
possible-
and
I
should
state
that
as
a
comment
just
so
that
alejandro
isn't
just
waiting
anyway
I'll
try
to
do
that
right
after
this
meeting.
A
A
123
is
the
next
feature,
release
of
backdrop
that
will
be
coming
out
september
15th
and
there's
a
number
of
things
that
we're
shooting
for
in
that
release.
So
far,
one
thing
came
through
this
week
that
was
unplanned
but
came
came
to
completion
and
that's
issue
50,
sorry,
45
21,
which
is
really
small,
but
it
standardizes
the
spelling
of
email
throughout
backdrop.
So
backdrop
was
split,
occasionally
using
e-mail
or
e-e-mail
instead
of
email.
A
All
one
word:
you
know
showing
its
age
from
drupal
that
e-mail
was
kind
of
the
way
email
was
spelled
in
the
early
days
of
the
internet
and
really
hasn't
been
that
way
for
the
past
decade
or
more
so
anyway,
that
issue
bw
panda,
take
the
lead
on
it
and
rg
piano,
followed
up
with
the
review,
thanks
to
both
of
you
for
making
that
happen.
A
All
right,
let's
see
other
features
the
entity
reference
module,
we're
working
on
getting
completed
into
123..
The
issue
number
is
1301.
This
one
has
been
stuck
herb:
dual
took
the
lead
on
it.
A
He
filed
a
pull
request
and
now
there's
this
hold
up.
Where
there's
been
three
additional
commits
to
the
contrib
project
that
we
need
to
get
integrated
into
the
pull
request
for
the
core
version,
and
the
holdup
here
is
just
purely
needing
to
jump
through
the
hoops
of
regenerating
the
pull
request,
while
maintaining
the
entire
git
history
from
contrib.
A
So
if
that
seems
like
it
would
be
useful,
then
that's
an
approach
that
we
could
try
to
speed
this
process
along
and
that'll.
Give
us
the
sooner
we
get
it
in
the
longer
of
a
testing
window,
we'll
have
to
get
it
prepared
for
123.
C
No
update
since
last
week
essentially
were
in
a
bit
of
a
holding
pattern
about
trying
to
clean
up
some
of
the
usability
issues
with
it,
and
the
one
thing
I'm
thinking
about
doing
is
removing
feature
which
is
the
ability
to
clone
a
field
group
from
one
entity
to
another
one
or
from
one
bundle
to
another
one
while
adding
the
field
group.
C
So
if
you
wanted
to
have,
for
example,
like
a
administrative
information
section
on
the
edit
form
and
on
the
display
form,
it's
really
convenient
to
be
able
to
say
build
it
on
the
edit
form
and
then
go
to
the
display
form
and
it's
a
clone
from
edit
form.
But
the
current
interface
for
doing
that
clone
operation
is
a
vertical
tab
on
the
add
fields
page
and
the
add
fields.
Page
is
already
really
complicated
and
adding
a
vertical
tab
into
that
interface,
really
clutters
the
interface
and
creates
sort
of
an
overwhelming
experience.
C
C
When
you
click
add
new
field
group,
you
go
to
a
standalone
page,
and
that
could
be
a
page
where
you
could
have
the
option
to
clone
from
another
entity
or
another
bundle
or
another
view
mode,
and
I
think
that
might
be
a
better
place
for
that
feature
than
throwing
it
onto
the
fields
form
with
all
of
the
other
field
options,
but
doing
that
might
also
slippery
slope
into
moving
the
ad
field
settings
onto
its
own
standalone
page.
So
we
get
two
action
links
there.
C
One
that
says
add
field
and
one
that
says
add
field
group,
and
so
I
think
trying
to
do
all
of
this
at
once
is
just
going
to
be
a
blocker
for
getting
field
group
into
core.
So
I
think
my
first
instinct
would
be
added
to
core
without
the
clone
functionality.
C
A
Yeah,
you
know,
I'm
not
sure
how
intensive
this
would
be,
but
it
would
be
helpful
if
we
had
an
understanding
of
how
many
contrib
projects
modify
the
field
form
in
the
same
way.
The
field
group
does
because
if,
if
we
build
field
group
into
core
and
field
group,
is
the
only
module
that
modifies
that
form
in
a
really
heavy
way,
then
that
kind
of
gives
us
the
freedom
to
make
further
modifications
without
impacting
contrib,
quite
as
much
but
field
group
is
very
popular
module.
A
It
runs
on
like
one
out
of
every
eight
backdrop,
websites
or
something
like
that,
like
you
know,
fair,
fair
percentage
and
we
can't
heavily
modify
the
field
form
if
we're
going
to
impact.
You
know
one
out
of
every
eight
backdrop
sites,
but
if
field
group
becomes
part
of
core
and
we
migrate
its
functionality
into
core
disable
field
group
module,
then
that
gives
us
a
little
bit
more
freedom
to
modify
that
form.
C
A
C
Where
it
form
alters
in
its
own
form
into
a
table,
so
I
think
that
the
way
that
other
forms
handle
this
now
is
a
very
different
way
than
the
way
field
group
does
it.
So
I'm
not
sure
we
need.
We
should
be
using
field
groups
like
our
example
of
how
to
do
it
or
how
we
might
want
to
do
it.
C
So
I
think
holistically
from
like,
if
you
were
going
to
build
this
interface
from
scratch,
how
would
you
build
it
ad
field
group
section
might
be
better
than
trying
to
see
like
how
many
other
projects
are
doing
it.
The
way
field
group
is
doing
it,
but
we
do
sort
of
have
that
question
of
like
that
managed
fields
listing
has
been
around
for
a
long
time.
It's
not
the
best
interface.
C
For
that
particular
scenario,
it
got
changed
a
little
bit
in
triple
eight
and
drupal
nine,
I'm
not
sure
it's
better,
but
it's
different.
We
could
ask
people
if
they
like
one
over
the
other
and
try
and
get
some
feedback
on
that,
but
yeah.
I
think.
D
D
C
Yeah,
I
think
adding
at
the
bottom
of
the
field
list
is
probably
less
terrible
than
what
field
group
is
doing,
which
is
sort
of
jamming
it
into
a
row
in
the
table,
but
yeah,
there's
also
stuff
at
the
bottom
of
the
formula
field
group.
So.
C
One
thing
that
I
was
thinking
is
that,
if
I
had
the
ability
to
do
this
from
scratch
would
be
to
change
the
way
field.
Ui
worked
to
support
settings
that
aren't
related
to
a
field,
so
you
could
have
a
settings
form
that
wasn't
tied
to
some
field
schema
or
something,
and
that
might
allow
additional
rows
to
be
added
into
the
table
with
configuration
options
that
work.
The
same
way,
field
configurations
options
work,
but
that
would
be
saving
that,
along
with
the
way.
A
C
Field
is
configured
so
it
would
allow
configuration
options
that
aren't
field
related
to
appear
on
the
field
manage
fields.
C
So
in
this
case
they'd
be
user
interface
related
with
display
speed,
they
could
be
layout
related
or
wherever
those
end
up
affecting
the
end
result,
but
that
might
be
something
we
could
brainstorm
on
to
try
and
figure
out
how
to
make
that
system.
You
could
use.
D
You
can
use
hook,
field
extra
fields
to
add
not
fields
to
your
field.
Ui.
D
A
C
A
Yeah,
if,
if
hookfield
extra
fields
work
had
had
options,
it
would
really
expand
the
way
that
that
form
could
be
used,
because
you
could
start
putting
all
kinds
of
things
in
there.
You
know
the
everything
that's
in
vertical
tabs
right
now:
common
settings,
menu
settings-
the
title
field
of
course,
is
popular
saying
that
people
want
to
be
able
to
control
yeah.
That
would
really
open
things
up.
Quite
a
lot.
A
Yeah
well
anyway,
yeah
sounds
like
you've
got
a
lot.
A
lot
of
work
cut
out
for
you,
jen
there's
a.
C
But
that
would
mean
that
we
would
be
removing
that
clone
option,
which
is
very
common,
that
you
want
the
same
thing
on
your
edit
form
and
on
your
display
form,
and
so
I
just
wanted
to
before.
I
made
that
call.
I
wanted
to
allow
people
to
be
like
don't
remove
this
feature.
I
need
it
so
we'll
see.
A
All
right,
great,
let's
see,
let's
move
on,
we've
got
only
one
more
issue
in
123
to
discuss
today.
I
think
and
that's
allowing
the
administrator
to
hide
the
title
on
comments.
Issue
4569,
which
tim
is
the
advocate
for
there's
two
poll
requests
that
have
been
filed.
It
looks
like
that.
We're
waiting
on
feedback
there
to
kind
of
determine
which
way
is
the
best
way
and
discuss
how
to
minimize
the
backwards
compatibility
impact
on
existing
themes.
A
Tim,
any
anything
you
sorry,
I
kind
of
took
your
summary,
but
is
there?
Is
there
more
to
add
there
about
the
state
of
things.
B
No,
I
no
it's
just
we're
yeah
deciding,
which
is
the
better
approach
than
changing
the
the
comment
template
or
doing
it
with
css.
I
think
we're
fairly
evenly
split
with
a
couple
of
people,
preferring
css,
a
couple,
preferring
the
template
and
a
couple
of
people
saying
well
either
could
work,
but
maybe
with
slight
preferences.
So
one
of
the
things
we've
been
waiting
for
or
which
I
think
would
be
helpful,
would
be
clarity
on
whether
both
approaches
aren't
even
acceptable.
B
For
example,
I
could
see
nate
where
you
might
object
to
the
css
approach.
For
the
same
reason,
some
other
people
have,
and
in
which
case
I
don't
need
to
keep
pursuing
it.
So
I'd
kind
of
like
some
before
we
push
it
any
further.
I
just
like
a
little
guidance
if
one,
if
from
a
core
committer's
perspective,
you
have
a
strong
opinion
that
would
be
really
helpful
at
this
stage.
A
B
A
Yeah,
I
think,
let's
see
where
does
the
css
one
hide
comment
title:
where
does
this
class
actually
get
added?
Okay,
it
gets
added
in
a
pre-process.
B
Yeah
and
like
it,
I
think
right
now,
if
I
recall
we're
basically
creating
a
second
css
file
and
jen.
You
know
we
have
this
other
issue
about
how
to
make
css
changes
to
core
which,
if
we
address
that,
might
help
us
avoid
adding
a
new
well
we're
at
it
a
different
way,
but
it
would
certainly
put
that
and
I
can't
well.
I
guess
the
problem
is
that
some
some
some
themes
also
override
some
some
themes
override
the
the
comment
template
and
many
of
them
override
the
css
as
well.
B
A
Yeah
I
overall
like
looking
at
these
things.
I
think
any
solution
is
fine,
if
I
think
we
discussed
this
previously
that
if
we
add
a
new
setting
and
the
new
setting
doesn't
work
on
on
existing
themes,
I
think
that's
totally
fine,
because
there's
an
it's
a
new
feature.
Themes
have
to
go
back
and
add
support
for
something
that
wasn't
there
before.
A
So,
the
the
only
thing
we're
really
concerned
about
is
existing
sites
they're
using
a
theme,
and
then
they
upgrade
to
the
new
version
of
backdrop.
The
behavior
should
remain
the
same
as
it
was
before,
and
I
believe
that
effectively.
B
Because
neither
of
them
take
effect
unless
you
check
this
box
right
to
hide
comments
right
now,
it's
not
possible
to
hide
comments,
so
nobody's
done
it
and
the
the
pull
request
adds
the
option
to
hide
comments
which
would
be
the
default
would
be
to
not
hide
them.
So
there
aren't
any
sites
out
there
that
have
already
chosen
to
hide
comments
unless
they're
using
a
contrib
module,
which
I
don't.
C
Yeah
yeah,
we
we
looked
at
that
or
talked
about
it
two
weeks
ago,
when
last
time
robert
was
here
because
he's
the
maintainer
of
the
kendrip
module
and
it
looks
like
it
there's
only
one
module
and
you
use
the
same
name
in
in
the
course
setting.
So
it
should
be
pretty
easy
to
write
an
update
script
to.
If
you
had
the.
A
Yep,
so
so,
moving
with
that
requirement
that
we
not
impact
existing
sites
and
themes
will
need
to
update
pretty
much
either
way
to
support
this
new
feature,
regardless
of
whether
it's
a
cs
up
like
create
a
new
css
file
or
upload
update
the
template
file.
A
And
now
I
guess
there
are
you
know,
depending
on
the
choice
we
use.
We,
we
follow
the
themes.
C
B
Well,
the
idea
of
the
css
solution
is
that
nobody
would
have
to
update
anything.
It
would
just
work
on
all
sites
without
that's
the
advantage.
That's
why
it's
the
only
reason
I'm
really
considering
it
I
mean,
I
think,
to
some
extent,
the
template
seems
like
a
really
good
solution,
except
that
it
would
break
a
lot
of
themes
and
the
css
solution.
Doesn't
it
works.
A
B
C
C
So
that
the
trade-off
there
is
hey,
look,
we
found
a
way
to
distribute
this
new
feature
that
will
work
for
everyone,
but
it's
going
to
create
a
little
clutter
in
core.
How
do
core
maintainers
feel
about
that?
Whereas
our
other
solution
would
be
like
hey,
we
found
a
way
to
make
it
work,
but
if
your
theme
has
overridden
the
css
file,
it
still
won't
work
if
we
put
it
somewhere
else
so.
A
Yeah
yeah
great
summary,
I
would
given
those
options.
I
would
prefer
the
one
that
causes
us.
You
know
to
have
less
baggage,
because
what,
if
we
add
the
new
css
file
with
the
idea
that
ultimately
we'd
like
to
get
rid
of
the
css
file
and
move
towards
an
approach?
That's
more
like
the
alternative,
we're
basically
just
delaying
when
the
break
will
happen.
C
C
Approaches
are,
we
can
make
it
work
or
we
don't
care
we're
not
going
to
try
and
if
we
choose
with
we
may
we
can
make
it
work
solution.
Then
there
are
the
two
options
of
we
can
do
it
in
a
way
that
will
always
work
that
creates
clutter
or
we
can
do
it
in
a
way
that
might
not
work
if
you've
written
a
css
file,
and
so
I
still
think
we
have
to
choose
between
that.
We
don't
co,
we
don't.
C
D
I'm
just
kind
of
throwing
this
out
there,
but
it
would
be
my
preference.
This
is
so.
This
is
a
new
css
file
in
a
module.
It's
not
in
a
theme.
B
D
So,
basically,
so,
primarily
the
the
downside,
I
think,
is
just
that
we
have
more
files,
but
I
think,
as
far
as
at
a
run
time
like
someone
viewing
the
page,
we
aggregate
all
that
stuff
anyway.
D
A
Yeah
I
see
what
you're
saying
that
more
granular
css
files
has
some
benefit.
The
kind
of
iffy
thing
about
this,
though,
is
that,
as
far
as
a
component
is
concerned,
this
is
like
a
very,
very
small
piece,
because
it's
only
the
comment
title
which
you
would
normally
think
of
as
being
part
of
the
comment
component.
A
So
it's
not
like
a
new
component
css
file.
It's
unfortunately
affecting
a
different
component
with
a
separate
css
file
that
is
very,
very
small,
so
I'm
not
sure
that
the
benefit
is
is
split.
The
way
that
a
front-ender
would
really
appreciate,
because,
instead
of
if
you
want
to
theme
a
comment
now
you'd
either
remove
the
css
file
in
your
theme
and
put
it
all
in
comment.css
or
you'd
you'd
override
both
two
css
files
just
have
full
control
over
the
display
of
a
comment.
C
A
D
A
A
C
Yeah
so,
okay,
first
question:
do
we
want
to
care
and
try
and
make
this
work
for
any
site,
or
do
we
just
say
we
don't
care
we're
not
going
to
try,
because
that's
the
first
decision
of
do.
We
want
to
do
it
with
css
or
do
we
want
to
do
it.
B
And
I
feel,
like
I've
said
this
a
lot
of
times,
but
there's
an
argument
right
that
we
can't
expect
for
a
new
feature
to
work
in
all
themes,
but
I
just
want
to
be
really
clear
about
the
thing:
is
there's
going
to
be
a
button
in
core
that
a
user
can
click
and
nothing's
going
to
happen
right?
So
that's
different.
There
are
other
features
that
might
be
there
and
the
theme
doesn't
accommodate
them,
but
it's
not
so
obvious
right,
there's
not
like
a
button.
That's
clicked
and
nothing's
happening.
B
I
think
I
I
don't
know
of
other
examples
like
that,
but
anyways,
but
we
could
I
mean
my
feeling
is.
If
we
do
go
this
route,
I
want
to
think
about
a
subtle
way.
There's
been
some
opposition
to
this,
but
I'd
like
a
subtle
way
to
at
least
alert
people
why
that
might
not
be
working
as
opposed
to
just
having
it
not
work.
So
that
would
be
my
sort
of
intermediate
position.
A
Yeah
and
and
policy
wise
dan,
I
think
my
my
preference
there
is
like,
if
it's
possible
to
make
you
know,
add
a
new
feature
and
also
not
impact
existing
sites
and
have
that
new
feature
work
then
absolutely
that
should
be
the
way
that
that
we
go.
But
this
is
an
issue
in
which
achieving
that
is
not
straightforward
and
we
don't
actually
I
mean,
there's,
there's
substantial
downsides
or
maybe
not
substantial,
but
there
are
downsides
to
attempting
it
because
we're
like
creating
baggage
and
craft
well,.
C
C
Because,
right
now
the
pull
request
is
putting
in
a
separate
style
sheet
which
it
sounds
like
it's
not
preferable,
but
there
are
a
bunch
of
other
places
we
can
put
it
to
and
we
should
revisit
our
other
issue,
which
is
why
it
gets
more
complicated
for
how
to
make
css
changes
to
existing
sites.
So
we
have
this
conditional,
css
selector
option
that
I
think
is
currently
the
preferred
one
where
if
this
were
to
go
into
backdrop
23
we
would
get
123.
C
C
That
way,
any
site
before
123
wouldn't
be
affected.
Any
site
that
was
installed
before
123
might
not
be
affected.
We
have
another
question
to
answer
on
that
one,
but
it
does
also
then
say:
okay.
Well,
if
your
theme
has
over
in
the
css
file,
you're
not
going
to
get
the
feature
right,
because
the
only
going
to
go
into
the
core
css
file
and
then,
if
you've
chosen
to
configure
your
site
not
to
get
this
class.
C
A
Yeah,
I
I
think,
also
you're
interpreting
my.
We
want
to
try
as
a
different
level
of
effort
than
what
I'm
thinking,
because
what
I'm
looking
at
is
we've
already
tried
and
there
are
difficulties
about
making
it
work
in
existing
themes,
and
so,
although
that
would
be
preferred,
it's
not
easy,
and
so
we
should.
We.
A
C
C
A
Yeah
yep,
that's
exactly
what
I'm
saying
that
yeah
that
it's
it
we
want
to
try,
but
it's
not
a
requirement
and
we
tried
and
it
was
difficult.
So
therefore
we
should
say:
okay,
this
isn't
required
for
this
interesting.
C
C
A
Right
and
there's
lots
of,
I
mean
yeah.
I
I
I
think
that
I
mean
this
isn't
really
setting
precedent,
because
we've
done
this
sort
of
thing
in
the
past.
Already,
that's
it's
like
when
you
add
a
new
feature.
Sometimes
themes
need
to
put
in
extra
work
to
support
that
feature,
and
this.
C
C
B
The
difference
is
that,
while
it
may
not
support
old
themes,
it's
sort
of
obvious-
and
you
know
if
you
apply
that
theme-
it
just
doesn't
work
and
it's
obvious.
Okay.
This
theme
doesn't
work
with
that.
My
concern
is
that
as
a
user,
I
pick
a
theme
and
I
pick
core.
I
see
an
option,
I
click
on
it.
It
doesn't
work.
I
don't
know
that
the
theme
is
the
problem.
B
There's
no
way
for
me
to
know
that,
so
I
think
core
is
broken
and
I
spend
a
half
hour
trying
to
figure
out
why
this
thing
isn't
working,
because
I
I
don't
understand
that
the
theme
just
doesn't
support
it.
That's
that's
different
than
like
it
just
looking
bad
in
the
theme
and
me
realizing.
Oh
well,
I
can't
use
this
theme
with
that
thing.
So.
C
A
Yeah,
what
I
mean
this
this
is
getting
into
you
know
straight,
like
blue,
blue
sky
brainstorming,
possibly,
but
you
know,
theme
files.
Theme.Info
files
have
been
used.
It
could
be
used
to
identify
whether
or
not
they
support
certain
features
like
color
module
support
right,
but
I
don't
particularly
like
that
option,
because
we
would
need
to
default
it
to
not
support
it.
A
Hiding
comment
titles
when
I
think
what
should
happen
is
that
contrib
themes
should
go
back
and
add
support
for
it
and
if
we
hide
it
by
defaults,
then
instead
can
trip
themes
may
may
just
you
know
all
new
themes
moving
forward
would
not
have
that
option
on
by
default,
and
then
they
wouldn't
support
it.
Like
has
new
themes
come
out
which
is
not
not
ideal
either
right.
B
On
the
other
hand,
you
know
we've
a
number
of
committers
who
I
think
would
update
right,
but
there's
there's
some
themes
that
will
never
get
updated,
but
they're
also
probably
relatively
infrequently
used.
I
don't
know
you
can
look
at
the
list
and
judge
for
yourself,
but
I
included
a
list
in
there
of
all
the
themes
and
the
ones
with
the
little
x's
are
the
ones
that
will
be
affected
by
this.
They,
you
know
they
won't
work,
it's
most
of
them.
It's
like
two-thirds
of
them.
B
B
We
can
make
a
concerted
effort
to
try
and
get
everybody.
You
know
again
most
people
to
update
their
themes.
A
My
opinion
on
which
way
to
go
the
template
approach
would
be
preferred
for
me,
because
I
think
that
that
is
more
the
way
that
we
would
write
it
if
we
were
starting
without
any
concern
from
the
past,
and
I
think
you
know
we-
we
tried
to
address
it
and
we
acknowledged
the
cost
and
we've.
You
know
said
that
it's
acceptable.
B
B
We'll
try
to,
I
will
try
to
figure
out
some
steps
to
mitigate
the
impact
as
much
as
I
can
and
I'll
think
more
about
that
as
we
try
to
implement
it.
A
So
yeah,
you
know
here's
another
idea,
I
don't
know.
A
Potentially
you
know
like
the
info
file
to
like
designate
whether
or
not
a
theme
supports
a
certain
feature
or
not
that's
a
precedent.
It's
already
there,
rather
than
defaulting
all
new
themes
to
having
that
option
off,
we
could
default
it
to
being
on
and
if
a
theme
didn't
want
to
do
the
work
of
updating
its
template
files
or
didn't
want
to
have
that
feature,
then
it
could
specify
its
info
file
that
that
is
not
a
valid
option
for
it
and
updating
the
theme,
then,
would
be
adding
a
line
in
the
info
file.
C
C
B
B
Right,
which
I
I
kind
of,
haven't
considered
that
as
even
a
possibility,
but
I
think
that
half
the
themes
that
need
it
would
probably
get
this
fix
and
there
might
be
half
that
don't
the
fix
would
be
that
hard.
A
lot
of
those
are
unmaintained
themes,
so
if
we
could
just
go
in
and
fix
it
on
them,
then
then
that
would
mitigate
this
problem,
but
I
don't
know
what
the
policy
is
there
and
that's
the
kind
of
thing
we
want
to
get
into.
A
Yeah,
it
starts
getting
pretty.
I
think
that
would
get
really
pretty
difficult
pretty
quickly,
because
themes
are
all
about
the
aesthetic.
You
know
in
the
way
that
they
present
and
we'd
have
to
make
some
assumptions
about
when
this
like,
when
the
title
is
hidden.
What
does
it
look
like
yeah,
which.
B
Well,
yeah,
I
s
yeah,
I
suppose
that's
true,
although
yeah
I
mean
I,
I
think
it's
a
pretty
minor
aesthetic
decision
and
if
the
theme's
unsupported
it
would
be
better
to
fix
it
than
than
to
make
that
small
assumption
so
and
we
might
even
be
able
to
do
it.
You
know
we
I
mean
one
option
would
be
well
okay.
Maybe
your
option
is
just
to
make
it
clear
that
we're
not
supporting
it
in
that
theme
rather
than
trying
to
fix
it,
but
I'll
shut
up.
B
D
Some
of
I
am
not
volunteering.
B
D
D
A
C
A
Know
asking
the
theme:
do
you
support
this
or
not,
but
that's
a
I
don't
know
kind
of
an
interesting
thought
experiment
you
know
like.
Could
we
detect
if
a
theme
supported
it
or
not
and
then
automatically
adjust
the
field
based
on
what
it
appeared?
The
theme
supported
right.
D
Oh
yeah,
if
it
has
a
title,
template
or
a
css
file
with
a
particular
name
or
if
it
targets
a
css
class
with
a
particular
name
or
something
like
that.
Yeah.
B
A
Yeah,
that's
a
really
weird
precedent.
You
know
like
I.
I
really
don't
like
that
kind
of
magical
functionality.
Where
you
haven't
done
something
explicitly.
You
did
something
that
could
potentially
you
know
have
done
something
weird
like.
If
you
changed
your
variable
names
like
in
pre-process
or
pre-assembled,
stuff
and
pre-processed,
then
it
wouldn't
the
things
we're
looking
for
the
detection
wouldn't
be
what
we
thought
it
would
be.
I
could
see
that
going
wrong
pretty
easily.
A
Yeah
well
yeah,
I
think
I
think,
maybe
for
today
we
might.
You
know
close
that
discussion.
A
A
D
C
C
D
A
Okay,
yeah
maybe
requesting
steps
to
like
how
to
test
it.
It
does
have
test
coverage,
but
I
don't
know
sometimes
the
tests
get
written
and
the
tests
the
tests
pass,
because
they're
not
actually
testing
correctly.
So
that
is
a
possibility.
A
Is
jen
available
for
anybody
else?
She
kind
of
froze
on
me.
A
I'm
laughing
because
it
right
as
you
keep
explaining
it
keeps
freezing
yeah
you're
good.
Now
you
want
to
try
again.
C
I'm
gonna
read
an
issue,
a
common
issue,
but
putting
a
block
that
displays
a
field
from
the
node
authors
from
the
node
author
on
the
node.
Template
does
not
load
any
content
from
the
field,
so
it
could
be
a
field
problem
rather
than
a
context
problem,
but
it
does
load
that
data
from
the
currently
logged
in
user,
which
means.
A
C
C
A
Oh
okay,
maybe
I'm
wrong
about
that.
Okay!
Well,
yeah,
that
it
is,
it
should
be
working
after
that
pull
request
for
sure.
Okay!
Well,
let's
wrap
up
for
today
we're
at
the
top
of
the
hour
thanks
so
much
folks
for
being
here
and
the
good
discussion
about
you
know
compatibility
and
what
to
do
with
that
common
title
yeah.
I
hope
that
gives
us
a
way
forward.