contents of the file, which enables REST viewers to see the actual
data which is useful when the files are privileged. Currently it
returns the contents of the file in JSON encoded form, which may not
be the best. Multipart/mime might be much better.
Fixes ticket #1224.
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.
module ordering, which is currently being done in the moduleorder
contrib module.
By default, the weight will be the same as the id of the row which
means that new modules will get added at the end of the list. This is
covered in the upgrade case as well.
The one gotcha is that we need to make sure that we don't try to sort
by the weight column if the gallery module version is < 32, which is
something we haven't done before.
Fixes ticket #1272.
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.
// Override the application/json mime type. The dialog based HTML uploader uses an iframe to
// buffer the reply, and on some browsers (Firefox 3.6) it does not know what to do with the
// JSON that it gets back so it puts up a dialog asking the user what to do with it. So force
// the encoding type back to HTML for the iframe.
// See: http://jquery.malsup.com/form/#file-upload
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));
}
