| Age | Commit message (Collapse) | Author |
|---|
|
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
|
|
|
|
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).
|
|
|
|
single query. In most cases, we were fetching 4-5 variables per page
load, so this is 2-3x faster.
|
|
|
|
|
|
|
|
|
|
|
|
ordering and known values. This way subsequent packaging runs won't
have any differences unless there's a real data change.
|
|
core_installer::install() now takes an $initial_install param that
allows us to enforce that we're doing a clean install. Use this in
both the scaffolding and the unit test code.
Greatly simplify the scaffolding uninstall/reinstall code.
|
|
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!)
|
|
bypassed.
|
|
data creation and the packaging code. The rest ofthe functionality is
either no longer required, or moved to the developer module (MPTT
Tree).
Also provide checking for the active user to be an admin.
|
|
developer module.
|
|
|
|
|
|
batch::start() before starting a series of events, and batch::stop()
when you're done.
In batch mode, the notification module will store up pending
notifications. When the batch job is complete, it'll send a single
digested email to each user for all of her notifications.
Updated the scaffold and local_import to use this. Haven't modified
SimpleUploader yet.
|
|
|
|
generating random albums and images
|
|
Starting a batch call batch::operation(name, item). In the case of
adding photos name = add and item is the parent of the new items.
When the operation is finished the batch::end_operation(name) is
called.
operation and end_operation events are called. Handlers
(i.e. item_created) can call batch::in_progress(name) to determine if
a batch is being processed.
|
|
start_batch and end_batch add and remove the batch id from the
session. Modules wishing to do batch processing, just need to fire
the start_batch and end_batch events. Other modules that need to be
aware of batches (i.e. notifications) just check the session for "batch_id".
|
|
events: start_add_batch and end_add_batch. The parameter is a batch
id which is generated on the first add request. The protocol is call
the add_photo as many times as required and then call finish when
done.
Also renamed the add method in local_import to add_photo so it is
consistent with simple_uploader
|
|
mirror the drupal pattern of using braces {}.
|
|
tag, search, comment and notification modules (Ticket #68)
|
|
|
|
idea. Instead convert movies to jpeg before doing any
transformations, which keeps the graphics functions clean and abstract
and dealing solely with image types. Lighter/simpler solution.
|
|
2) Protect the fullsize image with a permission check
3) Added a content:encoded element to each item which allows the image to show up in the body of the feed.
|
|
|
|
* Added new field in items table (path) which is sanitized version of
name.
* Added __set method on Items_module to set the path field whenever
the name field is changed.
* Made some changes to the scaffolding so missing the path column
would not kill the scaffolding.
* Changed MY_url::site so not having a 3rd parameter won't throw an error.
|
|
have a welcome page.
|
