Moodle Community Sites
  1. Moodle Community Sites
  2. MDLSITE-2107

One-click install button for direct installing plugins to Moodle 2.5

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Component/s: moodle.org/plugins
    • Labels:
      None

      Description

      This is the expected process that should happen once this is complete.

      steps 1 - 5 will be implemented here in this issue.

      Apu:

      1. Install button on top of page (uses preferred version if set, otherwise goes to download versions page?)
      2. Install links on every version in download page
      3. User preferences for Moodle site URLs. Allow multiple sites.
      4. Clicking install takes you to page listing existing sites. Can delete any there, or add a new one.
      5. Clicking on any site in the list sends you to (example URL) http://yoursite.com/admin/installplugin.php?plugin=xxxxx_xxxx&version=yyyyyyy

      David:

      1. Admin login is required before anything happens.
      2. This script initiates the download and installation, similar to upgrades.
      3. Consider backporting to 2.4? Including what it will look like to people on 2.4.0 which won’t support installing.

        Issue Links

          Activity

          Hide
          Aparup Banerjee added a comment -

          I thought there was an MDL for moodle side of this process but i might be mistaken or simply can't find it. please link them when known.

          Show
          Aparup Banerjee added a comment - I thought there was an MDL for moodle side of this process but i might be mistaken or simply can't find it. please link them when known.
          Hide
          Martin Dougiamas added a comment -

          Can you add two subtasks here? One for you and one for David.

          Show
          Martin Dougiamas added a comment - Can you add two subtasks here? One for you and one for David.
          Hide
          Aparup Banerjee added a comment -

          Just a note to mention that the "Others" category should be excluded from any automated process as the category is intended for risky plugins that may explode upon impact. I'll have to check if thats happening for updates atm but i'm pretty sure we shouldn't automatic do updates either.

          Show
          Aparup Banerjee added a comment - Just a note to mention that the "Others" category should be excluded from any automated process as the category is intended for risky plugins that may explode upon impact. I'll have to check if thats happening for updates atm but i'm pretty sure we shouldn't automatic do updates either.
          Hide
          Martin Dougiamas added a comment -

          For sure. IIRC there aren't any frankenstyle names there anyway.

          Show
          Martin Dougiamas added a comment - For sure. IIRC there aren't any frankenstyle names there anyway.
          Hide
          David Mudrak added a comment -

          there aren't any frankenstyle names there anyway.

          That is what I thought, too. I considered the category for "other" stuff like patches, icon sets etc. I was a bit surprised that is is supposed to be used for add-ons with proper frankenstyle that are just not considered "stable enough" to be published in the proper category (as I have been told).

          Show
          David Mudrak added a comment - there aren't any frankenstyle names there anyway. That is what I thought, too. I considered the category for "other" stuff like patches, icon sets etc. I was a bit surprised that is is supposed to be used for add-ons with proper frankenstyle that are just not considered "stable enough" to be published in the proper category (as I have been told).
          Hide
          Aparup Banerjee added a comment -

          Hm, there are 4 @ https://moodle.org/plugins/browse.php?list=category&id=38 right now with frankenstyle showing up (other_cloze, local_externalzip, block_navbuttons & block_vmoodle)

          I was not aware of any 'plugins in others category should not have frankenstyles' rule. My understanding was if they aren't safe (use at risk), or they install fine but the zip includes a patch (to be applied manually to have the plugin function), then they' fall under "Others".

          Show
          Aparup Banerjee added a comment - Hm, there are 4 @ https://moodle.org/plugins/browse.php?list=category&id=38 right now with frankenstyle showing up (other_cloze, local_externalzip, block_navbuttons & block_vmoodle) I was not aware of any 'plugins in others category should not have frankenstyles' rule. My understanding was if they aren't safe (use at risk), or they install fine but the zip includes a patch (to be applied manually to have the plugin function), then they' fall under "Others".
          Hide
          Martin Dougiamas added a comment -

          In any case the main thing is that stuff in the "Other" category is excluded from plugin installs and updates. Easy.

          Show
          Martin Dougiamas added a comment - In any case the main thing is that stuff in the "Other" category is excluded from plugin installs and updates. Easy.
          Hide
          David Mudrak added a comment -

          I summarised the current work in progress and the implementation plan at http://docs.moodle.org/dev/On-click_add-on_installation

          I have mdeploy.php support ready and will continue with other Moodle-side tasks. Then I can assist Apu on his work on Plugins part of the game.

          Show
          David Mudrak added a comment - I summarised the current work in progress and the implementation plan at http://docs.moodle.org/dev/On-click_add-on_installation I have mdeploy.php support ready and will continue with other Moodle-side tasks. Then I can assist Apu on his work on Plugins part of the game.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Hi, some comments:

          1) I see the benefit/interest about keeping a list of sites (by moodle.org user) controlled, providing easy "install me @ stronk7.com" buttons / links. No problem there.

          2) But later, when reading http://docs.moodle.org/dev/On-click_add-on_installation from David, I've seen that, by DEFAULT, in order to "auto-fill" that list of sites by user (basically a good idea) , the site name, url, version is being sent (point 3 in the diagram). And I've to express my concerns about that. You cannot send that information at all (can be a private site...). I'd say that it only can work controlled by an "opt-in" setting.

          3) Then, it's the problem of the installation of new add-ons by people that does not want to share/fill their sites at all. They won't have the nice buttons at all, so something must be provided to them (to be used easily in their sites). I think we could invent some "MUAC" (moodle unique add-on identifier), and by copying/pasting that identifier somewhere in their sites, the deploy machinery should be able to request the exact plugin/version quickly (starting in point 8 in the diagram).

          4) Note that 3 is not a problem for updates of already installed add-ons... because it's already detected and can be ignited from the user sites without landing to moodle.org/plugins at all. IMO for updates it would be enough to provide one link (new window) in case the admin wants to read about the new version, but no need to "install buttons" seems necessary. Just "update me" in the user site.

          5) Finally, I would provide some sort of "concentrator/proxy" url @ download.moodle.org (where the whole APIs thing) is running, letting it to redirect the user to the final location of the zip (it can be download.moodle.org itself, or current moode.org/plugins.... location... or anywhere else in the future). But let's start using that common concentrator URL since day 0.

          Note all these points do not affect the plugins add-on at all, it's all internal updates API/WS/calls machinery.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Hi, some comments: 1) I see the benefit/interest about keeping a list of sites (by moodle.org user) controlled, providing easy "install me @ stronk7.com" buttons / links. No problem there. 2) But later, when reading http://docs.moodle.org/dev/On-click_add-on_installation from David, I've seen that, by DEFAULT, in order to "auto-fill" that list of sites by user (basically a good idea) , the site name, url, version is being sent (point 3 in the diagram). And I've to express my concerns about that. You cannot send that information at all (can be a private site...). I'd say that it only can work controlled by an "opt-in" setting. 3) Then, it's the problem of the installation of new add-ons by people that does not want to share/fill their sites at all. They won't have the nice buttons at all, so something must be provided to them (to be used easily in their sites). I think we could invent some "MUAC" (moodle unique add-on identifier), and by copying/pasting that identifier somewhere in their sites, the deploy machinery should be able to request the exact plugin/version quickly (starting in point 8 in the diagram). 4) Note that 3 is not a problem for updates of already installed add-ons... because it's already detected and can be ignited from the user sites without landing to moodle.org/plugins at all. IMO for updates it would be enough to provide one link (new window) in case the admin wants to read about the new version, but no need to "install buttons" seems necessary. Just "update me" in the user site. 5) Finally, I would provide some sort of "concentrator/proxy" url @ download.moodle.org (where the whole APIs thing) is running, letting it to redirect the user to the final location of the zip (it can be download.moodle.org itself, or current moode.org/plugins.... location... or anywhere else in the future). But let's start using that common concentrator URL since day 0. Note all these points do not affect the plugins add-on at all, it's all internal updates API/WS/calls machinery. Ciao
          Hide
          Martin Dougiamas added a comment -

          I think this might be over-engineering things a little, Eloy.

          E2) We can have one button on their site like [Browse moodle.org for new plugins] and next to it a note that says "Privacy notice: This operation will send your site URL to moodle.org, if you would prefer not to do this then visit http://moodle.org/plugins in your browser".

          E3) Not a problem, as we'll always provide a direct download link and they can install things manually.

          E5) Totally agree on this (in fact I thought we had it). Who can write this?

          Show
          Martin Dougiamas added a comment - I think this might be over-engineering things a little, Eloy. E2) We can have one button on their site like [Browse moodle.org for new plugins] and next to it a note that says "Privacy notice: This operation will send your site URL to moodle.org, if you would prefer not to do this then visit http://moodle.org/plugins in your browser". E3) Not a problem, as we'll always provide a direct download link and they can install things manually. E5) Totally agree on this (in fact I thought we had it). Who can write this?
          Hide
          Aparup Banerjee added a comment -

          +1 to E2 (Opt-now)

          Show
          Aparup Banerjee added a comment - +1 to E2 (Opt-now)
          Hide
          David Mudrak added a comment -

          Re E1) Yes, so do I. I was just thinking that if the user just arrived from their Moodle site (and we know they clicked "Get more plugins!" there), it would be pretty stupid to ask them to input that site URL into the list manually.

          Re E2) I personally do not consider this as a privacy issue. Submitted values are available for the user only. They are optionally saved (if the user wishes so) in their preferences. They are asked if they want to store it or not. Anyway. This all machinery is there just to improve the usability (click - click). We can drop it completely, do not send any information and let them to maintain the list manually. I think it sucks though. Or, we can come with a compromise that only the site URL would be sent. Such an information is supposed to be sent via the HTTP referer header (http://en.wikipedia.org/wiki/HTTP_referer) anyway.

          Re E3) I agree with Martin.

          Re E5) Yup, I like the idea of download.moodle.org behaves as a sort of proxy. It could also cache the ZIP packages in a static storage (to bypass PHP processing) etc. However, we can switch to this anytime. We designed all the deployment machinery in a way that we control the URLs that are to be used for both installation and updating of plugins. And we missed the day 0 already, anyway as you know.

          Re Apu: Sorry, do you give +1 to the "opt-in" (admin must explicitly enable sending the information) or "opt-out" (admin can disable sending the information but it is on by default)?

          Show
          David Mudrak added a comment - Re E1) Yes, so do I. I was just thinking that if the user just arrived from their Moodle site (and we know they clicked "Get more plugins!" there), it would be pretty stupid to ask them to input that site URL into the list manually. Re E2) I personally do not consider this as a privacy issue. Submitted values are available for the user only. They are optionally saved (if the user wishes so) in their preferences. They are asked if they want to store it or not. Anyway. This all machinery is there just to improve the usability (click - click). We can drop it completely, do not send any information and let them to maintain the list manually. I think it sucks though. Or, we can come with a compromise that only the site URL would be sent. Such an information is supposed to be sent via the HTTP referer header ( http://en.wikipedia.org/wiki/HTTP_referer ) anyway. Re E3) I agree with Martin. Re E5) Yup, I like the idea of download.moodle.org behaves as a sort of proxy. It could also cache the ZIP packages in a static storage (to bypass PHP processing) etc. However, we can switch to this anytime. We designed all the deployment machinery in a way that we control the URLs that are to be used for both installation and updating of plugins. And we missed the day 0 already, anyway as you know. Re Apu: Sorry, do you give +1 to the "opt-in" (admin must explicitly enable sending the information) or "opt-out" (admin can disable sending the information but it is on by default)?
          Hide
          Aparup Banerjee added a comment -

          ah i meant +1 to (E2+E3)

          i'll clarify 'opt-now' jargon:

          • the site would save the info automatically (the moodle.org user can always delete them if they want) .. IF they send the information in the first place.
            • so they opt-in the instant they click the 'Get more add-ons!' (perhaps a term here to shorten this 'automatic installing of Add-ons' would help)
            • they opt-out by not clicking the button and reading the notice about sending data to moodle.org, so they go directly via link to plugins directory and proceed manually.

          that is if i understood MD right.

          Show
          Aparup Banerjee added a comment - ah i meant +1 to (E2+E3) i'll clarify 'opt-now' jargon: the site would save the info automatically (the moodle.org user can always delete them if they want) .. IF they send the information in the first place. so they opt-in the instant they click the 'Get more add-ons!' (perhaps a term here to shorten this 'automatic installing of Add-ons' would help) they opt-out by not clicking the button and reading the notice about sending data to moodle.org, so they go directly via link to plugins directory and proceed manually. that is if i understood MD right.
          Hide
          Aparup Banerjee added a comment -

          i don't see any need for a setting at all as the person doing the action is the admin.

          Show
          Aparup Banerjee added a comment - i don't see any need for a setting at all as the person doing the action is the admin.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          "over-engineering" ?

          E2) No problem as far as not private information about the site is passed. So I can "accept" url, name and version. But never, never, pass around the siteidentifier. And ideally only store that site persistently in the plugins db if it's really public site (aka, keep out all intranet/ip sites, or dns-failing sites.. more yet, we could store it only if present int the registration DB - and only store its id).

          If the site is not going to be stored, use it only for the current session. Be noted that, while common sense says that the admin will be logging to moodle.org to the "correct" account.... that's an artificial relation and it's possible to be logged as another user. I mean, nothing validates that the relation between the 2 sessions (at site and at moodle.org) is valid (only common-sense).

          REST) About E3) and E4), I just was trying to cover something that seems not to be supported and, more yet, current solution is far from optimal. Let me re-phrase it as a simple new, for your consideration, use case:

          New use case: "A clever admin wants to install mod_xxxx, filter_yyyy and question_zzzz to a dozen of sites". He already knows the add-ons and is 100% sure he wants them.

          Current solution: I'm sorry, do it manually (donwload, install...)
          Target solution: Be able to perform the automated installation without visiting moodle.org/plugins at all.

          E5) I can do it, just tell me which params should it be supporting and I'll do the "redirector" (for now, pointing to moodle.org/plugins/whatever). Just need to have the "whatever" defined. Feel free to create subtask.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - "over-engineering" ? E2) No problem as far as not private information about the site is passed. So I can "accept" url, name and version. But never, never, pass around the siteidentifier. And ideally only store that site persistently in the plugins db if it's really public site (aka, keep out all intranet/ip sites, or dns-failing sites.. more yet, we could store it only if present int the registration DB - and only store its id). If the site is not going to be stored, use it only for the current session. Be noted that, while common sense says that the admin will be logging to moodle.org to the "correct" account.... that's an artificial relation and it's possible to be logged as another user. I mean, nothing validates that the relation between the 2 sessions (at site and at moodle.org) is valid (only common-sense). REST) About E3) and E4), I just was trying to cover something that seems not to be supported and, more yet, current solution is far from optimal. Let me re-phrase it as a simple new, for your consideration, use case: New use case: "A clever admin wants to install mod_xxxx, filter_yyyy and question_zzzz to a dozen of sites". He already knows the add-ons and is 100% sure he wants them. Current solution: I'm sorry, do it manually (donwload, install...) Target solution: Be able to perform the automated installation without visiting moodle.org/plugins at all. E5) I can do it, just tell me which params should it be supporting and I'll do the "redirector" (for now, pointing to moodle.org/plugins/whatever). Just need to have the "whatever" defined. Feel free to create subtask. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Ops, and sorry for disturb, but just realized that this stuff is a good candidate to have some CLI support like (asuming it's under admin/cli/ma.php (manage_addons.php)).

          ma.php --upgrade => to fetch renewed information about add-ons.
          ma.php --show_updates => to list what can be updated and to which version.
          ma.php --update-all => to install all the updates
          ma.php --update mod_xxxx,filter_yyyy   |
          ma.php --install mod_xxxx,filter_yyyy  | => can be combined
          ma.php --help
          

          Just noting it to keep the developer thinking about how to code it for reusability.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Ops, and sorry for disturb, but just realized that this stuff is a good candidate to have some CLI support like (asuming it's under admin/cli/ma.php (manage_addons.php)). ma.php --upgrade => to fetch renewed information about add-ons. ma.php --show_updates => to list what can be updated and to which version. ma.php --update-all => to install all the updates ma.php --update mod_xxxx,filter_yyyy | ma.php --install mod_xxxx,filter_yyyy | => can be combined ma.php --help Just noting it to keep the developer thinking about how to code it for reusability. Ciao
          Hide
          Martin Dougiamas added a comment -

          Yes a script like that would be awesome.

          Show
          Martin Dougiamas added a comment - Yes a script like that would be awesome.
          Hide
          David Mudrak added a comment -

          Apu, just some quick notes. Please note I've updated the communication protocol spec: http://docs.moodle.org/dev/index.php?title=On-click_add-on_installation&action=historysubmit&diff=38528&oldid=38526 so that moodle.org/plugin will obtain the major version like '2.5' instead of the $CFG->branch like '25'. That will make matching against the software version in local_plugin_software easier & better defined.

          Also note I reverted your change of the project name as I really call it now "On-click add-on installation" instead of "One-click ..." (as it needs more than one click to install an add-on ). The point is that the admin can really install new add-ons just by clicking in the browser (thence "on-click") instead of connecting to the server shell/FTP.

          Show
          David Mudrak added a comment - Apu, just some quick notes. Please note I've updated the communication protocol spec: http://docs.moodle.org/dev/index.php?title=On-click_add-on_installation&action=historysubmit&diff=38528&oldid=38526 so that moodle.org/plugin will obtain the major version like '2.5' instead of the $CFG->branch like '25'. That will make matching against the software version in local_plugin_software easier & better defined. Also note I reverted your change of the project name as I really call it now "On-click add-on installation" instead of "One-click ..." (as it needs more than one click to install an add-on ). The point is that the admin can really install new add-ons just by clicking in the browser (thence "on-click") instead of connecting to the server shell/FTP.
          Hide
          David Mudrak added a comment -

          I believe we need to sort out MDLSITE-2178 for 2.5 plugins at least to make this work properly.

          Show
          David Mudrak added a comment - I believe we need to sort out MDLSITE-2178 for 2.5 plugins at least to make this work properly.
          Hide
          Derek Chirnside added a comment -

          @David: what's the chance of movement on this? Some thoughts follow, I hope I am not wasting your time.

          The list at MDLSITE-2178 makes me a bit tired just looking at it!! Is there any possibility of having three levels of plugins:
          A: non official
          B: official/checked. In the database, GIT etc as now.
          C: Official and passed for "one-click installable"

          ie, just ignore the non-compliant add-ons, and leave them in the DB.

          I am worried that if you raise the bar too high it will mean less engagement with the add-ons process by developers.
          If you make it too low we have quality issues.
          If Class C plugin XXP has a glitch, and the installable bit breaks, just demote it to Class B until it is fixed.

          I've changed my whole way of operating with Moodle since 2.0. Upgrading more often and sooner. This leads to the problem of plugins. Tweaks are needed more often (with the changes to Moodle) but not chaotically so (ie changes to Moodle innards are becoming more sort of organised). So I'm keen on the ability to push up to my Moodles little tweaks often, myself and not to pay the $$ to the providers for lots of little bits of work.

          But I also hear a little voice in my ear. Security.

          Over and out.

          -Derek

          Show
          Derek Chirnside added a comment - @David: what's the chance of movement on this? Some thoughts follow, I hope I am not wasting your time. The list at MDLSITE-2178 makes me a bit tired just looking at it!! Is there any possibility of having three levels of plugins: A: non official B: official/checked. In the database, GIT etc as now. C: Official and passed for "one-click installable" ie, just ignore the non-compliant add-ons, and leave them in the DB. I am worried that if you raise the bar too high it will mean less engagement with the add-ons process by developers. If you make it too low we have quality issues. If Class C plugin XXP has a glitch, and the installable bit breaks, just demote it to Class B until it is fixed. I've changed my whole way of operating with Moodle since 2.0. Upgrading more often and sooner. This leads to the problem of plugins. Tweaks are needed more often (with the changes to Moodle) but not chaotically so (ie changes to Moodle innards are becoming more sort of organised). So I'm keen on the ability to push up to my Moodles little tweaks often, myself and not to pay the $$ to the providers for lots of little bits of work. But I also hear a little voice in my ear. Security. Over and out. -Derek
          Hide
          Aparup Banerjee added a comment -

          just to note that this is basically up and running. There's still some refining to do but it should function for the majority.
          Please create sub-tasks here for issues you may encounter under this MDL (i may already be working on too).

          Derek, regarding security, if that means privacy, site data that is gained from an admin clicking the 'install add-on from plugins directory' button can be totally deleted from the plugins directory if desired by deleting the site entry. Further to that i believe there is a warning near that moodle button about the info sent (namely url and site-version)

          David, thanks for MDLSITE-2178 (more in that bug).

          Show
          Aparup Banerjee added a comment - just to note that this is basically up and running. There's still some refining to do but it should function for the majority. Please create sub-tasks here for issues you may encounter under this MDL (i may already be working on too). Derek, regarding security, if that means privacy, site data that is gained from an admin clicking the 'install add-on from plugins directory' button can be totally deleted from the plugins directory if desired by deleting the site entry. Further to that i believe there is a warning near that moodle button about the info sent (namely url and site-version) David, thanks for MDLSITE-2178 (more in that bug).
          Hide
          Aparup Banerjee added a comment -

          resolving this old issue.

          Show
          Aparup Banerjee added a comment - resolving this old issue.

            People

            • Votes:
              3 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development