Age | Commit message (Collapse) | Author | Files | Lines |
|
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...)
|
|
As discussed in https://vndb.org/t20453
|
|
As suggested in https://vndb.org/t13470.28 - with a few minor
adjustments.
This took me a few hours to code & test, SQL is hard :(
|
|
So that the save/load functionality is also available on a user's list.
Suggested by https://vndb.org/t950.1537
|
|
tweaking
|
|
Not yet super happy with the table-in-form layout thingy; buttons jump
around when adding/removing items, ugh.
I *am* quite happy with the dropdown search thingy, the new features
make it much more intuitive to have items that can't be selected. The
current Elm code usually ignores the selection of items that are already
present or otherwise unselectable, which can be rather confusing.
Having the input field replaced with a button is something I'm not yet
decided on. It does makes sense, but also requires an additional action
when adding multiple traits. Even if that action is just pressing the
enter key. Multi-select built into the DS abstraction might be a
solution.
|
|
I considered a few general purpose selection libraries, but they're all
significantly larger and would take a bit of effort to properly
integrate anyway.
|
|
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.
|
|
|
|
So that there aren't any columns in need of quoting anymore.
|
|
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)
|
|
Queries that normalize to nothing (e.g. ".") do not really need to throw
an error - it's not a bug in the front-end code - and should also not
prevent such entries from being created.
|
|
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.
|
|
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.
|
|
The card/grid modes are totally half-assed, they don't display release
status or notes and changes using the widget are not reflected in the
listing until a page refresh.
And the card mode will overflow if too many fields are selected.
|
|
Goal is to slowly consolidate more UList code with VN::List, so that all
columns and display options of the latter are also available on the
former. The only real change with the current commit is that more
columns can be selected in UList, but this is just step one.
|
|
|
|
|
|
|
|
Somewhat experimental feature, needs better testing, guidelines and
integration with the search function. Probably.
|
|
Fixes https://vndb.org/t2520.647
|
|
|
|
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
|
|
|
|
Fixes https://vndb.org/t2520.567
|
|
With additional VN cache columns for the new developers and average
table columns. The developers cache is also used by the AdvSearch to
potentially speed up some queries (and slow down others).
I also changed the popularity and rating caches to smallint. Doesn't
save anything with the current padding, but there's not much point in
using a floating point type when the values get rounded anyway.
|
|
|
|
This way there is always a single canonical path for each tag/trait,
which fixes the problem with traits that could belong to multiple groups
yet you couldn't control which one was selected, and this also removes
duplication in the VN->tags tab, which now doesn't have to non-canonical
tag paths.
|
|
|
|
This also fixes the issue that the reason for deletion is not displayed
if it's in the message of the last change, which is the case for newly
rejected tags/traits. The edit message is not displayed if the entry was
deleted in the first revision, as that's most likely an import.
|
|
Much the same as the previous conversion of tags.
|
|
I obviously forgot to test this one.
|
|
Another commit with changes all across the tree. But at least we have a
tangible improvement now: edit histories for tags.
|
|
Fixes https://vndb.org/t2520.542
|
|
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.
|
|
|
|
User id '0' referred to a special "deleted" user was a quick and dirty
hack to support proper account deletion. It didn't end up working in all
scenarios because some tables would have to allow multiple rows with
uid=0 (tag votes, among other things) and that required using NULL to
not trigger any UNIQUE constraints. So we ended up with inconsistent
handling of deleted users, some tables using 0 and others using NULL.
I've been using NULL for all recent code, this commit migrates the last
0s to NULL as well.
|
|
I had them as temporary redirects in order to safely handle a rollback,
but that won't be necessary anymore.
|
|
Fixes the first part of https://vndb.org/t2520.538
|
|
I think I've seen all the possible errors by now, what remains are
invalid/corrupted filter strings that aren't very interesting to handle.
|
|
Largely a copy-paste from TagPage.
|
|
|
|
Amazing how can browsers(?) and bots mangle URLs sometimes.
Anyway, the user will now get a friendly error message instead of a 500,
and I get to see log messages. Everyone happy. I hope.
|
|
|