The Museum that aims to expose the ongoing invisible unacceptable barbarity of the war that has killed more than 5 millions people to the outside world.
The Mobilization of Justice and Peace in the D.R. Congo (MJPC)has launch what it has described as phase one of its online museum of victims of the war in the D.R.Congo. According to the project coordinator of the MJPC, Amede Kyubwa, the online museum aims to expose this war, remaining virtually invisible to the outside world despite ongoing unacceptable barbarity, and aims to expose how innocent people in Congo continue to suffer massive human rights violations while armed groups responsible for these crimes go unpunished.
The online museum, available at http://www.yoursilenceoncongo.org , is currently developing its collections policy and plan to determine the scope of the collections. "The museum will make particular use of collected images/photos of the war victims and help prevent similar catastrophes in the future," said Mr. Kyubwa.
As part of denouncing the serious war crimes going unpunished in Congo, MJPC recently launched a petition to collect signatures demanding the United Nations Mission in Congo (MONUC) to immediately arrest the notorious war criminal Nkunda. Concerned citizens from around the world are signing the petition, including those from Australia, Belgium, Brazil, Canada, the USA, Kenya, Rwanda, France, German, Denmark, Germany, Italy, New Zealand, Norway, the Philippines, South Africa, Malawi, Burundi, Senegal, Nigeria, Spain, Japan, the UK, Venezuela, China, Zimbabwe, Tanzania, and Uganda. "There is no justification for MONUC, which has more than 17,000 troops in the DRC, to not take concrete actions to arrest Nkunda who is the subject of an international arrest warrant for war crimes and crimes against humanity since 2005," added Mr. Kyubwa.
The conflict in the Democratic Republic of Congo remains the deadliest conflict since World War II. More than 5 million people, mostly civilians, have died in the past decade, yet the war remains unknown. A particularly horrifying aspect of the conflict is the mass sexual violence being used as a weapon of war. Estimates are now at more than 1.3 million displaced people in North Kivu Province alone and there are more than 370,000 Congolese refugees who have sought safety in neighboring countries.
According to Mr. Kyubwa, the online museum is also designed to dignify victims by recognizing their suffering and raise public awareness regarding the importance of an urgent intervention in the eastern Congo to stop the ongoing impunity, sexual violence, crimes against humanity, and war crimes and to bring those responsible to justice without further delay.
About MJPC.
MJPC (www.mjpcongo.org )seeks to add a voice in advocating for justice and peace in the Democratic Republic of the Congo. To visit the online museum of victims of the war in the Congo please visit http://www.yoursilenceoncongo.org . For information on signing the ongoing petition demanding the U.N. in Congo (MONUC) immediately arrest war criminal Nkunda, please visit our website.
In this demo, the link underneath the attached media to FFMEG seems to have magically appeared. Is there somewhere that I need to enable this, because with ffmeg properly configured and installed (and media mover as well), I do not get this link underneath attached media.
how's we can get output format list.... i see on your screencast there's output format list on combobox, but not in mine... i'm using ffmpeg_converter 6.x-1.x-dev and 6.x-1.1-alpha1.
TIA
Seems to stop AHAH because of the "." in the file name. When I stripped them out, things work fine. I'm guessing this has to do with javascript, but I have not code dived this.
It's not just for security, but also correctness. Suppose you have the file "Bed&Breakfast.pdf"; an unencoded ampersand in HTML leads to a validation error, and in some cases to very surprising results, depending on the characters after the ampersand. In HTML you need "Bed&Breakfast.pdf". The function to do the conversion: check_plain.
Drupal has the philosophy to escape when mixing contexts (plaintext, html, mime headers, SQL).
Thanks for taking the time to go through this and illuminate where I was off base. I figured I was, but it is good to know where. A few threaded responses and I'll post the code changes once I complete them back to the post.
That's because you use:
$form['files']['#options'][] = $file;
See the PHP manual - "Creating/modifying with square bracket syntax" for an explanation of $array[].
Ok good point. I should have caught that one. One of those to many things going on, not paying enough attention to things. Originally I tried $form['files']['#options'] = $files but I think other issues (namely the theming) got int the way. Sigh.
$form['files'][$file]['name'] = array('#type' => 'markup', '#value' => basename($file))
Filenames are not HTML and they need to be escaped with check_plain before you mix them into an HTML context.
Huh. I am sort of surprised by this. Not that I don't agree with you that check_plain() is good practice, but wouldn't the Drupal upload process sanitize things already?
Radios seem to (at least from my testing here) operate differently than checkboxes with their #options property. Where checkboxes will take a value and a name, radios will take a name- in the form generation the value gets set to the number of radios there are- if you have 3 radios, their values are 0-2 respectively.
That's because you use:
$form['files']['#options'][] = $file;
See the PHP manual - "Creating/modifying with square bracket syntax" for an explanation of $array[].
If in doubt, try a simple test case such as below and you will see that the options key is what ends up in $form_state['values']:
Filenames are not HTML and they need to be escaped with check_plain before you mix them into an HTML context.
This perhaps where somebody who knows all the dark corners of the forms API can illuminate if what I'm about to do is just a ridiculous hack or the only tool in the shed.
This is a ridiculous hack. Unserializing userinput will get you into trouble quickly. It is also unneeded. You can store information in custom properties in the form array. $form['#some_val'] = $data. In the JS callback you can use $cached_form = form_get_cache($_POST['form_build_id'], &$cached_form_state) to retrieve the form definition.
Again, I do take the point that jQuery does take away the significant bulk of what I ran into. I think the argument against AHAH in this case is highlighted in the screen cast that I did- the form submission is does not use AHAH at all. However, what I'd like to do (and obviously, I was not clear about this) is use AHAH to check in on the status of the FFmpeg conversion and use the progress bar to report back to the user. This adds a huge level of complexity in that isn't at all in my post, but it was the direction that I'm aiming for. Or maybe I'm trying to make excuses :)
Hi Arthur,
I'd have to agree with dalin on this one - AHAH is for rendering new form elements and it's all about the AHAH callback and how to render them to make FAPI happy (er... no rhyme intended :-P). It's true that it means you don't have to write any jQuery yourself but that also means you don't have much flexibility in terms of extra information you can send to your callback. When all you're rendering is some information, as opposed to new form elements, a simple ajax callback is all you need and as dalin suggested you can pass the file information to your jQuery as an array in your settings variable. Then your callback path can take the file id as an argument and pass back the information for that file. Personally, I think the jQuery side of it is way easier than what you need to do in a full-on AHAH callback. But it's all a question of what you're comfortable with I suppose.
You're right that I could use jQuery to load the data in to the page. It is probably the case that it would make things simpler- for example, on the form submit, the $form['files_lookup'] could be a value instead of the serialized data (ultimately not that big a deal, but certainly not pretty) which would make the form workflow simpler.
From my perspective, since the actions are taking place on the form and I wanted an excuse to play around AHAH, I tied it to the form route. I like having all the action in one place, but I cost myself several hours doing it.
It is worth noting however that the AHAH stuff was remarkably fast and easy- except for the $_POST issue. In fact, I'd say it was as easy or easier than writing out the jQuery, but I think millage may vary.
You might be making things more complicated than it needs to be. Do you really need to use AHAH, or just a bit of simple jQuery? You're not actually changing the form, just adding a bit of bonus information. I think you might be able to just add the file information with drupal_add_js($file_array, 'setting'); You can then access that data via jQuery when the value of the radios change and build the table.
I think you are right- AHAH is a hurdle to get over, but at least for me, once I made the leap, it seems really straightforward- except of course when you start running into issues that seem to be related to constraints either in html elements or the forms API.
As per clean urls, no I didn't have any issues with them, however, I did try passing arguments back to the AHAH url and had no luck doing so. I also tried to do things like:
Which either did not work, or I had something else going on that made me think it was not working. I think that maybe one of the hardest things to deal with in the AHAH integration- you have so many moving parts between the forms API, a multistep form (well, I guess this is called something else under D6), and the AHAH itself that it can be challenging to figure out just where it is not working.
I haven't been working anything together with File info (which this is really cool btw) but I can definitely share the mental pains :) I've recently implemented some AHAH forms into the Book Administration drag/drop page and had a lot of trouble doing so. Did you experience any issues other then having fun fighting with the code? It was definitely a shift in thinking for me to finally get it working. Did you have any issues with AHAH and clean-urls? That site doesn't but I'm having some weird issues w/ it not working on various servers (specific to the AHAH calls).
Though Media Mover does offer S3 integration, along with email and ftp and a number of Drupal specific file harvesting mechanisms, I'm always interested in other solutions- I'd be game to talk integration- looking at the API seems like it could be straight forward to implement for Drupal
If you are interested in another approach to transcoding, check out the service I run called Mux. In short, we have an API, along with some sample PHP code (among other languages) that you can use to transcode video with all the primary controls you need: mimetype, framerate, resolution, bitrate, etc...
Best of all, you can use Mux free for low volume transcoding or scale up to your own servers running on Amazon EC2 and S3 if you need more video storage and streaming power than one Drupal box can handle.
Screencast helped. I will give Asset a try.
The Museum that aims to expose the ongoing invisible unacceptable barbarity of the war that has killed more than 5 millions people to the outside world.
The Mobilization of Justice and Peace in the D.R. Congo (MJPC)has launch what it has described as phase one of its online museum of victims of the war in the D.R.Congo. According to the project coordinator of the MJPC, Amede Kyubwa, the online museum aims to expose this war, remaining virtually invisible to the outside world despite ongoing unacceptable barbarity, and aims to expose how innocent people in Congo continue to suffer massive human rights violations while armed groups responsible for these crimes go unpunished.
The online museum, available at http://www.yoursilenceoncongo.org , is currently developing its collections policy and plan to determine the scope of the collections. "The museum will make particular use of collected images/photos of the war victims and help prevent similar catastrophes in the future," said Mr. Kyubwa.
As part of denouncing the serious war crimes going unpunished in Congo, MJPC recently launched a petition to collect signatures demanding the United Nations Mission in Congo (MONUC) to immediately arrest the notorious war criminal Nkunda. Concerned citizens from around the world are signing the petition, including those from Australia, Belgium, Brazil, Canada, the USA, Kenya, Rwanda, France, German, Denmark, Germany, Italy, New Zealand, Norway, the Philippines, South Africa, Malawi, Burundi, Senegal, Nigeria, Spain, Japan, the UK, Venezuela, China, Zimbabwe, Tanzania, and Uganda. "There is no justification for MONUC, which has more than 17,000 troops in the DRC, to not take concrete actions to arrest Nkunda who is the subject of an international arrest warrant for war crimes and crimes against humanity since 2005," added Mr. Kyubwa.
The conflict in the Democratic Republic of Congo remains the deadliest conflict since World War II. More than 5 million people, mostly civilians, have died in the past decade, yet the war remains unknown. A particularly horrifying aspect of the conflict is the mass sexual violence being used as a weapon of war. Estimates are now at more than 1.3 million displaced people in North Kivu Province alone and there are more than 370,000 Congolese refugees who have sought safety in neighboring countries.
According to Mr. Kyubwa, the online museum is also designed to dignify victims by recognizing their suffering and raise public awareness regarding the importance of an urgent intervention in the eastern Congo to stop the ongoing impunity, sexual violence, crimes against humanity, and war crimes and to bring those responsible to justice without further delay.
About MJPC.
MJPC (www.mjpcongo.org )seeks to add a voice in advocating for justice and peace in the Democratic Republic of the Congo. To visit the online museum of victims of the war in the Congo please visit http://www.yoursilenceoncongo.org . For information on signing the ongoing petition demanding the U.N. in Congo (MONUC) immediately arrest war criminal Nkunda, please visit our website.
In this demo, the link underneath the attached media to FFMEG seems to have magically appeared. Is there somewhere that I need to enable this, because with ffmeg properly configured and installed (and media mover as well), I do not get this link underneath attached media.
how's we can get output format list.... i see on your screencast there's output format list on combobox, but not in mine... i'm using ffmpeg_converter 6.x-1.x-dev and 6.x-1.1-alpha1.
TIA
The cursed (and much loved) HTML filter preempted me from posting what I meant. Imagine there's no space between & and amp;
In HTML you need "Bed & amp; Breakfast.pdf"
So I dug around a bit more and figured this out:
$form['test'] = array( '#type' => 'radios', '#default_value' => $form_state['values']['files'], '#options' => array('tnt_3.wmv.flv' => 'tnt_3.wmv.flv'), '#ahah' => array( 'event' => 'change', 'path' => 'ffmpeg_wrapper/file_data', 'wrapper' => 'file_data_display_test', 'method' => 'replace', ), );Seems to stop AHAH because of the "." in the file name. When I stripped them out, things work fine. I'm guessing this has to do with javascript, but I have not code dived this.
It's not just for security, but also correctness. Suppose you have the file "Bed&Breakfast.pdf"; an unencoded ampersand in HTML leads to a validation error, and in some cases to very surprising results, depending on the characters after the ampersand. In HTML you need "Bed&Breakfast.pdf". The function to do the conversion: check_plain.
Drupal has the philosophy to escape when mixing contexts (plaintext, html, mime headers, SQL).
Ah, flvmediaplayer did not like dealing with multiple domains. I just fixed it. Thanks for the heads up.
Your screencast generates an error #2048 in it's flashplayer
Thanks for taking the time to go through this and illuminate where I was off base. I figured I was, but it is good to know where. A few threaded responses and I'll post the code changes once I complete them back to the post.
Ok good point. I should have caught that one. One of those to many things going on, not paying enough attention to things. Originally I tried $form['files']['#options'] = $files but I think other issues (namely the theming) got int the way. Sigh.
Huh. I am sort of surprised by this. Not that I don't agree with you that check_plain() is good practice, but wouldn't the Drupal upload process sanitize things already?
Thanks for this link. For what ever reason, I did not find it.
That's because you use:
See the PHP manual - "Creating/modifying with square bracket syntax" for an explanation of $array[].
If in doubt, try a simple test case such as below and you will see that the options key is what ends up in $form_state['values']:
Next:
Filenames are not HTML and they need to be escaped with check_plain before you mix them into an HTML context.
This is a ridiculous hack. Unserializing userinput will get you into trouble quickly. It is also unneeded. You can store information in custom properties in the form array. $form['#some_val'] = $data. In the JS callback you can use $cached_form = form_get_cache($_POST['form_build_id'], &$cached_form_state) to retrieve the form definition.
For more information read katbailey's excellent http://katbailey.net/blog/katherine/the-dual-aspect-of-drupal-forms-and-...
As the last tip: when you bite off more than you can chew, scale back. Experiment with small subproblems until perfection, then integrate.
Again, I do take the point that jQuery does take away the significant bulk of what I ran into. I think the argument against AHAH in this case is highlighted in the screen cast that I did- the form submission is does not use AHAH at all. However, what I'd like to do (and obviously, I was not clear about this) is use AHAH to check in on the status of the FFmpeg conversion and use the progress bar to report back to the user. This adds a huge level of complexity in that isn't at all in my post, but it was the direction that I'm aiming for. Or maybe I'm trying to make excuses :)
Hi Arthur,
I'd have to agree with dalin on this one - AHAH is for rendering new form elements and it's all about the AHAH callback and how to render them to make FAPI happy (er... no rhyme intended :-P). It's true that it means you don't have to write any jQuery yourself but that also means you don't have much flexibility in terms of extra information you can send to your callback. When all you're rendering is some information, as opposed to new form elements, a simple ajax callback is all you need and as dalin suggested you can pass the file information to your jQuery as an array in your settings variable. Then your callback path can take the file id as an argument and pass back the information for that file. Personally, I think the jQuery side of it is way easier than what you need to do in a full-on AHAH callback. But it's all a question of what you're comfortable with I suppose.
KB
You're right that I could use jQuery to load the data in to the page. It is probably the case that it would make things simpler- for example, on the form submit, the $form['files_lookup'] could be a value instead of the serialized data (ultimately not that big a deal, but certainly not pretty) which would make the form workflow simpler.
From my perspective, since the actions are taking place on the form and I wanted an excuse to play around AHAH, I tied it to the form route. I like having all the action in one place, but I cost myself several hours doing it.
It is worth noting however that the AHAH stuff was remarkably fast and easy- except for the $_POST issue. In fact, I'd say it was as easy or easier than writing out the jQuery, but I think millage may vary.
You might be making things more complicated than it needs to be. Do you really need to use AHAH, or just a bit of simple jQuery? You're not actually changing the form, just adding a bit of bonus information. I think you might be able to just add the file information with drupal_add_js($file_array, 'setting'); You can then access that data via jQuery when the value of the radios change and build the table.
Hi btopro-
I think you are right- AHAH is a hurdle to get over, but at least for me, once I made the leap, it seems really straightforward- except of course when you start running into issues that seem to be related to constraints either in html elements or the forms API.
As per clean urls, no I didn't have any issues with them, however, I did try passing arguments back to the AHAH url and had no luck doing so. I also tried to do things like:
'#ahah' => array( 'path' => 'ffmpeg_wrapper/file_data?path=sites/default/files/myfile.mov'Which either did not work, or I had something else going on that made me think it was not working. I think that maybe one of the hardest things to deal with in the AHAH integration- you have so many moving parts between the forms API, a multistep form (well, I guess this is called something else under D6), and the AHAH itself that it can be challenging to figure out just where it is not working.
Thanks for the catch.
The link to the FFmpeg Wrapper points erroneously to projects/ffmpeg_wrapper. The correct URL is http://www.drupal.org/project/ffmpeg_wrapper :)
I haven't been working anything together with File info (which this is really cool btw) but I can definitely share the mental pains :) I've recently implemented some AHAH forms into the Book Administration drag/drop page and had a lot of trouble doing so. Did you experience any issues other then having fun fighting with the code? It was definitely a shift in thinking for me to finally get it working. Did you have any issues with AHAH and clean-urls? That site doesn't but I'm having some weird issues w/ it not working on various servers (specific to the AHAH calls).
[...] Vote Media Mover: RC 1 and Alpha 4 [...]
Though Media Mover does offer S3 integration, along with email and ftp and a number of Drupal specific file harvesting mechanisms, I'm always interested in other solutions- I'd be game to talk integration- looking at the API seems like it could be straight forward to implement for Drupal
If you are interested in another approach to transcoding, check out the service I run called Mux. In short, we have an API, along with some sample PHP code (among other languages) that you can use to transcode video with all the primary controls you need: mimetype, framerate, resolution, bitrate, etc...
You can try our free, web-based UI at http://mux.am or learn about our API access at http://muxcloud.com
Best of all, you can use Mux free for low volume transcoding or scale up to your own servers running on Amazon EC2 and S3 if you need more video storage and streaming power than one Drupal box can handle.
Conversion from WP missed a few things!
This sounds like it could help, but I can't see the link to the screencast you mention. Is it here somewhere?
Am I missing something? Where's the link to the screencast? ;)