| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Yay!
There are no more request handlers in the VNDB::* namespace and no more
Javascript in data/js/. This cleans up a lot of old legacy code that
wasn't fun to maintain.
|
|
Had been planning to use a more powerful preprocessor for CSS for a
while, so that I can also reorganize and clean up the CSS a bit. The
cleanup will come later, this is the first step to reorganize the build
system a bit and remove skingen.pl.
I moved all generated static assets to static/g/ (for _g_enerated),
including icons.png and js files. This simplifies management of
static/f/ and static/s/, which are fully in git.
Skins are now defined as sass files in css/skins/ with their images in
static/s/ using plain directory structure.
|
|
Turns out I forgot something in 3fc190f1898342d63b1308a83152fe45a88f7c3f
|
|
|
|
|
|
|
|
This was the last form in the old v2 code, so this allowed me to get rid
of the old form validation and generation abstractions.
The form is mostly a duplicate of the tag editing form, as expected.
It's really annoying to have to maintain pretty much duplicate code for
tags and traits, but there are just enough differences that the
complexity of sharing code or creating a new abstraction outweigh the
benefits. :(
|
|
This is a minor start towards rewriting the filter logic in the new v2rw
code. Filters were never validated before (I didn't have a good
framework for it - now I do) and invalid filters would result in a 500.
The new validation code is not yet applied, but failed validations will
be logged so that I can see if it's working correctly.
I mean, what better way to test than to throw it in production?
I'll write new (and more flexible) SQL generation functions for these
filters later, so that v2rw code can get filtered results and I can make
a start on rewriting the pages that depend on the functionality. The
validation schema can also be used to validate the filters stored in the
DB, so I can use it to get rid of the complex handling of stored invalid
filters.
|
|
|
|
The resolution field now works much like the engine field.
|
|
The trace_log showed that the vast majority of pageviews do not need any
Elm modules at all, so we can save a lot by not loading them on the page.
Some pages (most notably: VN pages for not-logged-in visitors) do need
JS but don't load any Elm modules. I've added a 'js' flag to
HTML::framework_() to indicate that and ensure that plain.js is still
loaded.
|
|
There's a lot of unused code in VNDB::DB::{VN,Release} still, but I'll
not fiddle with that for now.
|
|
This simplifies several actions and makes permission checks more
obvious. This is also yack shaving for another feature I've been
planning to add: boardmods should be able to set other users' "board"
permission, tagmods for tags, etc. So that partial user bans don't need
the full "usermod" permission.
|
|
Same change as with Producers::Graph before. This also adds an option to
show/hide unofficial relations.
Restructured the code a bit to allow for sharing code between
Producers::Graph and VN::Graph.
|
|
And get rid of the spoiler warning in the tag link browser. There are
lots of pages that would need it if we applied it consistently.
|
|
Replaces the old "wishlist status" column that I removed earlier. It's
kind of awkward, but at least the functionality still exists now.
|
|
Minimal version. It reuses the LabelEdit and VoteEdit widgets, but
doesn't allow setting a note or start/finish date at the moment.
VN pages now have both v2rw.js and the old vndb.js; Those two scripts
aren't meant to be used together on a single page, so I'm hoping this
will be temporary. I removed the 'checkall' handling from vndb.js as
that might conflict. It's only used on the old list pages anyway.
|
|
To my surprise, I actually managed to achieve acceptable performance by
just adding two indices. I totally expected I'd have to keep a cache
column in ulist_vns whether the row is private or not. The partial index
on the users table in fact improves the performance of the vote graph
query. A covering index improves that even further, but that requires
Postgres 11+, which the Docker image doesn't have yet (and isn't all
that crucial anyway).
There's a rather annoying potential for confusion regarding the private
flag on votes. The user page & list stats only look at whether the
'Voted' label is private, whereas the VN stats use the "proper" approach
of checking for any public label. Not entirely sure which of the two is
more intuitive.
|
|
Flexbox instead of floats. Apart from that, it's still very hacky. Uses
relative positioning in order to overlay 1px over the .mainbox.
This should fix the ages-old 'bottom tabs overlay next mainbox' bug and
provide more flexibility with adding a top-level <fieldset> or centered
buttons.
|
|
This is where the ExtLink module comes in handy: generating the revision
comparison thing is much easier now. Did find and fix a bunch of issues
with the new revision box generator code, but that was to be expected, I
hadn't tested that code well yet and this is its first more demanding
use.
Rest of this is a pretty direct rewrite, nothing too special.
|
|
This is yak shaving. The new module doesn't have much value as it is,
apart from having a central place to define link formats. This new
enrich_extlinks() approach is also a bit more efficient in that it can
avoid separate SQL queries for multiple objects.
But the real reason for these changes is that I can use that %LINKS hash
table to automatically generate the links part in the edit summary and
it should (hopefully) also be useful to generate a more
convenient/streamlined Elm edit form.
|
|
|
|
|
|
https://vndb.org/t2520.307
|
|
This is the first major editing form to be converted, so I'm expecting a
little breakage. A good chunk of this code has been copied from v3.
In terms of the UI there has been a small change: aliases that are still
referenced do not have the 'remove' link and instead have a flag that
shows that they are still referenced. This ought to be a bit friendlier
than throwing an error message after the user has submitted the form.
Some other things I'd like to improve in this form:
- BBCode preview
- Pasting in external links and letting the form figure out the Pixiv
ID, etc.
- Or perhaps even: Integrate AniDB/Wikidata search/autocompletion.
|
|
|
|
It's rather much code just to run a single SQL statement that I almost
never need. Incidentally, the feature was also broken because the DELETE
permission wasn't granted in perms.sql.
|
|
|
|
Only place where this isn't applied (yet?): Sorting user lists still
goes by the old username and board names don't use the new unicode
names.
I have to say, I quite like the sql_user() and user_() pattern. It's not
without problems when applied to everything, but it's good enough for
several use cases.
|
|
|
|
This bloats the users table a little bit, but that's fine. The main
advantage of this change is that we now have a proper schema for user
preferences, rather than the schemaless key-value mess we had before.
This commit also splits the 'tags_cat' preference up into tags_cont,
tags_ero and tags_tech bools, as that's more compact to store and easier
to work with.
This commit also changes the 'notify_nodbedit' preference to
'notify_dbedit' with inverted meaning. The reason the value was negated
in the first place was because the old schemaless approach did not
support positive defaults.
|
|
And I changed the filter selection into a more form-like thing. It's
slightly more powerful, but not sure it's such a huge improvement in
terms of UI. Everything should be identical apart from that.
|
|
A '-' before or after a DB identifier now counts as a "word character",
meaning in "d5-something" won't turn that "d5" into a link.
|
|
Most of this is copied from v3. I did improve on a few aspects:
- db_edit() and db_entry() use VNDB::Schema rather than dynamically
querying the DB. This has the minor advantage of a faster startup.
- The Elm code generator now writes to multiple files, this avoids
the namespace pollution seen in v3's Lib.Gen and makes the dependency
graph a bit more lean (i.e. faster incremental builds).
- The Elm code generator doesn't update the timestamp of files that
haven't been modified. This also speeds up incremental builds, the elm
compiler can now skip rebuilding unmodified files.
- The Elm API response generator code now uses plain functions rather
than code references and all possible responses are now defined in
Elm.pm. Turns out most API responses were used from more than a single
place, so it makes sense to have them centrally defined.
The doc page preview function is also much nicer; I'd like to apply this
to all BBCode textareas as well.
(Elm.pm itself is ugly as hell though. And we will prolly need some HTML
form generation functions in Elm to make that part less verbose)
|
|
More churn!
Also converted v3 to use VNWeb::Auth, considering the API is pretty much
the same. Converted VNWeb::* to use VNDB::Config directly rather than
read from tuwf->{}, converted VNWeb::HTML to use VNWeb::Auth, and
updated util/vndb.pl with the new code style.
I tested as much as I could, but I'm sure I broke something.
|
|
I copied and modified VN3::DB to VNWeb::DB, but it isn't used yet. Now
that I think about it, that module isn't "web" specific at all and
should perhaps be in the VNDB:: namespace. Oh well.
|
|
Present them in the same order as the main menu.
Remove user and forum stats, they're pretty much irrelevant. The user
count, in particular, is misleading - those aren't "active" users.
|
|
|
|
1. Every revision page may contain spoilers
2. Nobody reads those big red warnings, anyway
|
|
This gets rid of global.pl, config.pl and config3.pl and uses the
cleaner config3.pl format for the config file. The config is easily
accessible from anywhere by importing the new VNDB::Config module; The
global $VNDB::S,O,M,ROOT variables have been removed.
Sorry for all the churn...
|
|
|
|
I did create a function to export arrays, but ended up exporting them as
hashes. That ought to simplify a conversion to an enum type. Which will
likely never happen because I'd rather switch to dynamic user-defined
statuses, but that's quite a step further...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The current affiliate links format doesn't display as much information
as before but it's also a lot less messy.
|
