►
From YouTube: Backdrop Weekly - Nov 26th, 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).
C
My
camera's
off
australia.
A
All
right
we
are
live
today
is
november
27th,
which
here
in
the
united
states,
is
thanksgiving.
So
we
are
expecting
a
lower
than
usual
turnout,
but
we
will
continue
as
normal.
I'm
gonna
go
ahead
and
start
introductions.
I
am
jen
lampton.
I
am
joining
from
oakland
california,
in
close
proximity
to
my
kitchen,
so
I
can
rescue
the
pies
when
the
alarm
goes
off,
but
that's
it
luke.
Do
you
want
to
go
next.
E
I'm
at
nate
lampton
in
oakland,
california
and
yeah.
We've
got
some
interesting
things
that
have
been
happening
this
past
week
regarding
the
security
release
and
php.
So
I'm
looking
forward
to
talking
about
those
things
today,
peter.
A
That's
great,
so
speaking
of
yesterday's,
oh
well,
okay,
before
we
get
there
since
our
last
meeting
last
week,
we've
had
three
new
contributed
modules,
released
term
reference
view,
unpublished
and
login
allow
list.
So
I
want
to
continue
to
thank
our
contributors
for
making
more
modules
for
us,
which
is
great,
and
we
did
a
security
release
yesterday
and
we
finally
got
all
of
our
sites
updated,
including
the
localized
website,
which
is
something
that
we
almost
always
forgot,
and
I
was
very
excited
that
we
remembered
it
yesterday
and
even
added
it
to
the
documentation.
A
So
we
remember
it
from
now
on,
so
that
was
the
only
thing
going
on,
I
think
with
our
websites
but
nate.
Let
me
turn
over
you
to
talk
about
releases.
E
Yeah
so
backdrop
117.4
was
released
yesterday
as
peter
said,
that
was
a
security
release
and
it
was
released
very
late
for
which,
if
you
are
a
site
owner,
I
sympathize
and
I
I
think
it's
fair
to
apologize.
E
I
apologize
that
we
had
to
release
that
yesterday,
the
day
before
holiday.
In
the
united
states,
we
were
coordinating
with
drupal,
who
was
what
who
was
coordinating
with
a
third-party
library,
the
tar
tar,
tar
archive
library.
So
there's
an
upstream
fix
in
that
library,
which
drupal
then
deployed
that
then
we
also
deployed
just
to
be
in
sync
with
everybody.
E
So
the
new
version
came
out
yesterday.
It
did
include
a
couple
of
minor
fixes,
but
for
the
most
part
it
was
just
the
security
release.
116.6
also
came
out
if
you're
running
the
previous
version
of
backdrop.
That
also
includes
that
fix
and
yeah
it
was.
I
was
excited
to
have
that
release
put
together,
because
I
didn't
have
to
do
any
of
the
tasks.
E
Bw
panda
took
all
of
the
core
committer
tasks
and
made
both
of
the
minor
releases
or
bug
fix
releases.
Jen
was
primarily
doing
the
coordination,
but
that
was
really
great
to
be
able
to
stand
by
and
have
another
core
committer
run
the
entire
process
of
making,
not
one
but
two
releases.
So
thanks
peter
for
your
volunteering
there
and
great
job
putting
those
things
together.
Yesterday.
E
Let's
see
117.5
so
since
we
released
1174
yesterday
that
security
fix
everything
got
bumped
over
to
117
that
outstanding,
bugs
that
that
we're
working
on
getting
fixed
one
of
the
notable
issues
that
we've
had
since
117
2
was
released.
That's
where
we
added
support
for
mysql8
is
that
civicrm's
views
integration
broke
with
that
change.
E
E
So
you
can
do
kind
of
a
little
hack
in
settings.php
and
you've
been
able
to
do
this
in
every
version
of
drupal
that
I
can
recall
that
you
could
use
a
database
name
in
your
table
prefixes,
and
it
would
basically
make
it
so
you
would
use
multiple
databases
on
a
single
install
of
backdrop,
and
so
civi
crm
is
dependent
upon
that
to
switch
between
the
civic
crm
database
and
the
backdrop
database,
and
that
kind
of
sharding
no
longer
works
after
the
the
mysql8
support.
E
So
there
is
a
a
workaround
that
is
in
the
issue.
You
can
add
back
text
to
your
table
prefixes
and
then,
and
then
it
works.
E
So
there
is
a
little
bit
of
a
workaround
but
we'd
like
that
not
to
be
necessary.
So
the
the
approaches
that
we
have
there
there
is
a
pull
request,
but
it
needs
work.
There's
various
suggestions
about
how
we
could
solve
this
drupal
7
still
doesn't
have
my
sequel
8
support
they
haven't
committed
to
their
equivalent
patch
yet,
but
it
is
suggested
that
perhaps
we
take
that
approach.
The
drupal
7
patch
is
a
bit
more
conservative,
yet
more
tedious
to
maintain
than
the
the
backdrop
approach
in
backdrop.
E
We
just
tried
to
add
backticks
around
to
all
table
names
everywhere
and
drupal
7
is
making
a
white
list.
Sorry
an
allow
list
of
words
that
need
to
be
escaped,
but
that
list
is
really
long.
It's
like
over
a
hundred
words
and
so
maintaining
that
seems
like
it
would
be
tedious.
E
As
my
sequel
changes
in
the
future,
we
need
to
continue
adding
different
words
to
the
allow
list
so
kind
of
an
annoying
change
that
it
would
be
nice
not
to
need
to
do
that,
but
any
ideas,
if
anybody's
out
there
for
solving
this
problem
of
escaping
table
names
that
issue
47.45
currently
needs
some
brainstorming
as
to
how
we
can
best
solve
that
problem.
E
Let's
see
next
up
adding
support
for
php8
joseph
made
an
issue
for
this
just
a
couple
of
days
ago.
The
issue
is
47.72
highly
relevant,
because
today,
php
8
was
released
and
so
brand
new
version
of
php
out
there.
E
It
looks
like
generally
php
8
doesn't
have
too
big
of
a
compatibility
issues
with
previous
versions,
but
definitely
some
changes
are
necessary,
but
does
look
like
so
far
that
any
changes
that
we're
required
to
make
are
largely
backwards
compatible,
so
same
sort
of
thing
that
just
they
they
tighten
the
bolts
down
a
little
bit
again
as
to
things
that
you
probably
shouldn't
have
been
doing,
you're
not
allowed
to
do
anymore.
So
so
we
need
a
pull
request
for
that.
E
We
haven't
even
really
started
it
other
than
saying
it
would
be
nice
to
have
this.
Several
people,
including
myself,
are
dependent
upon
lando
for
doing
their
backdrop,
testing
and
lando
doesn't
have
php
8
support
yet
so
we
have
a
little
bit
of
a
chain
of
events
there
that
for
some
people
they
might
need
their
upstream
environments
to
be
updated
so
that
they
can
easily
test
that
system.
B
E
E
All
right,
so,
let's
see
other
issues
that
we
have
here
that
are
relatively
new
fixing
field
set.
Css
collapsible
field
set
css
in
particular
issue,
4766,
a
recent
version
of
backdrop.
I
can't
remember
if
it
was
117.2
or
117.3.
E
We
added
some
changes
to
the
styling
on
field
sets
to
make
them
work
better
on
mobile,
and
we
have
a
couple
of
regressions
that
propped
up
from
that.
We
already
made
one
fix
to
it
and
that
fix
was
in
117
4.
but
or
sorry
117
3.
I
guess,
but
there's
still
yet
more
issues,
there's
a
very
minor
one
that
sometimes
the
bottom
border
of
things
is
missing.
On
field
sets
so
issue.
4766
covers
that
there's
multiple
screenshots,
demonstrating
what
the
problem
looks
like
and
where
it
occurs.
E
E
Let's
see
something
got
fixed
this
week,
missing
hd
access
rules
for
php,
7
issue,
47
52.
We
add
certain
rules
in
htaccess
to
configure
php
set
some
variables
that
otherwise.
E
You
have
to
set
them
before.
Php
actually
starts
executing,
so
we
had
some
settings
that
were
specifically
set
for
if
running
php
is
php5,
we
added
matching
rules
for
php7
in
the
very
near
future.
I
suppose
we'll
probably
have
to
do
the
same
for
php8.
E
Let's
see
next
up
is
setting
a
reasonable
max
input.
Vars
a
php
variable
issue,
38
24.
That
issue
currently
needs
work.
Jen
you've
been
doing
a
lot
of
work
on
that
issue.
Do
you
have
anything
that
you'd
like
to
add
about
it.
A
E
Yeah
and
what
that
does
is,
doesn't
it
throw
a
warning
or
something
like
that
when
you're
on
a
form
that
you
try
to
submit
yeah.
A
So
when
you're
on
a
form,
it'll
count
the
number
of
form
element
children
and
if
that
number
is
within
five
percent
of
your
max
input,
bar's
value
it'll
put
a
yellow
error
message
on
the
form
that
says
this
form
isn't
going
to
work
properly.
Please
do
whatever
and
then
links
you
to
the
documentation
page
and
then,
if
you
submit
the
form,
it
throws
a
red
error
message
saying
this
form
has
not
submitted
properly
and
it
logs
it
to
watchdog
that
there
was
a
problem
with
the
form.
A
The
way
that
web
form
did
it
was
very
complicated
and
probably
accurate,
and
I
imagine
that
that
would
have
some
overhead
the
way
I
did
it
was
not
accurate,
and
so
it
probably
had
less
overhead.
So
I'm
not
really
sure
how
much
we
want
to
worry
about
that.
A
It
did
look
pretty
extensively
at
the
form
api
and
there
are
some
other
points
in
the
form
build
process
where
we
might
already
have
that
number
that
we
could
be
a
little
smarter
about
it
or
if
we
like
stored
that
in
like
a
static,
cache
or
something
and
then
retrieved
it
at
the
point
where
we
want
to
set
the
message,
we
wouldn't
have
to
count
everything
twice,
but
I
decided
that
I
wasn't
gonna
start
doing
that
until
we
were
sure
we
wanted
this
solution
so
yeah
there.
A
There
are
potential
places
for
cleanup
on
performance
side
of
things.
E
Great
and
so
the
thinking
there
is
that,
instead
of
adding
a
an
error
or
warning
on
the
status
report
that
we
just
have,
that
message,
so
is
that
right.
A
Yeah,
it
seems
like
most
people
don't
want
to
know
about
the
problem
until
it
happens,
rather
than
being
able
to
prevent
it
from
happening,
which
seems
a
little
weird
to
me.
We
are
able
to
set
the
value
for
limited
cases
like
when
you
have
mod
php
for
php,
5
or
php
7
and
you're
on
apache.
That
problem
has
been
solved
because
we've
set
it
in
htaccess,
but
when
we're
not
able
to
do
those
things,
we
are
not.
A
What
I
think
we
should
do
is
tell
people
like
hey
backdrop,
isn't
configured
properly
because
of
their
server
configuration
or
whatever
and
let
them
fix
it.
But
it
looks
like
everybody
wants
to
say:
let
the
site
fail
and
then,
after
it
fails,
we'll
be
able
to
tell
them
why
it
failed.
So
I
don't
know
it's
still.
Labeled
needs
for
feedback,
but
it
does
look
like
most.
People
would
rather
have
the
failure
than
prevent
it.
So
that's
what
we
want
to
do
is
fine.
C
I
think
it's
not
so
much
that
we
wanted
it
to
fail
it
small,
as
if
people
didn't
want
to
have
a
warning
in
the
status
report
page.
That
is
always
there
that
if
they
choose
not
like
to
ignore
it
or
that's,
not
an
issue
for
their
particular
site,
they
just
didn't
want
this
constant,
yellow
warning
there.
All
the
time.
A
Yeah,
I
don't
think
that's
an
issue
I
mean
if
you
choose
to
like
run
the
wrong
php
version
or
something
you
could
probably
also
get
away
with
it,
but
I
still
think
that
it's
important
that
people
know
that
they're
running
the
wrong
php
version
so
yeah
I
don't
know
it
would
be
good
if
we
could
get
more
voices
on
that
too.
I
don't
know
how
many
people
have
looked
at
it
other
than
people
that
are
already
on
it,
but
I
would
like
to.
B
A
B
A
We
only
have
a
couple
of
statuses
for
that
message
like
it
could
be
an
info
message
which
is
not
like
just
like
you
know
what
version
of
ck
editor.
Are
you
running
or
something
it'll
just
print
on
the
page,
and
then
we
have
an
error
which
would
throw
a
red
dot
on
your
site.
That's
like
hey.
Your
server
is
misconfigured,
please
fix
it
now,
which
everybody
thought
was
too
harsh,
and
so
the
compromise
was
like.
Well
what
if
we
made
it
a
warning,
but
now
it's
a
yellow
error.
A
So
it's
not
going
to
bother
anyone
unless
you're
on
the
status
report,
but
on
the
status
report
it
is
still
yellow
and
so
a
lot
of
people
are
uncomfortable
with
the
fact
that
their
site
will
have
a
yellow
error
on
it
if
it's
not
configured
properly,
but
I
don't
know
what
the
other
circumstances
are
for
the
yellow
errors
showing
up
there
and
how
people
are
feeling
about
that.
A
I
know
we
do
one
for
like
if
you
choose
not
to
set
your
domain
name
in
the
settings.php
file,
to
prevent
it
from
having
like
cross-site
origin,
request,
forgeries
or
something
it'll,
throw
a
yellow
error
there,
and
I
know
a
lot
of
people
are
comfortable
with
saying,
like
I'm,
accepting
the
security
risks
and
I'm
gonna
leave
that
yellow
warning
there,
and
I
feel
like
this
is
comparable,
maybe
even
more
dangerous
than
that,
because,
if
you're
comfortable
with
allowing
this
problem
on
your
site,
you're,
basically
saying
at
some
point
someone's
going
to
submit
a
form
and
it's
not
going
to
work
and
I'm
okay
with
that
and
that's
different
than
like
a
choice.
A
You've
specifically
made
to
not,
I
don't
know
so
it
would
be
good
to
to
figure
out
how
we
want
to
handle
this.
Another
thing
we
could
do
and
it's
a
little
bit
more
complicated-
is
that
we
could
trigger
the
warning
at
the
first
failure
and
or
even
make
it
an
error
at
that
point
right
where,
if
your
site
is
humming
along
perfectly
fine
with
the
misconfiguration
until
some,
I
don't
know,
form
gets
a
number
certain
number
of
elements
on
or
whatever
you
made
a
big
web
form.
A
At
that
point,
we
know
your
site's
failed
and
it
could
be
a
red
dot.
That's
like
hey
something's
wrong,
and
if
we
didn't
do
anything
until
there
I
mean
I
think
it
would
be
okay,
I
don't
know.
I
just
feel
like
for
people
who
are
building
sites
and
know
that
this
is
a
problem.
It's
super
frustrating
to
be
like.
Why,
like
you,
have
why.
A
A
E
I
was
gonna
say
well.
Some
of
the
good
news
is:
is
that
the
missing
hd
access
rules
for
php,
seven
that
issue
that
I
just
mentioned
before
this
one
42,
it's
like
47.52-
does
actually
increase
the
max
input
vars
in
hd
access.
If
it
can
so
this
issue,
3824
is
really
not
about
setting
the
max
input
vars,
because
we're
already
doing
that
now
it's
about
reporting,
if
it's
not
high
enough,
so
we
should
probably
just
retitle
that
issue
but
yeah
how
we
handle
it.
E
E
118
118
is
the
next
version
of
backdrop
that
will
be
coming
out
january,
15th
with
feature
freeze
on
january
1st.
That
means
that
you
know
we've
got
about
a
month
before
feature
freeze
for
118
rolls
around.
E
Let's
see,
normally
we
would
have
advocates
talk
about
each
one
of
their
issues.
There
aren't
a
whole
lot
of
people
here
this
week
because
of
the
holiday,
although
indigo
zella
did
say
that
the
web
p
support
issue
issue.
4509
is
still
in
the
same
state
that
it
needs
code
review,
but
it
has
gotten
some
good
positive
testing,
and
so
we
still
need
somebody
to
move
that
one
into
an
rtbc
state
if
they
believe
that
it's
ready
to
go.
E
C
So
previously,
there's
a
poor
request
that
needs
review
and
testing
indigo
zella
tested
it
and
says
it
works
for
her
and
then
greg
came
in
with
a
few
suggestions,
and
this
is
where
we
need
some
feedback
from
other
people
as
to
how
we
want
to
do
this.
So
the
pull
request
adds
a
new
field,
min
width
where
you
can
specify
the
the
width
like
media
query
width
at
which
the
menu
changes
to
a
hamburger,
pop-up
thingy.
C
Greg
suggested,
changing
it
to
two
separate
fields,
one
for
the
integer
value
and
then
one
as
a
drop
down
to
select
pixels
or
ems
or
whatever
a
few
of
us
thought
that
might
be
a
bit
too
complex,
but
we're
wanting
feedback
from
others
as
to
whether
that
would
be
better
or
not.
From
a
usability
point
of
view.
I
guess
so
that's
one
thing:
we
need
feedback
on
the
other.
One
is.
C
On
the,
where
we
have
the
existing
check
box
to
make
a
the
hamburger
menu
appear
on
small
screens,
someone
suggested
it
might
be
good
to
have
a
link
to
the
menu
settings
where
you
can
set
that
breakpoint.
C
So
we
added
in
the
description
text
a
link
to
the
menu
settings
page,
but
then
people
worked
out
that
you
can't
access
that
unless
you
have
a
certain
permission,
so
then
we
tried
to
wrap
that
link
in
a
permission
so
that,
if
you
have
the
permission,
you
can
see
the
link
and
if
you
don't
have
the
permission,
the
text
is
still
there
telling
you
that
this
can
be
configured.
But
you
then
just
need
to
ask
whoever's
managing
your
site
to
give
you
permission
or
to
change
it
or
whatever.
C
However,
the
code
like
the
translation
code
and
putting
the
link
in
there
conditionally,
based
on
whether
permission
or
not,
is
a
bit
yucky,
so
greg
tried
to
suggest
a
way
to
make
it
a
bit
cleaner
code.
But
that
means
that
that
whole
sentence
is
removed.
If
you
don't
have
the
right
permission,
which
means
you
don't
actually
get
to
see
that
that's
an
option.
C
So
again,
we're
just
wanting
feedback
there
as
to
how
to
make
that
cleaner
code,
if
possible,
but
also
still
allowing
or
do
we
need
to
allow
people
to
see
a
link
if
they
can't
access
it.
That
sort
of
thing
so
a
few
issues
there
we
want
feedback
on,
but
otherwise
the
other
pull
request
still
just
needing
people
to
test
it
make
sure
it
doesn't
freak
anything.
E
All
right
great,
that
is
a
kind
of
it.
We
also
have
these
other
issues,
but
we're
not
gonna
go
over
them
today.
We're
taking
a
holiday
and
initiatives,
documentation,
telemetry
and
ready
to
wear
luke
said
he's
okay,
passing
on
that
today.
So
is
there
anything
else?
I
guess
you
know.
I
think
that
this
kind
of
what
we
had
discussed
is
you
know
what
it
was
we're
going
to
cover
today.
Keep
it
kind
of
short.
Do
you
guys
have
anything
you
guys
like
to
bring
up.
B
I
have
a
a
major
feature
request.
I
thought
of
this.
This
week,
I've
I've
been
working
with,
with
tim,
on
on
simplo,
putting
up
one
of
my
sites
and
and
and
doing
more
more
complicated
things
involving
configuration
management
than
I've
done
in
the
past,
and
I
I
find
myself
desperately
wishing
that
backup
and
migrate
handled
configure.
You
know
cmi
stuff
as
well,
so
I'm
I'm
just
kind
of
curious
like
has
that
come
up?
Should
I
try
to
write
that?
Is
it
hard?
Is
it
doable.
A
Is
it
a
thing
also
wish
for
that?
I
don't
think
it's
hard,
because
we
already
have
the
ui
for
configuration
management.
We
just
need
to
trigger
those
same
events
from
the
backup
and
migrate,
pin
chip
module
so.
E
Yeah
conceptually
it's
pretty
simple,
I
mean
there's
just
json
files
that
should
go
along
with
the
database
dump
right.
It
might
be
a
little
bit
weird.
I'm
sure,
backup
and
migrate
does
a
lot
of
weird
things
because,
like
you
know,
overwriting
the
database
is
that
you
probably
have
to
go
outside
of
backdrops
apis
to
do
a
lot
of
that
stuff,
and
I
think
that
would
be
the
same
for
configuration
that
you
wouldn't
want
to
trigger
the
normal.
E
E
I
don't
think
that
it's
difficult
it
just
needs
to
go,
but
it
probably
will
need
to
work
outside
of
backdrops
normal
apis
because
you'll,
you
won't
want
to
actually
run
a
config
sync
you'll
just
want
to
replace
all
of
the
files
because
it
already
matches
the
database
but
yeah.
I
don't
think
that's
hard.
An
alternative
to
that,
of
course,
is
there's
also
an
open
issue
that
moves
configuration
into
the
database,
and
that
would
also
make
it
so
that
you
know
there
wouldn't
be
any
config
files
to
move.
B
I
I
I
just
didn't
know
if
it
was,
you
know
where
it
was
and
like
oh
yeah,
you
know
you
know
half
the
time.
I
asked
a
question
like
that.
The
answer
is
we
released
that
in
2017
and
I'm
like,
oh
okay,
so
so
that
that's
definitely
a
a
thing
that
could
be
done
all
right.
Sure
enough!
That's
that's
all
I
need
at
this
point
then.
E
Yeah,
I
think,
for
some
people.
I
know
the
way
that
we
manage
backdrop
cms.org
and
our
little
family
of
backdrop
sites
there
is
that
configuration
is
all
stored
in
git,
and
so
it's
not
really
quite
as
important,
I
think
for
us
but
yeah.
Well.
We
also
have
backups
automated
so
yeah.
It's
we're
in
a
little
bit
of
a
different
world
over
there,
but
yeah.
I
think
maybe
it's
one
of
these
things.
It's
like
the
the
value
is
greater
for
end
users.
E
Those
who
use
backup
and
migrate
than
it
is
for
you
know
the
the
a
little
bit
the
more
experienced
developers
who
have
other
systems
that
provide
their
backups
and
configuration
backups
and
all
of
that
stuff.
B
Yeah,
well
I
mean
I
just
in
the
past
I've
I've
discovered,
you
know
like
I've
been
in
situations
where,
where
faculty
migrate
is
used
as
a
version
control
system
fairly
fairly
aggressively
to
handle
all
sorts
of
things
that
wasn't
really
intended
to
and
and
it's
handled
it
well
enough
that
that's
that's
what
some
fairly
substantial
projects
I've
seen
and
worked
on
so
so
that
would
seem
seem
worthwhile
to
explore
that
as
an
option.
E
Yeah,
if
I'm
not
mistaken,
I
I
do
believe
that
you
know
backup
and
migrate
is
the
most
popular
backdrop
module
it's
installed,
apparently
on
just
about
half
of
all
backdrop
sites.
So
there
you
go.
It's
a
high
impact
place
to
make
contributions.
E
Yeah,
okay,
well,
anything
else.
C
Some
yeah
things
to
bring
up
some
things
have
been
getting
a
bit
of
discussion
lately
and
I
think
something
that
we
need
to
make
a
decision
on.
Hopefully
sooner
than
later,
is
the
whole
changing
css.
C
Non-Breaking
backwards
compatible
way,
sort
of
thing,
so
there's
an
issue
about
it,
which
we've
discussed
lots
of
options
and
then
tim
opened
an
issue
in
the
different
issue
queue.
I
think,
yeah
backdrop
cms.org
issue
queue
just
more
like
an
overview
of
how
we're
going
to
make
this
decision,
whether
we
take
it
to
the
pmc
or
leave
people
to
discuss
a
bit
longer
or
whatever,
but
yeah.
I
just
think
that
might
be
good
to
just
mention
and
get
either
more
feedback
on
or
just
make
a
decision.
C
So
we
can
move
on
because
it
sort
of
seems
to
be
holding
up
a
lot
of
issues,
not
knowing
how
best
to
add
or
change
css
in
core.
A
A
C
I
think
maybe
we
just
need
to
send
it
up
to
the
pmc
to
make
a
decision
on
what
do
we
believe
in
terms
of
backward
combility
compatibility
regarding
this
issue
and
then
how
do
we
address
it?
And
then
other
issues
can
sort
of
move
forward
a
bit
more
but
yeah.
It
seems
like
we're
just
currently
like
a
standstill
of
like
no
new
ideas
coming
forward
and
people
gridlocked
as
to
what
the
best
course
of
action.
E
Is
okay?
Well,
let's
wrap
it
up.
It
is
almost
turkey
time
here
in
california,
so
we're
going
to
can
we're
going
to
close
up
for
today
I
think
and
go
and
enjoy
our
thanksgivings
hope
everybody
out.
There
has
a
great
holiday
if
it's
a
holiday
and
if
not,
I
hope,
it's
a
great
thursday
and
or
friday.
I
guess
peter
sorry
and
yeah
thanks
and
we'll
see
you
guys
again
next
week
and
we'll
see
you
guys
on
the
internet
in
this
uq.