diff --git a/.vscode/settings.json b/.vscode/settings.json index f09d7f69ae..f83de6da82 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,4 +1,7 @@ { "stylelint.packageManager": "yarn", - "cSpell.enabled": true + "cSpell.enabled": true, + "cSpell.words": [ + "prechecks" + ] } diff --git a/data/migratedPages.yml b/data/migratedPages.yml index 7feb608e40..cfa7fb3013 100644 --- a/data/migratedPages.yml +++ b/data/migratedPages.yml @@ -1485,15 +1485,42 @@ Peer_reviewing: Plagiarism_API: - filePath: "/docs/apis/subsystems/plagiarism.md" slug: "/docs/apis/subsystems/plagiarism" +Plugin_QA_prechecks: +- filePath: "/general/community/plugincontribution/qaprechecks.md" + slug: "/general/community/plugincontribution/qaprechecks" +Plugin_code_prechecks: +- filePath: "/general/community/plugincontribution/codeprechecks.md" + slug: "/general/community/plugincontribution/codeprechecks" Plugin_contribution: - filePath: "/general/community/plugincontribution/index.md" slug: "/general/community/plugincontribution" +Plugin_contribution_checklist: +- filePath: "/general/community/plugincontribution/checklist" + slug: "/general/community/plugincontribution/checklist" +Plugin_documentation: +- filePath: "/general/community/plugincontribution/documentation.md" + slug: "/general/community/plugincontribution/documentation" Plugin_files: - filePath: "/docs/apis/commonfiles.md" slug: "/docs/apis/commonfiles" Plugin_types: - filePath: "/docs/apis/plugintypes/index.md" slug: "/docs/apis/plugintypes/" +Plugin_with_third_party_libraries: +- filePath: "/general/community/plugincontribution/thirdpartylibraries.md" + slug: "/general/community/plugincontribution/thirdpartylibraries" +Plugins_adoption_programme: +- filePath: "/general/community/plugincontribution/adoption.md" + slug: "/general/community/plugincontribution/adoption" +Plugins_directory: +- filePath: "/general/community/plugincontribution/pluginsdirectory.md" + slug: "/general/community/plugincontribution/pluginsdirectory" +Plugins_directory_API: +- filePath: "/general/community/plugincontribution/pluginsdirectoryapi.md" + slug: "/general/community/plugincontribution/pluginsdirectoryapi" +Plugins_guardians: +- filePath: "/general/community/plugincontribution/guardians.md" + slug: "/general/community/plugincontribution/guardians" Preference_API: - filePath: "/docs/apis/core/preference/index.md" slug: "/docs/apis/core/preference/" diff --git a/docs/apis/_files/changes.mdx b/docs/apis/_files/changes.mdx index d4386313c8..afcb40332e 100644 --- a/docs/apis/_files/changes.mdx +++ b/docs/apis/_files/changes.mdx @@ -1,5 +1,5 @@ -If your plugin includes a changelog in its root directory, this will be used to automatically pre-fill the release notes field when uploading new versions of your plugin to the [Plugins directory](https://docs.moodle.org/dev/Plugins_directory). This file can be in any of the following locations: +If your plugin includes a changelog in its root directory, this will be used to automatically pre-fill the release notes field when uploading new versions of your plugin to the [Plugins directory](/general/community/plugincontribution/pluginsdirectory). This file can be in any of the following locations: - `CHANGES.md`: as a markdown file; or - `CHANGES.txt`: as a text file; or diff --git a/docs/apis/_files/readme.mdx b/docs/apis/_files/readme.mdx index 185121a363..42bb31fa21 100644 --- a/docs/apis/_files/readme.mdx +++ b/docs/apis/_files/readme.mdx @@ -1,4 +1,4 @@ -We recommend that you include any additional information for your plugin in a project readme file. Ideally this should act as an offline version of all information in your plugin's page in the [Plugins directory](https://docs.moodle.org/dev/Plugins_directory). +We recommend that you include any additional information for your plugin in a project readme file. Ideally this should act as an offline version of all information in your plugin's page in the [Plugins directory](/general/community/plugincontribution/pluginsdirectory). We recommend creating your readme file in either a `README.md`, or `README.txt` format. diff --git a/docs/apis/_files/styles-css.mdx b/docs/apis/_files/styles-css.mdx index e62a0dd592..5b5495f69b 100644 --- a/docs/apis/_files/styles-css.mdx +++ b/docs/apis/_files/styles-css.mdx @@ -1,7 +1,7 @@ Plugins may define a '/styles.css' to provide plugin-specific styling. See the following for further documentation: -- [Plugin contribution checklist#CSS styles](https://docs.moodle.org/dev/Plugin_contribution_checklist#CSS_styles) +- [Plugin contribution checklist#CSS styles](/general/community/plugincontribution/checklist#css-styles) - [CSS Coding Style](https://docs.moodle.org/dev/CSS_Coding_Style) :::tip Avoid custom styles where possible diff --git a/docs/apis/commonfiles/index.mdx b/docs/apis/commonfiles/index.mdx index 19c8ab7ee2..c887bb2a23 100644 --- a/docs/apis/commonfiles/index.mdx +++ b/docs/apis/commonfiles/index.mdx @@ -161,4 +161,4 @@ import extraLangDescription from '../_files/lang-extra.md'; - [Plugin types](../plugintypes/index.md) - list of all supported plugin types - [Moodle plugins directory](https://moodle.org/plugins/) - repository of contributed plugins for Moodle - [Moodle plugin skeleton generator](https://moodle.org/plugins/tool_pluginskel) - allows to quickly generate code skeleton for a new plugin -- [Checklist for plugin contributors](https://docs.moodle.org/dev/Plugin_contribution_checklist) - read before submitting a plugin +- [Checklist for plugin contributors](/general/community/plugincontribution/checklist) - read before submitting a plugin diff --git a/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-details.png b/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-details.png new file mode 100644 index 0000000000..33bbf3dc80 Binary files /dev/null and b/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-details.png differ diff --git a/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-error.png b/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-error.png new file mode 100644 index 0000000000..c15a53c9f1 Binary files /dev/null and b/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-error.png differ diff --git a/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-success.png b/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-success.png new file mode 100644 index 0000000000..d13e8e8079 Binary files /dev/null and b/general/community/plugincontribution/_codeprechecks/plugin-codeprechecks-success.png differ diff --git a/general/community/plugincontribution/_documentation/infobox_plugin.png b/general/community/plugincontribution/_documentation/infobox_plugin.png new file mode 100644 index 0000000000..5a3c6c01af Binary files /dev/null and b/general/community/plugincontribution/_documentation/infobox_plugin.png differ diff --git a/general/community/plugincontribution/_guardians/plugins-guardian-logo.png b/general/community/plugincontribution/_guardians/plugins-guardian-logo.png new file mode 100644 index 0000000000..f192a19f20 Binary files /dev/null and b/general/community/plugincontribution/_guardians/plugins-guardian-logo.png differ diff --git a/general/community/plugincontribution/adoption.md b/general/community/plugincontribution/adoption.md new file mode 100644 index 0000000000..150a9f40d8 --- /dev/null +++ b/general/community/plugincontribution/adoption.md @@ -0,0 +1,61 @@ +--- +title: Plugins adoption programme +sidebar_position: 9 +tags: + - Guidelines for contributors + - Plugins + - Plugin documentation +--- +The Plugins adoption programme is a process for making it clear that a plugin is orphaned and is looking for a new maintainer. The programme is one of the mechanisms helping to minimise the risks of relying on additional plugins. The programme helps to find new maintainers for plugins whose original authors can't work on the plugin fully any more. + +The programmes started in 2014 by announcing it in [a forum post](https://moodle.org/mod/forum/discuss.php?d=260354#p1128482) and since then, many plugins found their new maintainers since then through it. + +### Motivation + +Having an additional plugin installed at a Moodle site is always a risk. One of the essential aspects (apart from the code quality itself) that potential plugin users have to consider is how well the plugin is being maintained. Does the maintainer release regular updates and bug fixes? Is the plugin updated every six months for the new Moodle major release? Is there a place to report bugs and feature requests? And when reported, are they reflected? + +It's not that difficult to write a new Moodle plugin these days. Many students do that as a part of their school or thesis projects, for example. But can one rely on the author of plugin to provide sufficient (or at least some) support for it? To be a responsible maintainer of a plugin is much harder than to be an author of it. Many maintainers work on their plugins in their free time. And even if they are lucky enough to be paid for doing that, it's just time consuming (as everything). + +At certain moment, maintainers can realise they are not able to give enough love to their plugins any more. In the essay The Cathedral and the Bazaar, Eric Steven Raymond says + +:::note + +When you lose interest in a program, your last duty to it is to hand it off to a competent successor. + +::: + +And that is what Moodle plugins adoption programme is about. + +### Programme rules for plugin maintainers + +1. It is not a shame to give up on a plugin maintenance. Unmaintained plugin is worse than no plugin. We appreciate that you as the original author do not want to harm Moodle reputation just because your old code broke someone's site. +1. If you decide to offer your plugin for adoption, let the world know via posting into the [Plugins traffic forum](https://moodle.org/mod/forum/view.php?id=8149). +1. Your plugin will be put into a [special set in the Plugins directory](https://moodle.org/plugins/?q=set:maintainer-needed). +1. Once there is a volunteer who would like to take over the maintenance, please reply to the forum. It will help if the candidate proves their skills via a reference or a patch for existing issue etc. So we all know the plugin is passed over to good hands. +1. Finally, the successor is given the lead maintainer role for the plugin with all the permissions (edit the plugin record, release new versions etc). The previous maintainer will be still listed as the original author in the directory. + +### Applying to become a maintainer + +If you would like to become a new maintainer of a plugin that has been put up for the adoption, please reply to the relevant post in the [Plugins traffic forum](https://moodle.org/mod/forum/view.php?id=8149). It will help to demonstrate that you would be able to maintain the plugin - ideally with existing pull requests or other contributions to the plugin. + +### Notes + +- The `@author` tag in the phpDocs block of a file should never be changed even after the whole file is rewritten eventually. It's GPL legal statement, not a credits line. +- If the plugin was originally using Github as its repository, it is recommended to transfer the ownership of the repo. That way, all the reported issues in the github tracker, pull requests and all other information is kept. + +### Forced adoption + +As discussed in [MDLSITE-5354](https://tracker.moodle.org/browse/MDLSITE-5354), there are cases when a plugin becomes effectively orphaned due to maintainer's inactivity. In most cases, we can get in touch with the maintainer and agree on putting the plugin up for adoption. In rare cases when the maintainer can't be reached, the following procedure applies. + +- Given that the maintainer has not logged in to the moodle.org site for 90 or more days +- When the maintainer does not reply to an email sent to their address (obtained from their moodle.org user profile, last commit message and tracker account) within a period of 30 days +- And the maintainer does not reply to a personal message sent to them via moodle.org messaging features within a period of 30 days +- Then plugins directory curators can consider the plugin maintainer disappeared and the plugin orphaned. It is then allowed to put the plugin up for adoption on behalf of the maintainer or assign it to another maintainer. + +### Initiating forced adoption + +If you are aware of a plugin that seems abandoned and you would like to help and become a new maintainer of it: + +- Try to contact the current maintainer and let them know about this Plugins adoption programme. It is always better to have the plugin put for adoption by the current maintainers. +- If you do not get any response within a reasonable period, please publish your offer and intention via a new post in the [Plugins traffic forum](https://moodle.org/mod/forum/view.php?id=8149) to make the community aware of it. +- The plugins directory curators are subscribed to that forum and will be notified about your post there. They will help you with further process. diff --git a/general/community/plugincontribution/checklist.md b/general/community/plugincontribution/checklist.md new file mode 100644 index 0000000000..e041822e8b --- /dev/null +++ b/general/community/plugincontribution/checklist.md @@ -0,0 +1,173 @@ +--- +title: Plugin contribution checklist +sidebar_position: 2 +tags: + - Guidelines for contributors + - Plugins + - Plugin documentation +--- +Before approaching the [Moodle plugins directory](https://moodle.org/plugins) and submitting your plugin (or a new plugin version), you are encouraged to go through the checklists below and fix eventual issues with your plugin. Doing so will make the reviewer of your plugin happy :-) and may have impact on how long your plugin has to spend in the approval queue before it lands smoothly. + +## Meta-data + +### Plugin descriptions + +- Have a meaningful description of your plugin prepared in English. +- You will need a short concise description (just a sentence or two) for the short description field, and another elaborated one for the full description field. +- It is encouraged to have the same info at the plugin record page and in its `README` file. + +### Supported Moodle versions + +- New plugins submitted into the plugins directory must support at least one of the currently maintained Moodle version. +- See [Releases](../../releases.md) for the list of currently maintained Moodle versions (policy issue [MDL-47579](https://tracker.moodle.org/browse/MDL-47579)). + +### Code repository name + +- Provide a consistent experience for other Moodle developers and site administrators - follow the repository naming convention for Moodle plugins: `moodle-{plugintype}_{pluginname}`. + +### Source control URL + +- Facilitate sharing and further development of your open-source plugin - provide publicly accessible URL of your code repository. +- Github is a choice of most Moodle plugin developers. + +### Bug tracker URL + +- Encourage participation and have a place to report issues, bugs, make feature requests, or suggest other types of improvements. +- Both [Moodle tracker](../../development/tracker/guide.md) and [Github issues](https://guides.github.com/features/issues/) are common. +- See [Plugin contribution#Tracker](./index.md#tracker) if you want to use the Moodle tracker. + +### Documentation URL + +- Have a place where further documentation of your plugin will be located. +- [Moodle docs](../../community/plugincontribution/documentation) is preferred location, [Github wikis](https://guides.github.com/features/wikis/) or your own website will work, too. + +### Illustrative screenshots + +- Capture some screenshots of your plugin to help folks get an idea of what it looks like when installed. +- We will use these screenshots at more places in the plugins directory in the future. + +### Licensing + +- All files that implement the interface between the Moodle core and the plugin must be licensed under GNU GPL v3 (or later). +- Additional files contained in the plugin ZIP package (such as third party libraries used by the plugin, or included media) may eventually use other license as long as it is [GPL compatible](http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses). See [Plugin files#thirdpartylibs.xml](/docs/apis/commonfiles#thirdpartylibsxml) for how to do it. +- Note that binary files violate GPL unless the source code is also included or available (e.g. Java classes or Flash). + +### Subscription needed + +- If the plugin requires a third-party subscription based service, make sure the description states it very clearly. +- If the plugin requires some credentials to integrate with an external system (such as API keys etc), the description should provide clear information of where and how the users can obtain them. +- To allow the testing of the plugin functionality, please provide us with demo credentials (such as API keys etc) so that the approval team can use them to see the plugin in action. + +## Usability + +### Installation + +- Make sure the plugin installs smoothly from the ZIP package using the in-build plugin installation interface. +- If any non-standard post-installation steps are needed, make sure they are clearly listed in both plugin description and the `README` file. + +### Dependencies + +- If the plugin depends on another additional plugin, make sure it is clearly stated in the description and in the `README` file. +- Also declare the dependency explicitly in the plugin's [version.php](/docs/apis/commonfiles/version.php) file. +- Plugins must not require the admin to run **composer** or similar dependency manager tools. Many Moodle admins do not have access to their server shell and/or are not experienced with PHP building tools. Moodle plugins are supposed to be distributed in packages that work out of the box. + +### Functionality + +- Test the plugin functionality with full developer debugging enabled. +- Make sure the code does not throw unexpected PHP warnings, notices or even errors. + +### Cross-DB compatibility + +- Test the plugin with multiple database engines supported by Moodle. +- At very least, the plugin is supposed to work with MySQL and PostgreSQL unless reasons are clearly explained in the description and the `README` file (such as the plugin is a wrapper for third-party DB specific utility). +- [Data manipulation API](/docs/apis/core/dml) helps you to ensure cross-db compatibility. + +## Coding + +### Coding style + +- It is encouraged to follow [Moodle coding style](../../development/policies/codingstyle) and other [coding guidelines](../../development/policies.md). +- It's not always possible to achieve "all greens" in automated syntax checks (especially when third party libraries are involved) but you should aim to it. +- Consistent style helps others to read and understand your code (not only during the approval review). + +### English + +- Moodle is an international project. To facilitate sharing, reviews of and contributions to your code, all comments, variable names, function names etc. should be in English. + +### Boilerplate + +- All files should contain the common boilerplate at the beginning with explicit GPL license statement. +- See the section [Coding style#Files](../../development/policies/codingstyle/index.md#files) for the template. + +### Copyrights + +- All files should contain the `@copyright` tag with your name. +- If you are re-using someone else's file, keep the original copyrights reference to the previous author and add your name as a copyright holder. +- Both things should be clear: (1) that it is you to be blamed for the file code and (2) that your work is based on someone else's work. + +```php +/** + * @copyright 2019 John Smith + * @copyright based on work by 2010 Mary Stuart + */ +``` + +### CSS styles + +- All styles.css files from all plugins are concatenated, cached and served as a one big resource on all pages of the given Moodle installation. +- For that reason, plugins must use properly namespaced selectors so that their style sheets can be safely combined with others without affecting other pages and elements beyond the plugin's scope. +- Plugin specific CSS selectors are needed to make sure that your styling does not accidentally affect other parts of Moodle outside your plugin scope. +- For example, instead of the selector `.contentarea` it is better to use something like `.path-mod-mymodule .contentarea` as the `.path-\*` classes are automatically added by the Moodle core renderers to the HTML `` tag. + +### Namespace collisions + +- Check that all your DB tables, settings, functions, classes, constants and variables are named correctly. In most cases their names must start with the plugin type and plugin name, as in `block_yourname_something` (so called [frankenstyle](../../development/policies/codingstyle/frankenstyle.md) prefix). Modules are an exception to this rule as functions such as get_coursemodule_from_id() rely on there being no preface of 'mod'. +- Do not define own classes, functions, variables or constants in the top-level scope (global space) without the valid frankenstyle prefix. +- See [Coding style#Functions and Methods](../../development/policies/codingstyle/index.md#functions-and-methods) for details. + +### Settings storage + +- Check that your settings are stored in the table `config_plugins` and not in the main `config` table. +- This helps to avoid `$CFG` bloat and potential collisions. +- Use `get_config()` to pull the settings data out of the `config_plugins` table. +- In the file ```settings.php```, the setting names are supposed to be `plugintype_pluginname/settingname` (note the slash) and not `plugintype_pluginname_settingname` or even just `settingname`. +- If you eventually need to change the settings yourself, use `set_config()`. + +### Strings + +- Avoid hard-code texts in the code, always use `get_string()`. +- Just the English strings should ship with the plugin. All other translations are supposed to be submitted as contributions at [https://lang.moodle.org](https://lang.moodle.org) once your plugin is approved - see [Translating plugins](https://docs.moodle.org/dev/Translating_plugins). +- Your code must not rely on trailing and leading whitespace in strings. +- The string file must be considered as pure data file with the syntax `$string[]('id') = 'value';`. No other PHP syntax such as [concatenation](http://php.net/manual/en/language.operators.string.php), [heredoc and nowdoc](http://php.net/manual/en/language.types.string.php) is supported by the tools that we use when processing your strings (even if it may work in Moodle itself). +- The English language pack (lang/en/) in Moodle does not use "Capitalised Titles". + +### Privacy + +- Avoid gathering, storing, processing and sharing personal data unless they are needed for the plugin functionality. +- Inform about all the personal data that the plugin processes, via both description and the [Privacy API](/docs/apis/subsystems/privacy/). +- For plugins that integrate with an external system, privacy API implementation is required prior approval in the plugins directory (most notably the meta-data provider part). + +### Security + +- Never trust the user input. +- Do not access superglobals like `$_REQUEST` directly, use wrappers like required_param() with correct type declared to sanitize input. +- Always use placeholders in custom SQL queries (`?` or `:named`). +- Always check for the `sesskey` before taking an action on submitted data. +- Check for `require_login()`. +- Always check that the user has appropriate capabilities before displaying the widgets *and* before taking the actual action. +- Avoid using malicious functions like `call_user_func()`, `eval()`, `unserialize()` and so on, especially when they would be called with user-supplied data. + +## Approval blockers + +Examples of issues that will prevent your plugin from being approved: + +1. There is no public and transparent issue tracker where the community members can leave feedback, report bugs and suggest improvements. +1. Your SQL fails to work on PostgreSQL even when working on MySQL. +1. It integrates with an external system and does not have the privacy API correctly implemented. +1. It is an activity module and does not have the backup and restore API implemented. + +## See also + +- [Some common issues in submitted plugins](https://moodle.org/mod/forum/discuss.php?d=263614) post at the Plugins traffic forum at moodle.org +- [Moodle Coding Style](https://moodle.org/mod/forum/discuss.php?d=371967) forum thread at the General Developer Forum at moodle.org +- [Plugin files](/docs/apis/commonfiles) has a list and descriptions of files that work the same in all plugin types diff --git a/general/community/plugincontribution/codeprechecks.md b/general/community/plugincontribution/codeprechecks.md new file mode 100644 index 0000000000..feed7e6a46 --- /dev/null +++ b/general/community/plugincontribution/codeprechecks.md @@ -0,0 +1,39 @@ +--- +title: Plugin code prechecks +sidebar_position: 3 +tags: + - Guidelines for contributors + - Plugins + - Plugin documentation +--- +In the Moodle Plugins directory, uploaded plugins versions are automatically tested against a set of formal criteria. These tests typically do not check the actual plugin functionality, security or code correctness. They are more focused on formal aspects of the coding style. As such, they are most valuable for the plugin maintainers themselves. + +## Labels + +Plugin version with no detected errors or warnings has a label like this displayed: + +![Plugin code prechecks success](_codeprechecks/plugin-codeprechecks-success.png) + +If there are some formal errors or warnings detected, a label like this is displayed: + +![Plugin code prechecks error](_codeprechecks/plugin-codeprechecks-error.png) + +The first of the two numbers gives the total number of detected errors, the second number shows the number of warnings. If there are no errors but some warnings, the label is displayed in orange colour. In case of some errors, the label is displayed in red. + +Clicking the code prechecks label takes you to a page with details on particular tests executed. Individual labels are displayed for each of the test, with the same formatting rules as described above. + +![Plugin code prechecks details](_codeprechecks/plugin-codeprechecks-details.png) + +Finally, clicking some of these individual test labels takes you to a page with detailed raw output of the test system. + +## Test types + +- **phplint**: Checks the plugin source code for correct PHP syntax. +- **phpcs**: Checks the plugin against the [Moodle coding style](../../development/policies/codingstyle). +- **js**: Checks the plugin against the [JavaScript coding style](/docs/guides/javascript/). +- **css**: Checks the plugin against the [CSS coding style](https://docs.moodle.org/dev/CSS_Coding_Style). +- **phpdoc**: Checks that the plugin files, classes and functions are documented in the source code. +- **savepoint**: Reports issues detected with the handling of [upgrade savepoints](/docs/guides/upgrade/). +- **thirdparty**: Reports issues with the [thirdpartylibs.xml](/docs/apis/commonfiles#thirdpartylibsxml) file. +- **grunt**: Reports issues with [Grunt](https://docs.moodle.org/dev/Grunt) builds. +- **mustache** : Reports issues with [Mustache templates](/docs/guides/templates/). diff --git a/general/community/plugincontribution/documentation.md b/general/community/plugincontribution/documentation.md new file mode 100644 index 0000000000..f7c052822f --- /dev/null +++ b/general/community/plugincontribution/documentation.md @@ -0,0 +1,68 @@ +--- +title: Plugin documentation +sidebar_position: 6 +tags: + - Plugins + - Plugin documentation + - Guidelines for contributors +--- +Plugin developers, maintainers and users are welcome to include documentation about their plugin in the [English Moodle Docs](https://docs.moodle.org). Of course it is fine to have documentation elsewhere, such as the Github wiki, however one advantage of including documentation in the English Moodle Docs is that 'Moodle Docs for this page' links in Moodle (when logged in as a teacher or admin) can lead directly to your plugin documentation (as explained in the [Header and footer](https://docs.moodle.org/en/Header_and_footer) documentation). And, very important, it will then be very easy for translators of Moodle Docs to add translations for this information. + +## Where should the documentation go? + +To create a page for your documentation, type in the browser address bar: `https://docs.moodle.org/en/Plugin_name` (where *Plugin name* is the name of the plugin in the plugins directory). + +If your plugin has a page in Moodle, you can redirect this page to your documentation page as follows: + +1. Log in to your Moodle site as admin and go to the page for your plugin. +2. Follow the 'Help and documentation' link in the footer to *docs.moodle.org/en/mod/pluginname* (or similar). +3. Create this page and add a redirect by adding the text `#redirect [Plugin name](https://docs.moodle.org/dev/Plugin_name)`. + +## What should the documentation include? + +Copy and complete the following template code to obtain an infobox listing details of the plugin: + +``` +{{Infobox plugin +|type = Enter the plugin type e.g. activity, block, filter +|entry = Enter the plugins directory link +|tracker = Enter the bug tracker URL +|discussion = Enter the link to the forum or discussion thread +|maintainer = [Maintainer name](https://docs.moodle.org/User/Maintainer_name) +|float = Enter left or right to make the box float to that side (optional) +}} +``` + +![Example infobox: Stamp collection module](./_documentation/infobox_plugin.png) + +:::note + +If there is not yet a discussion thread about your plugin, please create one in the [General plugins forum](http://moodle.org/mod/forum/view.phpid=44). + +::: + +:::note + +Please make sure that the page linked in 'User:Maintainer name|Maintainer name' actually has your relevant details (profile), or a link to an existing profile in Moodle or elsewhere. + +::: + +The documentation may also include: + +- A features overview with screenshots or videos. +- Installation instructions + +Plugin documentation examples: [Stamp collection](https://docs.moodle.org/en/Stamp_collection_module), [Profile switches](https://docs.moodle.org/en/Profile_switches). + +## Which version of the user docs should the documentation be added to? + +Plugin documentation should be added to the most recent version wiki in which the plugin works, for example if the plugin works in Moodle 4.0, it should be added to the [Moodle 4.0 docs wiki](https://docs.moodle.org/400/en/). + +## I need help! + +If any of the above sounds too complicated, please don't worry - just email Moodle Docs wiki admin Helen ([helen@moodle.org](mailto:helen@moodle.org)) who will be happy to help you :-) (Restoring and redirecting pages etc. are quick and easy for a wiki admin to do!) + +## See also + +- [Wiki editing help](http://docs.moodle.org/en/Help:Editing) +- [MDL-34035](https://tracker.moodle.org/browse/MDL-34035) A way to have more help links relative to wwwroot diff --git a/general/community/plugincontribution/guardians.md b/general/community/plugincontribution/guardians.md new file mode 100644 index 0000000000..29999fad95 --- /dev/null +++ b/general/community/plugincontribution/guardians.md @@ -0,0 +1,25 @@ +--- +title: Plugins guardians +sidebar_position: 8 +tags: + - Guidelines for contributors + - Plugin documentation + - Plugins +--- +![thumb](./_guardians/plugins-guardian-logo.png) + +**Plugins guardians** are Moodle community members who volunteer to provide peer-reviews on plugins submitted into the [Plugins directory](../../community/plugincontribution/pluginsdirectory). Their peer-review is considerably taken into account when deciding on the plugin approval. + +## Mission + +These are the main principles and goals of the Plugins guardians programme: + +1. Help to build healthy and sustainable eco-system of Moodle plugins. +1. Protect the Moodle sites from dangerous, unreliable and generally badly written plugins. +1. Serve the plugin authors by providing them with honest feedback on their work, together with suggestions on how to learn to improve their code. + +These three come in this priority order. So for example, even not-so-well-written plugins can be approved as long as it is believed the community would benefit from them and there are signs that maintainers will improve them in the future. + +## How to join + +Moodle developers and experienced users are welcome to sign up for the Plugin guardians programme. Please email David Mudrák for more details. Please attach links to your Moodle development related work such as published plugins, Moodle patches, forum posts in developer forums etc. diff --git a/general/community/plugincontribution/index.md b/general/community/plugincontribution/index.md index a9f3a80fa6..411c78a1ae 100644 --- a/general/community/plugincontribution/index.md +++ b/general/community/plugincontribution/index.md @@ -5,7 +5,7 @@ tags: - Plugins - Plugin documentation --- -This page describes how to contribute your code into the [Plugins directory](https://docs.moodle.org/dev/Plugins_directory) to share it with the Moodle community. +This page describes how to contribute your code into the [Plugins directory](../../community/plugincontribution/pluginsdirectory.md) to share it with the Moodle community. ## Why @@ -33,12 +33,12 @@ Before submitting your work to the Plugins directory, you should make sure you h - **Plugin name** - See the [Frankenstyle](../../development/policies/codingstyle/frankenstyle.md) page for details. - **Repository** - You are expected to have the plugin code published and shared in a way that facilitates collaboration on further development. Ideally, you have the code available in a public Git repository. Most developers found [Github](https://github.com) a good place to host their code on. The [Repository](#repository) section below provides more details. - **Tracker** - You are expected to have a system where users can report issues, bugs and feature requests for the plugin. Again, many developers use [Github issues](https://guides.github.com/features/issues/) happily these days. You can also use the Moodle tracker if you prefer. See [Tracker](#tracker) section for more details. -- **Documentation** - The plugin should have a good documentation available. See [Plugin documentation](https://docs.moodle.org/dev/Plugin_documentation) for options. +- **Documentation** - The plugin should have a good documentation available. See [Plugin documentation](../../community/plugincontribution/documentation.md) for options. - **Screenshots** - Prepare good screenshots that illustrate your plugin's essential features. ## Sharing code in the Plugins directory -So you have written a new plugin and want to share it now in the [Plugins directory](https://docs.moodle.org/dev/Plugins_directory)? Great! Shortly, the workflow of publishing and maintaining your plugin in the Plugins directory looks like this: +So you have written a new plugin and want to share it now in the [Plugins directory](../../community/plugincontribution/pluginsdirectory.md)? Great! Shortly, the workflow of publishing and maintaining your plugin in the Plugins directory looks like this: ![Workflow of contributing a plugin into the Moodle plugins directory](_index/plugin-contribution-workflow.png)
@@ -47,7 +47,7 @@ Workflow of contributing a plugin into the Moodle plugins directory ([SVG versio
-1. You upload the initial plugin version for approval from the [Register a new plugin](https://moodle.org/plugins/registerplugin.php) link, available in the Navigation block in the blocks drawer on the right. To help the approval review go smoothly, please feel encouraged to review the [Plugin contribution checklist](https://docs.moodle.org/dev/Plugin_contribution_checklist) and follow all the guidelines there. +1. You upload the initial plugin version for approval from the [Register a new plugin](https://moodle.org/plugins/registerplugin.php) link, available in the Navigation block in the blocks drawer on the right. To help the approval review go smoothly, please feel encouraged to review the [Plugin contribution checklist](../../community/plugincontribution/checklist.md) and follow all the guidelines there. 1. After you submit the plugin for approval, please brace yourself with patience. You will likely wait some weeks before you get initial review results. We generally try and provide the feedback sooner, but it is not always possible. The actual approval queue stats [are available](https://moodle.org/plugins/queue.php). 1. The plugin goes through the validation and approval process. 1. Almost all plugins are sent back as "needing more work" as a result of the initial review, and there is no reason to feel bad about that. It is natural part of the workflow. You may find particular issues reported so you have an opportunity to demonstrate your ability to co-operate with the reporter to resolve them. diff --git a/general/community/plugincontribution/pluginsdirectory.md b/general/community/plugincontribution/pluginsdirectory.md new file mode 100644 index 0000000000..f7e6a0608b --- /dev/null +++ b/general/community/plugincontribution/pluginsdirectory.md @@ -0,0 +1,12 @@ +--- +title: Plugins directory +sidebar_position: 7 +tags: + - Guidelines for contributors + - Plugin documentation + - Plugins +--- + +- Plugins developed and maintained by community members are listed in the [Plugins directory](https://moodle.org/plugins) at moodle.org. +- See the [Plugin contribution](../../community/plugincontribution) guidelines if you wish to contribute. +- In the User docs there is a [Contributed code category](https://docs.moodle.org/en/Category/Contributed_code) that has a list of community contributed code projects and documents. diff --git a/general/community/plugincontribution/pluginsdirectoryapi.md b/general/community/plugincontribution/pluginsdirectoryapi.md new file mode 100644 index 0000000000..e4dc137f0c --- /dev/null +++ b/general/community/plugincontribution/pluginsdirectoryapi.md @@ -0,0 +1,188 @@ +--- +title: Plugins directory API +sidebar_position: 10 +tags: + - Guidelines for contributors + - Plugins + - Plugin documentation +--- +The Plugins directory at http://moodle.org/plugins exposes some of its features via web services layer, allowing the community to develop custom tools and integrations with other services such as GitHub Actions or Travis CI. + +## Access token + +To use the web service described below, the caller (client) authenticates itself with an access token. In almost all cases, developers use their own personal token and let the scripts (clients) work on behalf of them. + +The easiest way to obtain the access token (and some other useful information) is to visit *Plugins > API access* page at moodle.org through the side Navigation block. + +The token can be alternatively obtained via the *Preferences > Security keys* or programmatically via `login/token.php` script at moodle.org (however, tokens obtain that way have very short expiration in contrast with the ones generated at the dedicated page). + +## Plugins maintenance service + +The Plugins maintenance service (`plugins_maintenance`) provides functions for the plugins maintainers. The service is declared as: + +```php +'Plugins maintenance' => [ + 'functions' => [ + 'local_plugins_get_maintained_plugins', + 'local_plugins_add_version', + ], + 'shortname' => 'plugins_maintenance', + 'requiredcapability' => 'local/plugins:editownplugins', + 'enabled' => true, + 'restrictedusers' => 0, + 'downloadfiles' => true, + 'uploadfiles' => true, +], +``` + +### Getting the list of maintained plugins + +The first external function `local_plugins_get_maintained_plugins` allows to read the list of all plugins and their recent versions the caller is maintainer of. It does not expect any parameters and its return structure is described as follows: + +```php +return new external_multiple_structure( + new external_single_structure([ + 'id' => new external_value(PARAM_INT, 'Internal plugin identifier'), + 'name' => new external_value(PARAM_TEXT, 'Name of the plugin'), + 'shortdescription' => new external_value(PARAM_TEXT, 'Short description'), + 'description' => new external_value(PARAM_RAW, 'Description'), + 'descriptionformat' => new external_format_value('description'), + 'frankenstyle' => new external_value(PARAM_PLUGIN, 'Full component frankenstyle name'), + 'type' => new external_value(PARAM_ALPHANUMEXT, 'Plugin type'), + 'websiteurl' => new external_value(PARAM_URL, 'Website URL'), + 'sourcecontrolurl' => new external_value(PARAM_URL, 'Source control URL'), + 'bugtrackerurl' => new external_value(PARAM_URL, 'Bug tracker URL'), + 'discussionurl' => new external_value(PARAM_URL, 'Discussion URL'), + 'timecreated' => new external_value(PARAM_INT, 'Timestamp of plugin submission'), + 'approved' => new external_value(PARAM_INT, 'Approval status'), + 'visible' => new external_value(PARAM_BOOL, 'Visibility status'), + 'aggdownloads' => new external_value(PARAM_INT, 'Stats aggregataion - downloads'), + 'aggfavs' => new external_value(PARAM_INT, 'Stats aggregataion - favourites'), + 'aggsites' => new external_value(PARAM_INT, 'Stats aggregataion - sites'), + 'statusamos' => new external_value(PARAM_INT, 'AMOS registration status'), + 'viewurl' => new external_value(PARAM_URL, 'View URL'), + 'currentversions' => new external_multiple_structure( + new external_single_structure([ + 'id' => new external_value(PARAM_INT, 'Internal version identifier'), + 'version' => new external_value(PARAM_INT, 'Version number'), + 'releasename' => new external_value(PARAM_TEXT, 'Release name'), + 'releasenotes' => new external_value(PARAM_RAW, 'Release notes'), + 'releasenotesformat' => new external_format_value('releasenotes'), + 'maturity' => new external_value(PARAM_INT, 'Maturity code'), + 'changelogurl' => new external_value(PARAM_URL, 'Change log URL'), + 'altdownloadurl' => new external_value(PARAM_URL, 'Alternative download URL'), + 'md5sum' => new external_value(PARAM_TEXT, 'MD5 hash of the ZIP content'), + 'vcssystem' => new external_value(PARAM_ALPHA, 'Version control system'), + 'vcssystemother' => new external_value(PARAM_TEXT, 'Name of the other version control system'), + 'vcsrepositoryurl' => new external_value(PARAM_URL, 'Version control system URL'), + 'vcsbranch' => new external_value(PARAM_TEXT, 'Name of the branch with this version'), + 'vcstag' => new external_value(PARAM_TEXT, 'Name of the tag with this version'), + 'timecreated' => new external_value(PARAM_INT, 'Timestamp of version release'), + 'approved' => new external_value(PARAM_INT, 'Approval status'), + 'visible' => new external_value(PARAM_BOOL, 'Visibility status'), + 'supportedmoodle' => new external_value(PARAM_TEXT, 'Comma separated list of support Moodle versions'), + 'downloadurl' => new external_value(PARAM_URL, 'Download URL'), + 'viewurl' => new external_value(PARAM_URL, 'View URL'), + 'smurfresult' => new external_value(PARAM_TEXT, 'Code prechecks results summary'), + ]) + ), + ]) +); +``` + +#### Example cURL client fetching the list of maintained plugins + +```bash +#!/bin/bash + +# Replace this with your own service access token. +TOKEN="d41d8cd98f00b204e9800998ecf8427e" + +CURL="curl -s" +ENDPOINT=https://moodle.org/webservice/rest/server.php +FUNCTION=local_plugins_get_maintained_plugins + +${CURL} ${ENDPOINT} --data-urlencode "wstoken=${TOKEN}" --data-urlencode "wsfunction=${FUNCTION}" \ + --data-urlencode "moodlewsrestformat=json" | jq +``` + +### Releasing a new version + +The second function `local_plugins_add_version` allows to release a new version to the plugin. The input parameters are described as: + +```php +return new external_function_parameters([ + // The pluginid or frankenstyle must be provided (in this order of precedence). + 'pluginid' => new external_value(PARAM_INT, 'Internal identifier of the plugin', VALUE_DEFAULT, null), + 'frankenstyle' => new external_value(PARAM_PLUGIN, 'Full component name of the plugin', VALUE_DEFAULT, null), + // ZIP can be specified by draft area itemid (with single file in it), content or URL (in this order of precedence). + 'zipdrafitemtid' => new external_value(PARAM_INT, 'Itemid of user draft area with uploaded ZIP', VALUE_DEFAULT, null), + 'zipcontentsbase64' => new external_value(PARAM_RAW, 'ZIP file contents encoded with MIME base64', VALUE_DEFAULT, null), + 'zipurl' => new external_value(PARAM_URL, 'ZIP file URL', VALUE_DEFAULT, null), + // Following params may be auto-detected from the ZIP content. + 'version' => new external_value(PARAM_INT, 'Version number', VALUE_DEFAULT, null), + 'releasename' => new external_value(PARAM_TEXT, 'Release name', VALUE_DEFAULT, null), + 'releasenotes' => new external_value(PARAM_RAW, 'Release notes', VALUE_DEFAULT, null), + 'releasenotesformat' => new external_format_value('releasenotes', VALUE_DEFAULT, FORMAT_MOODLE), + 'maturity' => new external_value(PARAM_INT, 'Maturity code', VALUE_DEFAULT, null), + 'supportedmoodle' => new external_value(PARAM_TEXT, 'Comma separated list of supported Moodle versions', + VALUE_DEFAULT, null), + // Other optional properties. + 'changelogurl' => new external_value(PARAM_URL, 'Change log URL', VALUE_DEFAULT, null), + 'altdownloadurl' => new external_value(PARAM_URL, 'Alternative download URL', VALUE_DEFAULT, null), + 'vcssystem' => new external_value(PARAM_ALPHA, 'Version control system', VALUE_DEFAULT, null), + 'vcssystemother' => new external_value(PARAM_TEXT, 'Name of the other version control system', VALUE_DEFAULT, null), + 'vcsrepositoryurl' => new external_value(PARAM_URL, 'Version control system URL', VALUE_DEFAULT, null), + 'vcsbranch' => new external_value(PARAM_TEXT, 'Name of the branch with this version', VALUE_DEFAULT, null), + 'vcstag' => new external_value(PARAM_TEXT, 'Name of the tag with this version', VALUE_DEFAULT, null), +]); +``` + +The API has been designed so that: + +- The actual ZIP can be taken from pre-uploaded file (standard way of using `webservice/upload.php`), or submitting the file contents directly, or providing an URL the ZIP should be fetched from. +- As many as possible parameters (such as list of supported Moodle versions, release name, release notes etc) default to the values specified in the ZIP itself. +- So it should be enough to specify just the plugin (either by numerical ID number of frankenstyle) and the ZIP with the new version. All other values are optional and can be used to override the auto-detected ones. + +When successful, the external function's response is described as: + +```php +return new external_single_structure([ + 'id' => new external_value(PARAM_INT, 'Internal identifier of the newly created version'), + 'md5sum' => new external_value(PARAM_TEXT, 'MD5 hash of the ZIP content'), + 'timecreated' => new external_value(PARAM_INT, 'Timestamp of version release'), + 'downloadurl' => new external_value(PARAM_URL, 'Download URL'), + 'viewurl' => new external_value(PARAM_URL, 'View URL'), + 'warnings' => new external_multiple_structure( + new external_value(PARAM_RAW, 'Validation warnings') + ), +]); +``` + +#### Example CLI script to release a new version of a plugin + +```bash +#!/bin/bash + +# Replace this with your own service access token. +TOKEN="d41d8cd98f00b204e9800998ecf8427e" + +# Set the full component name of the plugin. +PLUGIN=mod_subcourse +# Path to the ZIP fle with the new version. +ZIP=version.zip + +CURL="curl -s" +HOST="https://moodle.org/" +ENDPOINT_REST="${HOST}/webservice/rest/server.php" +ENDPOINT_UPLOAD="${HOST}/webservice/upload.php" + +ITEMID=$(${CURL} -F data=@${ZIP} "${ENDPOINT_UPLOAD}?token=${TOKEN}" | jq --raw-output '.[0].itemid') + +${CURL} ${ENDPOINT_REST} --data-urlencode "wstoken=${TOKEN}" --data-urlencode "wsfunction=${FUNCTION}" --data-urlencode "moodlewsrestformat=json" \ + --data-urlencode "frankenstyle=${PLUGIN}" --data-urlencode "zipdrafitemtid=${ITEMID}" | jq +``` + +#### GitHub Actions + +A new workflow can be configured at GitHub Actions to automatically release a new version in the Plugins directory once a tag is pushed to the repository. Please see https://github.com/moodlehq/moodle-plugin-release for details. diff --git a/general/community/plugincontribution/qaprechecks.md b/general/community/plugincontribution/qaprechecks.md new file mode 100644 index 0000000000..a9d1fbe744 --- /dev/null +++ b/general/community/plugincontribution/qaprechecks.md @@ -0,0 +1,36 @@ +--- +title: Plugin QA prechecks +sidebar_position: 4 +tags: + - Guidelines for contributors + - Plugins + - Plugin documentation + - QA +--- +Plugin QA prechecks are for testing the functionality of plugins submitted for approval in the Moodle Plugins directory. Together with [code prechecks](../../community/plugincontribution/codeprechecks), they are part of the plugin [approval process](../../community/plugincontribution#sharing-code-in-the-plugins-directory). + +Moodle community members with experience in setting up a local Moodle test environment can help with plugin QA prechecks. If you would like to help, please contact David Mudrák. + +## QA environment setup + +To perform plugin QA prechecks, you need to have a test Moodle site (normally the latest stable version) installed locally. Your test site should have + +- Developer debugging enabled with debugging messages displayed in order to report all PHP notices, warnings and errors spotted during plugin installation and usage. +- `$CFG->prefix` set to a non-default value, such as "m_" or "mqa_". This allows to catch cases when the default "mdl_" prefix is hard-coded in PHP. + +In addition, if possible the site should run on the PostgreSQL database engine to catch potential MySQL-specific SQL statements in the code. + +## Process + +1. Choose a plugin needing an initial review from the [list of plugins awaiting approval](https://moodle.org/plugins/report/index.php?report=pendingapproval_plugins) (access restricted to members of the [Plugins guardians](../../community/plugincontribution/guardians) group). +1. To show that you are going to perform the QA prechecks, set yourself as the plugin approval issue assignee (CONTRIB-xxx as mentioned at the plugin page comments area). +1. Download and install it on your test site then perform the QA prechecks as listed below. +1. Add a comment to the plugin approval issue with your findings using the 'Plugin QA checklist' canned response. +1. If you detect any problems with the plugin, add a comment to the plugin page asking the plugin developer to look at the plugin approval issue. +1. Once everything is fine, add a comment to the plugin approval issue 'Congratulations, your plugin passes the metadata and usability checks. :-) Coding checks will be done soon.' + +## QA prechecks + +1. Does the plugin have all the appropriate metadata as described in the [Plugin contribution checklist](../../community/plugincontribution/checklist)? +1. Does the plugin install nicely and not break or otherwise negatively affect the site functionality (anti-regression test)? This also checks that all eventual dependencies are already available in the plugins directory. +1. If possible (e.g. if no complex integration with an external system is needed), test the actual functionality of the plugin to see it works as described (feature test). diff --git a/general/community/plugincontribution/thirdpartylibraries.md b/general/community/plugincontribution/thirdpartylibraries.md new file mode 100644 index 0000000000..c065a471f7 --- /dev/null +++ b/general/community/plugincontribution/thirdpartylibraries.md @@ -0,0 +1,35 @@ +--- +title: Plugin with third party libraries +sidebar_position: 5 +tags: + - Guidelines for contributors + - Plugins + - Plugin documentation +--- +This page describes the correct way to include third party libraries with your plugin. + +A third party library refers to any library where the latest version of the code is not maintained and hosted by Moodle. An example is "Mustache.php". Following this process means that all third party libraries are correctly listed in the page *Site administration > Development > Third party libraries*, they can be tracked and kept up to date - and we will not introduce conflicting versions of the same library in different places. + +## Instructions + +The process for including a third party library is the same for core code as it is for a plugin - there are a number of steps to follow. + +1. Check the license to make sure the library uses a GPLv3 compatible license - see the [list of compatible licenses](https://www.gnu.org/licenses/license-list.en.html). If a library is not compatible with GPLv3 then it cannot be distributed together with the plugin in one ZIP package and hosted in the Moodle Plugins directory. +1. Check the library is not already shipped by core - we don't want multiple versions of the same library. +1. Download the latest stable release of the code. +1. Perform any build steps required to get a distributable version of the library. This will vary depending on the library - but an example is running less to generate minified css files. +1. Put that library into a sub folder in your plugin. It is best to NOT use version numbers in the foldername ("jquery" not "jquery-1.7.3"). +1. Create or update the `lib/thirdpartylibs.xml` file for your plugin, according to the format described in the [documentation](/docs/apis/commonfiles#thirdpartylibsxml). +1. Create a [`readme_moodle.txt`](/docs/apis/commonfiles#readme_moodletxt) file in the new third party library folder containing detailed instructions on how to complete steps 3-6 above. This should list download urls, build instructions etc. +1. Note any creation, update or deletion of third party libraries in your plugins `upgrade.txt` or [CHANGES](/docs/apis/commonfiles#changes). +1. Run `grunt ignorefiles` to regenerate ignored files path + +## Exceptions: + +### JavaScript AMD modules + +JavaScript AMD modules cannot exist in a sub-folder - they must exist in a single .js file in the amd/src folder for your plugin. So - the process for AMD files is the same as above, except that the license and readme_moodle.txt file contents must be added as a JavaScript comment to the top of the libraries .js file. + +## See also + +- [Grunt](https://docs.moodle.org/dev/Grunt) - Information for installing and using Grunt diff --git a/general/development/process/peer-review.md b/general/development/process/peer-review.md index 6c115e0962..834f76b486 100644 --- a/general/development/process/peer-review.md +++ b/general/development/process/peer-review.md @@ -204,7 +204,7 @@ See also the [Commit cheat sheet](https://docs.moodle.org/dev/Commit_cheat_sheet ### Third party code -Does the change contain [third party code](https://docs.moodle.org/dev/Plugin_with_third_party_libraries)? If so, ensure that: +Does the change contain [third party code](../../community/plugincontribution/thirdpartylibraries)? If so, ensure that: - The code is licensed under a [GPL compatible license](http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses%7C). - The instructions for upgrading/importing the library and contained within a readme_moodle.txt file. diff --git a/project-words.txt b/project-words.txt index 52aba6f3a6..afc8685fd8 100644 --- a/project-words.txt +++ b/project-words.txt @@ -121,6 +121,7 @@ coursecatlib coursefiles courseid courseindex +coursemodule crtl datafield dayofweek @@ -220,6 +221,7 @@ multichoice multilang multilanguage myprofile +nowdoc oldmoduleid onlinetext opcache @@ -232,6 +234,7 @@ pgsql phpcs phpdoc phpdocs +phplint phpmailer phpstorm phptags @@ -243,6 +246,7 @@ plugininfo pluginname plugintype plugintypes +prechecks previewquestion privatefiles protectusernames @@ -258,6 +262,8 @@ riskbitmask ruleset saas safeoverride +savepoint +savepoints scormreport selfcompletion sesskey @@ -271,6 +277,7 @@ simpletest siteadmin siteidentifier sitepolicynotagreed +superglobals smallmessage splitview stepslib