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.
- 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.
because we need those to make a package.
Fix the packaging code to ignore whatever prefix is being used by the
developer who is doing the packaging.
Update the install.sql file (there were a variety of small
inconsistencies, probably from hand-editing. Don't hand-edit this
file!)
them a nice "Welcome to Gallery 3" dialog. The text in there needs a
little work but it's a start.
In the process, re-build the install.sql using the scaffolding code.
creating tables with a table prefix.
There are still some queries that haven't been converted, so don't
start using prefixes yet. However, if you do, you can login and
modify the user profile.
task.php
* Added a owner_id field to the task database
* Modified the admin maintenace to show the owner of the task
<<**** Requires a reinstallation of core ****>>
1) move the rand_key column into core
2) don't do a max rand, just try to a get a random number less than
the current random number if that doesn't successd look the other way
- Added an outgoing_translations table to store translations from the local translation UI.
- I18n class is checking incoming_ and outgoing_translations for translations, giving the latter priority.
- Not handling plural strings in the translations UI yet.
- Flattened the directory structure
- Greatly simplified structure in installer; it now only reports environmental
checks that fail. Simplified code that prints exceptions. Use only mysql
calls for the installer, but select mysqli automatically if it's available.
Drop the response file; that's easily replicated with flag support
- Create a random password for the admin user
- Delete unused controllers
- Invert the form of the database config template to be mostly non-PHP
with just a few PHP calls
