On-click add-on installation
|One-click add-on installation|
|Project state||In progress|
|Assignee||David Mudrak, Aparup Banerjee|
This is a follow-up project on Automatic updates deployment aiming to implement the Episode III of the deployment saga.
Use case 1
- Sue logs in her Moodle site and goes to the Plugins overview page. She clicks the "Get more add-ons!" link at the top of the page.
- She is redirected to the Plugins directory. The Moodle version there is automatically set to the version of her Moodle site she just came from.
- She browses the list of plugins in the directory and finally finds an add-on she want to install.
- There is a big nice icon "Install" at the page so she clicks it.
- A popup-like overlay window is displayed with the list of Sue's sites. She has one site only so she clicks the "Install to this site" link next to it.
- She is redirected back to her site, to a page requiring her confirmation for the plugin installation. She confirms that she really wants to install that add-on by click at "Install" button.
- The Plugins check page appears, showing that there is the plugin ready to be installed (as if she just unzipped to her site).
There are two basic scenarios: The user (admin) starts at their site and clicks the "Get more add-ons!" link, or the user visits moodle.org/plugins directly. In both scenarios, the user may or may not have an account at moodle.org and may or may not be logged in there. In the second scenario the user may and may not be logged in at their site. Their site may or may not be Moodle 2.5 (and higher).
(1) Admin logs in their Moodle site and navigates to the "Plugins overview" page.
(2) Admin clicks the "Get more add-ons!" link at the top of the page.
(3) The link leads to a script like https://moodle.org/plugins/get.php?site=... where the parameter holds the encoded information about the site name, URL and branch.
(4) Plugins directory decodes the site information. Then ...
(4.1) If the user is not logged-in at moodle.org, they are asked if they want to log in (with a help icon to explain why login is useful).
(4.1.1) If they decide to continue in anonymous mode, the site information is stored in the MUC session cache, the Moodle version is set to the branch provided by the link (3) and they are redirected to the main moodle.org/plugins page.
(4.1.2) If they decide to log in, they are redirected to the login form, having the link (3) set in their $SESSION->wantsurl - thence jumping to (4.2).
(4.2) If the user is logged-in at moodle.org, the passed site information is compared with the list of their "own" sites recorded in their user preferences. If there is a change in the name name or the branch, or such URL is not recorded yet, they are asked to update it/add it to the list of their Moodle sites.
(5) The user navigates to the plugin they want to install. The "Install" button is displayed at the page.
(5.1) If they are logged-in, clicking the button opens a popup-like overlay window with the list of all recorded user's sites with a possibility to add a new site or delete an existing site. The "Install to this site" link is displayed next to each recorded site if its branch >= 2.5.
(5.2) If they are not logged in, clicking the button opens a popup-like overlay window with an input field for the site URL and the submit button labelled "Install to this site". If the MUC session cache contains the information about the site they came from, that site's URL is pre-filled in the field.
(6) Clicking the "Install to this site" button takes them to that site's /index.php. Additional information about the plugin version to be installed is passed via encoded HTTP GET parameter 'installaddon'.
(7) If optional_param('installaddon') is passed to /index.php, the user must log in as the admin (if they are not yet). A screen requiring their confirmation to install the given add-on is displayed. The sesskey is checked during the confirmation. For sites running 2.4.x and lower, nothing will happen.
(8) The site uses cURL call via HTTPS to fetch meta-information about the plugin to be installed, most notably the URL and the MD5 hash of the ZIP package to be downloaded. This information is to be provided by https://download.moodle.org/api/1.2/describe.php?plugin=frankenstyle_name&version=the_plugin_version (which in turn pulls data from local_plugins WS every now and then and when needed).
(9) The information about the given plugin and it's version is loaded from the database and the JSON response is prepared.
(10) The JSON response is sent back to the site.
(11) The parameters for the mdeploy.php script are prepared.
(12) The mdeploy.php utility is executed.
(13) The cURL GET call to download the ZIP.
(14) ZIP package is downloaded.
(15) ZIP is extracted into the correct location.
(16) The browser is redirected into the /admin to perform the installation.
Example of the encoding used in the step (3):
$siteinfo = array( 'name' => 'My School Online Courses', // The fullname of the SITEID course 'url' => 'http://my.school.edu/moodle', // $CFG->wwwroot 'branch' => 25, // $CFG->branch ); $jsonized = json_encode($siteinfo); $encoded = base64_encode($jsonized); $goto = new moodle_url('https://moodle.org/plugins/get.php', array('site' => $encoded));
The existing standalone utility mdeploy.php will be responsible for actual fetching and deploying the ZIP packages from moodle.org/plugins.
Required functionality for Moodle sites
- mdeploy.php supports the add-on installation mode
- UI to jump to moodle.org/plugins
- UI to confirm installation
- fetching the plugin meta-info
Required functionality for the Plugins directory
- Owned sites management - how to store them?
- MUC session cache for anonymous landings
- API providing the meta-information about the plugin
- UI to handle "Install" button clicks