- gallery_version is gone
- access related columns are now binary (Postgres)
- for some reason we've reverted back to the /*!40101*/ style settings
in mysqldump.
* Separate the portion of get_db_info.html.php that displays the status
of the var directory into a separate view var_dir_status.html.php
* Change the processing to always generate the database information request
screen unless there is an environment error, the var directory is not writable
and the install was successful
Signed-off-by: Tim Almdal <tnalmdal@shaw.ca>
Changed get_db_info.html.php to not display the database information
request form until the var directory is successfully tested as
writable. This prevents users from thinking they can enter the
database information prior to successfully accessing the var
directory.
Signed-off-by: Tim Almdal <tnalmdal@shaw.ca>
Add xxx_installer::upgrade($version) method so that upgrade stanzas
are separate from install stanzas. In the old code, to do an upgrade
meant that you had to re-evolve everything from the initial install
because we'd step through each version's changes. But what we really
want is for the initial install to start off in the perfect initial
state, and the upgrades to do the work behind the scenes. So now the
install() function gets things set up properly the first time, and the
upgrade() function does any work to catch you up to the latest code.
See gallery_installer.php for a good example.
only implementing schema version 1. This caused install.sql to be
populated from version 1 which meant that after install you'd have to
run the upgrader. No harm done, and the pattern is fixed for the
future.
Alphabetize the tables so it's easier to find stuff.
Install: <module>_installer::install() is called, any necessary tables
are created.
Activate: <module>_installer::activate() is called. Module
controllers are routable, helpers are accessible, etc. The module is
in use.
Deactivate: <module>_installer::deactivate() is called. Module code
is not accessible or routable. Module is *not* in use, but its tables
are still around.
Uninstall: <module>_installer::uninstall() is called. Module is
completely removed from the database.
Admin > Modules will install and activate modules, but will only
deactivate (will NOT uninstall modules).
us avoid doing lots of MPTT lookups to find the parent path when we're
trying to generate thumbnails, etc. Invalidate the cache at all the
right times. This greatly reduces our query count on album page views.
This fixes ticket #40.
already has Gallery 3 tables. Otherwise, permit it to continue.
We key this off of the existence of the g3_items table. Theoretically
it's possible that the g3_items table is gone but other tables are
still there, which could mess things up. I'm not going to worry about
that for now.
Fixes ticket #175
- Add a "captured" column to the items table.
- Pull the DateTime EXIF field and put it into the captured column
- Pull the Caption EXIF & IPTC fields and put them into the description
field if there was not already a value there
gets run at scaffolding::package() time, not on the target machine.
Instead, create a core module variable to trigger running
graphics::choose_default_toolkit() on the first admin login after install.
Fixes ticket #206.
