clickmeeting / moodle-plugin Goto Github PK

$string['modulename'] = 'Virtual Class';
$string['modulenameplural'] = 'Virtual Classes';

Should those say "Clickmeeting" ?

When someone goes to add your plugin to a course - if they have a number of different tools installed they wouldn't neccessarily know which one was a Clickmeeting activity.

Moodle uses a privacy API for GDPR compliance to allow plugins to specify how they deal with user data.
Sites that use continuous integration processes will not be able to use your plugin because Moodle runs unit tests which check to see if all extra plugins include the privacy class.

More information on the privacy class is here:
https://docs.moodle.org/dev/Privacy_API

please note this is not a blocker for approval in the plugins db at this stage.

Typically when displaying user names you should be using fullname($USER) because many sites will have a different way of displaying a users name.

your install.xml file looks incorrect and may cause issues for some sites.

You need to use the built-in xmldb editor UI in Moodle to fix this - easiest way to do this is to open it in the xmldb editor and make a change to a comment on a field or table to trigger a change - then use the xmldb editor built-in functions to save the file (you may need to change file-level permissions to allow xmldb editor to save the file.)

this is a blocker for approval in the plugins db.

extra/copy.swf
This appears to be an adobe flash file - is it needed? - can you please remove it as Flash is no longer supported.

in your scripts folder I see a few 3rd party libs (jquery/jquery.popupLight etc) - when you add a 3rd party lib to a plugin you must define it in the thirdpartylibs.xml file - please note that doesn't include js files you have written yourself (like popup.js seems to be.)
more information on this is here:
https://docs.moodle.org/dev/Plugin_files#thirdpartylibs.xml

Please review our security guidelines:
https://docs.moodle.org/dev/Security#Summary_of_the_guidelines

in particular files like view.php and index.php should implement a require or has_capability checks pretty soon after the require_login check.

Some of the tests run by the Moodle.org plugins db can be run via travis-ci on each commit in your github repo. Enabling Travis integration helps you to make sure future changes to your plugin will continue to follow the guidelines.

More information on this is here:
https://moodle.org/mod/forum/discuss.php?d=323384

but the short version:
grab this file:
https://github.com/moodlerooms/moodle-plugin-ci/blob/master/.travis.dist.yml
rename it as .travis.yml and put in the root of your github directory.
Go to:
https://travis-ci.org/profile/YOUR_GITHUB_USERNAME
Flick the switch for this repo.

then on every commit you make to github it will fire off a request to travis to run the tests in .travis.yml and will give you traffic lights beside each commit and generate a report.

something else you might want to change:
in .travis.yml the default file has this line:

env:
global:

MOODLE_BRANCH=MOODLE_35_STABLE
you might want to add other branches to that list - so you might want to change it something like:

env:
global:
MOODLE_BRANCH=MOODLE_35_STABLE
MOODLE_BRANCH=MOODLE_36_STABLE
MOODLE_BRANCH=MOODLE_37_STABLE

It looks like some of the fields defined in your "clickmeeting" table are not included in the backup/restore api - you should review these to make sure that backup/restore works as expected.

Please use our optional_param or required_param functions with appropriate sanitisation (PARAM_TEXT, PARAM_ALPHANUMEXT etc)
more information on this is in our security guidelines:
https://docs.moodle.org/dev/Security#Summary_of_the_guidelines

this is a blocker for approval in the plugins db.

functions like add_to_log and get_context_instance have been deprecated - you need to install your plugin on a new Moodle 3.8 site and enable developer debugging with display errors on and make sure your plugin doesn't report any debugging notices.

This is a blocker for approval in the plugins db.

Moodle has it's own Curl class which should be used instead of directly calling curl_init

This is mainly because many moodle sites sit behind a web proxy and require all traffic to be sent through a proxy.

This is a blocker for approval in the plugins db.

Typically repository names will use the "frankenstyle" prefix of a plugin - the more correct repository name would be "moodle-mod_clickmeeting" - using this convention makes it much easier for developers/git users to indentify the type of plugin when looking at the repo name too.

This doesn't block approval in the plugins db, but it's really nice to have.

please review the copyright headers in all files - I spotted at least one that stated:
"copyright 2011 your name"

Moodle core already includes jquery - you should check to see if you can re-use the existing core lib rather than including it again - that way you can rely on core updating with security issues etc.

note this is not currently a blocker for approval in the plugins db.