| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Largely a copy-paste from TagPage.
|
|
TODO: Add VN subquery and migrate trait pages.
|
|
|
|
|
|
Old /v/<char> URLs are still supported, but the main listing is at /v.
|
|
Moved old release browser, VN browser and tag pages to /old/, moved
/experimental/ pages to /, removed warnings and updated some references.
|
|
VNDB::Skins now behaves the same way as VNDB::Config - it provides a
single function that returns all the info you'll need.
This removes the tuwf->{skins} global variable, making skin-querying
code independent of the TUWF object, and, again, moving some
library-related functionality out of vndb.pl.
|
|
Turns out I forgot something in 3fc190f1898342d63b1308a83152fe45a88f7c3f
|
|
of tuwf->{..}
Config had been in a separate config->{..} object for a while now, old
code doesn't need it anymore so we can finally get rid of the tuwf->{..}
compact.
vndb.pl is not really the place for library code, so moved that around.
The old imgpath() and imgurl() functions weren't used anymore, so could
be safely replaced with the new functions that take the new vndbid
format.
(All this to make it easier to write separate scripts that call into
VNDB::/VNWeb:: code as a library)
|
|
Just pointless cleanup because I'm not in the mood to do meaningful
work...
|
|
This has three potential advantages:
- Memory used for image processing is released immediately, thus
resulting in lower average memory usage. I've yet to test how
significant this is in practice... I'm not entirely sure how VNDB's
memory use is distributed (not that it's really a problem, but if I
see something that could be optimized I try to optimize it. First
world engineering problems)
- The 'convert' command can be better sandboxed for increased security.
- Removes a dependency on a Perl module... except spritegen.pl still
uses it, but that can be rewritten as well if necessary.
In the process I found out that the old code's attempt to sharpen the
image after resizing was buggy and the sharpening was never applied.
This new code *does* apply the sharpen filter, so newly uploaded images
will be visually different (if resized).
I also found that imagemagick's built-in ratio-preserving resize
sometimes ends up with different image dimensions than my imgsize(). I
think that's a bug in my imgsize function, but it does result in a
discrepancy that should prolly be resolved as it may result in
screenshot thumbnails being displayed incorrectly.
|
|
The duplication has tripped me up before, in
f3420b701aa033c90678216bd36d374c10e3ac9f
|
|
|
|
|
|
I was originally planning to have only two query encoding forms: Fully
normalized JSON form and compact encoded form. But converting between
the two is kind of annoying and requires lookup tables, which makes the
normalized JSON form inconvenient for Elm. Hence I added a third form:
compact JSON form, which has the same data type transformations applied
as the compact encoded form, but still retains the JSON encoding and
structure. Converting between compact JSON form and compact encoded form
is fairly trivial. Downside is that this also implies that Query
handling in Elm needs to be done through field numbers rather than
names, which is more error prone - but this can be solved by generating
an Elm module with a variable for each field numer. Another downside is
that this makes it impossible to implement a normalized-form query
viewer and editor in Elm without hitting the server for conversions -
but such a feature is not very important anyway.
Other abstraction change is that AdvSearch.pm now exposes an
object-oriented interface, the object can keep track of the different
query forms and seems like a more suitable solution in this case.
|
|
https://vndb.org/t950.821
Flag is based on https://commons.wikimedia.org/wiki/File:Farsi.svg with
a light green brackground.
|
|
|
|
|
|
|
|
Now featuring full pagination & flexible columns.
|
|
|
|
|
|
|
|
This code is pretty easy to re-use.
|
|
Nothing new, but I do see more avenues for consolidation with traits.
|
|
Duplicating that code was really too much, the listings are way too
similar.
|
|
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. :(
|
|
Now supports full pagination, displaying & sorting on VN count and
displaying & filtering the searchable and applicable flags.
|
|
|
|
It's still missing a few mod features, will add those later.
|
|
This means the feeds are now generated on demand rather than every 15
minutes. Main reason for originally implementing this into Multi was
because RSS feeds tended to get requested a *lot* and I didn't want
those requests to impact site performance, but now that RSS is almost
dead it doesn't really matter that much anymore. A caching layer can
still be added anyway.
Be sure to restart Multi and delete www/feeds/ after this change.
|
|
The new filter framework hasn't been extensively tested yet, but seems
to mostly work.
No real changes to the homepage, but I did manage to make a few queries
a little bit faster. The most significant source of slowness is the
releases listing, but I can't optimize that without adding indices.
|
|
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.
|
|
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.
|
|
|
|
...which happens when I tag a new release.
And let's tag this 2.28.
|
|
Still need a place to dump "latest review comments". Perhaps merge with
"recent posts"? Not sure...
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
Also drop the thread_poll_votes.tid column, as it's not really
necessary.
And add ON DELETE CASCADEs to threads_posts and threads_boards to
simplify thread deletion.
Relatively invasive change, prolly broke something.
|
|
|
|
|
|
The copy-pasting here is ridiculous. But at the same time, that did
allow me to quickly rewrite the form in a single commit.
Here's hoping I didn't introduce too many copy-paste errors.
|
|
There's a lot more unreferenced code in VNDB::DB::*, but I'll not spend
too much effort cleaning that up right now. All of it can be deleted
in bulk at some point.
|
|
Deleted VNs could only be selected in the rare scenario where the
screenshots from the deleted entry have also been assigned to another
(non-deleted) entry. Fully deleted screenshots would already have been
excluded with the c_weight check.
Fixes https://vndb.org/t2520.457
|
|
Instead of the old NSFW flag.
|
|
This is mostly a copy-paste of the Char::Edit form.
|
