Previously, Markdown ordered lists in user content (in posts,
comments, previews, etc) would display like this:
1.
Foo bar baz.
This is because sanitize populates them as <li><p>Foo bar baz.</p></li>
Rather than mess with the Markdown engine and still not have backwards
compatibility, this has been solved in the frontend using CSS to force
the <p> to display inline.
Draft posts have already been excluded from the edit time limit for
obvious reasons--drafts are intended to be edited, and people use them
as personal megathreads on their profiles. Largely for the latter
use case, this commit also excludes comments on drafts from the limit.
The original artist of the new loading animation provided a version
with one changed frame and a slower animation speed. Further, this
was scaled and compressed to about half the weight of the original
implementation.
This change is sufficiently minor that it's not worth cache-busting
for the minority of users who will have already cached the prior,
especially given it leaks into markup.
Previously, cli.py ran in <repo-root>/files. However, our relative
paths assume the working directory is <repo-root>. This resulted in
sanitize.render_emoji L153 to improperly return false when checking
for the presence of 'files/assets/images/emojis/{emoji}.webp',
leading to emojis in notifications sent by cli.py-invoked tasks to
not be rendered to HTML.
This bug was discovered when lottery.check_if_end_lottery_task was
failing due to a stack trace thru end_lottery session < badge_grant
< send_repeatable_notifications < sanitize L208. In particular, when
`flask cron` (helpers/cron.py) executes, it does not set g.v, whereas
this code previously assumed that g.v : (None + User) and did not
check for its presence.