Moodle
  1. Moodle
  2. MDL-33640

Add ability to use custom filepicker templates

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3, 2.3.1
    • Fix Version/s: 2.3.2
    • Component/s: Filepicker, Repositories
    • Labels:
    • Testing Instructions:
      Hide
      • Install MDL-33640_full branch of Record Audio repository (https://github.com/MaxThrax/moodle-repository_recordaudio/tree/MDL-33640_full) - this branch contains a partial rewrite which utilises the proper template support added by this enhancement
      • Enable Record Audio repository
      • In a file picker, click the "Add..." button and make sure that the standard "Upload a file" repository appears correctly and functions as expected
      • In a file picker, click the "Add..." button and make sure that the "Record Audio" repository appears correctly (Author and License fields, followed by "Make a Recording" with the Flash recording widget) and functions as expected

      Note: Flash Player 10.1 or above is required for the "Record Audio" repository. No streaming server is required.

      Show
      Install MDL-33640 _full branch of Record Audio repository ( https://github.com/MaxThrax/moodle-repository_recordaudio/tree/MDL-33640_full ) - this branch contains a partial rewrite which utilises the proper template support added by this enhancement Enable Record Audio repository In a file picker, click the "Add..." button and make sure that the standard "Upload a file" repository appears correctly and functions as expected In a file picker, click the "Add..." button and make sure that the "Record Audio" repository appears correctly (Author and License fields, followed by "Make a Recording" with the Flash recording widget) and functions as expected Note: Flash Player 10.1 or above is required for the "Record Audio" repository. No streaming server is required.
    • Difficulty:
      Easy
    • Affected Branches:
      MOODLE_23_STABLE
    • Fixed Branches:
      MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-33640_master
    • Rank:
      41631

      Description

      It's currently possible to create and register a custom filepicker template, but none of the print/create methods that can be called by display_response have the ability to use custom templates. It would be very useful if there was a way to specify another attribute in the return value from the repository subclass which overrode this - my current workaround (for my audio recording repository plugin - https://github.com/MaxThrax/moodle-repository_recordaudio) is to override the "uploadform" template with a custom one which adds my extra code with a CSS file that simply hides it for anything but my repository, but it's not the nicest approach and isn't extensible (as it stands, if somebody else wanted to do the same thing, their repository and mine would not be entirely compatible unless both included code from each other).

      For the record, I chose not to use the text/html object approach used in the Equella repository as my plugin piggybacks on the standard upload method - so the easiest approach seems to be to piggyback on the standard upload form. I can imagine other plugins wanting to do similar things, so it seems like the best solution would be to make it easy to use a custom template (perhaps even make it easier to register custom templates) in the create_upload_form function, even if the other print/create functions don't get this ability just yet (I can see it potentially being useful for print_login too, but I don't personally have a use for it at present).

      Please feel free to ask for more details, and to take a look at my repository plugin to see my workaround. I may take a while to reply, as I'm about to head overseas for the rest of the month - but I'll try to check my email at least every couple of days.

        Issue Links

          Activity

          Hide
          Paul Nicholls added a comment -

          This enhancement would be a suitable replacement for MDL-33444

          Show
          Paul Nicholls added a comment - This enhancement would be a suitable replacement for MDL-33444
          Hide
          Martin Dougiamas added a comment -

          Unfortunately there is no way this can make 2.3 but we should think about it for 2.4.

          Show
          Martin Dougiamas added a comment - Unfortunately there is no way this can make 2.3 but we should think about it for 2.4.
          Hide
          Paul Nicholls added a comment - - edited

          Hi Martin,
          How about if I do the work?

          One-liner attached to add support for it to create_upload_form, which is the main use-case I can see (and would be enough for my case) - but the same approach could be used to add it to print_login and/or any other similar functions if desired.

          Cheers,
          Paul

          P.S. Here's a diff of the change required to my repo plugin to take advantage of this - also very simple: https://github.com/MaxThrax/moodle-repository_recordaudio/commit/73d1004543d8a6b1b0ed1bab204367b430bec193

          Show
          Paul Nicholls added a comment - - edited Hi Martin, How about if I do the work? One-liner attached to add support for it to create_upload_form, which is the main use-case I can see (and would be enough for my case) - but the same approach could be used to add it to print_login and/or any other similar functions if desired. Cheers, Paul P.S. Here's a diff of the change required to my repo plugin to take advantage of this - also very simple: https://github.com/MaxThrax/moodle-repository_recordaudio/commit/73d1004543d8a6b1b0ed1bab204367b430bec193
          Hide
          Ankit Gupta added a comment - - edited

          Nice work Paul. I have been facing a similar issue and have used workarounds to add the custom label to the upload form instead. That could be a solution.

          Show
          Ankit Gupta added a comment - - edited Nice work Paul. I have been facing a similar issue and have used workarounds to add the custom label to the upload form instead. That could be a solution.
          Hide
          Ankit Gupta added a comment -

          Just to update this issue too. I have been able to rewrite the plugin using the new filepicker API.

          https://github.com/ankitdbst/moodle-repository_mediacapture

          Show
          Ankit Gupta added a comment - Just to update this issue too. I have been able to rewrite the plugin using the new filepicker API. https://github.com/ankitdbst/moodle-repository_mediacapture
          Hide
          Paul Nicholls added a comment -

          I've added 2.3.1 as an affected version, and bumped the priority - this really ought to be dealt with ASAP (especially since it's such a trivial change) so that anyone wanting to do something similar doesn't come along and inadvertently make a repo plugin that's incompatible with mine by attempting to copy how I've done it. Martin and Marina, could you please look at getting it into the next 2.3 point-release? Now that I'm (mostly) caught up after my time away, I'm happy to extend the ability to other methods (beyond create_upload_form) and rebase my diffs against the latest master and 2.3, if that'll help convince you to integrate it

          Show
          Paul Nicholls added a comment - I've added 2.3.1 as an affected version, and bumped the priority - this really ought to be dealt with ASAP (especially since it's such a trivial change) so that anyone wanting to do something similar doesn't come along and inadvertently make a repo plugin that's incompatible with mine by attempting to copy how I've done it. Martin and Marina, could you please look at getting it into the next 2.3 point-release? Now that I'm (mostly) caught up after my time away, I'm happy to extend the ability to other methods (beyond create_upload_form) and rebase my diffs against the latest master and 2.3, if that'll help convince you to integrate it
          Hide
          Marina Glancy added a comment - - edited

          Paul, I really doubt that this is a good solution.
          Filepicker templates are defined in renderer. The idea of renderer is that it can be overwritten in theme. In your case html template is hardcoded inside the repository plugin. Besides I don't like the code

          $PAGE->requires->js_init_call('M.core_filepicker.set_templates', array($templates), true); 
          

          First, if repository constructor is called several times, you will include this template several times on the page. Second, it will overwrite the template defined by renderer if there is one, and it should be vice versa. And last, repository constructor is not the correct place for this at all. Templates should be set only on the pages that have filepicker. How do you know if core_filepicker module is included?

          I suggest you to look at the 'object' attribute, using which you can overwrite the upload form completely. It is used in core plugin repository_equella. Also Ankit Gupta used it in his repository_mediacapture (see his post above). Although Ankit used the file name 'renderer.php' which is reserved in moodle for defining the renderer classes. This is not correct, please do not copy this.

          Show
          Marina Glancy added a comment - - edited Paul, I really doubt that this is a good solution. Filepicker templates are defined in renderer. The idea of renderer is that it can be overwritten in theme. In your case html template is hardcoded inside the repository plugin. Besides I don't like the code $PAGE->requires->js_init_call('M.core_filepicker.set_templates', array($templates), true ); First, if repository constructor is called several times, you will include this template several times on the page. Second, it will overwrite the template defined by renderer if there is one, and it should be vice versa. And last, repository constructor is not the correct place for this at all. Templates should be set only on the pages that have filepicker. How do you know if core_filepicker module is included? I suggest you to look at the 'object' attribute, using which you can overwrite the upload form completely. It is used in core plugin repository_equella. Also Ankit Gupta used it in his repository_mediacapture (see his post above). Although Ankit used the file name 'renderer.php' which is reserved in moodle for defining the renderer classes. This is not correct, please do not copy this.
          Hide
          Ankit Gupta added a comment - - edited

          @Marina Glancy. Wasn't aware of the reserved name. Corrected it. Thank you.
          P.S. I am trying to fix a bug while using $mform for replacing raw html with moodle forms in the framework. Please see this http://goo.gl/vSs8T commit for a working example.

          Show
          Ankit Gupta added a comment - - edited @Marina Glancy. Wasn't aware of the reserved name. Corrected it. Thank you. P.S. I am trying to fix a bug while using $mform for replacing raw html with moodle forms in the framework. Please see this http://goo.gl/vSs8T commit for a working example.
          Hide
          Paul Nicholls added a comment -

          Marina, the way I'm doing it at the moment is just the way that worked - I'd understand (and agree) 100% if you'd rather see it implemented in a more robust way. I have a couple of suggested approaches:

          • optional templates.php in the plugin directory
          • optional static method in the repository_pluginname class which returns the relevant info
            Either approach would be triggered (included or called) once only, at the same time that the core templates are set up.

          If you (HQ) are happy with the idea of adding support for custom filepicker templates, I'm happy to work on actually implementing it if need be - just let me know whether you're happy with either of the approaches above, or if not, how you'd rather see it implemented.

          In the interim, time allowing, I may investigate rewriting my plugin to use the object approach - but even if I do, I'd still like to see custom template support added, as I think it's a tidier way to implement certain things than the object approach.

          Show
          Paul Nicholls added a comment - Marina, the way I'm doing it at the moment is just the way that worked - I'd understand (and agree) 100% if you'd rather see it implemented in a more robust way. I have a couple of suggested approaches: optional templates.php in the plugin directory optional static method in the repository_pluginname class which returns the relevant info Either approach would be triggered (included or called) once only, at the same time that the core templates are set up. If you (HQ) are happy with the idea of adding support for custom filepicker templates, I'm happy to work on actually implementing it if need be - just let me know whether you're happy with either of the approaches above, or if not, how you'd rather see it implemented. In the interim, time allowing, I may investigate rewriting my plugin to use the object approach - but even if I do, I'd still like to see custom template support added, as I think it's a tidier way to implement certain things than the object approach.
          Hide
          Marina Glancy added a comment -

          Paul, you still did not persuade me. Why would we make those templates when we have 'object'? I still can not see any advantages - what will templates allow that objects don't?
          at the moment:

          • For core upload repository the site admin can override the existing template in the theme.
          • For new repositories the repository developer can use 'object', create his own renderer and use it to display the object. Again, site admin can override this renderer in the theme.

          It is the standard way admin customises the output in moodle. Why do we need new API like template.php and static methods in repository plugins when we already have renderer.php and methods to return the renderer? This will make the life more difficult for users.

          Show
          Marina Glancy added a comment - Paul, you still did not persuade me. Why would we make those templates when we have 'object'? I still can not see any advantages - what will templates allow that objects don't? at the moment: For core upload repository the site admin can override the existing template in the theme. For new repositories the repository developer can use 'object', create his own renderer and use it to display the object. Again, site admin can override this renderer in the theme. It is the standard way admin customises the output in moodle. Why do we need new API like template.php and static methods in repository plugins when we already have renderer.php and methods to return the renderer? This will make the life more difficult for users.
          Hide
          Paul Nicholls added a comment -

          Forcing repository developers to use "object" if all they're really after is a form seems like making us jump through hoops when the infrastructure to make it simpler already exists.

          Basically, it boils down to making it simpler to build 3rd-party repository plugins which build on existing/core functionality - rather than reinventing the wheel, the ability to register (and use) custom templates would confer the ability to reuse the wheels that already exist in Moodle core. There's already a system in place which does everything I need - except it uses a standard file input, whereas I need to use a bit of custom HTML (my recorder). Writing my own form and handler script, figuring out how to handle file name collisions, working out what function to call on the parent window when I'm done, and so on just seems completely unnecessary when Moodle core already knows how to handle it.

          I'm also worried about the long-term stability of the object approach - it wouldn't surprise me to see at least one major browser vendor either deliberately or inadvertently tighten security on same-origin frames/object embeds in a way that prevents the child page from calling methods in the parent page, which could break the plugin's ability to (for example) tell the file picker that a file has been chosen. For instance, with the advent of window.postMessage, browser vendors may start to shift towards that as the one and only way to send messages between frames/pages.

          Show
          Paul Nicholls added a comment - Forcing repository developers to use "object" if all they're really after is a form seems like making us jump through hoops when the infrastructure to make it simpler already exists. Basically, it boils down to making it simpler to build 3rd-party repository plugins which build on existing/core functionality - rather than reinventing the wheel, the ability to register (and use) custom templates would confer the ability to reuse the wheels that already exist in Moodle core. There's already a system in place which does everything I need - except it uses a standard file input, whereas I need to use a bit of custom HTML (my recorder). Writing my own form and handler script, figuring out how to handle file name collisions, working out what function to call on the parent window when I'm done, and so on just seems completely unnecessary when Moodle core already knows how to handle it. I'm also worried about the long-term stability of the object approach - it wouldn't surprise me to see at least one major browser vendor either deliberately or inadvertently tighten security on same-origin frames/object embeds in a way that prevents the child page from calling methods in the parent page, which could break the plugin's ability to (for example) tell the file picker that a file has been chosen. For instance, with the advent of window.postMessage, browser vendors may start to shift towards that as the one and only way to send messages between frames/pages.
          Hide
          Ankit Gupta added a comment -

          Hi Paul,

          I recently finished implementing a mediacapture plugin framework in Moodle 2.3 using the object. The plugin allows sub-plugins or recorders to operate within the framework. The plugin has a simple interface (very few functions) which every recorder must extend. Enabling them in the admin section allows the recorders to be available to the user.

          I have written a sample sub-plugin/recorder using nanogong. (Check plugins in the repository below)

          For more see this:
          https://github.com/ankitdbst/moodle-repository_mediacapture

          And as far as I know there is no requirement for accessing parent elements/methods in the object approach. It can have it's own set of js and css definitions.

          P.S. There may be some bugs. I am working on making the code stable and inline with moodle guidelines.

          Show
          Ankit Gupta added a comment - Hi Paul, I recently finished implementing a mediacapture plugin framework in Moodle 2.3 using the object. The plugin allows sub-plugins or recorders to operate within the framework. The plugin has a simple interface (very few functions) which every recorder must extend. Enabling them in the admin section allows the recorders to be available to the user. I have written a sample sub-plugin/recorder using nanogong. (Check plugins in the repository below) For more see this: https://github.com/ankitdbst/moodle-repository_mediacapture And as far as I know there is no requirement for accessing parent elements/methods in the object approach. It can have it's own set of js and css definitions. P.S. There may be some bugs. I am working on making the code stable and inline with moodle guidelines.
          Hide
          Paul Nicholls added a comment - - edited

          I've updated the pull details with a new, clean approach which allows plugins to register templates (which themes can override via the renderer) simply by defining a get_template() method. The template is registered under the plugin's name, so it shouldn't be able to conflict with existing templates - but any core templates will override plugin templates of the same name should a conflict arise. This makes things easier for plugin developers, without any noticeable change to users (except possibly nicer/better repository plugins!) and in a way that's still flexible enough to be overridden by themes.

          Marina, you asked why we need this "when we already have renderer.php and methods to return the renderer" - the answer to that is that while themes can override the renderer, repository plugins can't. I certainly don't think that they should be able to, either - because that would be giving each individual plugin far too much power. This approach results in a middle ground whereby the plugin can have input into the renderer by defining a template, which can then be overridden by a theme's renderer if desired. It adds no complexity for plugin developers - instead, it provides a cleaner, simpler alternative for some plugins.

          I considered conferring the ability to use custom templates on the login form as well as the upload form, but I decided against it since the login form is already pretty flexible - and the template isn't used directly, but rather is a collection of types of field which can be combined to produce the actual form.

          The attached patch is pretty trivial, has absolutely no impact on existing plugins and only adds functionality - since 2.3 is out there in the wild now, I don't necessarily expect this to make it into a 2.3 release (though it certainly shouldn't cause any problems, and it applies cleanly), but I'd really like to see this make it into 2.4.

          Show
          Paul Nicholls added a comment - - edited I've updated the pull details with a new, clean approach which allows plugins to register templates (which themes can override via the renderer) simply by defining a get_template() method. The template is registered under the plugin's name, so it shouldn't be able to conflict with existing templates - but any core templates will override plugin templates of the same name should a conflict arise. This makes things easier for plugin developers, without any noticeable change to users (except possibly nicer/better repository plugins!) and in a way that's still flexible enough to be overridden by themes. Marina, you asked why we need this "when we already have renderer.php and methods to return the renderer" - the answer to that is that while themes can override the renderer, repository plugins can't. I certainly don't think that they should be able to, either - because that would be giving each individual plugin far too much power. This approach results in a middle ground whereby the plugin can have input into the renderer by defining a template, which can then be overridden by a theme's renderer if desired. It adds no complexity for plugin developers - instead, it provides a cleaner, simpler alternative for some plugins. I considered conferring the ability to use custom templates on the login form as well as the upload form, but I decided against it since the login form is already pretty flexible - and the template isn't used directly, but rather is a collection of types of field which can be combined to produce the actual form. The attached patch is pretty trivial, has absolutely no impact on existing plugins and only adds functionality - since 2.3 is out there in the wild now, I don't necessarily expect this to make it into a 2.3 release (though it certainly shouldn't cause any problems, and it applies cleanly), but I'd really like to see this make it into 2.4.
          Hide
          Marina Glancy added a comment -

          Hi Paul,

          I like this approach much much more and I'm ready to agree with those templates. Still have some 'buts' for your implementation:

          The method should be called get_upload_template() because it is used only for upload. The same way I'd replace template name with:

          $templates['uploadform_'. $meta->type] = $repository->get_upload_template();
          

          In filepicker.js the template should also be passed as data.upload.template but maybe it's not necessary at all if we can check that the template with name 'uploadform_'+[repositorytype] exists

          And another observation:
          Imagine there are several filepickers on the page and the first one is, say, URL form element. It has very limited number of supported repositories and upload repositories are not among them. Your repository will not be in the list of repositories, therefore the template will not be picked up. When another filepicker is initialized, the $templatesinitialized is already true and the template won't be printed again.

          Maybe the static variable $templatesinitialized shall be an array with the repository name (or 'core') as key.
          It is safe to call M.core_filepicker.set_templates() several times, the templates will be appended to the list.

          Show
          Marina Glancy added a comment - Hi Paul, I like this approach much much more and I'm ready to agree with those templates. Still have some 'buts' for your implementation: The method should be called get_upload_template() because it is used only for upload. The same way I'd replace template name with: $templates['uploadform_'. $meta->type] = $repository->get_upload_template(); In filepicker.js the template should also be passed as data.upload.template but maybe it's not necessary at all if we can check that the template with name 'uploadform_'+ [repositorytype] exists And another observation: Imagine there are several filepickers on the page and the first one is, say, URL form element. It has very limited number of supported repositories and upload repositories are not among them. Your repository will not be in the list of repositories, therefore the template will not be picked up. When another filepicker is initialized, the $templatesinitialized is already true and the template won't be printed again. Maybe the static variable $templatesinitialized shall be an array with the repository name (or 'core') as key. It is safe to call M.core_filepicker.set_templates() several times, the templates will be appended to the list.
          Hide
          Paul Nicholls added a comment -

          Hi Marina,
          That makes sense - I named the method (and chose the template name) before I realised that it didn't make sense to allow custom templates on login forms; since the template name is fixed and it's only applicable to the upload form, I've also done as you suggest and made it automatically use the custom template if one exists. I also hadn't realised that initialise_filepicker() could be called multiple times with different repositories - I'd assumed that $repositories was an array of all enabled repositories.

          I've just pushed a new commit which makes the following changes:

          • $templatesinitialized is now an array, so that subsequent calls to initialise_filepicker which request different repositories will include those (and only those) templates which it requires but have not yet been included
          • The get_template method has also been renamed to get_upload_template (and the template to "uploadform_" followed by the repository type), since it only applies to upload forms
          • If a plugin provides a get_upload_template method, the template it returns will now automatically be used instead of the standard uploadform template when generating an upload form
          Show
          Paul Nicholls added a comment - Hi Marina, That makes sense - I named the method (and chose the template name) before I realised that it didn't make sense to allow custom templates on login forms; since the template name is fixed and it's only applicable to the upload form, I've also done as you suggest and made it automatically use the custom template if one exists. I also hadn't realised that initialise_filepicker() could be called multiple times with different repositories - I'd assumed that $repositories was an array of all enabled repositories. I've just pushed a new commit which makes the following changes: $templatesinitialized is now an array, so that subsequent calls to initialise_filepicker which request different repositories will include those (and only those) templates which it requires but have not yet been included The get_template method has also been renamed to get_upload_template (and the template to "uploadform_" followed by the repository type), since it only applies to upload forms If a plugin provides a get_upload_template method, the template it returns will now automatically be used instead of the standard uploadform template when generating an upload form
          Hide
          Marina Glancy added a comment -

          great, Paul. Thanks.
          It seems to me that you did not revert the previous change and now repositories upload_templates are passed to M.core_filepicker.set_templates twice

          Show
          Marina Glancy added a comment - great, Paul. Thanks. It seems to me that you did not revert the previous change and now repositories upload_templates are passed to M.core_filepicker.set_templates twice
          Hide
          Paul Nicholls added a comment -

          Hi Marina,
          I'm not quite sure what you mean - each template will only be added into the $templates array if it isn't listed in the $templatesinitialized static array; the call to M.core_filepicker.set_templates only happens if there are any templates in $templates. If you're actually seeing templates being registered twice, could you please let me know where you're seeing it happen, so that I can investigate?

          Show
          Paul Nicholls added a comment - Hi Marina, I'm not quite sure what you mean - each template will only be added into the $templates array if it isn't listed in the $templatesinitialized static array; the call to M.core_filepicker.set_templates only happens if there are any templates in $templates. If you're actually seeing templates being registered twice, could you please let me know where you're seeing it happen, so that I can investigate?
          Hide
          Marina Glancy added a comment -

          Paul, I looked at code again, it's fine. For some reason it looked to me yesterday as if you printed custom template twice. I did not actually install yet, just doing code review.

          You can submit this for integration, please add some testing instructions. We need also to update dev docs at http://docs.moodle.org/dev/Repository_plugins

          Thanks a lot for your work! I realise that I gave you hard time with my reviewing, hope you understand my reasons

          Show
          Marina Glancy added a comment - Paul, I looked at code again, it's fine. For some reason it looked to me yesterday as if you printed custom template twice. I did not actually install yet, just doing code review. You can submit this for integration, please add some testing instructions. We need also to update dev docs at http://docs.moodle.org/dev/Repository_plugins Thanks a lot for your work! I realise that I gave you hard time with my reviewing, hope you understand my reasons
          Hide
          Paul Nicholls added a comment -

          Hi Marina,
          I've added some (pretty basic) testing instructions - if you want to be particularly thorough I guess you could run through all tests related to the file picker in order to ensure no regressions have occurred, but given the scope of the changes, that's probably not necessary.

          How do I submit this for integration? I'm not sure if I just haven't found where/how to do it, or if I don't currently have the ability to do so - is it something that only the assignee (currently you, in this case) can do?

          I'm happy to update the dev docs, though might be worth waiting until it lands so that we can specify a version number in which it was added. Since it only adds a new option (i.e. doesn't change anything that's already documented), there's not a great deal of point in making documentation available before it's integrated - nothing needs to be done in anticipation of it.

          Show
          Paul Nicholls added a comment - Hi Marina, I've added some (pretty basic) testing instructions - if you want to be particularly thorough I guess you could run through all tests related to the file picker in order to ensure no regressions have occurred, but given the scope of the changes, that's probably not necessary. How do I submit this for integration? I'm not sure if I just haven't found where/how to do it, or if I don't currently have the ability to do so - is it something that only the assignee (currently you, in this case) can do? I'm happy to update the dev docs, though might be worth waiting until it lands so that we can specify a version number in which it was added. Since it only adds a new option (i.e. doesn't change anything that's already documented), there's not a great deal of point in making documentation available before it's integrated - nothing needs to be done in anticipation of it.
          Hide
          Marina Glancy added a comment -

          Paul, I changed you as assignee and submitted this for integration

          Show
          Marina Glancy added a comment - Paul, I changed you as assignee and submitted this for integration
          Hide
          Sam Hemelryk added a comment -

          Thanks guys, this has been integrated now

          Show
          Sam Hemelryk added a comment - Thanks guys, this has been integrated now
          Hide
          Rossiani Wijaya added a comment -

          Hi Paul,

          I'm not sure if the error is related with this issue or record audio repository.

          Testing this issue in firefox works great except when trying to save the recording audio, it showed 'no files attached' error and the page freeze with 'uploading, please wait' message.

          While testing this issue in chrome, clicking on the right area of the filepicker (for record audio repo) will trigger a browse window. Selecting 'setting' option will freeze the display.

          Could you please provide some feedback?

          Thanks

          Show
          Rossiani Wijaya added a comment - Hi Paul, I'm not sure if the error is related with this issue or record audio repository. Testing this issue in firefox works great except when trying to save the recording audio, it showed 'no files attached' error and the page freeze with 'uploading, please wait' message. While testing this issue in chrome, clicking on the right area of the filepicker (for record audio repo) will trigger a browse window. Selecting 'setting' option will freeze the display. Could you please provide some feedback? Thanks
          Hide
          Paul Nicholls added a comment -

          Hi Rossiani,
          I just checked out a fresh copy of the master branch from integration.git, installed it, then checked out the MDL-33640_full branch of the Record Audio repository and installed that - and it all seems to work fine for me, both in Firefox and in Chrome. Can you please double-check that you're using the MDL-33640_full branch of the recording repository (NOT the MDL-33640 branch, which was for an earlier quick and dirty way of adding this functionality, or the master branch which uses various workarounds/hacks on different versions of Moodle)? If you're definitely running the correct branch, maybe try purging your Moodle site's caches and your browser caches, to make sure you're not getting some old/outdated javascript?

          As for the freeze when you click the "Settings" button, what OS are you testing on? The button just triggers Flash's settings manager, which doesn't seem to work well on Linux (and may not work on OSX either, I'm not sure) - there are other ways of accessing the settings manager on Linux (the settings panel for allowing microphone access can be found at http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager02.html#118539 for instance). That's obviously well beyond the scope of this issue, since it's an issue at Adobe's end...

          -Paul

          Show
          Paul Nicholls added a comment - Hi Rossiani, I just checked out a fresh copy of the master branch from integration.git, installed it, then checked out the MDL-33640 _full branch of the Record Audio repository and installed that - and it all seems to work fine for me, both in Firefox and in Chrome. Can you please double-check that you're using the MDL-33640 _full branch of the recording repository (NOT the MDL-33640 branch, which was for an earlier quick and dirty way of adding this functionality, or the master branch which uses various workarounds/hacks on different versions of Moodle)? If you're definitely running the correct branch, maybe try purging your Moodle site's caches and your browser caches, to make sure you're not getting some old/outdated javascript? As for the freeze when you click the "Settings" button, what OS are you testing on? The button just triggers Flash's settings manager, which doesn't seem to work well on Linux (and may not work on OSX either, I'm not sure) - there are other ways of accessing the settings manager on Linux (the settings panel for allowing microphone access can be found at http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager02.html#118539 for instance). That's obviously well beyond the scope of this issue, since it's an issue at Adobe's end... -Paul
          Hide
          Rossiani Wijaya added a comment -

          Hi Paul,

          Thank you for the feedback.

          I will check with the integrator which patch they added for this issue.

          As for the freeze for accessing the setting button, I did the test using ubuntu and OSX.

          Show
          Rossiani Wijaya added a comment - Hi Paul, Thank you for the feedback. I will check with the integrator which patch they added for this issue. As for the freeze for accessing the setting button, I did the test using ubuntu and OSX.
          Hide
          Paul Nicholls added a comment -

          Hi Rossiani,
          It looks as though the correct patch has made it into integration - but it sounds like you may have the wrong version of the Record Audio repository (which isn't being integrated, as far as I'm aware). You can grab a zip of the correct version for testing against this patch as a zip from https://github.com/MaxThrax/moodle-repository_recordaudio/zipball/MDL-33640_full (or clone git://github.com/MaxThrax/moodle-repository_recordaudio.git and then make sure that you switch to/checkout the "MDL-33640_full" branch).

          -Paul

          Show
          Paul Nicholls added a comment - Hi Rossiani, It looks as though the correct patch has made it into integration - but it sounds like you may have the wrong version of the Record Audio repository (which isn't being integrated, as far as I'm aware). You can grab a zip of the correct version for testing against this patch as a zip from https://github.com/MaxThrax/moodle-repository_recordaudio/zipball/MDL-33640_full (or clone git://github.com/MaxThrax/moodle-repository_recordaudio.git and then make sure that you switch to/checkout the " MDL-33640 _full" branch). -Paul
          Hide
          Rossiani Wijaya added a comment -

          Hi Paul,

          I did download the full version for the recordaudio and still not able to upload the file.

          *attaching error image

          Show
          Rossiani Wijaya added a comment - Hi Paul, I did download the full version for the recordaudio and still not able to upload the file. *attaching error image
          Hide
          Rossiani Wijaya added a comment -

          Raj is helping me to test this issue.

          Thanks Raj!

          Show
          Rossiani Wijaya added a comment - Raj is helping me to test this issue. Thanks Raj!
          Hide
          Paul Nicholls added a comment - - edited

          Hi Rossiani,
          That screenshot shows the old version of the plugin - not the MDL-33640_full branch. Can you please either use the link in my previous comment to download a zip of the correct branch, or if you're using git, change to the "MDL-33640_full" (NOT "MDL-33640" without the "_full") branch, and then try again? The correct version for testing this patch should have the Author and Choose License fields above the recorder (which should have the caption "Make a recording" next to it).

          Cheers,
          Paul

          Edit: I've deleted the old MDL-33640 branch from my Github repository now, since it's not of any use. That should hopefully help clear up any ambiguity in the branch names.

          Show
          Paul Nicholls added a comment - - edited Hi Rossiani, That screenshot shows the old version of the plugin - not the MDL-33640 _full branch. Can you please either use the link in my previous comment to download a zip of the correct branch, or if you're using git, change to the " MDL-33640 _full" (NOT " MDL-33640 " without the "_full") branch, and then try again? The correct version for testing this patch should have the Author and Choose License fields above the recorder (which should have the caption "Make a recording" next to it). Cheers, Paul Edit: I've deleted the old MDL-33640 branch from my Github repository now, since it's not of any use. That should hopefully help clear up any ambiguity in the branch names.
          Hide
          Rajesh Taneja added a comment -

          Works fine for me

          Show
          Rajesh Taneja added a comment - Works fine for me
          Hide
          Rossiani Wijaya added a comment -

          yes, I got it to work.

          Thanks Paul and Raj.

          Test passed.

          Show
          Rossiani Wijaya added a comment - yes, I got it to work. Thanks Paul and Raj. Test passed.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          For the good and the bad... this is now part of Moodle and people around the world will start using it immediately, what a responsibility!

          Many thanks for your collaboration, yay!

          Closing, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - For the good and the bad... this is now part of Moodle and people around the world will start using it immediately, what a responsibility! Many thanks for your collaboration, yay! Closing, ciao

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: