Age | Commit message (Collapse) | Author | Files | Lines |
|
The original language is the language of the first release of the VN,
and is cached in vn.c_olang. (Geez, the vn table has more caching
columns than actual information >.>)
|
|
Because the site never looked good in IE7, and the new filter system
doesn't work *at all*. (Doesn't work correctly on IE8 either, but I'll
try to fix that)
|
|
Has been requested quite often, now finally implemented.
|
|
The release filters are now pretty much complete. Save, perhaps, for
some improved styling and grouping in the filter selector; but I'm too
lazy for that at the moment.
|
|
Surprisingly enough, the SQL queries are still quite fast even when
matching on the animation columns.
And thanks to the new filter system, adding this filter was incredibly
easy.
|
|
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.
|
|
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...
|
|
plpgsql is available by default in PostgreSQL 9.0, so there's no need
for this statement anymore.
|
|
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 effectively removes compatibility with all PostgreSQL versions
below 9.0.
The use of the WHEN clause has two major advantages:
1. Performance: Trigger functions aren't executed when they don't need to.
2. Easier and more general trigger functions; as some of the logic has
been placed in the trigger definitions now.
|
|
Back from 180s to ~5 or ~6 seconds. It used to be quite fast on
PostgreSQL 8.4, but somehow the planner failed to generate a proper
execution plan for that query after the upgrade. This query is fast 9.0.
|
|
Also fixed a minor bug with no change notification being sent to Multi
when only the official flag has been changed.
|
|
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
|
|
Looks like I forgot to add vn.c_search
|
|
|
|
This makes jsgen.pl a bit easier to maintain, as there's not one
reliable source to get the keys from (namely, the JS code itself).
Also cleaned up the l10n() function in jsgen.pl to be more readable.
I had expected the new .js file to be smaller because this trick may
remove some keys that were previously present but unused. Unfortunately
it seems the file only grew a bit larger and compression seems to be
less effective now. No idea why this happened. :-(
|
|
This replaces the "cookie_auth" setting, and applies to all cookies in
use by VNDB.
|
|
|
|
|
|
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.
|
|
This makes sure that these also get forced reloaded on a version change.
|
|
Conflicts:
data/lang.txt
|
|
This one is also configurable, but mainly because I want to avoid
generating several thousands of notifications for a single action...
|
|
And added a settings window where you can disable this notification,
which is something you really want to do if you're an active
contributor...
|
|
Forgot to do this in the earlier commit.
|
|
|
|
As requested, http://vndb.org/t423
|
|
And changed vn.c_languages to an array type while I was at it. This
required some changes in the Perl code, and I found a bug in DBD::Pg
while I was at it:
https://rt.cpan.org/Ticket/Display.html?id=54224
Luckily, there's an easy workaround for that.
|
|
This one's a lot faster.
|
|
Complex queries...
|
|
Nothing wrong with using the same name...
|
|
These aren't likely to change anyway, and things will become less easy
to display when other types of notifications are added.
|
|
62cb41c3b8780bffe5a8ea58a6a7b5053d9e1059
and
4895ea63323b94f0b128d6874be997a24d3a3b0d
were bad jokes, really... let's hope this permanently fixes the problem.
|
|
An expiration date doesn't make much sense if it's both not used and if
it can't be configured by the user, so just make this a timestamp to
indicate when the session has been added, which, while still not really
used, is more valuable.
|
|
If we're going to automatically remove older sessions, it would make
more sense to remove unused sessions, rather than old sessions that are
still in use. But we first need to keep track of when a session has last
been used to do so...
|
|
Setting the l10n cookie is now done from a separate url: /setlang
This makes the language determination code less complex, and makes sure
nobody links to pages that change the UI language without intending to.
(I've seen some links floating around with the l10n parameter included,
which is... bad)
|
|
The current setup should be able to handle all kinds of notifications,
though only PMs are implemented at this point. More to come.
|
|
Added a userid field in the skin config files, from which the credits
are loaded. Now I don't have to constantly update d7 for every language
when something changes in the skin files.
|
|
And updated skingen.pl and vndb.pl to make use of this abstraction.
|
|
This is implemented by adding ihid (item hidden) and ilock (item
locked) columns to the changes table,
The (vn|release|producer).(hidden|locked) columns now work as a
cache, refering to the changes.(ihid|ilock) columns with
changes.id = (vn|release|producer).latest.
The cached columns are updated automatically each time a new revision is
inserted.
This is a pretty large change, bugs are quite likely.
|
|
Simply re-using them by truncating the tables first is faster, and
requires less locking when performing batch edits in one transaction.
|
|
So that people with correctly configured browsers don't have to manually
choose their language of choice with the language switcher, and so that
most people will have one cookie less. (The 'l10n' cookie is removed if
it matches the Accept-Header language -- or the fallback)
More info @
http://www.w3.org/International/questions/qa-lang-priorities
|
|
The functions can now be edited without having to repeat them in the
update scripts. Just importing the func.sql file with \i will do the
trick.
|
|
|
|
Also added a little sanity checking on the edit_(vn|release) table,
and added a default value for releases_rev.released.
|
|
This will make it easier to do automated edits, either from cron jobs,
Multi, update scripts, or from within SQL triggers.
So far only the VN related functions have been defined/updated, trying
to edit/add releases or producers will not work at the moment.
The functions for editing or adding a new database entry have been
merged, as the procedure is rather similar.
util/dump.sql will be updated later on.
|
|
|
|
This column was used to differentiate between automated edits and user
edits, but that later changed to checking for changes.requester = 1.
The column has since never really been used, and due to a bug introduced
in VNDB 2.0, it has never been updated, either. Meaning it's not even
accurate for any database changes made after december 2008...
|
|
This removes the need for the dbVNCache() function in perl.
|