approach.
- Rearrange Simple_Uploader_Controller::add_photo() to validate
the form early in the process, and switch to using model based
validation.
- Move thumbnail generation into gallery_event::item_created() so
that it's decoupled from the model.
- Delete photo::create() and move all of its logic into
Item_Model::save().
- Add Item_Model::$data_file to track the data file associated
with new movies and photos.
- Do some cleanup on the validation callbacks -- it turns out the
2nd argument is the field name not the value.
guess how to send the user back. Instead, proxy the originating item
id through the edit forms so that we can tell exactly what page we
were on when we began editing. If we were viewing the item, then
redirect to its new url (in case it changed) to fix ticket #745. But
if we were viewing some other item, then just stay on the current page
to fix#940.
The page_type approach didn't work because you'd have the same
"collection" page_type when doing a context menu edit for an album.
If you can change the extension, then you can alter the way the server
handles the file, which is a security problem. So for example, you
can change a .JPG to a .PHP and then if you put some malicious PHP
code in the EXIF data, you can get the server to execute
it. Vulnerability is low because only users who have edit permissions
could do this.
Fixes ticket #846
component for that given item. Album hierarchies are represented by
nested slugs. By default, we convert the filename to a slug when you
create an album, photo or movie.
instead it throws an exception if there's a problem. The normal case
for graphics::generate is that it's going to succeed. It'll only fail
if something un-handleable went wrong, so just use the resulting
exception.
This required putting a wrapper view around the forms and passing
this view as the parameter to the item_edit_form event. The view
contains a $script variable that the modules can add script to be
included in the form html when rendered as part of the ajax response.
good pattern for allowing modules to add their own hooks to item forms!
1) Album, photo and movie forms now all use edit_item as the group and
we publish item_edit_form and item_edit_form_completed events which
makes it much easier in the module to handle all events. They can
still differentiate based on $item->type if they want to.
2) Added tag::clear_all() and tag::compact() functions which takes the
place of hiwilson's tag::update() function and is now used in
tag_event::item_delete(). This provides a simple API that allows
us to have a lot less event handling code. It's less efficient
than what hiwilson was doing before in that it will delete and
re-add tags, but if that ever turns out to be a performance issue
we can do something about it then.
related events from within the model handling code. The only
exception to this currently is item_created which is challenging
because we have to save the item using ORM_MPTT::add_to_parent()
before the object itself is fully set up. When we get that down to
one call to save() we can publish that event from within the model
also.
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.
