Age | Commit message (Collapse) | Author | Files | Lines |
|
This greatly reduces the size of the Javascript file. The compressed
size has been reduced with about 9kB, and is now a total of 14kB for
en.js. A nice property of this is that more translations can be added
without increasing the JS size.
While I was at it, I made jsgen.pl also replace mt() function calls in
cases where an exact TL string was requested without any additional
arguments and/or formatting codes. This helped reduce the compressed
size by about 1kB.
My aim is to keep *all* the JS code of VNDB smaller than the jQuery core
library, as a general "fuck you" towards users of large and bloated JS
libraries. We must keep the VNDB page loading times lower than that of
other sites, after all!
|
|
Rather than trying to figure out what to update in the Perl code,
duplicating the logic that's already present in the Makefile.
This is only enabled when 'regen_static' is set to true in
data/config.pl.
|
|
fil_parse() now checks for proper formatting of the string and ignores
key/value pairs that are not the list of allowed keys. This makes it
impossible to provide extra, unintended, arguments to dbReleaseGet(),
such as 'results'.
|
|
It seems a comma has to be escaped in query string values. A ~ doesn't
and thus makes the URIs significantly shorter.
|
|
There's no validation of the filter string yet, and somehow I don't feel
like adding that; it's a lot of code and there's nothing to protect -
the values are inserted using parameters into a SELECT query, the worst
thing that could happen is the user receiving a 500.
Also, I've started using the perl '//=' operator, which was added in
5.10. This removes support for older perls.
|
|
This isn't entirely functional yet, the server side will need to be
rewritten as well. And after that new filters should be added and this
system should also be used for VN/producer search.
script.js is getting quite large with all those new translation strings,
it may be an idea to generate a separate .js file for each language and
only load the one being used.
I won't have a valid reason to feel bored anytime soon, at least...
|
|
This makes deleting user accounts less error prone.
It also seems I forgot to git add update_2.14.sql in an earlier commit,
sorry about that.
|
|
This also gets rid of three perl warnings.
|
|
|
|
|
|
|
|
The official flag of untouched relations wasn't properly copied from the
old revision.
|
|
I added this clause to slightly speed up the SQL query at producer
pages, but it turns out to slow down release search queries by a factor
100.
|
|
This is a very old bug. Never fixed it before because I couldn't think
of a clean/easy solution and it wasn't important to waste my time on.
|
|
It's an awesome feature now. :-)
|
|
A nice expanded view. It also happens to be faster than the old view in
terms of SQL queries. (In most cases at least)
Can be improved a little more by:
- Adding an 'expand/collapse' feature to list only the VNs
- Adding a column indicating the role of the producer (dev/pub)
|
|
Algorithm::Diff::Fast can handle perl encoded UTF-8 perfectly fine, so
the encode and decode functions aren't necessary anymore.
|
|
This module is cleaner, faster and has less dependencies.
(didn't exist yet at the time I first implemented the revision diffs)
|
|
|
|
This is the first part. The flag is stored in the database, can be
edited through the usual VN edit form, and is displayed in the diff
viewer.
Things to do to make this feature fully functional:
- display "official" status on VN page at the relation listing
- update relation graphs to display unofficial relations differently
- update guidelines
|
|
Just a simple question.
|
|
The code is a bit more complicated now, and it's not a lot faster, but
at least this helps a bit.
|
|
Similar to ab64b573846da39622b8d430b079d7e8806a35d3, but with a few more
constraints as dbVNGet() is a more generic function. This and the other
commit greatly improve the page generation time of the homepage. From
~250ms to ~110ms in my tests.
|
|
By rewriting the query and using the trick documented here:
http://blog.rhodiumtoad.org.uk/2009/03/08/selecting-random-rows-from-a-table/
Can be further optimized by putting an index on vn_screenshots.scr
|
|
Really need a cleaner solution for that. PostgreSQL actually provides a
better solution, need to change to that.
|
|
Also fixes a cross-site request forgery vulnerability. Not as strong as
the others but it's not very crucial anyway.
|
|
|
|
Conflicts:
lib/VNDB/DB/VN.pm
lib/VNDB/Func.pm
|
|
And clean up the alias field before it gets inserted into the DB.
Does not provide any feedback to the user, let's just hope our users are
clever enough to figure out what happened.
|
|
|
|
Those boards are most active.
|
|
Looks cleaner now.
|
|
|
|
This replaces the "cookie_auth" setting, and applies to all cookies in
use by VNDB.
|
|
And made sure the dimensions are truncated in VNDBUtil::imgsize().
Setting the width/height attributes makes sure that the browser can
reserve space for the image when it hasn't been loaded yet, which
prevents the overall page layout from changing while the images are
loading. (which is annoying if your connection isn't all that fast)
|
|
Which may also be useful for other scripts.
|
|
And changed the order a bit, as suggested by ImmLff.
|
|
|
|
|
|
|
|
|
|
|
|
Now it's finally possible to run multiple VNDB's with different
databases on the same domain without constantly getting logged out.
|
|
I could swear the user pages have always been noindex'ed... hmm.
|
|
This adds a new column to the vn table: c_search, which holds the
normalized titles for speedy search results using LIKE.
Also split some functions from VNDB::Func that didn't require YAWF into
a VNDBUtil module, so Multi can also make use of them. The normalization
functions are the same for Multi and VNDB, after all.
The API and Multi::IRC still use the old search, these should be updated
as well.
|
|
|
|
Crawlers would often find such pages, and the query would often take
more than a second to finish, in some extreme cases even 10 seconds.
This fix converts an intermediate result into an array, forcing the
query planner to evaluate the subquery first, resulting in a far more
optimal query plan.
|
|
1. Don't try to normalize the GTIN code in the releases form when it's 0
2. Don't try to gtintype() *every* number in the search
|
|
We have to assume that the input doesn't always have enough zeros,
to fill the 12 characters, otherwise UPC codes fail when they are
fetched from the database (which is stored as a bigint, no zero padding
in the output). Instead, we'll just add the zeros ourselves up to 12 for
normalization purposes.
|
|
You can't quite check the length of the GTIN code if you strip away
zeros in the beginning, right?
|