Moodle mod resource view php

Activity modules

Activity modules are a fundamental course feature and are usually the primary delivery method for learning content in Moodle.

The plugintype of an Activity module is mod , and the frankenstyle name of a plugin is therefore mod_[modname] .

All activity module plugins are located in the /mod/ folder of Moodle.

The term [modname] is used as a placeholder in this documentation and should be replaced with the name of your activity module.

Folder layout​

Activity modules reside in the /mod directory.

Each module is in a separate subdirectory and consists of a number of mandatory files and any other files the developer is going to use.

Below is an example of the file structure for the folder plugin.

View an example directory layout for the `folder` plugin.

. ├── backup │ ├── moodle1 │ │ └── lib.php │ └── moodle2 │ ├── backup_folder_activity_task.class.php │ ├── backup_folder_stepslib.php │ ├── restore_folder_activity_task.class.php │ └── restore_folder_stepslib.php ├── classes │ ├── analytics │ │ └── indicator │ │ ├── activity_base.php │ │ ├── cognitive_depth.php │ │ └── social_breadth.php │ ├── content │ │ └── exporter.php │ ├── event │ │ ├── all_files_downloaded.php │ │ ├── course_module_instance_list_viewed.php │ │ ├── course_module_viewed.php │ │ └── folder_updated.php │ ├── external.php │ ├── privacy │ │ └── provider.php │ └── search │ └── activity.php ├── db │ ├── access.php │ ├── install.php │ ├── install.xml │ ├── log.php │ ├── services.php │ └── upgrade.php ├── download_folder.php ├── edit.php ├── edit_form.php ├── index.php ├── lang │ └── en │ └── folder.php ├── lib.php ├── locallib.php ├── mod_form.php ├── module.js ├── phpunit.xml ├── pix │ ├── icon.png │ └── icon.svg ├── readme.txt ├── renderer.php ├── settings.php ├── styles.css ├── tests │ ├── backup │ │ └── restore_date_test.php │ ├── behat │ │ └── folder_activity_completion.feature │ ├── event │ │ └── events_test.php │ ├── externallib_test.php │ ├── generator │ │ └── lib.php │ ├── generator_test.php │ ├── lib_test.php │ ├── phpunit.xml │ └── search │ └── search_test.php ├── version.php └── view.php 

Standard Files and their Functions​

There are several files that are crucial to Moodle. These files are used to install your module and then integrate it into Moodle. Each file has a particular function, some of the files are optional, and are only created if you want to use the functionality it offers. Below are the list of most commonly used files.

Backup Folder​

Plugin Backup configuration

File path: /backup/

If your plugin stores data then you may need to implement the Backup feature which allows the activity to backed up, restored, and duplicated.

For more information on Backup and restore, see the following:

access.php — Capability defaults​

Plugin capabilities

File path: /db/access.php

The db/access.php file contains the initial configuration for a plugin’s access control rules.

Access control is handled in Moodle by the use of Roles, and Capabilities. You can read more about these in the Access API documentation.

Changing initial configuration

If you make changes to the initial configuration of existing access control rules, these will only take effect for new installations of your plugin. Any existing installation will not be updated with the latest configuration.

Updating existing capability configuration for an installed site is not recommended as it may have already been modified by an administrator.

For activities the following capabilities are required:

• mod/[modname]:addinstance : Controls whether a user may create a new instance of the activity
• mod/[modname]:view : Controls whether a user may view an instance of the activity

The example below shows the recommended configuration for the addinstance and view capabilities.

This configuration will allow:

• editing teachers and managers to create new instances, but not non-editing teachers.
• all roles to view the activity.

Granting the view capability to archetypes like guest does not allow any user to view all activities. Users are still subject to standard access controls like course enrolment.

For further information on what each attribute in that capabilities array means visit NEWMODULE Adding capabilities.

  $capabilities = [ 'mod/[modname]:addinstance' => [ 'riskbitmask' => RISK_XSS, 'captype' => 'write', 'contextlevel' => CONTEXT_COURSE, 'archetypes' => [ 'editingteacher' => CAP_ALLOW, 'manager' => CAP_ALLOW, ], 'clonepermissionsfrom' => 'moodle/course:manageactivities', ], 'mod/[modname]:view' => [ 'captype' => 'read', 'contextlevel' => CONTEXT_MODULE, 'archetypes' => [ 'guest' => CAP_ALLOW, 'student' => CAP_ALLOW, 'teacher' => CAP_ALLOW, 'editingteacher' => CAP_ALLOW, 'manager' => CAP_ALLOW, ], ], ]; 

