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.
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.
Deimos
Jerome Leclanche
deing
wirelyre
Petr Stastny
Jedi Burrell