Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
The 'language' column in releases_rev has been replaced with a
releases_lang table. As this is quite a big change, there may still
be bugs floating around somewhere.
|
|
+ Set 2.4 date in ChangeLog
|
|
I really need to write an abstraction layer within PgSQL to make inserting
new revisions using plain SQL easier.
|
|
|
|
|
|
TODO:
- update d3
- filters on /r
|
|
TODO: filter on /r
|
|
TODO:
- Update d3
- Add filter to /r
|
|
The bayesian ranking algorithm isn't exactly meant to be used to
differentiate between absolute values, so do a pre-check on AVG(vote)
before considering a VN in the rating.
I've also played around with using plain old averages as score, but I'd
say the ordering is a lot better with the bayesian ranking, the displayed
score is just slightly more confusing.
|
|
Use a user's highest vote on a child tag in the calculation of the
rating of a parent, rather than the average.
|
|
Fixed major performance bug caused by referencing the wrong table, moved
all intermediate views to tag_vn_calc() as temporary views (similar to
update_vnpopularity()) and renamed tags_vn_stored to tags_vn_bayesian.
|
|
|
|
Conflicts:
lib/VNDB/DB/Discussions.pm
util/updates/update_2.3.sql
|
|
|
|
Which is a more accurate description, and doesn't confuse with the
tagging system.
Note than even all internal uses of the word 'tag' have been replaced,
as I'm not a huge fan of different terminology in the code and UI. This
update might break some things related to the discussion board.
|
|
|
|
|
|
Updated hourly by Multi.
May want to look for a better way to update this cache, because I'm
afraid the current tags_vn_calc() is going to perform very badly on
larger databases.
|
|
|
|
|
|
|
|
...taking into account the votes on child tags and one user
voting on multiple child tags.
Doing this realtime is slow... very slow. Tried playing around
with storing the ratings in a normal table for caching, but don't
have enough data to do proper benchmarks and determine the fastest
method yet.
|
|
Consistent with all other aliases field
|
|
But it already starts to look like something that might work.
|
|
|
|
Mostly playing around with the possibilities,
tag page layout & database scheme are far from final
|
|
|
|
|
|
|
|
This would at least annoy the people who'll try to manipulate
the rankings, and will make finding duplicate users a bit easier.
(Not that it's really a problem at the moment)
|
|
|
|
The following query should be run periodically to update the rankings:
SELECT update_vnpopularity();
I'll fix Multi::Maintenance to do this automatically.
|
|
|
|
TODO: update d3 and automatically convert all 'patch' media releases
in the DB to use this flag.
|
|
|
|
Simply set the 'maintitle' to '0'
|
|
boxbg.png are generated
|
|
|
|
Less error prone, and only updates the skins that need updating and
are actually writable.
|
|
|
|
|
|
|
|
Skins are automatically regenerated if necessary. This, however,
requires the vndb.pl process to have write access to the skins,
which is most often not the case. To do this, simply do a:
chmod 777 static/s/*; chmod 666 static/s/*/{boxbg.png,style.css}
(and make sure to repeat that each time a new skin is added)
|
|
...by removing all newlines, whitespace and comments from the
generated CSS file.
None of the CSS sent to the browser is maintained by hand now, so
adding some compression is easy. :-)
This compression is disabled if the debug config flag is enabled,
considering debugging an unreadable CSS file isn't fun.
|
|
|
|
So, instead of using separate smaller CSS files to overwrite
directives in the main (/static/f/style.css) file, I decided
to generate one CSS file for each skin, which includes everything
needed to render the page. The template for this skin is now
/data/skingen/style.css.
I just don't feel like maintaining two separate files when
changing something to the CSS.
Also converted the old layout into a skin directory (angel),
since the default skin isn't in the CSS template anymore.
|
|
generator
|
|
...but not yet in the skin generator, as I haven't really decided
yet whether to generate those colors based on the other colors, or
to make them configurable from the skin config (= more work for the
people who create the skins)
|
|
How it works:
Create new directory in static/s/
Create a 'conf' file (see the test skin for a template)
Run skingen.pl, which will generate a style.css and boxbg.png
This process will probably be automated using a simple web interface
or something...
There's no skin selector yet, so Util/LayoutHTML.pm has to be modified
to view the generated skin.
|