This makes it so that all wiki pages' headings will have anchors and get
replaced with links to themselves. We'll probably need some styling
updates now, since having them look like large links isn't great.
Since every commit only affects a single file, this will make it much
easier to see what they're affecting (and stop users from needing to
include it manually).
Sometimes the database initialization fails, generally due to some
earlier step in the setup having an issue. Even if a re-provision
resolves that issue, the database init wouldn't be re-run since it was
set up to only happen after the database was created.
This changes it so that it will try to select from the users table, and
if that fails it will re-run the initialization.
This allows groups to have wiki pages. The rendered form of the page is
stored in the database, but the markdown source is kept on the
filesystem, using git to maintain the history (by doing a commit on
every edit).
A lot of aspects of this are still quite rough, but it should be a
decent start.
This is always weird when it wraps (especially on mobile, where it's
fairly common). You end up with weird cases like having "(500" after the
title and "words) on the next line.
This was too small - lists weren't really indented so they were a little
weird to read. The smaller margin for the nested ones is good though, so
this will leave that.
This is a bit risky because of potential conflicts with other routes
(like "~group_name/new_topic" if "new_topic" was a valid ID36), but it
was being used a little before so it's probably better to have
available.
This replaces all the Solarized colors that were still left in the white
theme (except in syntax-highlighting), and tries to improve some of the
contrast. It can probably still use some work, but should be better
overall.
Renames BleachContext to HTMLSanitizationContext, and simplifies the
default case a little by just allowing None as the context instead of
needing an explicit DEFAULT enum member.
We're using requests directly in some code now (scrapers), so it should
be in here instead of just coming in as a dependency of other packages.
This also seems to fix some issues related to the version of urllib3
that gets automatically installed.
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.
Deimos
Jerome Leclanche
deing
wirelyre
Petr Stastny
Jedi Burrell