| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- Fix mouse-over text of language flag on homepage
- Capitalize release types in edit form
- Use plural form of character roles on VN page listing
|
|
|
|
I definitely needed the Tie::IxHash thing for these.
|
|
This removes the reliance on sort() to provide meaningful ordering (the
keys aren't always good for ordering) and removes the 'order' hack used
for (vn|prod)_relations.
|
|
Now that graphviz knows the actual strings, it has a better opportunity
to create better graphs.
(Most of them still look messy tho)
|
|
|
|
|
|
Compresses a little better. I reduced the number of iterations required
to find the optimal image size in spritegen.pl, but generating the
icons.png is *incredibly slow* when combining zopflipng with the 'slow'
option. It's possible to parallelize the calculation and use multiple
cores to speed it up, but that seems overkill.
Some icons.png compression stats:
METHOD SIZE RUNTIME
default 18103 <1sec
slow 17941 few secs
pngcrush 15385 <1sec
pngcrush+slow 15148 few mins
zopflipng 14986 few secs
zopflipng+slow 14898 ~1 hour
|
|
|
|
They had to be deleted from the database at some point, otherwise we
still have thousands of easily-cracked password hashes in the database.
Note that I could have opted to use scrypt on top of the sha256 hashes
so the passwords would remain secure without needing to reset
everything, but doing that after one year of switching to scrypt is
likely not worth it. Everyone who still actively uses his account has
already been converted to scrypt, everyone else should just reset their
password whevener they decide to come back.
|
|
|
|
|
|
A recent version of imagemagick creates 16 bit depth PNG images by
default for some reason. This results in an unnecessarily large file
size increase and pngcrush doesn't do much to counter it (and its
-bit_depth option has been deprecated, too).
The atomic replace is quite handy to avoid people seeing any wierd
intermediate images while the slow+pngcrush options are being used.
|
|
Tends to compress a bit better than JavaScript::Minifier::JS. But is
also a lot slower, so not really useful when devving.
Stats for en.js:
raw gzip
uglifyjs 68199 19446
JS::Minifier::XS 79862 21624
Uncompressed 107662 28663
On an unrelated note, I like how jQuery boasts about being "Only 32kB
minified and gzipped.". That's quite a bit more than all of VNDB's
Javascript combined. For a damn library.
|
|
This simplifies the JS version of mt() a bit and makes the whole
internationalization framework a bit more robust. I also changed the
VARS.{rlist_status,age_ratings,languages,platforms,char_roles} arrays to
include the L10N string. This simplifies the JS code and reduces the JS
size. There's a few more of such lists that can be transformed in the
same way, I'll get to that later.
|
|
The name of the profile setting isn't very clear. Not sure what to do
with it.
|
|
Having a proper and up-to-date list of moderators is an often requested
feature.
|
|
https://vndb.org/t6138.226 - https://vndb.org/t6048.132
|
|
|
|
|
|
Let's see how this goes.
|
|
Note that it's still in the postgresql ENUM type. Removing that is
possible, but not very trivial.
|
|
Conflicts:
lib/Multi/Feed.pm
lib/Multi/IRC.pm
|
|
I probably don't want to have the 'trace' log level on the actual
server.
|
|
|
|
|
|
|
|
|
|
TUWF properly detects HTTPS and includes this in the returned URL, so
this change ensures that all URLs adopt properly to HTTP and HTTPS.
|
|
|
|
Completely disregard my comments regarding DoS in commit
6e0a0e1d00e11da9b4eab2163e19314f752b05b5 - successful logins aren't
throttled at all. The other reason for lowering this value is because
the API requires a login for each new TCP session, and it doesn't seem
like many (any?) applications keep the TCP session alive for very long.
Still, 65536 is more secure than the default of 16384.
|
|
I increased the N parameter to approximate about 500ms to generate the
hash. This is quite a paranoid setting for a website, but login attempts
are throttled so there's not much of a DoS factor. (Alright, password
changing feature isn't throttled so the DoS factor still exists. But
really, there's some pages with longer page generation times anyway.)
I did lower the size of the salt a bit (Crypt::ScryptKDF uses 256 bits
by default), because 64 bits of randomness should have low enough chance
of collision with only ~100k users (even with a million users,
seriously).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TODO: Get rid of the 'processing' flag and all the async loading of
screenshot data in the screenshot uploader.
|
|
This isn't documented yet.
|
|
|
|
|
|
And added an update_2.23.sql file which now also includes the previously
added indices. Currently, this update file can be run as often as you
want, it doesn't make any noticable changes when you run it on a
database that has already been updated. (i.e. I can update the main site
without a new release)
|
|
O A B AB - this makes more sense in Russian, where they are numbered
rather than named. (And is a sensible order in any case)
|
|
Provided they have the 'edit' permission in the first place.
|
|
|
|
|
|
+ Fixed makefile
I haven't been able to properly test this yet as a bug[1] in PostgreSQL
9.0.4 is preventing me from editing release entries.
[1] http://archives.postgresql.org/pgsql-bugs/2011-08/msg00119.php
|
