This fixes the issue with previewing empty markdown (though maybe we
should really prevent that), as well as making sure they don't get a
misleading obsolete preview if they lose internet or something similar.
Now that we have the Edit/Preview tabs, having another line of text
above that feels pretty excessive. There are still some awkward uses of
this though, and the field should probably have a <label> element
regardless, so this will likely need some revisiting.
Previously the styling was just based on the <header> element, but that
ends up inadvertently styling any other <header>s inside comments, which
we don't necessarily want.
Previously, the flattening was starting at a very low threshold (above
depth 4) on all screen sizes. This changes it to be responsive, where
larger screens (generally) won't flatten until higher depth levels. On
desktop-size resolutions, it will probably be extremely rare to ever see
any flattened threads, since it will only happen at depth 20+.
These thresholds were picked pretty arbitrarily, but seemed decent from
some testing. I also kept the indentation size smaller until a larger
screen size, since the sidebar's appearance actually reduces the comment
tree space by a lot, and the indents are excessive until the screen is
quite large.
So far the most confusing aspect of the flattened single replies is when
there are sibling comments on the same level. For example, if a comment
has 2 replies (A and B) and A has one reply (C), the flattening would
put all of A, B, and C on the same indentation level as A C B. This was
confusing and made it hard to recognize where a subtree ended and it
went back to sibling comments.
This change makes it so that the flattening will only happen when there
are no siblings. This will reduce how often the flattening is applicable
somewhat, but also eliminates this confusing case entirely.
At the "bottom" of the common topic tags list, there can be a large
number of tags that all have the same usage count, with the cutoff being
somewhere in the middle of the list. For example, the list for a group
might be cutting off in the middle of "tags that have been used 5
times". Previously, it was more or less random which tags in that set
would be excluded or excluded - this changes it so that the ones used
most recently will be given preference.
Since tags are all lowercase, no suggestions would be found if the user
typed in any uppercase letters. This converts to lowercase and fixes
that issue.
Previously, the autocompleting tag input would only actually submit the
tags that had been converted to "chips". This meant that if the user had
a "leftover" tag that they had typed in but not actually converted to a
chip (by typing a comma or using the autocomplete dropdown), it would be
lost when they submitted the form.
This appends it to the tags before submitting, so that it's not lost.
A user with JS disabled can submit new topics, but the autocomplete
behavior was making it so that their tags were lost, because the "real"
tags input was a hidden one that was only updated by JS.
This starts the original (visible) input out as the tags one, and has
the JS move it over to the hidden one, so it will only happen if they
have JS enabled.
This applies the new stored/updated lists of common tags for each group
to the topic-tagging form, both for new submissions as well as editing
the tags on an existing one.
This sets up a cronjob that will run every hour to select the most
common tags used in a group (up to 100), and store them in a new column
in the groups table. This will be used to populate the list of tags to
use for autocompletion.
eeldam is smarter than me and realized that there's a way easier way to
select the same comments without needing to chain all those :not()s - we
can just select all comments with a single reply that are nested inside
one with a minimum depth.
This commit changes the selector to use that new simplified method, as
well as moving the whole mess into a mixin, which can be re-used when we
want to start applying this at different depths on different screen
sizes.
In topic listings, when a link topic is from YouTube or Twitter, this
will now display more info about the "source" instead of just the
domain. For YouTube, the channel name is displayed, and for Twitter, the
author of the tweet is displayed.
In (very rare) cases where a topic's excerpt is made up of a long string
that doesn't wrap, it could end up pushing the topic voting button to
the right and making it inaccessible. This should fix those cases.
Lately there have been multiple "exemplary fights", where people are
using the Exemplary label to highlight and boost comments that they
especially agree with, even if the comments themselves aren't especially
good.
I think the prominence of the Exemplary badge and the count of how many
Exemplary labels a comment has received are contributing to this. This
was only made visible somewhat recently (9b64d22d), so I'm going to try
removing it again now. There should probably be a page added to Docs
explaining the different "stripe" colors, since the Exemplary stripe is
now unexplained and not obvious.
This was mostly motivated by a hope that this will help with the
mysterious iOS 12 bug that's causing topic listings to behave strangely
when the user tries to tap on the comments link (space gets added and
the link moves down).
The main change here is to add a new .topic-with-excerpt class, and only
add the "content" area to the CSS grid when that class is present,
instead of always adding it and just leaving it empty if the topic has
no excerpt.
In addition, this switches to using grid-gap to space out the rows
instead of margins, and center-aligns the row contents vertically on
mobile, where we want them spaced out a little to help avoid misclicks.
This redirect being first in the file meant that if someone tried to
access a dev version through any method except using "localhost" (such
as via the IP address), no server block would be matched, which causes
nginx to use the first one. That resulted in a 301 redirect to
tildes.net, which definitely shouldn't happen for a dev version.
This change both moves the redirect to the bottom, as well as only
adding it if it's the "prod" environment, since it's not needed in the
dev environment at all.
For some reason, when a topic in a listing can't be voted on (either
your own topics or the viewer is logged-out), CSS grid was adding some
space for the "content" area where the excerpt is shown, even when there
is no excerpt.
This switches to using minmax() to allow that row's height to shrink
down to zero, which fixes the spacing.
mypy version 0.700 includes some stubs for the bleach library, but
they're not correct and cause errors when run on the Tildes codebase.
I've left a comment on the typeshed repo here, so hopefully it will be
resolved before long:
https://github.com/python/typeshed/pull/2709#issuecomment-483120729
I'll pin mypy's version to the previous version of 0.670 for now to
avoid this, but if the stubs aren't fixed for a while I may need to do
it differently.
Starting with psycopg2 version 2.8, the package on pypi no longer
contains a binary version and must be compiled from source. These two
packages are required for this to be possible.
It would have been simpler to just switch to the psycopg2-binary
package, however that isn't a very good solution overall since many
other packages treat "psycopg2" as the dependency that they want
installed, not "psycopg2-binary". Overall, this situation is pretty
messy and I'm not sure what will end up being the final state, but this
should work for now.
More info about the source-only change:
http://initd.org/psycopg/articles/2018/02/08/psycopg-274-released/
The UPDATE query that marks notifications read due to interaction was
causing a flush, so if the user repeated an interaction (such as trying
to vote again on a comment they had already voted on), the autoflush
would cause an IntegrityError when it tried to re-insert the vote.
This moves the UPDATE into a block with autoflush disabled, and also
just moves the interaction-marking into its own function instead of
having so many duplications of its logic.
A few minor interface improvements for topic tag filters - mostly just
changing to the settings page defining them in a textarea, with one per
line. Previously this was just a text input with the tags
comma-separated, which got unwieldy very quickly.
This reduces the size and spacing of some of the elements of a topic in
topic listings on small screens, and should make information display
better overall.
These buttons were basically icons, and it's better to have them with
text labels like this. Their left border was also disappearing at
smaller screen sizes due to re-using the .btn-comment-collapse style, so
it's better to do a separate style for "light buttons" like this, and
keep that behavior specifically to the actual comment collapse buttons.
When someone posts a new topic, this will automatically remove any tag
that matches the group name. So for example, if the topic is being
posted in ~music, a tag of "music" will be removed.
If there turns out to be some edge case where this is important, it can
be re-added through the tag editing interface, since this only applies
when posting a new topic.
When a user interacts with a comment (by voting, replying, labeling, or
bookmarking), any unread notifications they have from that comment will
now be marked as read.
This behavior is on by default, but can be disabled in Settings if the
user would rather mark all notifications read manually.
Unfortunately, right now Chrome only supports "pixelated", and Firefox
only supports "crisp-edges", so this should give the best result across
browsers.
Deimos
wirelyre
Petr Stastny
Jedi Burrell
Shane Moore
Chad Birch
Benjamin Lowry