| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Most of this is copied from v3. I did improve on a few aspects:
- db_edit() and db_entry() use VNDB::Schema rather than dynamically
querying the DB. This has the minor advantage of a faster startup.
- The Elm code generator now writes to multiple files, this avoids
the namespace pollution seen in v3's Lib.Gen and makes the dependency
graph a bit more lean (i.e. faster incremental builds).
- The Elm code generator doesn't update the timestamp of files that
haven't been modified. This also speeds up incremental builds, the elm
compiler can now skip rebuilding unmodified files.
- The Elm API response generator code now uses plain functions rather
than code references and all possible responses are now defined in
Elm.pm. Turns out most API responses were used from more than a single
place, so it makes sense to have them centrally defined.
The doc page preview function is also much nicer; I'd like to apply this
to all BBCode textareas as well.
(Elm.pm itself is ugly as hell though. And we will prolly need some HTML
form generation functions in Elm to make that part less verbose)
|
|
This gets rid of global.pl, config.pl and config3.pl and uses the
cleaner config3.pl format for the config file. The config is easily
accessible from anywhere by importing the new VNDB::Config module; The
global $VNDB::S,O,M,ROOT variables have been removed.
Sorry for all the churn...
|
|
I think this is the last one. 'make' in a development environment is now
beautifully fast and 'make prod' generates nicely small assets.
(arguably we could have an even faster dev setup by not generating an
icons.png in the first place, but then we'd need more code to
differentiate between dev & prod, which is also a pain)
This change does remove the "slow" option that would use the compressed
image size in the optimization algorithm, but I hadn't used that option
for a while anyway, it takes an hour and only saves about 100 bytes.
|
|
Similar to previous commit.
|
|
This rather significantly speeds up development builds. Also simplifies
skingen.pl and its config a bit.
The new compressed files are written to /s/*/style.min.css{,.gz}, it is
up to the web server to serve those instead of /s/*/style.css.
|
|
I was getting tired of having to keep two branches up-to-date with the
latest developments, so decided to throw v3 into the same branch - just
different files (...which will get mostly rewritten again soon). The two
versions aren't very different in terms of dependencies, build system
and support code, so they can now properly share files. Added a section
to the README to avoid confusion.
This merge also makes it easier to quickly switch between the different
versions, which is handy for development. It's even possible to run both
at the same time, but my scripts use the same port so that needs a
workaround.
And it's amazing how often I break the Docker scripts.
|
|
I initially wanted to move the static/.. files onto the Docker volume,
so that all dynamic site data is stored in a single place. But that
turned out to be impossible to do without some really ugly hacks. So
instead I went with the opposite approach: get rid of the 'vndb-data'
volume and instead store everything in the source directory. This also
requires running PostgreSQL as the 'devuser', but that's fine for a
development setup. All of this makes it more obvious what is going on
and simplifies the init script.
|
|
This affects the following:
- API login with a weak password is disallowed, affected users will have
to change their password through the website to continue using the API.
- Registration, password reset or password change forms require the new
password to not be in the dictionary.
- Attempting to log in to the website with a weak password will
force-redirect to a password change form, allowing a new password to
be set (using the weak-but-still-valid password as check).
|
|
It's been a while since I had static/f/ in git, so I had to adjust
.gitignore a bit.
The CSS changes are purely opinion, but it does integrate better with
the existing layout.
Everything else are bug fixes.
|
|
|
|
This changes quite a bit to the way the editing functions work. Because
these functions are very repetitive and it's easy to keep things out of
sync, I created a script to generate them automatically. I had to rename
a few function and table names for consistency to make this work.
Since database entries don't have a 'latest' column anymore, and since
the order in which tables are updated doesn't have to be fixed, I
dropped many of the SQL triggers and replaced them with a
edit_committed() function which is called from edit_*_commit() and
checks for stuff to be done.
Don't forget to run 'make' before importing the update script.
|
|
It became a bit of a hassle to keep updating that file manually in Gimp.
This script performs surprisingly well for our set of icons.
|
|
This isn't documented yet.
|
|
|
|
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!
|
|
TODO: add links to these feeds from the site
|
|
This page is pretty specific to the main VNDB, and each VNDB would probably
have it's own d8.
|
|
|
|
While this 'processing' is currently limited to minifying the file if
JavaScript::Minifier::XS is available, this change would make it a lot
easier to make the strings in the JS code translatable.
|
|
The graphs are now stored in the DB in SVG format, the static/rg/
directory can be removed (not used anymore).
SVG data is stored using the xml data type, so now I can say for
sure you'd need at least PostgreSQL 8.3.
This feature still needs some tweaking, though. Current state isn't
perfect.
|
|
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.
|
|
...this is basically everything we're going to rewrite
|
|
|
