| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Broken in 8a8593e91e5252a24fdfa7d46c28134668ab7c9c
Oops.
|
|
This work is to support a safe self-service account deletion feature,
but I haven't implemented that part yet.
|
|
Tried some malicious multiline inputs, wasn't a big issue given that
HTML doesn't render newlines, but could still be surprising in some
places.
|
|
See TUWF commit fd3d2ca6a18222dafaa13dbcb7a6ccce1c4d9e6e
Fixes https://vndb.org/t2520.822 and a few related bugs.
(I may have introduced a few new bugs with this, let's see...)
|
|
|
|
Another bug found by the JS error logger \o/
Turns out numeric element IDs are kind of icky. They were disallowed in
HTML4, then allowed in HTML5 but still not supported in CSS selectors.
So let's just give them a little prefix to make sure it'll work.
|
|
Previous solution relied on negative margins more than I liked. This
solution is still surprisingly fiddly.
This requires TUWF commit 4b0e2df89fe180bfa2f3da195a80684a46a649db
|
|
Hopefully without breaking anything.
Switched to using flexbox for the homepage boxes instead of grid, in
order to fix an overflow issue on Pale Moon. But I later fixed a similar
issue with the relation graphs and history tables, so perhaps that
switch wasn't necessary.
|
|
|
|
To reserve <b> for the standout styling.
|
|
Which is also kind of an abuse, but at least the semantics are much
closer.
(Next up: the standout class. Slowly working towards a "font: inherit"
and "color: inherit" reset, which'll remove the need for a bunch of ugly
workarounds)
|
|
|
|
With this ranking system, searching for titles like 'L' and 'ONE.' is
now at least possible, and YU-NO at least shows up on the first page
when searching for "yu no". The actual normalization and matching
algorithm hasn't really changed, except that all search terms must now
match a single title, but there's still a whole bunch of false
positives.
Ranking is not available through the API yet.
The trigram index should make it possible to do site-wide searching at a
more reasonable speed, I'll experiment with that later.
|
|
|
|
|
|
This is a huge back-end change for a small benefit, but it also improves
consistency a bit in the way that titles are handled and passed around.
The Elm code still uses separate title/alttitle fields at various
places, not sure if I want to bother converting that, too.
I'm sure there's bugs, given how many files this touches.
|
|
Bit of an experiment. I should probably swap the schema columns too
(i.e. name + latin) to be consistent with the recent VNs & releases, but
that's not really a requirement for applying these preferences.
And the more places where title preferences are applied, the more
important it becomes to also set proper html "lang" attributes, which
this commit doesn't do either.
|
|
Instead using the static view for the default title preferences, inline
SELECT statements for custom preferences and wonderful
vnt()/releasest() SQL functions for item_info().
Performance wise I don't expect much of a difference, except there's
fewer writes and less per-page overhead from the CREATE TEMPORARY VIEW
commands. Primary motivation for these changes is so that we can extend
title preferences to other database types without incurring more
overhead by needing to create more views.
|
|
For some reason applying to_tsquery() to a string twice gets different
results than doing it once. Didn't expect that from a normalization
function, but oh well.
Fixes https://vndb.org/t2520.651
|
|
Yeah, I forgot that user IDs can be undef for deleted users.
|
|
This avoids leaking the initial list of targeted users in the list.
These system notifications are still not supported all that well as the
code doesn't handle threads with thousands of boards very efficiently,
but for now that doesn't seem to be a problem yet.
|
|
|
|
This implements the main database model part of custom title languages
(https://vndb.org/t12465). Selecting the right title for display is done
in SQL through the 'vnt' VIEW, which can be overridden in each session
with a TEMPORARY VIEW in order to support user title preferences, but
that part has not been implemented yet.
I had started out using an sql_vn() function that returned a subquery
instead of using a VIEW, but then ran into trouble with the item_info()
SQL function. This VIEW approach also happened to simplify much of the
code. I did have to get rid of the Discusssions::Lib::sql_boards()
function, as Postgres was unable to optimize the subquery inside a UNION
inside a subquery for some reason. Haven't run into any other noticeable
performance regressions yet.
TODO:
- Implement actual user title preferences
- Add the correct 'lang' HTML attributes everywhere a title is displayed
(we do have the information now, though it still isn't trivial)
- Add title fetching support to API
|
|
|
|
Both in the quality of the results and query performance.
The performance boost wasn't as significant as I had hoped, but it's
something.
|
|
|
|
parsing
|
|
|
|
|
|
|
|
|
|
The type of the dbobj can be inferred from its id now that we use
vndbid's for all database entries.
|
|
I had wanted to split this up into multiple commits and roll out in
stages, but couldn't really find a natural way to do so. There are
several places that take a generic identifier and expect it to work the
same for all entries they support, so changing one entry at a time
wasn't going to be any easier. Only the tags & traits haven't been
updated yet, I'll convert those later.
While this is a major change and affects a lot of code, the individual
changes are all pretty simple. I'm surprised how much code did not have
to be updated at all. No doubt I've missed a few places, though, so this
commit will almost certainly break something.
|
|
https://vndb.org/t2520.537
|
|
Seems to be working so far. I'll find the actual bugs in production.
|
|
posts/reviews
The mark as read functionality was already present in some form for
threads, but is now made consistent among all notification types. This
removes the need for the redirect from the notification listing.
The deletion of notifications is intended to avoid pointless
notifications, especially in case of spam.
|
|
By removing the ltype, using the vndbid type, renaming 'subid' to 'num'
(as used elsewhere) and removing the reference to uid=0.
|
|
Fixing bb2html to only convert ids would complicate options a lot,
adding a new formatting function to only convert ids would make sense,
but then all formatting functions kind of look alike, so I figured a
single bb_format() to support all use cases may be a better approach.
Trigger for this was that people do (understandably) put [spoiler] in
thread titles, and that should not be interpreted as the spoiler tag.
|
|
|
|
Much to my disappointment, people don't write proper summaries and, as
such, summaries are not useful to be considered a "short review" on
their own right. This necessitates splitting the reviews onto different
pages.
|
|
|
|
Oh man, the can_edit() interface is way too obscure when it comes to
threads and posts.
|
|
and comments
rtype is not necessary, the DB identifier is sufficient. The separate
type column was supposed to simplify DB lookups (but that's all
consolidated in a single function anyway, so it didn't help much) and
easy filtering depending on what mods have access to (but there is no
such filter, and even with vndbids that should be easy enough).
Converting the object ID into a vndbid + num should make it easier to
correlate reports if necessary.
|
|
review comments
This split simplifies Discussions::Edit a little bit and allows
Discussions::PostEdit to be generic enough to handle editing review
comments as well.
|
|
Not really sure how to integrate and handle this, to be honest. I'll
just play around and see what works.
|
|
Which I broke by removing the DEFAULT clause on threads_posts.uid. That
column still used the old uid=0 for deleted users rather than the
uid=NULL that I was planning to migrate the entire DB to. So while I'm
fixing up the threads schema, may as well update this too.
There's still a bunch of columns relying on uid=0, but I can fix that
later.
|
|
Setting location.hash directly has the downside of adding an entry to
the browser's history, which is annoying.
|
|
Both pointless and wrong.
|
|
counts/lastpost
This solves a few problems:
- 'hidden' posts will no longer cause the thread to be bumped to the
front page.
- Deleting posts will no longer cause other posts to be renumbered (and
hence will not break existing links to posts)
- Numbers of deleted posts will no longer be re-used (except when they
were the last post in the thread - fixing this would require an
additional column in 'threads', but it didn't seem worth the trouble)
|
|
This removes the need for the post_url() function.
This is a small step towards supporting non-continuous post numbers.
|