events.php — Event observers​

Event observer definitions

File path: /db/events.php

Moodle supports a feature known as Event observers to allow components to make changes when certain events take place.

The db/events.php file allows you define any event subscriptions that your plugin needs to listen for.

Event subscriptions are a convenient way to observe events generated elsewhere in Moodle.

Communication between components

You should not use event subscriptions to subscribe to events belonging to other plugins, without defining a dependency upon that plugin.

See the Component communication principles documentation for a description of some of the risks of doing so.

  // This file is part of Moodle - http://moodle.org/ // // Moodle is free software: you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation, either version 3 of the License, or // (at your option) any later version. // // Moodle is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // // You should have received a copy of the GNU General Public License // along with Moodle. If not, see .  /**  * Event observer definitions for the plugintype_pluginname plugin.  *  * @package plugintype_pluginname  * @copyright Year, You Name  * @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later  */  $observers = [ [ 'eventname' => '\core\event\course_module_created', 'callback' => '\plugintype_pluginname\event\observer\course_module_created::store', 'priority' => 1000, ], ]; 

install.xml — Database installation​

Database schema

File path: /db/install.xml

The install.xml file is used to define any database tables, fields, indexes, and keys, which should be created for a plugin during its initial installation.

When creating or updating the install.xml you must use the built-in XMLDB editor within Moodle.

Moodle requires that you create a table for your plugin whose name exactly matches the plugin name. For example, the certificate activity module must have a database table named certificate . Certain fields within this table are also required:

Field name	Properties	Keys / Indexes	Notes
id	INT(10), auto sequence	primary key for the table
course	INT(10)	foreign key to the course table
name	CHAR(255)	Holds the user-specified name of the activity instance
timemodified	INT(10)	The timestamp of when the activity was last modified
intro	TEXT	A standard field to hold the user-defined activity description (see FEATURE_MOD_INTRO )
introformat	INT(4)	A standard field to hold the format of the field

upgrade.php — Upgrade steps​

Upgrade steps

File path: /db/upgrade.php

The db/upgrade.php file contains upgrade steps, including database schema changes, changes to settings, and other steps which must be performed during upgrade.

See the Upgrade API documentation for further information.

Generating Database Schema changes

When making changes to the database schema you must use the build-in XMLDB editor within Moodle. This can be used to generate php upgrade steps.

The install.xml schema must match the schema generated by the upgrade at all times.

To create an upgrade step you must:

1. Use the XMLDB editor to create the definition of the new fields
2. Update the install.xml from the XMLDB editor
3. Generate the PHP upgrade steps from within the XMLDB Editor
4. Update the version number in your version.php

In many cases you will be able to combine multiple upgrade steps into a single version change.

When a version number increment is detected during an upgrade, the xmldb_[pluginname]_upgrade function is called with the old version number as the first argument.

See the Upgrade API documentation for more information on the upgrade process.

  // This file is part of Moodle - http://moodle.org/ // // Moodle is free software: you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation, either version 3 of the License, or // (at your option) any later version. // // Moodle is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // // You should have received a copy of the GNU General Public License // along with Moodle. If not, see .  /**  * Upgrade steps for the mod_[modname] plugin.  *  * @package mod_[modname]  * @copyright Year, You Name  * @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later  */  function xmldb_certificate_upgrade($oldversion = 0)   if ($oldversion  2012091800)   // Add new fields to certificate table. $table = new xmldb_table('certificate'); $field = new xmldb_field('showcode'); $field->set_attributes(XMLDB_TYPE_INTEGER, '1', XMLDB_UNSIGNED, XMLDB_NOTNULL, null, '0', 'savecert'); if (!$dbman->field_exists($table, $field))   $dbman->add_field($table, $field); > // Add new fields to certificate_issues table. $table = new xmldb_table('certificate_issues'); $field = new xmldb_field('code'); $field->set_attributes(XMLDB_TYPE_CHAR, '50', null, null, null, null, 'certificateid'); if (!$dbman->field_exists($table, $field))   $dbman->add_field($table, $field); >  // Certificate savepoint reached. upgrade_mod_savepoint(true, 2012091800, 'certificate'); > > 

Источник