| Age | Commit message (Collapse) | Author |
|---|
|
gallery 2 -> 3
comment 1 -> 2
|
|
|
|
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.
|
|
extension is unavailable. Fixes ticket #393.
|
|
|
|
|
|
that install.sql is more stable.
|
|
|
|
be run from the command line and will throw a 404 if it is run as a web request.
|
|
|
|
database and var directory to a seperate standalone file in the installer. This will save the current database environment and restore it when the packaging is complete
|
|
Settings > Advanced. It's stored in the variable as an
internationalized string and localized at output time.
|
|
that it's fragile, and I broke it when I sorted the columns
alphabetically a day or two ago.
|
|
Rebuild install.sql
|
|
|
|
gallery module. This type of mass update is prone to some small bugs.
|
|
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).
|
|
> Settings > Advanced. The default is 75.
|
|
|
|
|
|
are getting installed.
|
|
single query. In most cases, we were fetching 4-5 variables per page
load, so this is 2-3x faster.
|
|
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.
|
|
|
|
|
|
when adding photos/movies/albums
|
|
|
|
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
|
|
has a key on item_id
|
|
variable interpolation. Fixes ticket #229.
|
|
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.
|
|
use this as the default instead of id. This prepares the way for
manual reordering in the organize functionality.
|
|
|
|
ordering and known values. This way subsequent packaging runs won't
have any differences unless there's a real data change.
|
|
|
|
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!)
|
|
|
|
as two separate columns in the item table.
|
|
If I understand correctly, this is better for performance. I could be
wrong here, though.
|
|
descriptions.
|
|
This helps us to make sure that we only see the welcome message once.
|
|
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.
|
|
Date, Update Date, Random Key, Title, Mime Type, Item Type & Number of views)
|
|
identify table names that need substitution.
|
|
mirror the drupal pattern of using braces {}.
|
|
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
|
