Since we're adding a prefix to the Solarized theme's "value" and CSS
class, we need to convert old values so that people using a Solarized
theme don't lose their setting. This changes it in two places:
* The value of the "theme" cookie, using the tween we already have for
dealing with that cookie.
* The user's default theme setting in the database.
Since the site originally launched with only the Solarized themes,
they've always just been referred to internally as "light" and "dark".
This changes them to solarized-light and solarized-dark respectively.
Previously, the "theme cookie tween" was setting the theme cookie on
every single GET request, in order to make sure that the domain was set
on it so that it would be accessible from the Blog and Docs sites. We've
been doing this for a long time now though, and almost every cookie
should have been set properly now.
Now, this tween will only set the cookie when it's actually necessary -
when the user is logged-in and has a default theme, but doesn't already
have a theme cookie.
I'm going to make some changes to this tween, so the metric will help me
keep an eye on how often it's triggering, which should make it easier to
be sure the changes are working as expected.
Previously the posted/edited times of comments wrapped very poorly on
small screens. This improves it somewhat, making it so they won't wrap
"internally" but the edited time will go underneath the posted time.
More improvements are still needed, especially with the Link/Parent nav
links, but this is definitely better.
Previously, subgroups were always included in topic queries. This meant
that, for example, it was impossible to subscribe to ~tildes without
always also having ~tildes.official topics in your home page as well.
This change makes it so that the home page now only includes topics from
groups that the user is actually subscribed to. When visiting a group
individually it still includes the subgroups.
As part of deploying this, I'll want to automatically add subscriptions
for users that were subscribed to ~tildes but not ~tildes.official so
they don't see a behavior change (and that's the only current subgroup).
The button will only appear when:
* User has the "mark new comments" setting enabled
* User has the "collapse old comments automatically" setting disabled
* The current topic has some new comments
marshmallow 3.0 is now released, after being in RC stage for quite a
long time. Tildes's usage of it will require a bunch of updates, so I'm
just going to pin it to a 2.x version for now.
Previously the collapsed <details> would match the width of their
content, but this made them a little harder to recognize, and were
difficult to click on in (unusual) cases such as using a link as the
<summary>. Having them full-width like this should be fine with the
border, and fix those issues.
Previews for large wiki pages were failing because their maximum length
is a lot longer than comments'. Basing it on a specific markdown
"location" isn't ideal, but wiki pages will almost certainly always be
the longest, so it's probably fine.
If a user has topic visit-tracking enabled, this makes it so that the
comments link will jump directly to the comments section when returning
to a topic that they've visited previously. This is mostly useful with
long text topics so you don't always have to scroll past all the text.
It might also be good to apply this to the title link for text topics,
but I'm not sure if many people click on that with the bright "(x new)"
drawing their attention.
Most tables have a created_time column, so this will be usable on most
models and is more convenient and readable than always needing to
subtract from utc_now().
Having it in _base.scss was breaking the mobile layout because it ended
up affecting the text-topic excerpts. This should be safer, since it was
really only intended to affect the new <details> blocks possible inside
user text anyway.
This was previously being done a bit manually in the JS and HTML, but
CSS can handle it like this, which simplifies some things (and also
takes the +/- out of the DOM, which is probably good in this case).
Eventually it might be a good idea to have these link to lists of pages
inside each folder (or maybe fall back to that if an index page doesn't
exist), but this is good for now.
Not needed for much yet, but should be used here anyway to prevent
"new_page" pages from being created inside folders (which isn't possible
yet anyway).
The base Spectre.css style for tables only has borders between rows, but
that can look pretty weird in larger tables. This is more of a normal
table styling.
Deimos
Lugubris
Bauke
deing
Wes Cook
Josh Arrington