provide a "show_user_profiles_to" setting to allow admins to open it
up to everybody (choices there are "registered_users", "admin_users"
or "everybody"). Fixes ticket #1378.
The photo view page caches the dimensions of the full size and then
renders it in Javascript. But after rotation, those dimensions are no
longer valid. Create a new function on the items controller that
returns the appropriate dimensions, then add a hook on
$.gallery_replace_image and implement the hook on the photo view page
to have it make an async call to get the new dimensions.
Fixes ticket #1317
a call to Organize with the appropriate album open. I have not yet
figured out how to get the SWF code to highlight the active image, but
that's coming. Partial fix for #1204.
Refactor the rotate code in Quick_Controller to replace the data file,
and then have gallery_event::item_updated_data_file() pick up after
the change is saved, rebuild the image and handle album covers. This
is much more portable than before and it will allow any mechanism (eg:
REST) to replace the source image.
links on the Admin > Maintenance page to allow you to turn it on and
off. This should be efficient since we cache all vars and look them
up on every request anyway.
This also allows us to have the Fix task enable maintenance mode while
it's running which greatly reduces the chances that somebody will come
along and hork the database while we're tinkering with MPTT pointers.
Fixes ticket #1259.
by the following rules:
1) An initial dialog or panel load can take either HTML or JSON, but
the mime type must accurately reflect its payload.
2) dialog form submits can handle a pure HTML response, but the mime
type must also be correct. This properly resolves the problem
where the reauth code gets a JSON response first from the reauth
code, and then an HTML response when you reauth and continue on to
a given form -- try it out with Admin > Settings > Advanced.
3) All JSON replies must set the mime type correctly. The json::reply
convenience function does this for us.
4) By default, any HTML content sent back in the JSON response should be
in the "html" field, no longer the "form" field.
The combination of these allows us to stop doing boilerplate code like
this in our controllers:
// Print our view, JSON encoded
json::reply(array("form" => (string) $view));
instead, controllers can just return HTML, eg:
// Print our view
print $view;
That's much more intuitive for developers.
I've done some tests on a 60M flv and found that there's no difference
in memory consumption with these three approaches:
public function test() {
Kohana::close_buffers(false);
$file = "/home/bharat/basketball.flv";
if ($fd = fopen($file, "rb")) {
while (true) {
$bits = fread($fd, 65535);
if (strlen($bits) == 0) {
break;
}
print $bits;
set_time_limit(30);
}
fclose($fd);
}
Kohana_Log::add("error","test: " . print_r(array(memory_get_peak_usage(true),memory_get_peak_usage(false)),1));
}
public function test2() {
Kohana::close_buffers(false);
$file = "/home/bharat/basketball.flv";
$fd = fopen($file, "rb");
fpassthru($fd);
fclose($fd);
Kohana_Log::add("error","test2: " . print_r(array(memory_get_peak_usage(true),memory_get_peak_usage(false)),1));
}
public function test3() {
Kohana::close_buffers(false);
$file = "/home/bharat/basketball.flv";
readfile($file);
Kohana_Log::add("error","test3: " . print_r(array(memory_get_peak_usage(true),memory_get_peak_usage(false)),1));
}
Hide the fieldset and legend in the theme, since they don't add any value.
Change l10n_client::_server_url() to use the short style GMC urls and make the
API a little tighter.
deletes in bulk. This lets us avoid the problem where we continually
choose and delete album covers which makes deletes really slow. It
probably also avoids huge amounts of notification emails (untested).
Fixes ticket #1190.
see if we're deleting the album we're inside in quick::delete. If we
delete the album we're currently viewing, redirect to the parent.
This fixes ticket #1185.
