MoodleDocs - User contributions [en]

Learning Tools/Installation

2026-03-23T10:02:34Z

Stronk7:

== Installation ==
For more detailed info how to install plugins in general, visit https://docs.moodle.org/501/en/Installing_plugins.

To install Learning Tools, you have three options:
=====Option 1: Install from Moodle.org=====
'''''NOT YET POSSIBLE, WAITING FOR PLUGIN APPROVAL'''''
#Login as an admin and go to Site administration > Plugins > Install plugins. (If you can't find this location, then plugin installation is prevented on your site.)
#Click the button 'Install plugins from Moodle plugins directory'.
#Search for "Learning Tools", click the install button, then click Continue.
#Confirm the installation request
#Check the plugin validation report
=====Option 2: Install from zip package=====
#Download Learning Tools from <nowiki>https://bdecent.de/product/learningtools</nowiki>
#Login to your Moodle site as an admin and go to Administration > Site administration > Plugins > Install plugins.
#Upload the ZIP file. You should only be prompted to add extra details (in the Show more section) if the plugin is not automatically detected.
#If your target directory is not writeable, you will see a warning message.
#Check the plugin validation report
=====Option 3: Install manually on server=====
#Download Learning Tools from <nowiki>https://bdecent.de/product/learningtools</nowiki>
#Rename the folder to "learningtools"
#Upload or copy it to your Moodle server.
#Unzip it in the `/local` directory. (the path should then look for example like this: [https://yourmoodle.com/mod/pulse/version.php https://yourmoodle.com/local/learningtools/version.php])
#In your Moodle site (as admin) go to Settings > Site administration > Notifications (you should, for most plugin types, get a message saying the plugin is installed).
==Initial configuration==
After the installation, the plugin is ready to use. The floating button will immediately show up for all authenticated users (guests and non-authenticated users can't use them).
===Global settings===
Learning Tools has a couple of global settings which can be accessed via at ''Site administration > Plugins > Local Plugins > Learning Tools''
*'''Notification display time''' — this defined the time that the notification is shown to the user after the user for example bookmarked a page
*'''Learning Tools in user menu''' — syntax for adding tools to the user menu (see below)
*'''Manage Learning Tools''' — on this page, you can enable/disable, sort and uninstall each tool
===Adding Learning Tools to the user menu===
In order to keep the floating button menu as simple as possible, we have only added the "action" (e.g. create a bookmark), but not the "list" (e.g. see all bookmarks). Instead, we tried to make Learning Tools as native as possible by adding them on the user profile, following a design pattern used by core moodle (e.g. for forum posts or user related reports).

In addition, we think that the user menu is a great spot as well to provide access, too. That's why we've prepared the syntax for you, so that you can simply copy and paste it into the user menu. (we had initially automated that, but it felt too intrusive and would have potentially surprised some administrators, which is why we opted for this solution instead).

The user menu can be customized here: ''Site administration > Appearance > Themes > Theme settings > User menu items'' (or simply search for user menu).
[[Category:Learning Tools]]
[[Category:bdecent plugins]]
[[Category:Plugin]]

[[es:Instalación de Herramientas de Aprendizaje]]

Talk:Installing plugins

2026-03-20T09:46:11Z

Stronk7:

Hi,

I'd suggest to remove the "Contributed code" category from this page. This is not contributed code, but real information about how to install code/plugins, contributed or no. --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] ([[User talk:Eloy Lafuente (stronk7)|talk]]) 09:45, 20 March 2026 (UTC)

Talk:Installing plugins

2026-03-20T09:45:39Z

Stronk7: Created page with "Hi, I'd suggest to remove the "Contributed code" category from this page. This is not contributed code, but real information about how to install code, contributed or no. --~~~~"

Hi,

I'd suggest to remove the "Contributed code" category from this page. This is not contributed code, but real information about how to install code, contributed or no. --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] ([[User talk:Eloy Lafuente (stronk7)|talk]]) 09:45, 20 March 2026 (UTC)

Count user block

2025-11-19T17:27:39Z

Stronk7:

This plug-in is the block which counts the number assigned to the roll within a course like moodle1.9.
Only an administrator can use.
When it installs in the front page of moodle, this block considers the load of a server and a total button is not displayed.

You can be a registered user on the screen, such as moodle1.9 When you click the name of the role.

GitHub:

https://github.com/h-honda/moodle

[[Category: Plugin]]

blocks/moodletxt/addressbook contact add

2025-11-16T16:32:08Z

Stronk7:

== Adding a Contact to a MoodleTxt Address Book ==

This page allows you to add a new contact to your address book. The first section allows you to enter some basic information about the contact:

*Contact's first name
*Contact's last name
*Name of company (if contact is a company, or represents one)
*Contact's phone number

=== Group Membership ===

Any groups that already exist within your address book are displayed in the "Addressbook Groups" list on the left of the page. If you want to add this new contact to any of these groups, select them from the list on the left and click the >> button. This will move them to the list on the right hand side of the page. The new contact will be added to any groups that are shown in this list on the right when it is saved to the address book.

=== Saving the Contact ===

When you are satisfied with the details you have entered for the new contact, you have two options when saving it. You can either save the contact, and return to the address book's listing page, or you can clear the form to add another contact. Select the appropriate button from the bottom of the form, and the contact will be saved to the database.

[[Category:MoodleTxt|Addressbook Add Contact]]
[[Category:Plugin]]

blocks/moodletxt/addressbook groups

2025-11-16T16:31:56Z

Stronk7:

== Managing your MoodleTxt Addressbook Groups ==

This page consists of three forms, allowing you to add, edit and delete groups.

=== Adding a Group ===

Adding a group to the address book couldn't be simpler. Locate the form at the top of the page headed '''Add a Group'''. This form has a single text box for the name of the group. Give the group a name, and then click the "Add Group" button, and the new contact group will be created.

=== Updating Group Members ===

If you wish to add or remove members from a group, first select the group you wish to modify from the large drop-down box at the top of the form labelled '''Update Group Members'''. When you have selected a group, you should see the form update, with the current group members being moved from the list of potential members on the left to the list of current members on the right (assuming that the group already has members).

[[Image:moodletxt-group-member-selector.png|frame|center|Group membership selector]]

To add contacts to the group, select them from the list of potential members on the left, and click the ">>" button. You will see them move to the list of group members on the right. To remove contacts from the group, select them from the right hand list and click the "<<" button.

Once you are satisfied with the list of group members, click the "Update Group" button, and the group membership list will be updated. The page will refresh, and a short notification should be displayed indicating that the group has been saved to the database.

=== Deleting Groups ===

The first step to deleting a group is to select the one you wish to delete from the drop-down list at the top of the form labelled '''Delete a Group'''. (You'll find it at the bottom of the page.)

When you have done this, you need to confirm what should happen to the contacts that are already in the group being deleted. Three options are available, and are shown below the group list.

; Preserve Contacts : Will remove the group without affecting the contacts contained within it.
; Delete Contacts : This will remove the group and delete its members from the address book. This is useful for erasing old classes/years from the book.
; Merge Contacts : This will remove the group and transfer its contacts into another group, allowing you to merge groups together. If you select this option, be sure to select a destination group from the drop-down list provided.

Once you have decided what you want to happen to the group's members, click the "Delete Group" button and the group will be erased from the address book.

[[Category:MoodleTxt|Addressbook Groups]]
[[Category:Plugin]]

blocks/moodletxt/addressbook view

2025-11-16T16:31:49Z

Stronk7:

== Viewing a MoodleTxt Address Book ==

This page exists displays all contacts available within the selected address book. It allows you to browse, edit and delete them, as well as export the list to a file for download. If you wish to add a new contact to the address book, or edit your address book's contact groups, two links to the pages that handle this functionality are available at the top-left of the page.

=== Contact Listing ===

The primary feature of this page is a listing of all contacts contained within the address book. The table of contacts shows the following fields:

*Contact's first name
*Contact's last name
*Name of company (if contact is a company, or represents one)
*Contact's phone number

The list displayed is a standard Moodle table, and can be re-ordered, edited and navigated like any other tabular list in Moodle.

=== Editing a Listed Contact ===

MoodleTxt supports inline editing of the contacts displayed in the contact list. To edit a contact, simply double-click on it. The text row representing that contact will be automatically converted into a form.

[[Image:moodletxt-addressbook-contact-edit.png|border|none]]

You can then make the appropriate corrections to the contact directly within the listing. Once you are satisfied with your changes, click the "Save" button at the right of the contact row, and the contact will be saved back into the listing. Clicking "Cancel" will revert any changes and restore the contact's entry to its previous state.

=== Deleting One or More Contacts ===

To delete contacts from your address book, first select them in the contact listing by checking the box at the left of each contact entry. (You can also select or deselect all contacts on the page by using the "Check all"/"Uncheck all" links at the bottom left of the table.) Once you have the contacts you wish to delete selected, click the "Delete the selected records" link underneath the contact listing, and the contacts will be removed from the address book.

Alternatively, if the set of contacts you wish to retain in the address book is smaller than the set you wish to delete, you can select the contacts you wish to keep, and then click the link labelled "Delete all records except those currently selected" underneath the contact listing. This will delete all contacts in the address book except for those that you have selected from the contact listing.

=== Changing the Address Book's Name and Visibility ===

If you wish to change the details of the address book, they are displayed as an inline form at the top-left of the page, just above the contact listing. Simply edit the address book's name and visibility level and click the "Save" button. The page will refresh, and a short notification should be displayed indicating that the address book's details were updated in the database.

Possible visibility levels for the address book:

; Private Address Books : These are address books visible only to you, and can only have messages sent to them from your account.
; Global Address Books : These are visible to all users within the Moodle system, and messages can be sent to them from anywhere. However, the address book can still only be edited/maintained by you.

[[Category:MoodleTxt|Addressbook Listing]]
[[Category:Plugin]]

blocks/moodletxt/addressbooks

2025-11-16T16:31:44Z

Stronk7:

== MoodleTxt: Managing Address Books ==

MoodleTxt allows you to create your own address books of contacts for sending messages to. These are generally contacts who do not have accounts within the Moodle system themselves, such as the parents of students.

Your existing address books (if you have any) are displayed at the top of the page. Clicking on the name of an address book will open it for browsing and editing on another page. The icon next to an address book indicates whether it is a private or global addressbook.

[[Image:moodletxt-addressbook-icons.png|frame|none|Example of a global and private addressbook, with icons.]]

; Private Address Books : These are address books visible only to you, and can only have messages sent to them from your account.
; Global Address Books : These are visible to all users within the Moodle system, and messages can be sent to them from anywhere. However, the address book can still only be edited/maintained by you.

=== Adding a New Address Book ===

Adding a new address book to MoodleTxt is simple. Under the '''Add a new address book''' heading, type the name of the new address book into the box labelled "Address book name". Below that, select whether you want the address book to be private (only usable by you) or global (usable by anyone).

When you are happy with your selections, click the "Add" button below the form. The page will refresh, and your new address book should appear in the list at the top of the page, along with a short success message indicating that the address book was saved to the database successfully. You can now click into the address book and begin adding contacts to it.

=== Deleting an Existing Address Book ===

This section allows you to permanently delete an address book from the MoodleTxt block, or optionally merge it into another existing address book.

Firstly, select the address book you wish to delete from the first drop-down box in this section. Next, you have the option to either delete the contacts in the address book, or merge them into another one. If you select the first option, then when the address book is deleted, all contacts and contact groups within it will also be permanently deleted. If you select the second option, then when the address book is deleted, all of its contacts and groups will be moved into another address book within the system. In order to use this option, you must select the destination address book from the second drop-down list provided.

Once you are happy with the options selected, click the "Delete/Merge" button below the form. The page will be refreshed, and your selected address book should have been removed from the list of existing address books at the top of the page. A short notification message should also be displayed, indicating that the address book was successfully deleted from the database.

[[Category:MoodleTxt|Addressbooks]]
[[Category:Plugin]]

Moodletxt capabilities

2025-11-16T16:31:36Z

Stronk7:

== List of all capabilities installed by MoodleTxt ==

This page is an administrator's reference for the user capabilities that will be installed into your Moodle installation by MoodleTxt. You can use these to grant or deny access to the various sections of MoodleTxt using these capabilities in the standard Moodle control panel.

{| class="wikitable"
|-
! Capability Name
! Default Assignment
! Description
|-
| block/moodletxt:addressbooks
| Teachers and admins
| Granting this permission allows a user to create addressbooks within MoodleTxt
|-
| block/moodletxt:adminsettings
| Admins only
| Allows a user to use the MoodleTxt control panel and see error messages intended for administrators.
|-
| block/moodletxt:adminusers
| Admins only
| Allows a user to admin user information within MoodleTxt, such as editing a user's message filters, or viewing their message history.
|-
| block/moodletxt:defaultinbox
| Teachers and admins
| If a user has this capability assigned to them at system level, then they can be selected as the "default inbox" when creating message filters. (A default inbox is where any unfiltered messages for a given account are deposited.)
|-
| block/moodletxt:globaladdressbooks
| Teachers and admins
| If this user can create address books within MoodleTxt, they can create global address books that can be viewed and used by all users within the system.
|-
| block/moodletxt:personalsettings
| Teachers and admins
| Having this capability assigned to a user allows them to edit their own messaging preferences. This includes message templates and signatures, as well as options related to message display.
|-
| block/moodletxt:receivemessages
| Teachers and admins
| Any user that has this capability assigned can receive inbound messages within the block.
|-
| block/moodletxt:sendmessages
| Teachers and admins
| Any user that has this capability assigned can send messages out from the block.
|-
| block/moodletxt:viewstats
| Teachers and admins
| Any user that has this capability assigned can view user/message statistics. (Coming in 3.1)
|-
| block/moodletxt:viewmoodletxtpluslogs
| Admins only
| Allows the user to view the logs of event-based messaging. (Largely redundant, may be removed in 3.1. Users that have the :adminusers permission can use the sent page, which was upgraded since 3.0 beta 2, to view these logs already.)
|}

[[Category:MoodleTxt|Capabilities]]
[[Category:Plugin]]

Moodletxt cron

2025-11-16T16:31:26Z

Stronk7:

== MoodleTxt Updates Via Cron ==

=== What is cron? ===

; Cron job : The term generally used (in Unix circles) to refer to a user-defined script or program that is automatically run at regular intervals.

MoodleTxt can optionally use a cron job to fetch regular updates from the ConnectTxt server, including new inbound messages, and status updates for previously sent messages.

=== Why use cron? ===

The recommended method of acquiring updates from the ConnectTxt system is [[Moodletxt_push|XML Push]]. However, this requires an inbound connection to your Moodle server. If you cannot configure this connection, but still wish to receive updates from the ConnectTxt system automatically, then you can use MoodleTxt's local cron job to automatically poll the ConnectTxt system for updates at regular intervals. This is much more efficient than the default update settings (where checks are made when certain pages are loaded) and will result in a performance increase for MoodleTxt.

=== Automatic Setup ===

As of MoodleTxt 2.4, this cron script automatically adds itself to the main Moodle maintenance script, so if you already have this running at short, regular intervals, no action is required to enable cron – MoodleTxt will automatically fetch inbound messages and status updates every time the Moodle maintenance script runs.

=== Custom Setup ===

If your Moodle maintenance script is not enabled, or does not run often enough for MoodleTxt use, you can still use cron to fetch message details. MoodleTxt provides a script that is another entry point to the cron system, which you can set to run at shorter intervals separate from the Moodle maintenance script. The path to this script is “/blocks/moodletxt/cron.php”, under your main Moodle installation directory. For example, if you have Moodle installed on Linux at:

/srv/www/moodle/

Then the path to the cron script would be:

/srv/www/moodle/blocks/moodletxt/cron.php

By specifying this file to be run in your chosen scheduling software, at an interval of your choosing, you can emulate the efficiency of the [[Moodletxt_push|XML Push]] service without changing your security configuration.

=== Steps to Take After Setup ===

Once you have configured cron according to your needs, it is wise to turn off the per-request updates from the [[admin/setting/blocksettingmoodletxt|MoodleTxt Settings page]]. (These are the Get_Status_On_View and Get_Inbound_On_View settings.) These will no longer be needed, and you will gain a performance boost by disabling them.

[[:Category:MoodleTxt | View all MoodleTxt documentation]]
[[Category:MoodleTxt|Cron]]
[[Category:Plugin]]

error/block moodletxt/errorbadbookid

2025-11-16T16:31:20Z

Stronk7:

== Attempting to View/Edit an Address Book That Is Not Yours ==

You have attempted to view or edit a MoodleTxt addressbook, or the contacts within it, and received the error message:

''The address book selected was invalid, or you do not own the address book you are attempting to edit.''

=== Cause ===
Address books created within MoodleTxt can only be edited by the user that created them, and in most cases this applies to viewing the address book also. You are attempting to edit an address book that you do not have ownership of, and as such MoodleTxt has blocked this action.

[[Category:MoodleTxt|Error]]
[[Category:Plugin]]

error/block moodletxt/errorbadmessageid

2025-11-16T16:31:14Z

Stronk7:

== Attempting to View a Message That Does Not Exist ==

You have attempted to view a sent message within MoodleTxt, and received the error message:

''The message ID given does not exist, or does not belong to the user ID found. Please select a valid message to view.''

=== Cause ===
There are several potential causes for this error:

# The ID of the message you are attempting to view is incorrect. If you are copying and pasting a link to a message, please ensure that you have included all the page's parameters in the link.
# The message you are attempting to view no longer exists within the database.

[[Category:MoodleTxt|Error]]
[[Category:Plugin]]

error/block moodletxt/errornoaccountspresent

2025-11-16T16:31:08Z

Stronk7:

== No ConnectTxt Accounts Present Within MoodleTxt ==

You have gone to the "Compose a Message" page within MoodleTxt, and received the error message:

''No ConnectTxt accounts have been added to moodletxt. The system administrator must link moodletxt to one or more ConnectTxt accounts before messages can be sent.''

=== Cause ===
MoodleTxt uses SMS messaging accounts on the [http://www.bbconnecttxt.com/ ConnectTxt] messaging system to send and receive SMS messages. Before MoodleTxt can be used to send out messages, one or more ConnectTxt accounts must be made available to you via MoodleTxt's control panel.

=== Solution ===
Your system administrator must make one or more ConnectTxt accounts available for you to use.

If you are the system administrator, then you can find out more information about how to do this in the [[admin/setting/blocksettingmoodletxt|MoodleTxt settings documentation]].

[[Category:MoodleTxt|Error]]
[[Category:Plugin]]

error/block moodletxt/errornopermissionmessage

2025-11-16T16:31:01Z

Stronk7:

== Attempting to Access a Message You Do Not Have Permission to View ==

You have attempted to view the details of a sent message within MoodleTxt, and received the following message:

''You are not authorised to view this message.''

=== Cause ===
The message you have attempted to view does not belong to you, and you do not have the [[Moodletxt_capabilities|necessary access level]] to view another user's message details.

[[Category:MoodleTxt|Error]]
[[Category:Plugin]]

blocks/moodletxt/preferences

2025-11-16T16:30:54Z

Stronk7:

== MoodleTxt User Preferences ==

On this page of the block, you can configure your user-specific preferences. These include your message templates, SMS signature, and various other options that relate to how you use the messaging block.

=== Signature ===

A message signature is a short piece of text (up to 25 characters) that you can optionally append to the end of your outgoing messages within MoodleTxt. This signature is useful for identifying yourself to the recipient, or for including common reply information (such as "reply with keyword BEN"). If you already have a message signature stored within MoodleTxt, it will appear in the textbox labelled "signature", otherwise this block will be blank. To edit your signature, simply enter the text you would like to use in this box. You will notice the character counter above it decreasing from 25 towards 0 as you type, indicating the number of usable characters you have remaining. Once you hit 25 characters, you will be unable to type any further.

When you are happy with your signature text, click the "Save" button at the bottom of the page. The page will refresh, and you should receive a short notification that the signature text has been updated.

=== Message Templates ===

Message templates can be used to store and re-use commonly sent messages, making sending these messages quick and easy. Templates can be selected from the [[blocks/moodletxt/send|message composition page]], instead of filling in the message text by hand, and can contain any text that a regular message can.

You will notice two sections on the page, '''My Message Templates''' and '''Add New Template'''. The first of these lists all your existing message templates (if you have any), and allows you to select them for editing or deletion. The second section contains a text area in which you can add a new template to the system, or edit one you have selected from the existing list.

=== Adding a New Template ===

To add a new template, click inside the box labelled "Template Text", and enter your message. As you type, you should see the number of characters you have used displayed directly above the message box, along with the number of individual SMS messages your text will be broken into. For example, the display '''172 / 2''' means you have used 172 characters, and that this will be split into two messages when sent.

Also, underneath the message text box. you will find three buttons, labelled "First Name," "Last Name," and "Full Name."

[[Image:moodletxt-compose-tag-buttons.png|border|center]]

Clicking on any of these buttons will insert a "tag" into the message. This tag will be automatically replaced, for each recipient, with the appropriate name, allowing you to add a personal touch to the message. For example:

''"Hello %FIRSTNAME%, welcome to DMU."''

Will be converted automatically to:

''"Hello Jaime, welcome to DMU."''

When you are satisfied with the text in the template editing box, click the "Save" button at the bottom of the page. The page will refresh, and you should see a short notice at the top of the screen indicating that the template has been saved.

=== Editing an Existing Template ===

To edit a template that has already been saved in the MoodleTxt block, go to the section headed '''My Message Templates'''. Select the template you wish to edit from the list and click the "Edit Template" button below it. The '''Add New Template''' section will be retitled to '''Edit Existing Template''', and your template will appear in the editing box. You can now make your desired changes to it, exactly as if you were adding a new template to the system. When you are satisfied with your changes, click the "Save" button at the bottom of the page. The page will refresh, and you should see a short notice at the top of the screen indicating that the template has been updated.

=== Deleting a Template ===

To remove a template from MoodleTxt, go to the section headed '''My Message Templates'''. Select the template you wish to delete from the list and click the "Delete Template" button below it. A confirmation message will be displayed over the page. If you are happy to delete the template, click the "OK" button. The page will refresh, and a short message should be displayed at the top of the screen, indicating that the template has been deleted.

=== Inbox Preferences ===

Several options exist that relate to how MoodleTxt displays messages in your [[blocks/moodletxt/received|inbox]], and these are listed here. Firstly, you can instruct MoodleTxt to hide the names and phone numbers of received messages within the inbox listing. This is useful in classroom or group situations, where you wish to receive feedback or opinions from a number of people whilst keeping their responses anonymous. With this box checked, MoodleTxt will hide sender information for these messages.

Finally, there is the option to determine how often MoodleTxt's dynamic inbox checks for new messages with the Moodle system. If you are on the [[blocks/moodletxt/received|inbox]] page, it will check with the database for new messages at the interval you set here. Please note that this is separate from checking with the ConnectTxt system for new messages, and will only pick up messages that have already been received by the Moodle system. Administrators wanting more information on how messages are received by MoodleTxt can find it in the documentation for the [[admin/setting/blocksettingmoodletxt|main settings page]].

When you have edited your inbox preferences accordingly, click the "Save" button at the bottom of the page. The page will refresh, and you should see a short message at the top of the screen, indicating that your preferences have been updated.

[[Category:MoodleTxt|Preferences]]
[[Category:Plugin]]

Moodletxt push

2025-11-16T16:30:47Z

Stronk7:

== MoodleTxt and Pushed Updates ==

=== What is XML Push? ===

For those MoodleTxt administrators whose Moodle installations are publicly accessible from outside their local network, ConnectTxt offers a free service that automatically sends updates to sent messages, along with any new inbound messages, directly to your MoodleTxt installation.

=== Why should I use it? ===

XML Push updates are sent out as soon as they are received by the ConnectTxt system. As a result, this solution provides the quickest and most convenient update of message status records, and ensures that the information contained within your installation is up-to-date and useful. It also provides a performance boost for your MoodleTxt installation, as once XML Push is enabled you can disable the default update methods within MoodleTxt.

=== Information required for setup ===

To use XML Push, please first ensure that you are certain of the URL (web address) for your your Moodle installation. Beneath this, the XML Push script is located at “/blocks/moodletxt/push.php.” For example, if your URL for Moodle is normally:

<nowiki>https://www.yoursite.com/moodle</nowiki>

Then the path to XML Push will be:

<nowiki>https://www.yoursite.com/moodle/blocks/moodletxt/push.php</nowiki>

Once you have made a note of this URL, you must decide on a username and password for ConnectTxt to use to authenticate themselves on your installation. This username is used so that only ConnectTxt may send data through to your system, and helps to keep your installation secure – if the correct username and password are not supplied, XML Push simply shuts itself down, not accepting any further data.

When you have decided on a username and password for XML Push to use, please save them in [[admin/setting/blocksettingmoodletxt|MoodleTxt's system settings]] to enable the XML Push system.

=== Passing information to ConnectTxt ===

Now you should have all the information necessary to activate XML Push with ConnectTxt. Please contact the ConnectTxt support team (using the contact information displayed at the end of this document) with:

# A list of all the ConnectTxt accounts that will need to be enabled for use with XML Push (this is normally a list of all the accounts stored in MoodleTxt).
# The URL path to XML Push on your installation.
# The XML Push username and password you defined above and stored on the setting screen.

ConnectTxt will then activate your account(s) for use with XML Push. This process is normally completed quickly, but can take up to 24 hours.

=== After setup ===

If your change your XML Push username or password in the future, or add/remove any ConnectTxt accounts from the MoodleTxt system, please notify ConnectTxt of any changes that need to be made.

Once you have configured cron according to your needs, it is wise to turn off the per-request updates from the [[admin/setting/blocksettingmoodletxt|MoodleTxt Settings page]]. (These are the Get_Status_On_View and Get_Inbound_On_View settings.) These will no longer be needed, and you will gain a performance boost by disabling them.

=== ConnectTxt Contact Details ===

; Telephone : +44 (0) 113 234 2111
; E-mail : txttoolssupport@blackboard.com
; Live Chat : [http://messenger.providesupport.com/messenger/txttools.html Click here to chat live with our support team].

[[Category:MoodleTxt|Push Updates]]
[[Category:Plugin]]

blocks/moodletxt/send

2025-11-16T16:30:39Z

Stronk7:

== Sending a Message via MoodleTxt ==

This page will run you through the process of sending out a message from the MoodleTxt compose page. Given the wide number of options that MoodleTxt provides for outbound messaging, this page is designed as a wizard, to easily section off the various stages of composing a new message. You can move forwards and backwards through the steps of the wizard by clicking on their titles at the top of the form.

[[Image:moodletxt-compose-nav.png|frame|center|The compose wizard is organised into 4 steps. Click on a step to zoom to it]]

=== Step 1: Recipients ===

Firstly, you must select the recipients for the message. You may send a text message to one or more individuals, to a pre-defined group of users/contacts, to additional recipients you specify on the page, or any combination of the three.

On the left of the screen you will see the "Potential Recipients" list. This list holds all the recipients (of a given type) that were found in your Moodle system. These are the recipients that you can add to the message. On the right of the screen you will see the "Selected Recipients" list. Any recipient that is in this list when the form is submitted will receive the message.

[[Image:moodletxt-compose-recipient-lists.png|frame|center|The "potential" and "selected" recipient lists for MoodleTxt. Clicking the >> and << buttons will add or remove selected recipients to/from the message.]]

To add a recipient to the message, find them in the list on the left, select them, and click the button with the right-facing arrows (>>). The recipient will move across to the selected list. To remove them from the message, click the button with the left-facing arrows (<<). The recipient will be removed from the selected list, and reappear in the potential list on the left; they will no longer receive a copy of the message.

You will notice that the recipients you are selecting are colour-coded. These colours designate the type of recipient that you are selecting. Underneath the two lists you will notice a number of coloured buttons: "Users", "User Groups", "Addressbook Contacts", "Addressbook Groups". Users are the user accounts and user groups defined in your Moodle installation. Address Books contain the contacts and groups you define within MoodleTxt. Click on one of these buttons to display the appropriate contact list.

[[Image:moodletxt-compose-recipient-selectors.png|frame|center|Clicking on one of these colour-coded buttons displays the appropriate contacts in the "Potential Recipients" list]]

(To select more than one contact from a list, hold down CTRL on Windows/Linux, or the Apple/cloverleaf key on a Mac, and click on each contact. You can also select a group of sequential contacts by clicking on the first contact, then holding the SHIFT key and selecting a contact further up/down the list. This will select every contact in a range.)

Finally, if you wish to add recipients to the message that are not already stored within Moodle or MoodleTxt, you can use the "Add Additional Contact" form, which you will find underneath the recipient lists at the bottom of the slide. Enter the contact's first name, last name and phone number in the appropriate boxes, and click the “Add Contact” button. The new contact will be added to the “Selected Recipients” list on the right of the page.

Any contacts you added from the “Additional Recipients” form
will be destroyed when removed from the "Selected Recipients" list.

Once you are satisfied with your recipient selections, click on "Step 2" in the navigation bar at the top, and you'll be taken to the Compose Message screen.

=== Step 2: Compose Message ===

On this slide of the wizard, you will compose the actual message that is to be sent out to course participants. You can utilise pre-saved [[blocks/moodletxt/preferences|templates]] for sending out commonly used messages/notices, or write the message free-hand. You can also customise the message by merging in the recipient's name, and sign it with your own custom [[blocks/moodletxt/preferences|signature]].

Inside the large textbox marked "Message", please type your intended text message. As you type, you should see the number of characters you have used displayed directly above the message box, along with the number of individual SMS messages your text will be broken into.

[[Image:moodletxt-compose-counters.png|border|center]]

If you wish to use a pre-defined message template, select it from the drop-down list marked “Message Templates”, and it will automatically fill the textbox with the template for you. Message length counters will update automatically. If you wish to add your own customised signature to the message, checking the "Add Signature" checkbox will append your signature to the end of the message in the textbox.

Also, underneath the message text box. you will find three buttons, labelled "First Name," "Last Name," and "Full Name."

[[Image:moodletxt-compose-tag-buttons.png|border|center]]

Clicking on any of these buttons will insert a "tag" into the message. This tag will be automatically replaced, for each recipient, with the appropriate name, allowing you to add a personal touch to the message. For example:

''"Hello %FIRSTNAME%, welcome to DMU."''

Will be converted automatically to:

''"Hello Jaime, welcome to DMU."''

==== Unicode Messages ====

If you use any characters that do not fit within the standard [http://en.wikipedia.org/wiki/GSM_03.38 GSM alphabet] used by SMS messages, then these will be sent as Unicode messages. This does not affect message delivery in any way, but it does reduce the number of characters allowed per message from 160 to 70. MoodleTxt checks your text automatically as you type, and if you use characters that require a Unicode message, then a warning message will be displayed below the textbox. The "characters per message" field will also change to 70 to reflect this, and "characters/messages used" will be recalculated according to the new message length.

=== Step 3: Message Options ===

This step of the wizard allows you to schedule a message to be delivered at a later date, along with any other options that relate to message delivery.

==== Unicode Messaging Options ====

Firstly, if your message contains unicode message characters, as detailed above, you can opt to disable these characters in the outgoing message. If you decide to suppress these characters in the message, they may appear garbled on the recipient's phone (though the rest of the message should appear OK). However, doing so will restore the 160 character length of the message, and remove the restriction to 70 characters that unicode messages normally have.

To suppress unicode characters, select "Restrict message to GSM character set only" in the first option set, under the heading "Unicode Messaging Options".

==== Scheduling ====

To schedule your message for delivery at a later point, first you need to select the "Schedule to send later" option under the "Scheduling" heading. Once you have done this, select a time and date using the combo boxes provided. The date and time you enter is according to your own timezone on your Moodle user account; this will be converted automatically by MoodleTxt to Universal Time before sending.

=== Step 4: Review & Send ===

The final step of the wizard exists simply to allow you to review all the details of the message in one place, prior to it being sent. The recipients of the message are displayed, along with the message text, how many characters and messages per recipient will be used, and any unicode warnings that are relevant. Once you are happy with the information displayed on this last screen, click the "Send Message" button at the bottom to send the message to ConnectTxt.

[[Category:MoodleTxt|Send]]
[[Category:Plugin]]

blocks/moodletxt/sent

2025-11-16T16:30:30Z

Stronk7:

== Sent Message Listing ==

This page lists all the messages sent out by the existing Moodle user, as well as (if you have the right permissions enabled) all messages sent out by other Moodle users. Some general statistics regarding messages sent are shown at the top left of the page. The sent message listing contains the following columns:

; User Account : The name of the Moodle user that sent this message out. Clicking on the linked username within this column will take you to that user's Moodle profile page.

; ConnectTxt Account : The ConnectTxt account through which this message was sent.

; Message Text : A shortened summary of the message sent. Clicking on this text summary will take you to [[blocks/moodletxt/status|a page detailing its current status]].

; Time Sent : The time at which this message was sent from the system, adjusted to your timezone.

; Created by : Whether the message was written by the user or [[#event_gen|generated by a system event]]. (Only displayed when you have selected to view event-generated messages alongside your own created messages.)

The listing table can be edited and re-ordered like any other Moodle data table. Once you are happy with the data currently onscreen, you can also export it to a spreadsheet or similar file using the download options at the bottom of the table. Simply select the type of export you would like from the provided drop-down list, and then click the download button.

=== <span id="event_gen">Viewing Event-Generated Messages</span> ===

As of MoodleTxt 3, messages can be generated by system events (such as those arriving via MoodleTxt Plus), as well as by the user. These messages are recorded like any other message, but are hidden on the sent message listing by default. If you wish to view any event-generated messages that have been sent out automatically from your account to another user, then you can enable them using the drop-down box at the top left of the screen.

[[Image:moodletxt-sent-type-list.png|frame|center|Allows you to show or hide event-generated messages.]]

The options in this drop-down box are pretty self-explanatory. You can opt to either hide all event-generated messages (the default option), show the event-generated messages inline with your other sent messages, or show the event-generated messages on their own. If you decide to show event-generated messages alongside your own user-created messages, then an additional column is displayed showing whether the message was written by the user or generated by an event.

=== Viewing Other User's Messages ===

If you have the correct [[Moodletxt_capabilities|user capabilities]] assigned, you can view messages sent out by other users within the system. An additional drop-down box will be displayed at the top left of the page:

[[Image:moodletxt-sent-user-list.png|border|center]]

Select the user you wish to view, and the page will reload with that user's messages listed. Alternatively, you can select "All Users" to view every message sent out via your MoodleTxt installation.

[[Category:MoodleTxt|Sent]]
[[Category:Plugin]]

admin/setting/blocksettingmoodletxt

2025-11-16T16:30:24Z

Stronk7:

== MoodleTxt Settings ==

This page contains all the common configuration options for MoodleTxt. At the top of the page you will see two links:

; ConnectTxt Accounts : This link will take you to the ConnectTxt account admin pages, which will allow you to add, update and restrict these accounts. If you have just installed MoodleTxt, this should be your first stop.
; Inbound Message Filters : This link will take you to the inbound filter management page, which will allow you to create filters for inbound SMS messages, routing them to particular Moodle users.

=== Send/Receive Settings ===

The first 4 settings in this section relate to how MoodleTxt gets both message status updates and new inbound messages from the ConnectTxt system. By default, MoodleTxt pulls these updates on a per-request basis, whenever users visit certain pages. However, it can be configured to get these updates automatically, which improves the performance of the block and results in far fewer outbound connections. The available automatic update methods are [[Moodletxt_cron | cron]] and [[Moodletxt_push | push]]. We '''highly''' recommend taking the time to set up push functionality, as it is the fastest and most efficient method of obtaining updates.

{| class="wikitable"
|-
! Field Name
! Field Label
! Description
|-
| Get_Status_On_View
| Automatically get status updates on "View Message" page
| If this box is checked, then whenever a user views the current status of a sent message, the block will first connect to the ConnectTxt system in order to fetch updates. You should uncheck this if you have configured an automatic update option as mentioned above.
|-
| Get_Inbound_On_View
| Automatically get inbound messages on Inbox page
| If this box is checked, then whenever a user views their inbox, the block will first connect to the ConnectTxt system in order to fetch new messages. You should uncheck this if you have configured an automatic update option as mentioned above.
|-
| Push_Username
| XML Push Username
| If you have set up XML push updates (highly recommended) then this is the username you provided to ConnectTxt as part of that setup. ConnectTxt uses this username to authenticate itself with your MoodleTxt installation when connecting to it.
|-
| Push_Password
| XML Push Password
| If you have set up XML push updates (highly recommended) then this is the password you provided to ConnectTxt as part of that setup. ConnectTxt uses this password to authenticate itself with your MoodleTxt installation when connecting to it.
|}

The last two settings in this category control other parameters related to message sending via ConnectTxt.

{| class="wikitable"
|-
! Field Name
! Field Label
! Description
|-
| Protocol_Warnings_On
| Display SSL security warnings
| If you do not have SSL connections to the ConnectTxt server enabled, MoodleTxt will generally display warnings that your data is being transmitted in an unsecure manner. To disable these warnings, uncheck this box.
|-
| Event_Messaging_Account
| Event Messaging Account
| This is the ConnectTxt account that MoodleTxt will use when it is asked to send automatic messages out in response to system events. By extension, this is the ConnectTxt account that will be used to send any messages originating via the MoodleTxt Plus message processor plugin. If no account is selected, then MoodleTxt will be unable to send event-generated messages.
|}

=== Recipient Settings ===

The settings in this section relate to how MoodleTxt captures user phone/name information from the Moodle system, and how it processes that information in order to send SMS messages out. (Future versions of the block will feature improvements in international phone number handling.)

{| class="wikitable"
|-
! Field Name
! Field Label
! Description
|-
| National_Prefix
| National Prefix
| This is the default dialling prefix for phone numbers within your country. It is the digit or set of digits that all phone numbers begin with when being dialled within the country. This defaults to 0, the UK domestic dialling prefix. ('''Note:''' If the phone numbers you enter into MoodleTxt are already formatted internationally, e.g. +441234567890, then this setting is ignored.)
|-
| Default_International_Prefix
| Default International Prefix
| This is the international dialling prefix for phone numbers within your country. This usually consists of a plus '+' sign, along with two or three digits, and is used when dialling into your country from another location. This defaults to +44, the UK international dialling prefix. ('''Note:''' If the phone numbers you enter into MoodleTxt are already formatted internationally, e.g. +441234567890, then this setting is ignored.)
|-
| Phone_Number_Source
| Take phone numbers from
| This option allows you to choose the field in your user database table that MoodleTxt will search for mobile phone numbers (phone1 or phone2). This is largely redundant in modern Moodle setups, where phone2 has been standardised as the mobile phone field, and exists for long-running installations where things may be different. If mobile phone numbers are populated to the phone1 field in your system, then select it from this drop-down.
|-
| Default_Recipient_Name
| Default Recipient Name
| When Moodle cannot find a recipient's name in the database, or cannot match an incoming phone number to any known contact, this is the name/identifier it will record against that message.
|}

=== Proxy Settings ===

If connections between your MoodleTxt installation and ConnectTxt need to be routed via a proxy server, then you can enter the details of that proxy server in this section. '''Please note:''' MoodleTxt currently only supports proxy servers that use either BASIC authentication, or no authentication at all. Newer versions of Moodle have their own proxy settings within the system, and future versions of the block will migrate to use those settings for proxy support.

{| class="wikitable"
|-
! Field Name
! Field Label
! Description
|-
| Proxy_Host
| Proxy Address
| The host/IP address of your proxy server.
|-
| Proxy_Port
| Proxy Port
| The TCP/IP port your proxy server listens on for connections.
|-
| Proxy_Username
| Proxy Username
| If your proxy server requires a username for authentication, then enter it here (BASIC authentication only).
|-
| Proxy_Password
| Proxy Password
| If your proxy server requires a password for authentication, then enter it here (BASIC authentication only).
|}

=== Miscellaneous Settings ===

This section contains any other global settings for MoodleTxt that do not fall into one of the earlier categories.

{| class="wikitable"
|-
! Field Name
! Field Label
! Description
|-
| jQuery_Include_Enabled
| Include main jQuery package
| MoodleTxt uses the popular jQuery library within its user interface. Some Moodle installations already include this library within their active themes. If this is the case, then attempting to load both libraries can cause problems with the system. To turn off MoodleTxt's jQuery installation and have it use the one provided with your theme, uncheck this box. ('''Note:''' You will require at least jQuery 1.6 for this to work.)
|-
| jQuery_UI_Include_Enabled
| Include jQuery UI Library
| MoodleTxt uses the jQuery User Interface library for many common widgets/user interface components. Some Moodle installations already include this library within their active themes. If this is the case, then attempting to load both libraries can cause problems with the system. To turn off MoodleTxt's jQuery UI installation and have it use the one provided with your theme, uncheck this box. ('''Note:''' You will require at least jQuery UI 1.7 for this to work.)
|-
| Show_Inbound_Numbers
| Show source names/numbers in inbox (Default)
| In a classroom situation, such as a survey, where many people can see the messages that are coming into the system, you may wish to anonymise them by hiding the source of the messages. In current versions of MoodleTxt, inbound messages are anonymised by default. To show those message sources on inbox pages by default, then check this box. Since MoodleTxt 3.0, users can override these settings for their own inboxes, so this setting is now a default.
|-
| RSS_Update_Interval
| RSS Update Interval
| This setting controls how often MoodleTxt should check with the RSS feed on the ConnectTxt servers for new updates. (This is being retired, as Moodle 2.3 and up can find updates automatically.)
|-
| RSS_Expiry_Length
| RSS items expire after
| This setting controls how long an update notification from ConnectTxt should be displayed on the MoodleTxt admin panel. (This is being retired, as Moodle 2.3 and up can find updates automatically.)
|}

[[Category:MoodleTxt|Settings]]
[[Category:Plugin]]

blocks/moodletxt/status

2025-11-16T16:30:13Z

Stronk7:

== Message Status Page ==

The message status page gives full details on the recipients of a given message, along with the status of the text messages sent. When the page loads, the details of the message sent will appear at the top left. This includes the Moodle user from which the message was sent, the time at which it was sent, the time it was scheduled to be sent at, and the actual text of the message. Below this, the recipients of the message are listed.

For each recipient, the following information is shown:

; Recipient : This field shows the name of the recipient, whether they are a Moodle user or a contact in your address book.

; Destination Number : The phone number to which the text message was sent.

; Time of Update : The time and date at which this message's status information was last updated by the ConnectTxt system.

; Message Status : The current status of this text message. There are three icons that are used to denote the status of a message. A red icon with a cross through it means that the message has failed. The recipient will not receive the message, and it should be checked and re-sent to this recipient. A green icon with no cross or tick means that the message has been sent, and no further information has yet been received. A green icon with a tick means that the message was received by the recipient.

The listing table can be edited and re-ordered like any other Moodle data table. Once you are happy with the data currently onscreen, you can also export it to a spreadsheet or similar file using the download options at the bottom of the table. Simply select the type of export you would like from the provided drop-down list, and then click the download button.

=== Updating Message Statuses ===

If your MoodleTxt installation has been configured correctly, it will automatically update message statuses in the background, without your intervention. However, if you wish to check for updated information, simply click the "Update" button, above the status listing on the left of the page. The page will refresh (this may take a moment while the ConnectTxt system is contacted), and the most up-to-date information will be displayed.

[[Category:MoodleTxt|Status Messages]]
[[Category:Plugin]]

admin/setting/moodletxtfilters

2025-11-16T16:30:06Z

Stronk7:

== Managing Inbound Filters in MoodleTxt ==

This page allows you to edit MoodleTxt's inbound message filters. These filters are used when incoming messages are received from the ConnectTxt system, to forward them to the appropriate Moodle user's inbox. This form uses a step-by-step process to edit the filters in place, and add new ones. Fields within the form that are not ready for use, or depend on user input, will be locked until they are ready, so don't worry if you can't immediately access some parts of the form.

=== Selecting a ConnectTxt Account ===

Firstly, select the ConnectTxt account within the system you wish to apply filters on from the first drop-down box in the form. You will see a loading icon appear for a short period whilst MoodleTxt loads the existing filter structure for that account.

'''Note:''' In terms of filtering, ConnectTxt accounts are independent of one another. It is quite possible to have the same keyword filter on several different accounts, routing messages to different users. Similarly, it is possible to set up one keyword across all accounts that is always filtered to the same user.

=== Selecting or Creating a Filter ===

Once the loading icon has disappeared, the two lists of existing filters will be populated and unlocked. You now have two options.

# '''To edit an existing filter''' on the system, select it from either the keyword or phone number filter list. You will see another loading message while the details of that particular filter are pulled out of the database. When this disappears, you should be able to see the filter's current recipients in the large select box underneath.
# '''To create a new filter''', click the green "add" icon to the right of either the keyword or phone number filter lists, depending on which you wish to create. The filter list will be replaced with a text box. In this box you enter the operand for your new filter – that is the keyword or phone number on which you wish to filter messages. Once you have done this, the large recipient list underneath should be unlocked.

You have now specified the filter you wish to edit. Below the two filter options on the page is a larger select box. This box holds a list of all the recipients specified for a particular filter. For a new filter, this will be blank, and for an existing filter, it will show the list of previously selected recipients for that filter.

=== Adding and Removing Filter Recipients ===

To add a new recipient to a filter, locate the textbox labelled "Add users to filter". This is an auto-completing search box. As you type in it, it searches the Moodle database for the user you are looking for and displays possible selections onscreen. You can search by either first name, last name or username. For example, typing "Pre" into our MoodleTxt test server would display "Preece, Greg J (admin)".

Once the user you are looking for is displayed, select them by either highlighting them with the arrow keys and hitting return, or by clicking on them with the mouse. You should see the user being added to the recipient list.

To remove a recipient from a filter, select them from the recipients list and click the "Remove selected users from filter" button below it. They will be immediately removed from the recipients list. You can remove multiple users at the same time by either holding CTRL to select multiple individual entries, or holding SHIFT to select a consecutive group.

Once the filter has been edited/created to your satisfaction, and the recipients list appears correct, click the "Save the filter" button at the bottom of the form, and it will be saved back to the database. If you have removed all recipients from an existing filter, then that filter will also be deleted once the recipients have been removed.

[[Category:MoodleTxt|Settings Filters]]
[[Category:Plugin]]

admin/setting/moodletxtaccountsnew

2025-11-16T16:29:55Z

Stronk7:

== Adding a New ConnectTxt Account to MoodleTxt ==

This page allows you to register a new ConnectTxt account with the MoodleTxt block. It should be one of your first stops after installing the block, and you will be redirected to it if you attempt to access other account-related pages when no accounts have been added to MoodleTxt.

If no accounts have been added to MoodleTxt when you go to this page, then some introductory text will be displayed explaining the purpose of the block and providing useful contact information. Beneath this, you will find the form for entering a new ConnectTxt account. Enter the username and password of the ConnectTxt account you wish to add to MoodleTxt. You may also enter a short description of the account if you wish.

With this done, please select a user to use as the default inbox for incoming messages on this account. The user with the default inbox is the one that will receive any inbound text messages that do not match any user filters within the MoodleTxt installation. This is to prevent unfiltered messages being lost. It is required that you select a default inbox owner even if you do not intend to use MoodleTxt for inbound messaging. Only users with the [[Moodletxt_capabilities|"block/moodletxt:defaultinbox" capability]] can own default inboxes.

Once you are done, click “Add Account.” The page will refresh. As it does so, the account details entered will be validated with the ConnectTxt system. This ensures that all the ConnectTxt accounts you save in MoodleTxt exist on the ConnectTxt system, that the passwords are correct, and that the accounts have been enabled for use with MoodleTxt. If no errors are found, you will be taken to the [[admin/setting/moodletxtaccounts|MoodleTxt account listing page]].

[[Category:MoodleTxt|Settings Account New]]
[[Category:Plugin]]

admin/setting/moodletxtaccounts

2025-11-16T16:29:36Z

Stronk7:

== Moodletxt: ConnectTxt Account Listings ==

On this page, you can get an overview of all the ConnectTxt SMS messaging accounts that have been registered within MoodleTxt. When you first load the page, you will be shown a list of all currently saved ConnectTxt accounts, along with their basic details. You can use this page to edit an account's details, along with which users can access each account.

=== Adding a New Account ===

[[admin/setting/moodletxtaccountsnew|Adding new accounts]] is handled on a separate page. To add a new ConnectTxt account to the MoodleTxt system, click the "Add New Account" link in the paragraph at the top of the page. If you attempt to view the account listings page, and no ConnectTxt accounts have been added to MoodleTxt, you will be automatically redirected to this link (this only occurs at first installation).

=== Account Listing ===

The onscreen table shows all ConnectTxt accounts currently stored within the MoodleTxt block. At first glance, the following fields are displayed:

; Username : The username of the ConnectTxt account.
; Description : The description you gave the ConnectTxt account when adding it to MoodleTxt.
; Messages Sent : The total number of messages sent through this account.
; Allow Outbound : Whether outbound access (message sending) is enabled on this account. If outbound messaging is enabled, you will see an icon showing 4 outbound arrows. If outbound messaging is disabled, you will see a red cross.
; Allow Inbound : Whether inbound access (receiving messages) is enabled on this account. If inbound messaging is enabled, you will see an icon showing 4 inbound arrows. If inbound messaging is disabled, you will see a red cross.
; Credits Used : The number of credits that have been used on your ConnectTxt account. This includes all messages sent, not just those sent via MoodleTxt. This figure is updated via [[Moodletxt_cron|cron]], or manually [[#updateInfo|via the controls on this page]].
; Credits Remaining : The number of remaining credits on your ConnectTxt account. If your account is invoiced, this will show as an ∞ infinity symbol.
; Account Type : What type of account billing this ConnectTxt account has enabled. This is typically either invoiced or pre-paid.
; Last Update : The time at which this account's online details (credits used/remaining, account type) were last updated from the ConnectTxt system.

=== Changing an Account's Password or Description ===

On the far left of an account's listing, before its username, you will find the edit button.
[[Image:moodletxt-account-edit-button.png|border|none]]
Clicking this button will open a modal dialog box containing the account's description, and a field allowing you to enter a new password. Edit the description as you see fit.

'''The password field is optional, and should only be filled in if you need to change the password on the account.'''

Once the fields in the dialog box are complete, click the "Save" button. The system will contact ConnectTxt to validate the details entered, and to fetch the latest credit data for the account. If the account is successfully validated, the dialog box will close and you will be returned to the main account listing.

=== Changing Which Users can Send Messages Via an Account ===

[[Image:moodletxt-account-access-button.png|border|none]]
MoodleTxt allows you to restrict outbound access to ConnectTxt accounts to a given list of Moodle users. If you would like to restrict access to an account, click on the "edit access" icon at the front of the account's "Allow Outbound" field. A modal dialog box will open containing a form that will allow you to restrict user access.

[[Image:moodletxt-account-access-form.png|frame|center|Access restriction form]]
The list labelled "Allowed Users" is the list of Moodle users that this account will be restricted to. If this list is blank, then the account will be unrestricted. To add users to the list, begin typing their name or username in the search box at the top of the form. This is an auto-completion search box, and will automatically perform a background search for the entered name (or partial name) when you stop typing.

When the user you wish to add appears in the auto-complete list, select them using the mouse or arrow and enter keys. They will be added to the list of users allowed to access the account. To remove one or more users from the list, click on their username(s) and then click the "Remove User(s)" button below the list. Removing all users from the list will make the account unrestricted.

Once you are happy with the restrictions applied to (or removed from) the account, click the "Save" button. The account's restrictions will be updated in the database, and you will be taken back to the account listing.

=== Disabling/Enabling Inbound and Outbound Access on an Account ===

You can completely turn off inbound or outbound access for any given ConnectTxt account. This is a simple matter of toggling the switches displayed under the "Allow Outbound" and "Allow Inbound" fields for an account. If your chosen route is enabled, you will see an icon featuring 4 green arrows. If it is disabled, you will see a red cross. Clicking on an enabled route will turn it off, and vice versa. For example, in this screenshot, the account has outbound messaging enabled, but is disabled for inbound messaging:

[[Image:moodletxt-access-toggles.png|border|center]]

=== <span id="updateInfo">Updating Account Information</span> ===

If you have [[Moodletxt_cron|cron-based updates]] enabled, then credit information for all your ConnectTxt accounts will be updated at regular intervals. If not, you can manually fetch updates from the account listing page, simply by clicking the "Update Credit Info" button at the top of the page. When you click this button, a progress bar will appear, and the system will run through each account in turn, updating the information on the page as it goes. Any information that has been updated will be displayed in bold. When the progress bar reaches 100% and all accounts have been processed, it will hide itself again, and the update button will be re-enabled.

[[Image:moodletxt-accounts-updater.png|border|center]]

[[Category:MoodleTxt|Settings Account Listing]]
[[Category:Plugin]]

Webinar module

2025-11-06T08:58:31Z

Stronk7:

[[Category:Moodle23]]

==Overview and Installation==
Download latest version of the plugin from http://moodle.org/plugins/view.php?plugin=mod_webinar.
===Summary===
This is an activity module for web conferencing which enables Adobe Connect webinar sessions to be added as an activity to any course.
===Description===
The Webinar activity module enables Adobe Connect hosted webinars to be added as an activity to any course. This is intended for hosted Adobe deployments, not on-premise deployments - see http://www.adobe.com/products/adobeconnect.html

The Webinar activity module includes the following functionality:

*Add/edit/delete webinar session
*Assign a host user to a session - based on 'teacher' system role
*Register for session / assign students to a session
*Unregistered for session / unassign students from a session
*Automated email notifications to registered students
*Join session
*View / record webinar
*Run attendance report
All webinar administration is done from within Moodle from setting up webinar sessions, registering users on webinar sessions and joining sessions. Only when the student clicks on Join Session do they leave Moodle and view the webinar in the Adobe Connect Player window. Upon exiting the webinar session they will be returned to the Moodle course page.

It has been tested using Adobe Connect Pro 8 (and 9) hosted accounts, using the Adobe Connect Web Services API - see http://help.adobe.com/en_US/connect/8.0/webservices/index.html.
===Requirements===
*Moodle 2.3 or Moodle 2.2
*An Adobe Connect account - register for a 30-day free trial at http://www.adobe.com/uk/products/acrobatconnectpro/trial/
*All users attending session will be required to have Flash Player 10.1 or higher, with the ability to install Adobe Connect Add-Ins in order to share their screen.
===Installation===
#Unpack the module into your Moodle install in order to create a mod/webinar directory.
#Visit the /admin/index.php page to trigger the database installation.
#(Optional) Change the default options in the activity modules configuration.
#(Optional) Assign roles of teacher or non-editing teacher to one or more users to be able to assign them as webinar hosts.

==User Guide==

===Adding Webinar activity===
To add an webinar activity, go to a course you have created and turn editing on and then select add an activity:

This is a two step process.

1. Click the 'Add an activity or resource' link:
[[Image:MoodleDocs add_webinar_activity_1.png|frame|center|1. Add webinar activity]]

2. Select the 'Webinar' radio button and then click 'Add':
[[Image:MoodleDocs add_webinar_activity_2.png|frame|center|2. Add webinar activity]]

You will then be taken to the 'Add a new Webinar' screen. Where you need to enter the name of your webinar. There are also fields for 'description' and 'Agenda' but these are optional.
[[Image:MoodleDocs adding_new_webinar_screen.png|frame|center|Adding a new webinar screen]]

===Editing Webinar activity===
To edit the activity you need either turn editing on or select 'Edit settings' from the 'course settings' panel. You are then taken to the 'Updating Webinar' page:
[[Image:MoodleDocs updating_webinar_screen.png|frame|center|Updating webinar screen]]

===Delete Webinar activity===
To delete the activity you need to turn editing on and select the 'x' symbol and you will then be given the option to confirm the deletion of the activity:
[[Image:MoodleDocs select_delete_webinar_screen.png|frame|center|Delete webinar]]

===View Webinar activity===
To view the webinar activity you just need to click on the activity link on your course page. You will then be taken to the view page which displays the title, description and webinar session information:

Manager View:
[[Image:MoodleDocs view_webinar_page_user.png|frame|center|User view webinar page]]

User View:
[[Image:MoodleDocs view_webinar_page_manager.png|frame|center|Manager view webinar page]]

===Adding a new session===
To add a new session click the 'Add a new session' link on the 'view webinar' page.
[[Image:MoodleDocs add_new_session_link.png|frame|center|Add a new session link]]

On the 'Adding a new session' page you then need to fill in the appropriate details:

#Host - This is a dropdown list of all the people than can be hosts. This will be anyone who has the role of admin, teacher or non editing teacher for the course in question. ** NOTE: for single host license Adobe Connect accounts, the selected host must be the Adobe Connect account holder, and the Moodle user account will need to be registered under the same email address as the Adobe Connect account is registered to. **
#Capacity - The maximum amount of users you want to be able to attend the webinar
#Start date/time
#Finish date/time
[[Image:MoodleDocs add_a_new_session_page.png|frame|center|Add a new session page]]

===Editing a session===
To edit a session open the view webinar page and click the edit icon next to any of the sessions listed. You are then taken to the edit page, when you can change the details as needed.
[[Image:MoodleDocs edit_session_icon_link.png|frame|center|Edit session link]]

[[Image:MoodleDocs edit_session_screen.png|frame|center|Edit session screen]]

===Delete a session===
To delete a session simply select the 'x' icon for the session in question on the view webinar page. You will then be prompted to confirm the deletion.
[[Image:MoodleDocs delete_session_icon.png|frame|center|Delete session link]]

[[Image:MoodleDocs confirm_delete_session.png|frame|center|Delete session confirmation]]

===View/Add attendees===
As a manager for the webinar (administrator, teacher or non editing teacher) you can view the users that have registered for the session and also have the option to add users yourself, these users will then be emailed by Moodle to say they have been registered on the session.

First from the view webinar page click on the 'Attendees link':
[[Image:MoodleDocs attendees_link.png|frame|center|Add attendees link ]]

You are then taken to the 'Attendees' page where you can view the attendees and also have the option to add or remove them from the session:
[[Image:MoodleDocs view_attendees_screen.png|frame|center|View attendees screen]]

Clicking on the 'Add/remove attendees' link then takes you to a standard Moodle add and remove users page:
[[Image:MoodleDocs add_remove_attendees_screen.png|frame|center|Add and Remove attendees screen]]

The users added or deleted are then sent an email Moodle confirming this action. The mail can be configured in the usual way with the language strings:
[[Image:MoodleDocs example_registration_email.png|frame|center|An example registration email]]

===User registration===
The logged in user navigates the course with the webinar in it and then clicks on the link, they are then taken to the 'View Webinar' page where they can register for any of the available sessions there.
[[Image:MoodleDocs user_register_for_session_link.png|frame|center|Register on session link]]

Once the user clicks on 'Register' they are taken to a confirmation page.
[[Image:MoodleDocs register_on_session_conformation_screen.png|frame|center|Register on session confirmation screen]]

The user can also cancel their booking here if they wish to buy clicking on the 'Cancel booking' link:
[[Image:MoodleDocs cancel_booking_for_session_link.png|frame|center|Cancel booking link]]

The user is then taken to a cancel booking screen where they can also enter a reason for the cancellation if they so wish:
[[Image:MoodleDocs cancel_booking_page.png|frame|center|Cancel booking page]]

===Join a session===
As a user you only get the option to join a session, but if logged in as the session host, you can join the session as the host.

From the 'View Webinar' page you can then select the 'Join session' link:

User:
[[Image:MoodleDocs user_join_session.png|frame|center|Join session: user]]

Session Host:
[[Image:MoodleDocs admin_join_session_as_host.png|frame|center|Join session as host]]

Once you have joined a session Adobe connect will start and you will be logged in. For more information on using Adobe connect please see the documentation available from: http://www.adobe.com/support/connect/gettingstarted/index.html.

Example host screen:
[[Image:MoodleDocs webinar_adobe_connect_host.png|frame|center|Example host screen]]

Example user screen with the hosts desktop being shared and webcam enabled:
[[Image:MoodleDocs webinar_user_screen_with_shared_desktop_and_webcam_from_host.png|frame|center|Example user screen with host shared desktop and webcam]]

[[Category:Plugin]]

Moodle LAE

2025-10-17T07:22:12Z

Stronk7: add it to "Contributed code" category

==Meaning of LAE==
The '''LAE''' in Moodle LAE stand for 'Liberal Art Edition'

The goal of the LAE is to provide a coherent package for modules, patches, and code developed (or improved) by the Collaborative Liberal Arts Moodle Project (CLAMP).

This package consists of the code that the developers and instructional technologists at CLAMP schools have deemed essential to their operation of Moodle. A number of other recommend add-ons for Moodle are available through CLAMP web site (http://www.clamp-it.org). These recommended add-ons, however, have certain caveats that you should be aware of, and it is imperative that you read their respective readme files before installing them.

==Project Homepage==

http://www.clamp-it.org/code/moodle-2-5-2liberal-arts-edition-v5-1-0/

==Contact==

Questions about the LAE can be sent to Ken Newquist at newquisk@lafayette.edu or 610-330-5759. CLAMP members may participate in the development of the LAE by joining the Development Project in Redmine (our collaboration web site) at:

http://redmine.clamp-it.org/projects/development

==Contents==

Moodle 2.5.2+LAE5.1.0 consists of the core Moodle 2.5.2 release plus a number of CLAMP-developed features and bug fixes.

The following core features are included:

Anonymous Forums
Auto-creation of groupings for groups
Per-course resource display options

Anonymous Forums

A completely new version of the Anonymous Forums option in Moodle. This version introduces a new "Anonymous User" who is attached to forum posts, allowing faculty to back up and restore a forum without losing anonymity. This feature is disabled by default.
Auto-creation of groupings for groups

This feature creates a grouping for each group in a course. This feature is disabled by default; you must enable the Experimental "Group Members Only" setting to use this feature.
Per-course resource display options

You may choose a default resource display option at the course level now instead of at the site-level.
Contributed modules

CLAMP recommends the following contributed modules. If you have downloaded the "Package" version of the LAE then these modules are already available.
Filtered Course List

This block allows you to list a current term and a future term's courses first, based on whatever term-based naming convention you use in your Moodle courses' shortname field (e.g. FA11, SP12). It also allows you to specify a course category instead."
LAE Grader Report

This is an alternative Grader Report for Moodle. It includes fixed scrolling on the vertical and horizontal axes and a new optional total display.
OU Dates Report

This course report, developed by Tim Hunt at the Open University, allows teachers to quickly edit date-aware items in course modules such as quizzes and assignments.
Quickmail

A block used to quickly send emails to members of a class, replicating similar functionality found in other learning management systems. This version is forked from the Quickmail currently maintained by Louisiana State University.
Roster Report

A course report which displays the user pictures for everyone enrolled in a course.

==Downloading the LAE==

You can get the LAE in two ways:

Download the tar and zip packages from the CLAMP web site: http://www.clamp-it.org/code/

Download the current release branch from the CLAMP code repository:

git clone https://github.com/CLAMP-IT/moodle v2.5.2-LAE5.1.0 git checkout -b v2.5.2-LAE5.1.0

By default this is the "Package" version which includes the contributed modules. If you just want the core version of the LAE checkout the v2.5.2-LAE5.1.0-base tag instead.

CLAMP maintains two branches for each major version:

LAE_25_STABLE contains the core code only
LAE_25_PACKAGE includes the contributed modules

==Installing the LAE==

If you are installing Moodle for the first time, you can follow the standard Moodle installation instructions (substituting the LAE Moodle package for the regular Moodle one)

https://docs.moodle.org/en/Installing_Moodle
Upgrading to the LAE

If you are upgrading an existing installation, you can follow your normal procedure for doing an "in-place" upgrade (replacing your old Moodle files with the new LAE ones, then copying over any additional modules or blocks you might have from the old install into the new one)

A few notes:

Always backup your original Moodle files and database before doing an upgrade.

We strongly recommend doing a test upgrade on a development Moodle instance before upgrading your production instance.

[[Category:Contributed code]]

Poster module

2025-05-16T16:32:09Z

Stronk7: adding it to the plugins cat

See [https://moodle.org/plugins/view/mod_poster the module record] in the Plugins directory.

== Motivation ==
There are many useful blocks available for Moodle. Typically, they can be only added to the sides of the Moodle pages, or to the
user's dashboard page (also known as My home page). Sometimes, you may want to keep your course main page quite clean, not cluttered
with blocks on both sides. In such case, you can put useful blocks into a separate Poster page.
The overall concept is somewhat similar to how pages are created in Mahara - but it is typically the teacher in Moodle who creates
the Poster for students to view.

== Usage ==
To use the module, you should understand how Moodle sticky blocks work. See [Block
settings](https://docs.moodle.org/en/Block_settings) page for more details.
1. Add the module instance into the course.
2. Keep the editing mode on.
3. Add the Moodle blocks you want to display on the poster.
4. Click the icon to configure the block. Set the block instance so that it is displayed in the context of the
poster, on page type _Poster module main page_ (`mod-poster-view`), inside the region `mod_poster-pre` or `mod_poster-post`.
5. Alternatively, use the drag and drop feature to move the block to the regions at the poster content area.
6. Note that some blocks must be first added to the course main page first, configured to be displayed at any page and then
configured again to be displayed at the poster main page only (this is how block positioning works in Moodle generally).
The poster can be used as for example:
* Course wall/dashboard (contact teachers, detailed outline of the course, latest news, comments, ...).
* Project dashboard (project goals, calendar, comments, people, ...)
* Research report (goals, methods, results, comments, ...)

== Implementation ==
The Poster module uses not so well known feature of the Moodle blocks architecture. In almost all cases, it is the theme that
defines regions where plugins can be added to. However, in special cases, such as this one, any Moodle plugin can define its custom
block regions. Within the context of the Poster module instance, when displaying its view.php page, two extra block regions are
defined - `mod_poster-pre` and `mod_poster-post`. The Poster module itself is just a tiny wrapper for displaying these two regions
as its content. Simple and clever.
The module natively supports responsive layout in bootstrap based themes (both 2.x and 3.x versions).

== Licence ==
Copyright (C) 2023 onwards: bdecent gmbh
based on the work of 2015 David Mudrák
This program 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.

This program 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 this program. If not, see http://www.gnu.org/licenses/.

[[Category:Plugin]]

User:Eloy Lafuente (stronk7)/Using OpenAI API-compatible providers

2024-09-24T09:25:35Z

Stronk7:

== Introduction ==

Moodle 4.5 and its AI subsystem comes with a basic number of supported LLM providers. One of them is the OpenAI provider.

While it's a "proprietary" [https://openai.com/index/openai-api/ API], it has become sort of a ''"de facto" standard''' and many other LLM providers, both open and commercial, or tools like AI proxies or routers, come with an OpenAI API-compatible layer to use their services.

That enables to, virtually, '''use any model out there''' (text completions, images, embeddings, ...) as far as the provider has implemented those OpenAI API-compatible entry points. Just search out there for "OpenAI compatible" and you will find them out.

As an example, in this article, '''we'll be using [https://ollama.com Ollama]''' that is one of the most popular open LLM providers that, apart from its own API, also comes with [https://ollama.com/blog/openai-compatibility OpenAI compatibility], supports many [https://ollama.com/library open models], can be installed locally (or remotely) and works on CPUs (slow!), GPUs (faster) and it's really [https://github.com/ollama/ollama/blob/main/README.md#cli-reference easy to manage].

But, again, don't forget that '''this is only an example and the very same applies to any other provider or tool supporting the OpenAI API'''. And they are legion! Depending of your needs, usage, monitoring, budget, LLM features... you may end using any of them.

== Configuring Moodle to use a locally installed Ollama ==

=== Requirements ===

# An instance of Moodle (4.5dev or later) is [https://docs.moodle.org/en/Installing_Moodle installed and running].
# Ollama is [https://ollama.com/download installed] in the same computer where Moodle is running.
# Some [https://ollama.com/library LLM model] has been pulled and is available to Ollama, we'll be using <tt>llama3.1</tt> in this example.
# It's working ok. You can test it by executing this in the terminal:
ollama run llama3.1 "I love Moodle"</tt>.
Or, in a complementary manner, this raw http call can be used to verify that the service is available via OpenAI API by executing:
curl --location 'http://127.0.0.1:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
"model": "llama3.1",
"messages": [
{
"role": "user",
"content": "I love Moodle"
}
]
}'

=== Moodle HTTP security configuration ===

By default, as a security measure, Moodle blocks local network hosts to be accessed with Curl. That includes the usual local networks, like 192.168.1.x, or 10.x.y.z, ... and also 127.0.0.1 or localhost. Similarly, by default, only ports 80 and 443 are allowed.

In our case, remember that this is a locally installed Ollama, we need to allow 127.0.0.1 (or localhost) to be accessed. And, also, we need to allow the 11434 port to be used. Note that those details match the <tt>curl</tt> command that we used in the previous section.

To do so, just go to Admin -> General -> Security -> HTTP security (or use the admin search utility to find it) and then proceed to apply these changes:
# In the "cURL blocked hosts list" (curlsecurityblockedhosts) setting, remove both the <tt>127.0.0.1/8</tt> and <tt>localhost</tt> entries.
# In the "cURL allowed ports list" (curlsecurityallowedport) setting, add the <tt>11434</tt> port.
# Save changes.

Done, now Moodle should be able to connect to 127.0.0.1:11434, that matches our local Ollama installation.

Note that if you're using any other OpenAI compatible '''local''' provider, or if you're running it in another '''local''' server, you may need to allow other addresses (by IP or by name) and ports, but the mechanism is exactly the same.

=== Moodle OpenAI provider configuration ===

Now that we have the local provider (Ollama) running and we have configured Moodle to have access to it, we are going to configure the OpenAI provider, these are the steps to follow:
# Go to Admin -> General -> AI -> Manage settings for AI providers
# Enable the "OpenAI API provider" by clicking on the toggle.
# Click the "OpenAI API provider" settings link.
# In the "Provider actions", enable both the "Generate text" and "Summarise text" actions, by clicking their "Enabled" toggle. Note that, in the case of Ollama, it doesn't provide any LLM able to generate images, so we cannot enable it for our case. Other OpenAI compatible provider may be able to do so.
# Both for the, now enabled, "Generate text" and "Summarise text" actions, click on their "Settings" link and proceed to configure the following:
#* Model: llama3.1
#* API endpoint: http://127.0.0.1:11434/v1/chat/completions
#* Save changes.

And that's all. Now we should be able to use our local Ollama provider for the AI placements available in our Moodle instance: HTML Editor and Course Assistance placements. Don't forget to enable and configure their settings at Admin -> General -> AI -> Manage settings for AI placements.

=== A brief note about security ===

Note that, '''by default''', Ollama only binds (listens) to 127.0.0.1 (or localhost) and port 11434. Or, in other words, its main use is to be installed in the same host where the client (Moodle in this case) is installed. And that's what the configuration above covers. And '''can be considered a "secure" configuration''' as far as nobody else (but the same host) can access to it.

If you want to '''install Ollama in another host''', then you will have to open it for remote access (setting the <tt>OLLAMA_HOST</tt>, see Ollama documentation). But that opens it for remote access from anywhere by default. And '''that is an "insecure" configuration''' at all effects because Ollama doesn't support any Authorisation schema (say API keys, say auth headers, ...). Be warned about that and ask to the IT experts before allowing such a remote access, sure that they will help you to protect the Ollama installation using different mechanisms (firewalls, reverse proxies, auth layers, ...).

Finally, once again, note that this documentation is 100% focussed on a local (same host) Ollama installation. But '''there are dozens of alternative OpenAI compatible providers out there''', and many of them do support Authorisation or virtual API keys and offer more security for remote access, support for different LLMs, ... so it's recommended to try a few of them depending on each's one own requirements and infrastructure availability.

User:Eloy Lafuente (stronk7)/Using OpenAI API-compatible providers

2024-09-24T07:11:39Z

Stronk7:

== Introduction ==

Moodle 4.5 and its AI subsystem comes with a basic number of supported LLM providers. One of them is the OpenAI provider.

While it's a "proprietary" [https://openai.com/index/openai-api/ API], it has become sort of a ''"de facto" standard''' and many other LLM providers, both open and commercial, or tools like AI proxies or routers, come with an OpenAI API-compatible layer to use their services.

That enables to, virtually, '''use any model out there''' (text completions, images, embeddings, ...) as far as the provider has implemented those OpenAI API-compatible entry points. Just search out there for "OpenAI compatible" and you will find them out.

As an example, in this article, '''we'll be using [https://ollama.com Ollama]''' that is one of the most popular open LLM providers that, apart from its own API, also comes with [https://ollama.com/blog/openai-compatibility OpenAI compatibility], supports many [https://ollama.com/library open models], can be installed locally (or remotely) and works on CPUs (slow!), GPUs (faster) and it's really [https://github.com/ollama/ollama/blob/main/README.md#cli-reference easy to manage].

But, again, don't forget that '''this is only an example and the very same applies to any other provider or tool supporting the OpenAI API'''. And they are legion! Depending of your needs, usage, monitoring, budget, LLM features... you may end using any of them.

== Configuring Moodle to use a locally installed Ollama ==

=== Requirements ===

# An instance of Moodle (4.5dev or later) is [https://docs.moodle.org/en/Installing_Moodle installed and running].
# Ollama is [https://ollama.com/download installed] in the same computer where Moodle is running.
# Some [https://ollama.com/library LLM model] has been pulled and is available to Ollama, we'll be using <tt>llama3.1</tt> in this example.
# It's working ok. You can test it by executing this in the terminal:
ollama run llama3.1 "I love Moodle"</tt>.
Or, in a complementary manner, this raw http call can be used to verify that the service is available via OpenAI API by executing:
curl --location 'http://127.0.0.1:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
"model": "llama3.1",
"messages": [
{
"role": "user",
"content": "I love Moodle"
}
]
}'

=== Moodle HTTP security configuration ===

By default, as a security measure, Moodle blocks local network hosts to be accessed with Curl. That includes the usual local networks, like 192.168.1.x, or 10.x.y.z, ... and also 127.0.0.1 or localhost. Similarly, by default, only ports 80 and 443 are allowed.

In our case, remember that this is a locally installed Ollama, we need to allow 127.0.0.1 (or localhost) to be accessed. And, also, we need to allow the 11434 port to be used. Note that those details match the <tt>curl</tt> command that we used in the previous section.

To do so, just go to Admin -> General -> Security -> HTTP security (or use the admin search utility to find it) and then proceed to apply these changes:
# In the "cURL blocked hosts list" (curlsecurityblockedhosts) setting, remove both the <tt>127.0.0.1/8</tt> and <tt>localhost</tt> entries.
# In the "cURL allowed ports list" (curlsecurityallowedport) setting, add the <tt>11434</tt> port.
# Save changes.

Done, now Moodle should be able to connect to 127.0.0.1:11434, that matches our local Ollama installation.

Note that if you're using any other OpenAI compatible '''local''' provider, or if you're running it in another '''local''' server, you may need to allow other addresses (by IP or by name) and ports, but the mechanism is exactly the same.

=== Moodle OpenAI provider configuration ===

Now that we have the local provider (Ollama) running and we have configured Moodle to have access to it, we are going to configure the OpenAI provider, these are the steps to follow:
# Go to Admin -> General -> AI -> Manage settings for AI providers
# Enable the "OpenAI API provider" by clicking on the toggle.
# Click the "OpenAI API provider" settings link.
# In the "Provider actions", enable both the "Generate text" and "Summarise text" actions, by clicking their "Enabled" toggle. Note that, in the case of Ollama, it doesn't provide any LLM able to generate images, so we cannot enable it for our case. Other OpenAI compatible provider may be able to do so.
# Both for the, now enabled, "Generate text" and "Summarise text" actions, click on their "Settings" link and proceed to configure the following:
#* Model: llama3.1
#* API endpoint: http://127.0.0.1:11434/v1/chat/completions
#* Save changes.

And that's all. Now we should be able to use our local Ollama provider for the available AI placements available in our Moodle instance: HTML Editor and Course Assistance placements. Don't forget to enable and configure their settings at Admin -> General -> AI -> Manage settings for AI placements.

=== A brief note about security ===

Note that, '''by default''', Ollama only binds (listens) to 127.0.0.1 (or localhost) and port 11434. Or, in other words, its main use is to be installed in the same host where the client (Moodle in this case) is installed. And that's what the configuration above covers. And '''can be considered a "secure" configuration''' as far as nobody else (but the same host) can access to it.

If you want to '''install Ollama in another host''', then you will have to open it for remote access (setting the <tt>OLLAMA_HOST</tt>, see Ollama documentation). But that opens it for remote access from anywhere by default. And '''that is an "insecure" configuration''' at all effects because Ollama doesn't support any Authorisation schema (say API keys, say auth headers, ...). Be warned about that and ask to the IT experts before allowing such a remote access, sure that they will help you to protect the Ollama installation using different mechanisms (firewalls, reverse proxies, auth layers, ...).

Finally, once again, note that this documentation is 100% focussed on a local (same host) Ollama installation. But '''there are dozens of alternative OpenAI compatible providers out there''', and many of them do support Authorisation or virtual API keys and offer more security for remote access, support for different LLMs, ... so it's recommended to try a few of them depending on each's one own requirements and infrastructure availability.

User:Eloy Lafuente (stronk7)/Using OpenAI API-compatible providers

2024-09-24T07:09:17Z

Stronk7:

== Introduction ==

Moodle 4.5 and its AI subsystem comes with a basic number of supported LLM providers. One of them is the OpenAI provider.

While it's a "proprietary" [https://openai.com/index/openai-api/ API], it has become sort of a ''"de facto" standard''' and many other LLM providers, both open and commercial, or tools like AI proxies or routers, come with an OpenAI API-compatible layer to use their services.

That enables to, virtually, '''use any model out there''' (text completions, images, embeddings, ...) as far as the provider has implemented those OpenAI API-compatible entry points. Just search out there for "OpenAI compatible" and you will find them out.

As an example, in this article, '''we'll be using [https://ollama.com Ollama]''' that is one of the most popular open LLM providers that, apart from its own API, also comes with [https://ollama.com/blog/openai-compatibility OpenAI compatibility], supports many [https://ollama.com/library open models], can be installed locally (or remotely) and works on CPUs (slow!), GPUs (faster) and it's really [https://github.com/ollama/ollama/blob/main/README.md#cli-reference easy to manage].

But, again, don't forget that '''this is only an example and the very same applies to any other provider or tool supporting the OpenAI API'''. And they are legion! Depending of your needs, usage, monitoring, budget, LLM features... you may end using any of them.

== Configuring Moodle to use a locally installed Ollama ==

=== Requirements ===

# An instance of Moodle (4.5dev or later) is [https://docs.moodle.org/en/Installing_Moodle installed and running].
# Ollama is [https://ollama.com/download installed] in the same computer where Moodle is running.
# Some [https://ollama.com/library LLM model] has been pulled and is available to Ollama, we'll be using <tt>llama3.1</tt> in this example.
# It's working ok. You can test it by executing this in the terminal:
ollama run llama3.1 "I love Moodle"</tt>.
Or, in a complementary manner, this raw http call can be used to verify that the service is available via OpenAI API by executing:
curl --location 'http://127.0.0.1:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
"model": "llama3.1",
"messages": [
{
"role": "user",
"content": "I love Moodle"
}
]
}'

=== Moodle HTTP security configuration ===

By default, as a security measure, Moodle blocks local network hosts to be accessed with Curl. That includes the usual local networks, like 192.168.1.x, or 10.x.y.z, ... and also 127.0.0.1 or localhost. Similarly, by default, only ports 80 and 443 are allowed.

In our case, remember that this is a locally installed Ollama, we need to allow 127.0.0.1 (or localhost) to be accessed. And, also, we need to allow the 11434 port to be used. Note that those details match the <tt>curl</tt> command that we used in the previous section.

To do so, just go to Admin -> General -> Security -> HTTP security (or use the admin search utility to find it) and then proceed to apply these changes:
# In the "cURL blocked hosts list" (curlsecurityblockedhosts) setting, remove both the <tt>127.0.0.1/8</tt> and <tt>localhost</tt> entries.
# In the "cURL allowed ports list" (curlsecurityallowedport) setting, add the <tt>11434</tt> port.
# Save changes.

Done, now Moodle should be able to connect to 127.0.0.1:11434, that matches our local Ollama installation.

Note that if you're using any other OpenAI compatible '''local''' provider, or if you're running it in another '''local''' server, you may need to allow other addresses (by IP or by name) and ports, but the mechanism is exactly the same.

=== Moodle OpenAI provider configuration ===

Now that we have the local provider (Ollama) running and we have configured Moodle to have access to it, we are going to configure the OpenAI provider, these are the steps to follow:
# Go to Admin -> General -> AI -> Manage settings for AI providers
# Enable the "OpenAI API provider" by clicking on the toggle.
# Click the "OpenAI API provider" settings link.
# In the "Provider actions", enable both the "Generate text" and "Summarise text" actions, by clicking their "Enabled" toggle. Note that, in the case of Ollama, it doesn't provide any LLM able to generate images, so we cannot enable it for our case. Other OpenAI compatible provider may be able to do so.
# Both for the, now enabled, "Generate text" and "Summarise text" actions, click on their "Settings" link and proceed to configure the following:
#* Model: llama3.1
#* API endpoint: http://127.0.0.1:11434/v1/chat/completions
#* Save changes.

And that's all. Now we should be able to use our local Ollama provider for the available AI placements available in our Moodle instance: HTML Editor and Course Assistance placements. Don't forget to enable and configure their settings at Admin -> General -> AI -> Manage settings for AI placements.

=== A brief note about security ===

Note that, '''by default''', Ollama only binds (listens) to 127.0.0.1 (or localhost) and port 11434. Or, in other words, its main use is to be installed in the same host where the client (Moodle in this case) is installed. And that's what the configuration above covers. And '''can be considered a "secure" configuration''' as far as nobody else (but the same host) can access to it.

If you want to '''install Ollama in another host''', then you will have to open it for remote access (setting the <tt>OLLAMA_HOST</tt>, see Ollama documentation). But that opens it for remote access from anywhere by default. And '''that is an "insecure" configuration''' and all effects because Ollama doesn't support any Authorisation schema (say API keys, say auth headers, ...). Be warned about that and ask to the IT experts before allowing such a remote access, sure that they will help you to protect the Ollama installation using different mechanisms (firewalls, reverse proxies, auth layers, ...).

Finally, once again, note that this documentation is 100% focussed on a local (same host) Ollama installation. But '''there are dozens of alternative OpenAI compatible providers out there''', and many of them do support Authorisation or virtual API keys and offer more security for remote access, support for different LLMs, ... so it's recommended to try a few of them depending on each's one own requirements and infrastructure availability.

User:Eloy Lafuente (stronk7)/Using OpenAI API-compatible providers

2024-09-24T07:08:38Z

Stronk7:

== Introduction ==

Moodle 4.5 and its AI subsystem comes with a basic number of supported LLM providers. One of them is the OpenAI provider.

While it's a "proprietary" [https://openai.com/index/openai-api/ API], it has become sort of a ''"de facto" standard''' and many other LLM providers, both open and commercial, or tools like AI proxies or routers, come with an OpenAI API-compatible layer to use their services.

That enables to, virtually, '''use any model out there''' (text completions, images, embeddings, ...) as far as the provider has implemented those OpenAI API-compatible entry points. Just search out there for "OpenAI compatible" and you will find them out.

As an example, in this article, '''we'll be using [https://ollama.com Ollama]''' that is one of the most popular open LLM providers that, apart from its own API, also comes with [https://ollama.com/blog/openai-compatibility OpenAI compatibility], supports many [https://ollama.com/library open models], can be installed locally (or remotely) and works on CPUs (slow!), GPUs (faster) and it's really [https://github.com/ollama/ollama/blob/main/README.md#cli-reference easy to manage].

But, again, don't forget that '''this is only an example and the very same applies to any other provider or tool supporting the OpenAI API'''. And they are legion! Depending of your needs, usage, monitoring, budget, LLM features... you may end using any of them.

== Configuring Moodle to use a locally installed Ollama ==

=== Requirements ===

# An instance of Moodle (4.5dev or later) is [https://docs.moodle.org/en/Installing_Moodle installed and running].
# Ollama is [https://ollama.com/download installed] in the same computer where Moodle is running.
# Some [https://ollama.com/library LLM model] has been pulled and is available to Ollama, we'll be using <tt>llama3.1</tt> in this example.
# It's working ok. You can test it by executing this in the terminal:
ollama run llama3.1 "I love Moodle"</tt>.
Or, in a complementary manner, this raw http call can be used to verify that the service is available via OpenAI API by executing:
curl --location 'http://127.0.0.1:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
"model": "llama3.1",
"messages": [
{
"role": "user",
"content": "I love Moodle"
}
]
}'

=== Moodle HTTP security configuration ===

By default, as a security measure, Moodle blocks local network hosts to be accessed with Curl. That includes the usual local networks, like 192.168.1.x, or 10.x.y.z, ... and also 127.0.0.1 or localhost. Similarly, by default, only ports 80 and 443 are allowed.

In our case, remember that this is a locally installed Ollama, we need to allow 127.0.0.1 (or localhost) to be accessed. And, also, we need to allow the 11434 port to be used. Note that those details match the <tt>curl</tt> command that we detailed in the previous section.

To do so, just go to Admin -> General -> Security -> HTTP security (or use the admin search utility to find it) and then proceed to apply these changes:
# In the "cURL blocked hosts list" (curlsecurityblockedhosts) setting, remove both the <tt>127.0.0.1/8</tt> and <tt>localhost</tt> entries.
# In the "cURL allowed ports list" (curlsecurityallowedport) setting, add the <tt>11434</tt> port.
# Save changes.

Done, now Moodle should be able to connect to 127.0.0.1:11434, that matches our local Ollama installation.

Note that if you're using any other OpenAI compatible '''local''' provider, or if you're running it in another '''local''' server, you may need to allow other addresses (by IP or by name) and ports, but the mechanism is exactly the same.

=== Moodle OpenAI provider configuration ===

Now that we have the local provider (Ollama) running and we have configured Moodle to have access to it, we are going to configure the OpenAI provider, these are the steps to follow:
# Go to Admin -> General -> AI -> Manage settings for AI providers
# Enable the "OpenAI API provider" by clicking on the toggle.
# Click the "OpenAI API provider" settings link.
# In the "Provider actions", enable both the "Generate text" and "Summarise text" actions, by clicking their "Enabled" toggle. Note that, in the case of Ollama, it doesn't provide any LLM able to generate images, so we cannot enable it for our case. Other OpenAI compatible provider may be able to do so.
# Both for the, now enabled, "Generate text" and "Summarise text" actions, click on their "Settings" link and proceed to configure the following:
#* Model: llama3.1
#* API endpoint: http://127.0.0.1:11434/v1/chat/completions
#* Save changes.

And that's all. Now we should be able to use our local Ollama provider for the available AI placements available in our Moodle instance: HTML Editor and Course Assistance placements. Don't forget to enable and configure their settings at Admin -> General -> AI -> Manage settings for AI placements.

=== A brief note about security ===

Note that, '''by default''', Ollama only binds (listens) to 127.0.0.1 (or localhost) and port 11434. Or, in other words, its main use is to be installed in the same host where the client (Moodle in this case) is installed. And that's what the configuration above covers. And '''can be considered a "secure" configuration''' as far as nobody else (but the same host) can access to it.

If you want to '''install Ollama in another host''', then you will have to open it for remote access (setting the <tt>OLLAMA_HOST</tt>, see Ollama documentation). But that opens it for remote access from anywhere by default. And '''that is an "insecure" configuration''' and all effects because Ollama doesn't support any Authorisation schema (say API keys, say auth headers, ...). Be warned about that and ask to the IT experts before allowing such a remote access, sure that they will help you to protect the Ollama installation using different mechanisms (firewalls, reverse proxies, auth layers, ...).

Finally, once again, note that this documentation is 100% focussed on a local (same host) Ollama installation. But '''there are dozens of alternative OpenAI compatible providers out there''', and many of them do support Authorisation or virtual API keys and offer more security for remote access, support for different LLMs, ... so it's recommended to try a few of them depending on each's one own requirements and infrastructure availability.

User:Eloy Lafuente (stronk7)/Using OpenAI API-compatible providers

2024-09-23T21:38:33Z

Stronk7: Created page with "== Introduction == Moodle 4.5 and its AI subsystem comes with a basic number of supported LLM providers. One of them is the OpenAI provider. While it's a "proprietary" [https://openai.com/index/openai-api/ API], it has become sort of a ''"de facto" standard''' and many other LLM providers, both open and commercial, or tools like AI proxies or routers, come with an OpenAI API-compatible layer to use their services. That enables to, virtually, '''use any model out there..."

== Introduction ==

Moodle 4.5 and its AI subsystem comes with a basic number of supported LLM providers. One of them is the OpenAI provider.

While it's a "proprietary" [https://openai.com/index/openai-api/ API], it has become sort of a ''"de facto" standard''' and many other LLM providers, both open and commercial, or tools like AI proxies or routers, come with an OpenAI API-compatible layer to use their services.

That enables to, virtually, '''use any model out there''' (text completions, images, embeddings, ...) as far as the provider has implemented those OpenAI API-compatible entry points. Just search out there for "OpenAI compatible" and you will find them out.

As an example, in this article, '''we'll be using [https://ollama.com Ollama]''' that is one of the most popular open LLM providers that, apart from its own API, also comes with [https://ollama.com/blog/openai-compatibility OpenAI compatibility], supports many [https://ollama.com/library open models], can be installed locally (or remotely) and works on CPUs (slow!), GPUs (faster) and it's really [https://github.com/ollama/ollama/blob/main/README.md#cli-reference easy to manage].

But, again, don't forget that '''this is only an example and the very same applies to any other provider or tool supporting the OpenAI API'''. And they are legion! Depending of your needs, usage, monitoring, budget, LLM features... you may end using any of them.

== Configuring Moodle to use a locally installed Ollama ==

=== Requirements ===

# An instance of Moodle (4.5dev or later) is [https://docs.moodle.org/en/Installing_Moodle installed and running].
# Ollama is [https://ollama.com/download installed] in the same computer where Moodle is running.
# Some [https://ollama.com/library LLM model] has been pulled and is available to Ollama, we'll be using <tt>llama3.1</tt> in this example.
# It's working ok. You can test it by executing this in the terminal:
ollama run llama3.1 "I love Moodle"</tt>.
Or, in a complementary manner, this raw http call can be used to verify that the service is available via OpenAI API by executing:
curl --location 'http://127.0.0.1:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
"model": "llama3.1",
"messages": [
{
"role": "user",
"content": "I love Moodle"
}
]
}'

=== Moodle HTTP security configuration ===

By default, as a security measure, Moodle blocks local network hosts to be accessed with Curl. That includes the usual local networks, like 192.168.1.x, or 10.x.y.z, ... and also 127.0.0.1 or localhost. Similarly, by default, only ports 80 and 443 are allowed.

In our case, remember that this is a locally installed Ollama, we need to allow 127.0.0.1 (or localhost) to be accessed. And, also, we need to allow the 11434 to be used. Note that those details match the <tt>curl</tt> command that we detailed in the previous section.

To do so, just go to Admin -> General -> Security -> HTTP security (or use the admin search utility to find it) and then proceed to apply these changes:
# In the "cURL blocked hosts list" (curlsecurityblockedhosts) setting, remove both the <tt>127.0.0.1/8</tt> and <tt>localhost</tt> entries.
# In the "cURL allowed ports list" (curlsecurityallowedport) setting, add the <tt>11434</tt> port.
# Save changes.

Done, now Moodle should be able to connect to 127.0.0.1:11434, that matches our local Ollama installation.

Note that if you're using any other OpenAI compatible '''local''' provider, or if you're running it in another '''local''' server, you may need to allow other addresses (by IP or by name) and ports, but the mechanism is exactly the same.

=== Moodle OpenAI provider configuration ===

Now that we have the local provider (Ollama) running and we have configured Moodle to have access to it, we are going to configure the OpenAI provider, these are the steps to follow:
# Go to Admin -> General -> AI -> Manage settings for AI providers
# Enable the "OpenAI API provider" by clicking on the toggle.
# Click the "OpenAI API provider" settings link.
# In the "Provider actions", enable both the "Generate text" and "Summarise text" actions, by clicking their "Enabled" toggle. Note that, in the case of Ollama, it doesn't provide any LLM able to generate images, so we cannot enable it for our case. Other OpenAI compatible provider may be able to do so.
# Both for the, now enabled, "Generate text" and "Summarise text" actions, click on their "Settings" link and proceed to configure the following:
#* Model: llama3.1
#* API endpoint: http://127.0.0.1:11434/v1/chat/completions
#* Save changes.

And that's all. Now we should be able to use our local Ollama provider for the available AI placements available in our Moodle instance: HTML Editor and Course Assistance placements. Don't forget to enable and configure their settings at Admin -> General -> AI -> Manage settings for AI placements.

=== A brief note about security ===

Note that, '''by default''', Ollama only binds (listens) to 127.0.0.1 (or localhost) and port 11434. Or, in other words, its main use is to be installed in the same host where the client (Moodle in this case) is installed. And that's what the configuration above covers. And '''can be considered a "secure" configuration''' as far as nobody else (but the same host) can access to it.

If you want to '''install Ollama in another host''', then you will have to open it for remote access (setting the <tt>OLLAMA_HOST</tt>, see Ollama documentation). But that opens it for remote access from anywhere by default. And '''that is an "insecure" configuration''' and all effects because Ollama doesn't support any Authorisation schema (say API keys, say auth headers, ...). Be warned about that and ask to the IT experts before allowing such a remote access, sure that they will help you to protect the Ollama installation using different mechanisms (firewalls, reverse proxies, auth layers, ...).

Finally, once again, note that this documentation is 100% focussed on a local (same host) Ollama installation. But '''there are dozens of alternative OpenAI compatible providers out there''', and many of them do support Authorisation or virtual API keys and offer more security for remote access, support for different LLMs, ... so it's recommended to try a few of them depending on each's one own requirements and infrastructure availability.

Upgrading

2024-04-09T14:51:39Z

Stronk7: Show only versions that can be upgraded to 4.4 (aka, Moodle 4.1.2 an up)

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''
==Check the requirements==
Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:
* You can only upgrade to Moodle {{Version}} from Moodle 3.11.8 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/311/en/Upgrading upgrade to 3.11.8] as a first step.
==Before upgrading==
'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.
== Backup important data ==
There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)
See [[Site backup]] for more specific information.
== Check for plugin updates ==
If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.
==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.
== Install the new Moodle software ==
You can download the latest release from [https://download.moodle.org/ Moodle downloads].
=== Standard install package ===
# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.
====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz
Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):
cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod
Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.
chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle
If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.
=== Using Git ===
You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.
===Command line upgrade===
On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.
== Finishing the upgrade ==
The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.
===Fatal error: Maximum execution time of 30 seconds exceeded...===
If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==Possible issues that may affect you in Moodle {{Version}}==

===LTI External tool improvements===

External tool is no longer available in the activity chooser. Instead, teachers can create a tool via a new page [[LTI External tools]] in the More menu of their course, then choose to make it available in the activity chooser. Existing tools created at site level and set to show as a preconfigured tool or show in the activity chooser are listed on the LTI External tools page.

There's also a new option to restrict site-level tools to courses in specific categories only.

===Site-level default settings for activity completion===

You can set default [[Activity completion settings]] for all courses on the site in ''Site administration > Courses > Default activity completion''. Previously, the default at course level was 'Student must manually mark the activity as done' for all activities. After upgrading, the default at site and course level is 'None', with the exception of any changed course level defaults, which are retained.

===Communication===

To use the new feature [[Communication]], which includes an integration with Matrix, you must enable communication providers in ''Site administration > Development > Experimental settings''.

===Sharing courses to MoodleNet===

If [[Share to MoodleNet|sharing to MoodleNet]] is enabled on the site, in 4.3 teachers can also share courses or selected items from the course to MoodleNet.

===Multi-factor authentication===

To increase site security, you can enable [[Multi-factor authentication]] in ''Site administration > Plugins > Manage multi-factor authentication''.

===SCORM database structure improvements===

If your site has a large amount of SCORM tracking data, the 4.3 upgrade may take longer than usual. However, after upgrading you should see some performance improvements.

===New user tour===

Moodle 4.3 includes a new [[User tours|user tour]] for the Grader report, highlighting features added in Moodle 4.2. If desired, you can disable it in Site administration / Appearance / User tours.

===Creative Commons 4.0 licences===

Creative Commons 4.0 licences are available. Creative Commons 3.0 licences are disabled - this prevents future use while not affecting existing use.

===HTTP only cookies default set to on===

HTTP only cookies (cookiehttponly) is set to on for new installs and the UI setting is removed. For upgraded sites, the current setting persists. Unless your site is using old SCORM packages or similar, HTTP only cookies should be on. If required, it can be changed in config.php.

===Role renaming settings move===

Role renaming settings are no longer in the course settings but instead can be found in ''Course > Participants > Role renaming''.

===Scrolling on mobile devices issue when using Atto===

To avoid a bug affecting mobile device users using Atto (MDL-79636), users need to change their text editor to TinyMCE.

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.3%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.3%20AND%20labels%20%3D%20ui_change ui_change-labelled issues].

===New capabilities in Moodle {{Version}}===

* communication/matrix:moderator
* factor/capability:cannotpassfactor
* mod/forum:canmailnow
* moodle/contentbank:copyanycontent
* moodle/contentbank:copycontent
* moodle/course:configurecoursecommunication
* moodle/group:configurecustomfields
* moodle/moodlenet:sharecourse
* tool/mfa:mfaaccess

===Removed capabilities===

* mod/lti:addmanualinstance

== Moodle 4.1, 4.2 and 4.3 upgrading notes ==
Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation:
* [https://docs.moodle.org/401/en/Upgrading Upgrading to Moodle 4.1]
* [https://docs.moodle.org/402/en/Upgrading Upgrading to Moodle 4.2]
* [https://docs.moodle.org/403/en/Upgrading Upgrading to Moodle 4.3]

==Any questions about the process?==
Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.
==See also==
* [https://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&version=17960 Moodle 4.2 release notes]
[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

PHP

2024-02-02T10:44:04Z

Stronk7: Updating versions to actual ones.

{{Installing Moodle}}
PHP is the scripting language in which Moodle is developed. It is integrated with your web server. The web server detects php pages (by their extension) and sends them to PHP for execution. PHP must be installed and configured properly for Moodle to work effectively (or at all).
==PHP Versions==
* Moodle 3.0.1 and later support PHP 7, however
** Moodle 3.1 and earlier does not support PHP 7.1 or later (this means that there is currently no combination of releases of Moodle and PHP that are still supported before Moodle 3.4);
* Moodle 3.4 and Moodle 3.5 '''require''' PHP 7.0 or PHP 7.1 or PHP 7.2
* Moodle 3.6 '''requires''' PHP 7.0 or later
* Moodle 3.7 '''requires''' PHP 7.1 or later
* Moodle 3.9 '''requires''' PHP 7.2 to 7.4
* Moodle 3.11 and 4.0 '''requires''' PHP 7.3 to 8.0
* Moodle 4.1 (LTS) '''requires''' PHP 7.4 to 8.1
* Moodle 4.2 '''requires''' PHP 8.0 to 8.2
* Moodle 4.3 '''requires''' PHP 8.0 to 8.2

==PHP Settings==
Check these settings in your php.ini or .htaccess file (if you're using Apache). For settings which use ON/OFF as their values, you can substitute 1 for ON and 0 for OFF if you prefer. If you change php.ini, don't forget to restart the server.
* ''memory_limit'' needs to be at least 96M (although some functions may not work if this low). Moodle will refuse to install if lower. 128M is recommended. Large systems may need an even higher setting.
* ''session.save_handler'' needs to be set to FILES.
* ''magic_quotes_runtime'' needs to be OFF. (DEPRECATED in PHP 5.3.0, and REMOVED as of PHP 7.0.0.)
* ''file_uploads'' needs to be ON.
* ''session.auto_start'' needs to be OFF.
* The temp folder must be defined and writeable by your webserver user
* Check the error display/logging section. Make sure the settings are appropriate for your server use.
* ''post_max_size'' and ''upload_max_filesize'' restrict the maximum file size that can be uploaded.
* Check the ''[mail function]'' and database section (for your chosen database) to make sure they match your server configuration.
==HTTP_RAW_POST_DATA errors==
Some users are experiencing $HTTP_RAW_POST_DATA related errors, when establishing connection between MNET servers or making AJAX web services requests.
<pre>
Request for server name returned empty response

line 134 of /mnet/lib.php: call to debugging()
line 115 of /admin/mnet/peers.php: call to mnet_get_public_key()
</pre>
These errors are affecting installations running moodle on PHP 5.6 version and it's a PHP bug on the '''always_populate_raw_post_data''' setting the default value to 0.

To avoid the error messages above, please change the value following setting on your php.ini file:
* '''always_populate_raw_post_data''' should be changed to '''-1'''.
For more information about this bug, see: https://bugs.php.net/bug.php?id=66763
==Finding the correct php.ini==
Sometimes it is not obvious where the php.ini file is located or you may even find more than one. To be certain run 'phpinfo' - see below. The path of the php.ini file is a few lines down in the top section.

Note that if you are using command-line (CLI) PHP for running cron (or anything else) it may be configured with a ''different'' php.ini file. To check, run the following command:
<pre>
php -i | grep php.ini
</pre>
==PHP Extensions and libraries==
The following PHP extensions are required or recommended (some, e.g. iconv, ctype and tokenizer are now included in PHP by default). Others will need to be installed or selected.
==== Required extensions ====
* '''ctype'''
* '''curl'''
* '''dom'''
* '''gd'''
* '''iconv'''
* '''intl'''
* '''json'''
* '''mbstring'''
* '''pcre'''
* '''simplexml'''
* '''spl'''
* '''xml'''
* '''zip'''
* The appropriate extension for your chosen database is also required ('''pgsql''', '''mysqli''', '''sqlsrv''', '''oci8''', or '''pdo''')
* Other PHP extensions may be required to support optional Moodle functionality, especially external authentication and/or enrolment (e.g. LDAP extension for LDAP authentication and the sockets extension for Chat server).
==== Recommended extensions ====
* '''openssl''' (required for networking and web services)
* '''soap''' (required for web services)
* '''sodium''' (required on PHP 8 and above)
* '''tokenizer'''
* '''xmlrpc''' (required for networking and web services)
==Installing (missing) extensions==
This depends on how PHP was installed on your machine and what access you have. Here are some possibilities:
* The extension might be installed but not enabled; you can enable it in php.ini with the <code>extension=<extension-name></code> [https://www.php.net/manual/en/ini.core.php#ini.extension directive].
* If this is a hosted server you are likely to have to ask the administrator or hosting company.
* If PHP was compiled from source you will need to recompile, changing the 'configure' settings - see [[Compiling PHP from source]].
* If it was installed using packages (typically Linux) you can install the required package (see your Linux distribution's documentation)
* If you are using Windows you just need to uncomment the appropriate DLL files in php.ini
After making any changes or additions, don't forget to re-start your web server.
== .htaccess files ==
If you don't have access to the php.ini file or there are conflicting requirements with other PHP applications on the same server you may be able to change PHP settings in an .htaccess file. This should be placed in the 'root' of your Moodle installation (i.e. the same place as the config.php file).

'''The file isn't always called .htaccess and may not work at all. Contact your server administrator to be sure'''

Settings are made by adding lines in one of two formats:
* php_value ''name value''
* php_flag ''name on/off''
Examples:
* '''php_value memory_limit 128M'''
* '''php_flag register_globals off'''
==PHP info==
The phpinfo display contains information about the configuration of your PHP installation. This is useful for checking:
* that your PHP installation meets Moodle's system requirements.
* the values that are currently applied to your server's PHP install, e.g. File upload limits
* that you have installed the required modules needed for Moodle to work, e.g. the LDAP module for LDAP authentication.
=== Displaying phpinfo in Moodle===
An administrator can find PHP info in ''Settings > Site administration > Server > PHP info''.
=== Displaying phpinfo outside of Moodle ===
To view the phpinfo information:
* Create a file called info.php using your text editor, containing this single line:
<code php>
<?php phpinfo(); ?>
</code>
* Save this file as info.php
* Upload this file into the root web accessible folder on your server.
* Now open this file in your browser. For example <nowiki>http://<server-name>/info.php</nowiki>.
==See also==
*[[Compiling PHP from source]]
* [https://docs.moodle.org/dev/Moodle_and_PHP7 Moodle and PHP7] in the developers documentation
*http://www.php.net/ - the PHP web site
*[https://php.iis.net/ http://php.iis.net/] - Microsoft PHP Installer for IIS
* [[MoodleDocs:Style_guide#PHP_syntax_highlighting]] to highlight PHP syntax
* [[Code syntax highlighting]] that uses the GeSHi (Generic Syntax Highlighter) filter.
[[de:PHP]]
[[es:PHP]]

User talk:Eloy Lafuente (stronk7)

2024-01-06T16:53:14Z

Stronk7: Created page with "test talk page"

test talk page

admin/environment/custom check/db prefix too long

2023-09-10T15:30:30Z

Stronk7: Created page with "Since Moodle 4.3, the max allowed length for the database tables prefix (<tt>$CFG->prefix</tt>) are 10 characters. If your database is using longer prefixes, you will need to..."

Since Moodle 4.3, the max allowed length for the database tables prefix (<tt>$CFG->prefix</tt>) are 10 characters.

If your database is using longer prefixes, you will need to rename all the tables to use a new, shorter, prefix.

References:
* [https://moodledev.io/general/releases/4.3#database-requirements Moodle 4.3 release page database requirements].
* MDL-76459

admin/environment/custom check/php not 64 bits

2023-01-02T15:42:55Z

Stronk7: amend

This message means that your current [[PHP]] version is not 64 bits.

A new feature of PHP7 is it has now 64-bit version so it can use more than 4GB RAM and code performance can be potentially two times faster depending on the application design.

{{Note|Since Moodle 4.2 it's required to use a 64-bit version of PHP and the underlying Operating System.}}

[[es:admin/environment/custom check/php not 64 bits]]

admin/environment/custom check/php not 64 bits

2023-01-02T15:40:02Z

Stronk7:

This message means that your current [[PHP]] version is not 64 bits.

A new feature of PHP7 is it has now 64-bit version so it can use more than 4GB RAM and code performance can be potentially two times faster depending on the application design.

{{Note|Starting with Moodle 4.2 only 64bits Operating Systems and PHP installations are supported.}}

[[es:admin/environment/custom check/php not 64 bits]]

Upgrading

2022-11-15T18:10:00Z

Stronk7: Update the information to the versions that may be involved in the upgrades (3.9 and up)

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''
==Check the requirements==
Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:
* You can only upgrade to Moodle {{Version}} from Moodle 3.9 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/39/en/Upgrading_to_Moodle_3.9 upgrade to 3.9] as a first step.

==Before upgrading==
'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.
== Backup important data ==
There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)
See [[Site backup]] for more specific information.
== Check for plugin updates ==
If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.
==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.
== Install the new Moodle software ==
You can download the latest release from [https://download.moodle.org/ Moodle downloads].
=== Standard install package ===
# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.
====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz
Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):
cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod
Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.
chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle
If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.
=== Using Git ===
You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.
===Command line upgrade===
On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.
== Finishing the upgrade ==
The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.
===Fatal error: Maximum execution time of 30 seconds exceeded...===
If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.
==After upgrading==
{{Note|If BigBlueButtonBN was previously installed, because the recordings are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed.

This means that in large deployments (with many recordings), the process may take some time (it can be hours) and therefore recordings may not be displayed immediately. But they are still there.}}
==Possible issues that may affect you in Moodle {{Version}}==

=== General ===

See the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.1%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.1%20AND%20labels%20%3D%20ui_change ui_change-labelled issues].

=== XMLRPC ===
* The installation of the '''XMLRPC PHP extension''' is not needed for Moodle 4.1 core anymore. All [[MNet]] features continue working exactly the same, but using a PHP library instead (see MDL-76055 for details).
* If you were using the '''webservice_xmlrpc''' plugin for integrations with other systems, be warned that it has been removed from core for Moodle 4.1 (see MDL-76052 for details). It's now available @ https://github.com/moodlehq/moodle-webservice_xmlrpc and has been also published in the [https://moodle.org/plugins/webservice_xmlrpc Plugins directory]. Note that, if you want to continue using this plugin, then you will need, '''before starting the upgrade process''', to:
*# Install the '''XMLRPC PHP extension''', the webservice requires it.
*# Install the '''webservice_xmlrpc plugin''', from the links in the previous paragraph, into the <tt>webservice/xmlrpc</tt> directory.
*# Then, and only then, start the upgrade process.

=== New plugins in Moodle {{Version}} ===
====BigBlueButton====
{{Note|For recordings to work properly, [https://docs.moodle.org/501/en/Cron Cron] Jobs must be enabled. Also, if you are using [https://github.com/blindsidenetworks/scalelite ScaleLite] for load balancing your BigBlueButton servers, make sure you are running the latest release of ScaleLite.}}
BigBlueButtonBN has been [https://moodle.org/plugins/mod_bigbluebuttonbn contributed plugin] for more than 10 years. It enables Moodle to interoperate with a BigBlueButton server and it is part of Moodle 4.0 as a core plugin. For more details see [https://docs.moodle.org/501/en/BigBlueButton BigBlueButton in Moodle 4.0]
When upgrading to Moodle 4.0, there are two possible scenarios.
===== BigBlueButtonBN was not installed =====
If the plugin was never installed, there are only two considerations to make.
* BigBlueButton is disabled by default. Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin comes pre-configured with a Free Tier Hosting that comes with some restrictions.
===== BigBlueButtonBN was already installed =====
If the plugin was already installed, and the steps were followed correctly, the upgrade should be completed normally. But there are also some considerations to make.
* BigBlueButton may be disabled by default. If this is the case Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin will only change the BigBlueButton credentials if the former Free Tier Hosting `https://test-install.blindsidenetworks.com/bigbluebutton/` was used. If it was not, then the existing service will still be the same.
===== General consideration =====
Regardless of the scenario, there is one general consideration

BigBlueButton is still the repository for recordings, but the metadata is now stored in Moodle, so instead of making a getRecording requests each time a BigBlueButton activity is displayed, the view is entirely populated with Moodle data. While this makes the code more efficient, it also means that every recording needs to be processed as part of the upgrade.
# For recordings to work properly, cron jobs must be enabled
# Since the recording are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed. This means that in in large deployments (with many recordings), the recordings may take some time (it can be hours) to be processed and therefore to be displayed as part of the activities.

The details of the process can be checked in the cron job logs.

And remember that if the Plugin was not uninstalled, and the pre-existing rooms are there, the recordings are still referenced. Nothing is lost even if they are not shown immediately. They only need to be migrated.

Additionally, when using Scalelite as the Load Balancer for BigBlueButton, make sure the [https://github.com/blindsidenetworks/scalelite/releases/tag/v1.3.4 latest version] is deployed. With any other Load Balancer, make sure the BigBlueButton service updateRecordings is correctly implemented. Otherwise the migration will not be completed.
===Custom user tours===
If you have created any custom user tours where the URLs do not end in a % symbol (for example '/course/view.php'), these will no longer appear when viewing a page which has extra text at the end of the URL, such as /course/view.php?id=123. To make these tours work again, add a % to the end of the URL ('/course/view.php%'). The % symbol was always supposed to be necessary, but due to a bug in earlier versions, was previously not required.
===New capabilities in Moodle {{Version}}===
* mod/bigbluebuttonbn:addinstance
* mod/bigbluebuttonbn:addinstancewithmeeting
* mod/bigbluebuttonbn:addinstancewithrecording
* mod/bigbluebuttonbn:deleterecordings
* mod/bigbluebuttonbn:importrecordings
* mod/bigbluebuttonbn:join
* mod/bigbluebuttonbn:managerecordings
* mod/bigbluebuttonbn:protectrecordings
* mod/bigbluebuttonbn:publishrecordings
* mod/bigbluebuttonbn:unprotectrecordings
* mod/bigbluebuttonbn:unpublishrecordings
* mod/bigbluebuttonbn:view

* mod/quiz:emailnotifyattemptgraded

* moodle/question:commentall
* moodle/question:commentmine

* moodle/reportbuilder:edit
* moodle/reportbuilder:editall
* moodle/reportbuilder:scheduleviewas
* moodle/reportbuilder:view

* qbank/customfields:changelockedcustomfields
* qbank/customfields:configurecustomfields
* qbank/customfields:viewhiddencustomfields
=== Moodle 3.9, 3.10, 3.11 and 4.0 upgrading notes ===
Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation:
* [https://docs.moodle.org/39/en/Upgrading Upgrading to Moodle 3.9]
* [https://docs.moodle.org/310/en/Upgrading Upgrading to Moodle 3.10]
* [https://docs.moodle.org/311/en/Upgrading Upgrading to Moodle 3.11]
* [https://docs.moodle.org/400/en/Upgrading Upgrading to Moodle 4.0]

==Any questions about the process?==
Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.
==See also==
* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion
[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2022-11-15T14:22:33Z

Stronk7: Fixed a couple of links to point to 4.1 issues in the tracker

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''
==Check the requirements==
Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:
* You can only upgrade to Moodle {{Version}} from Moodle 3.9 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/39/en/Upgrading_to_Moodle_3.9 upgrade to 3.9] as a first step.

==Before upgrading==
'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.
== Backup important data ==
There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)
See [[Site backup]] for more specific information.
== Check for plugin updates ==
If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.
==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.
== Install the new Moodle software ==
You can download the latest release from [https://download.moodle.org/ Moodle downloads].
=== Standard install package ===
# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.
====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz
Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):
cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod
Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.
chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle
If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.
=== Using Git ===
You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.
===Command line upgrade===
On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.
== Finishing the upgrade ==
The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.
===Fatal error: Maximum execution time of 30 seconds exceeded...===
If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.
==After upgrading==
{{Note|If BigBlueButtonBN was previously installed, because the recordings are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed.

This means that in large deployments (with many recordings), the process may take some time (it can be hours) and therefore recordings may not be displayed immediately. But they are still there.}}
==Possible issues that may affect you in Moodle {{Version}}==

=== General ===

See the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.1%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.1%20AND%20labels%20%3D%20ui_change ui_change-labelled issues].

=== XMLRPC ===
* The installation of the '''XMLRPC PHP extension''' is not needed for Moodle 4.1 core anymore. All [[MNet]] features continue working exactly the same, but using a PHP library instead (see MDL-76055 for details).
* If you were using the '''webservice_xmlrpc''' plugin for integrations with other systems, be warned that it has been removed from core for Moodle 4.1 (see MDL-76052 for details). It's now available @ https://github.com/moodlehq/moodle-webservice_xmlrpc and has been also published in the [https://moodle.org/plugins/webservice_xmlrpc Plugins directory]. Note that, if you want to continue using this plugin, then you will need, '''before starting the upgrade process''', to:
*# Install the '''XMLRPC PHP extension''', the webservice requires it.
*# Install the '''webservice_xmlrpc plugin''', from the links in the previous paragraph, into the <tt>webservice/xmlrpc</tt> directory.
*# Then, and only then, start the upgrade process.

=== New plugins in Moodle {{Version}} ===
====BigBlueButton====
{{Note|For recordings to work properly, [https://docs.moodle.org/501/en/Cron Cron] Jobs must be enabled. Also, if you are using [https://github.com/blindsidenetworks/scalelite ScaleLite] for load balancing your BigBlueButton servers, make sure you are running the latest release of ScaleLite.}}
BigBlueButtonBN has been [https://moodle.org/plugins/mod_bigbluebuttonbn contributed plugin] for more than 10 years. It enables Moodle to interoperate with a BigBlueButton server and it is part of Moodle 4.0 as a core plugin. For more details see [https://docs.moodle.org/501/en/BigBlueButton BigBlueButton in Moodle 4.0]
When upgrading to Moodle 4.0, there are two possible scenarios.
===== BigBlueButtonBN was not installed =====
If the plugin was never installed, there are only two considerations to make.
* BigBlueButton is disabled by default. Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin comes pre-configured with a Free Tier Hosting that comes with some restrictions.
===== BigBlueButtonBN was already installed =====
If the plugin was already installed, and the steps were followed correctly, the upgrade should be completed normally. But there are also some considerations to make.
* BigBlueButton may be disabled by default. If this is the case Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin will only change the BigBlueButton credentials if the former Free Tier Hosting `https://test-install.blindsidenetworks.com/bigbluebutton/` was used. If it was not, then the existing service will still be the same.
===== General consideration =====
Regardless of the scenario, there is one general consideration

BigBlueButton is still the repository for recordings, but the metadata is now stored in Moodle, so instead of making a getRecording requests each time a BigBlueButton activity is displayed, the view is entirely populated with Moodle data. While this makes the code more efficient, it also means that every recording needs to be processed as part of the upgrade.
# For recordings to work properly, cron jobs must be enabled
# Since the recording are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed. This means that in in large deployments (with many recordings), the recordings may take some time (it can be hours) to be processed and therefore to be displayed as part of the activities.

The details of the process can be checked in the cron job logs.

And remember that if the Plugin was not uninstalled, and the pre-existing rooms are there, the recordings are still referenced. Nothing is lost even if they are not shown immediately. They only need to be migrated.

Additionally, when using Scalelite as the Load Balancer for BigBlueButton, make sure the [https://github.com/blindsidenetworks/scalelite/releases/tag/v1.3.4 latest version] is deployed. With any other Load Balancer, make sure the BigBlueButton service updateRecordings is correctly implemented. Otherwise the migration will not be completed.
===Custom user tours===
If you have created any custom user tours where the URLs do not end in a % symbol (for example '/course/view.php'), these will no longer appear when viewing a page which has extra text at the end of the URL, such as /course/view.php?id=123. To make these tours work again, add a % to the end of the URL ('/course/view.php%'). The % symbol was always supposed to be necessary, but due to a bug in earlier versions, was previously not required.
===New capabilities in Moodle {{Version}}===
* mod/bigbluebuttonbn:addinstance
* mod/bigbluebuttonbn:addinstancewithmeeting
* mod/bigbluebuttonbn:addinstancewithrecording
* mod/bigbluebuttonbn:deleterecordings
* mod/bigbluebuttonbn:importrecordings
* mod/bigbluebuttonbn:join
* mod/bigbluebuttonbn:managerecordings
* mod/bigbluebuttonbn:protectrecordings
* mod/bigbluebuttonbn:publishrecordings
* mod/bigbluebuttonbn:unprotectrecordings
* mod/bigbluebuttonbn:unpublishrecordings
* mod/bigbluebuttonbn:view

* mod/quiz:emailnotifyattemptgraded

* moodle/question:commentall
* moodle/question:commentmine

* moodle/reportbuilder:edit
* moodle/reportbuilder:editall
* moodle/reportbuilder:scheduleviewas
* moodle/reportbuilder:view

* qbank/customfields:changelockedcustomfields
* qbank/customfields:configurecustomfields
* qbank/customfields:viewhiddencustomfields
=== Moodle 3.6, 3.7, 3.8, 3.9, 3.10 and 3.11 improvements ===
Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]
* [https://docs.moodle.org/38/en/Upgrading Upgrading to Moodle 3.8]
* [https://docs.moodle.org/39/en/Upgrading Upgrading to Moodle 3.9]
* [https://docs.moodle.org/310/en/Upgrading Upgrading to Moodle 3.10]
* [https://docs.moodle.org/311/en/Upgrading Upgrading to Moodle 3.11]

==Any questions about the process?==
Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.
==See also==
* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion
[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2022-11-15T14:21:19Z

Stronk7: Upgrade notes about XMLRPC added

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''
==Check the requirements==
Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:
* You can only upgrade to Moodle {{Version}} from Moodle 3.9 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/39/en/Upgrading_to_Moodle_3.9 upgrade to 3.9] as a first step.

==Before upgrading==
'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.
== Backup important data ==
There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)
See [[Site backup]] for more specific information.
== Check for plugin updates ==
If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.
==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.
== Install the new Moodle software ==
You can download the latest release from [https://download.moodle.org/ Moodle downloads].
=== Standard install package ===
# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.
====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz
Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):
cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod
Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.
chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle
If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.
=== Using Git ===
You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.
===Command line upgrade===
On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.
== Finishing the upgrade ==
The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.
===Fatal error: Maximum execution time of 30 seconds exceeded...===
If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.
==After upgrading==
{{Note|If BigBlueButtonBN was previously installed, because the recordings are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed.

This means that in large deployments (with many recordings), the process may take some time (it can be hours) and therefore recordings may not be displayed immediately. But they are still there.}}
==Possible issues that may affect you in Moodle {{Version}}==

=== XMLRPC ===
* The installation of the '''XMLRPC PHP extension''' is not needed for Moodle 4.1 core anymore. All [[MNet]] features continue working exactly the same, but using a PHP library instead (see MDL-76055 for details).
* If you were using the '''webservice_xmlrpc''' plugin for integrations with other systems, be warned that it has been removed from core for Moodle 4.1 (see MDL-76052 for details). It's now available @ https://github.com/moodlehq/moodle-webservice_xmlrpc and has been also published in the [https://moodle.org/plugins/webservice_xmlrpc Plugins directory]. Note that, if you want to continue using this plugin, then you will need, '''before starting the upgrade process''', to:
*# Install the '''XMLRPC PHP extension''', the webservice requires it.
*# Install the '''webservice_xmlrpc plugin''', from the links in the previous paragraph, into the <tt>webservice/xmlrpc</tt> directory.
*# Then, and only then, start the upgrade process.

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.0%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.0%20AND%20labels%20%3D%20ui_change ui_change-labelled issues].

=== New plugins in Moodle {{Version}} ===
====BigBlueButton====
{{Note|For recordings to work properly, [https://docs.moodle.org/501/en/Cron Cron] Jobs must be enabled. Also, if you are using [https://github.com/blindsidenetworks/scalelite ScaleLite] for load balancing your BigBlueButton servers, make sure you are running the latest release of ScaleLite.}}
BigBlueButtonBN has been [https://moodle.org/plugins/mod_bigbluebuttonbn contributed plugin] for more than 10 years. It enables Moodle to interoperate with a BigBlueButton server and it is part of Moodle 4.0 as a core plugin. For more details see [https://docs.moodle.org/501/en/BigBlueButton BigBlueButton in Moodle 4.0]
When upgrading to Moodle 4.0, there are two possible scenarios.
===== BigBlueButtonBN was not installed =====
If the plugin was never installed, there are only two considerations to make.
* BigBlueButton is disabled by default. Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin comes pre-configured with a Free Tier Hosting that comes with some restrictions.
===== BigBlueButtonBN was already installed =====
If the plugin was already installed, and the steps were followed correctly, the upgrade should be completed normally. But there are also some considerations to make.
* BigBlueButton may be disabled by default. If this is the case Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin will only change the BigBlueButton credentials if the former Free Tier Hosting `https://test-install.blindsidenetworks.com/bigbluebutton/` was used. If it was not, then the existing service will still be the same.
===== General consideration =====
Regardless of the scenario, there is one general consideration

BigBlueButton is still the repository for recordings, but the metadata is now stored in Moodle, so instead of making a getRecording requests each time a BigBlueButton activity is displayed, the view is entirely populated with Moodle data. While this makes the code more efficient, it also means that every recording needs to be processed as part of the upgrade.
# For recordings to work properly, cron jobs must be enabled
# Since the recording are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed. This means that in in large deployments (with many recordings), the recordings may take some time (it can be hours) to be processed and therefore to be displayed as part of the activities.

The details of the process can be checked in the cron job logs.

And remember that if the Plugin was not uninstalled, and the pre-existing rooms are there, the recordings are still referenced. Nothing is lost even if they are not shown immediately. They only need to be migrated.

Additionally, when using Scalelite as the Load Balancer for BigBlueButton, make sure the [https://github.com/blindsidenetworks/scalelite/releases/tag/v1.3.4 latest version] is deployed. With any other Load Balancer, make sure the BigBlueButton service updateRecordings is correctly implemented. Otherwise the migration will not be completed.
===Custom user tours===
If you have created any custom user tours where the URLs do not end in a % symbol (for example '/course/view.php'), these will no longer appear when viewing a page which has extra text at the end of the URL, such as /course/view.php?id=123. To make these tours work again, add a % to the end of the URL ('/course/view.php%'). The % symbol was always supposed to be necessary, but due to a bug in earlier versions, was previously not required.
===New capabilities in Moodle {{Version}}===
* mod/bigbluebuttonbn:addinstance
* mod/bigbluebuttonbn:addinstancewithmeeting
* mod/bigbluebuttonbn:addinstancewithrecording
* mod/bigbluebuttonbn:deleterecordings
* mod/bigbluebuttonbn:importrecordings
* mod/bigbluebuttonbn:join
* mod/bigbluebuttonbn:managerecordings
* mod/bigbluebuttonbn:protectrecordings
* mod/bigbluebuttonbn:publishrecordings
* mod/bigbluebuttonbn:unprotectrecordings
* mod/bigbluebuttonbn:unpublishrecordings
* mod/bigbluebuttonbn:view

* mod/quiz:emailnotifyattemptgraded

* moodle/question:commentall
* moodle/question:commentmine

* moodle/reportbuilder:edit
* moodle/reportbuilder:editall
* moodle/reportbuilder:scheduleviewas
* moodle/reportbuilder:view

* qbank/customfields:changelockedcustomfields
* qbank/customfields:configurecustomfields
* qbank/customfields:viewhiddencustomfields
=== Moodle 3.6, 3.7, 3.8, 3.9, 3.10 and 3.11 improvements ===
Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]
* [https://docs.moodle.org/38/en/Upgrading Upgrading to Moodle 3.8]
* [https://docs.moodle.org/39/en/Upgrading Upgrading to Moodle 3.9]
* [https://docs.moodle.org/310/en/Upgrading Upgrading to Moodle 3.10]
* [https://docs.moodle.org/311/en/Upgrading Upgrading to Moodle 3.11]

==Any questions about the process?==
Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.
==See also==
* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion
[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2022-11-15T13:54:19Z

Stronk7: Moodle 4.1 requires Moodle 3.9 to upgrade

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''
==Check the requirements==
Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:
* You can only upgrade to Moodle {{Version}} from Moodle 3.9 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/39/en/Upgrading_to_Moodle_3.9 upgrade to 3.9] as a first step.

==Before upgrading==
'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.
== Backup important data ==
There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)
See [[Site backup]] for more specific information.
== Check for plugin updates ==
If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.
==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.
== Install the new Moodle software ==
You can download the latest release from [https://download.moodle.org/ Moodle downloads].
=== Standard install package ===
# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.
====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz
Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):
cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod
Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.
chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle
If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.
=== Using Git ===
You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.
===Command line upgrade===
On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.
== Finishing the upgrade ==
The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.
===Fatal error: Maximum execution time of 30 seconds exceeded...===
If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.
==After upgrading==
{{Note|If BigBlueButtonBN was previously installed, because the recordings are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed.

This means that in large deployments (with many recordings), the process may take some time (it can be hours) and therefore recordings may not be displayed immediately. But they are still there.}}
==Possible issues that may affect you in Moodle {{Version}}==
''Please add items here...''
* [[:dev:Core plugins review for Moodle 4.0]]
* [[:dev:Add a block cleanup]]

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.0%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%204.0%20AND%20labels%20%3D%20ui_change ui_change-labelled issues].

=== New plugins in Moodle {{Version}} ===
====BigBlueButton====
{{Note|For recordings to work properly, [https://docs.moodle.org/501/en/Cron Cron] Jobs must be enabled. Also, if you are using [https://github.com/blindsidenetworks/scalelite ScaleLite] for load balancing your BigBlueButton servers, make sure you are running the latest release of ScaleLite.}}
BigBlueButtonBN has been [https://moodle.org/plugins/mod_bigbluebuttonbn contributed plugin] for more than 10 years. It enables Moodle to interoperate with a BigBlueButton server and it is part of Moodle 4.0 as a core plugin. For more details see [https://docs.moodle.org/501/en/BigBlueButton BigBlueButton in Moodle 4.0]
When upgrading to Moodle 4.0, there are two possible scenarios.
===== BigBlueButtonBN was not installed =====
If the plugin was never installed, there are only two considerations to make.
* BigBlueButton is disabled by default. Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin comes pre-configured with a Free Tier Hosting that comes with some restrictions.
===== BigBlueButtonBN was already installed =====
If the plugin was already installed, and the steps were followed correctly, the upgrade should be completed normally. But there are also some considerations to make.
* BigBlueButton may be disabled by default. If this is the case Administrators must enable it from Site administration > Plugins > Manage activities and then check the box to accept the data processing agreement.
* BigBlueButton is an external service. The plugin will only change the BigBlueButton credentials if the former Free Tier Hosting `https://test-install.blindsidenetworks.com/bigbluebutton/` was used. If it was not, then the existing service will still be the same.
===== General consideration =====
Regardless of the scenario, there is one general consideration

BigBlueButton is still the repository for recordings, but the metadata is now stored in Moodle, so instead of making a getRecording requests each time a BigBlueButton activity is displayed, the view is entirely populated with Moodle data. While this makes the code more efficient, it also means that every recording needs to be processed as part of the upgrade.
# For recordings to work properly, cron jobs must be enabled
# Since the recording are processed asynchronously in the background, the data migration starts after the Moodle upgrade has been completed. This means that in in large deployments (with many recordings), the recordings may take some time (it can be hours) to be processed and therefore to be displayed as part of the activities.

The details of the process can be checked in the cron job logs.

And remember that if the Plugin was not uninstalled, and the pre-existing rooms are there, the recordings are still referenced. Nothing is lost even if they are not shown immediately. They only need to be migrated.

Additionally, when using Scalelite as the Load Balancer for BigBlueButton, make sure the [https://github.com/blindsidenetworks/scalelite/releases/tag/v1.3.4 latest version] is deployed. With any other Load Balancer, make sure the BigBlueButton service updateRecordings is correctly implemented. Otherwise the migration will not be completed.
===Custom user tours===
If you have created any custom user tours where the URLs do not end in a % symbol (for example '/course/view.php'), these will no longer appear when viewing a page which has extra text at the end of the URL, such as /course/view.php?id=123. To make these tours work again, add a % to the end of the URL ('/course/view.php%'). The % symbol was always supposed to be necessary, but due to a bug in earlier versions, was previously not required.
===New capabilities in Moodle {{Version}}===
* mod/bigbluebuttonbn:addinstance
* mod/bigbluebuttonbn:addinstancewithmeeting
* mod/bigbluebuttonbn:addinstancewithrecording
* mod/bigbluebuttonbn:deleterecordings
* mod/bigbluebuttonbn:importrecordings
* mod/bigbluebuttonbn:join
* mod/bigbluebuttonbn:managerecordings
* mod/bigbluebuttonbn:protectrecordings
* mod/bigbluebuttonbn:publishrecordings
* mod/bigbluebuttonbn:unprotectrecordings
* mod/bigbluebuttonbn:unpublishrecordings
* mod/bigbluebuttonbn:view

* mod/quiz:emailnotifyattemptgraded

* moodle/question:commentall
* moodle/question:commentmine

* moodle/reportbuilder:edit
* moodle/reportbuilder:editall
* moodle/reportbuilder:scheduleviewas
* moodle/reportbuilder:view

* qbank/customfields:changelockedcustomfields
* qbank/customfields:configurecustomfields
* qbank/customfields:viewhiddencustomfields
=== Moodle 3.6, 3.7, 3.8, 3.9, 3.10 and 3.11 improvements ===
Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]
* [https://docs.moodle.org/38/en/Upgrading Upgrading to Moodle 3.8]
* [https://docs.moodle.org/39/en/Upgrading Upgrading to Moodle 3.9]
* [https://docs.moodle.org/310/en/Upgrading Upgrading to Moodle 3.10]
* [https://docs.moodle.org/311/en/Upgrading Upgrading to Moodle 3.11]

==Any questions about the process?==
Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.
==See also==
* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion
[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Analytics settings

2021-11-11T18:16:26Z

Stronk7: tidy up some code and information making reference to mlbackend versions

{{Analytics}}
The Moodle learning analytics system requires some initial configuration before it can be used. You can access ''Analytics settings'' from ''Site administration > Analytics > Analytics settings''.

== Site information ==

Site information will be used to help learning analytics models take characteristics of the institution into account. This information is also reported as part of site data collection when you register your site. This will allow HQ to understand which areas in learning analytics are seeing the most use and prioritize development resources appropriately.

== Configure learning analytics settings ==

Analytics may be disabled from Site administration / Advanced features

They may then be configured from Site administration / Analytics.

=== Predictions processor ===

[[Image:analytics01_predictions_processor34.png|frame|center|Predictions processor selection]]

Prediction processors are the machine learning backends that process the datasets generated from the calculated indicators and targets and return predictions. Moodle core includes 2 prediction processors:

==== PHP predictions processor ====

The PHP processor is the default. There are no other system requirements to use this processor.

==== Python predictions processor ====

The Python processor is more powerful and it generates [https://www.tensorflow.org/get_started/summaries_and_tensorboard graphs that explain the model performance]. It requires setting up extra tools: Python itself (https://wiki.python.org/moin/BeginnersGuide/Download) and the moodlemlbackend python package. The package can be installed in the web server (in all the nodes if in a clustered environment) or in a separate server.

===== Versions =====

* Moodle 3.8 and up uses package 2.3.* (minimum 2.3.1)
* Moodle 3.9.11 and up uses package 2.6.* (minimum 2.6.4)
* Moodle 3.10.8 and up uses package 2.6.* (minimum 2.6.4)
* Moodle 3.11.4 and up uses package 2.6.* (minimum 2.6.4)
* Moodle 4.0 and up uses package 3.0.* (minimum 3.0.2)

===== Installed in the web server =====

The latest version of the [https://pypi.org/project/moodlemlbackend/ packages for '''Moodle 3.8''' and up] are compatible with '''Python 3.4, 3.5, 3.6 and 3.7'''. Note that the package should be available for both the Command Line Interface (CLI) user and the user who runs the web server (e.g. www-data).

# If necessary, install Python 3 (and pip for Python 3)
# Ensure that you use Python 3 to install the moodlemlbackend package (for VERSION, see the previous section):

sudo -H python3 -m pip install "moodlemlbackend==VERSION"
# You must also enter the path to the Python 3 executable in Site administration -> Server -> System paths:
[[File:path_to_python_3.png|frame|center|Enter system path for Python 3]]

===== Installed in a separate server =====

To install the python package in a separate server instead of installing it on the web server/s have some advantages:
* Keeps the python ML backend as an external service
* To keep a separated control of the resources the web server/s dedicate to serving Moodle and the resources dedicated to the python ML backend
* You can reuse the same ML server for multiple Moodle sites. Easier to setup and maintain than to install/upgrade the python package in all nodes in the cluster
* You can install the package as a new docker container in your dockerized environment
* You can serve the ML backend from AWS through the API gateway and AWS lambda, storing the trained model files in S3

On the other hand, it is expected that there can be some added latency in connecting to the python ML backend server.

The python backend is exposed as a Flask application. The Flask application is part of the official 'moodlemlbackend' Python package and its FLASK_APP script is 'webapp', in the root of the package. You are free to use the setup that better suits your existing infrastructure.

====== New server in your infrastructure ======

The python ML backend is exposed as a Flask application, which uses a WSGI server (https://wsgi.readthedocs.io/en/latest/what.html) to be exposed to the www. The official documentation on how to deploy a Flask app can be found in https://flask.palletsprojects.com/en/1.0.x/tutorial/deploy/.

* Use MOODLE_MLBACKEND_PYTHON_USERS environment var to set a list of users and password (comma-separated). The value is 'default:sshhhh' (user: default, password: sshhhh).
* Set MOODLE_MLBACKEND_PYTHON_DIR to the path you want to use to store the data generated by the package

====== Docker ======

https://hub.docker.com/r/moodlehq/moodle-mlbackend-python is the official moodle-mlbackend-python docker image. We use it internally at Moodle HQ for internal testing and you can use it as well. You may want more control over the image, if that is the case https://github.com/moodlehq/moodle-docker-mlbackend-python/blob/master/Dockerfile can serve as an example of what is needed to get the python moodlemlbackend package working.

* Use MOODLE_MLBACKEND_PYTHON_USERS environment var to set a list of users and passwords (comma-separated). The value is 'default:sshhhh' (user: default, password: sshhhh).

To run the docker container locally you can execute (For <tt>VERSION</tt>, see the Versions section above):

<syntaxhighlight lang="bash">
docker pull moodlehq/moodle-mlbackend-python:VERSION-python3.7.5
docker run -d -p 5000:5000 --name=mlbackendpython --rm --add-host=mlbackendpython:0.0.0.0 moodlehq/moodle-mlbackend-python:VERSION-python3.7.5
</syntaxhighlight >
'''Note''' that you need to add <tt>--network=moodledocker_default</tt> if your are using moodle-docker and you want this container to be visible from the web server.

Then add this to your config.php file:

<syntaxhighlight lang="php">
$CFG->pathtopython = 'python';
define('TEST_MLBACKEND_PYTHON_HOST', 'localhost'); // Change to "mlbackendpython" if your are using moodle-docker.
define('TEST_MLBACKEND_PYTHON_PORT', 5000);
define('TEST_MLBACKEND_PYTHON_USERNAME', 'default');
define('TEST_MLBACKEND_PYTHON_PASSWORD', 'sshhhh');
</syntaxhighlight>

To check if it works, this command should not Skip any test:

<syntaxhighlight lang="bash">
vendor/bin/phpunit analytics/tests/prediction_test.php --verbose
</syntaxhighlight>

====== AWS serverless service ======

You can serve the Flask application as a serverless application using the AWS API gateway and AWS lambda. The easiest way to do it is using Zappa https://github.com/Miserlou/Zappa to deploy the Flask application contained in the python ML package.

* Use MOODLE_MLBACKEND_PYTHON_USERS environment var to set a list of users and password (comma-separated). The value is 'default:sshhhh' (user: default, password: sshhhh).
* Set MOODLE_MLBACKEND_PYTHON_DIR to the path you want to use to store the data generated by the package
* Set these environment variables below to setup the S3 access:
** MOODLE_MLBACKEND_PYTHON_S3_BUCKET_NAME to the bucket name
**AWS_ACCESS_KEY_ID as usual
** AWS_SECRET_ACCESS_KEY as usual

Once this has been done, you can select the Python prediction processor as the default or for an individual model:
[[File:python_backend.png|frame|center|Predictions processor default]]

[[File:python_backend_at_model.png|frame|center|Predictions processor selection for an individual model]]

=== Log store ===
From Moodle version 2.7 and up, the “Standard logstore” is the default. If for some reason you also have data in the older “legacy logs,” you can enable the Moodle Learning Analytics system to access them instead.

=== Analysis intervals ===

Analysis intervals determine how often insights will be generated, and how much information to use for each calculation. Using proportional analysis intervals allows courses of different lengths to be used to train a single model.

Several analysis intervals are available for models in the system. In this setting, the analysis intervals that will be used to evaluate models are defined, e.g. so the best analysis interval identified by the evaluation process can be selected for the model. This setting does not restrict the analysis intervals that can be used for specific models.

[[Image:06_timesplitting.png|frame|center|Analysis intervals]]

Each analysis interval divides the course duration into segments. At the end of each defined segment, the predictions engine will run and generate insights. It is recommended that you only enable the analysis intervals you are interested in using; the evaluation process will iterate through all enabled analysis intervals, so the more analysis intervals enabled, the slower the evaluation process will be.

=== Models output directory ===

[[Image:03_models_output_directory.png|frame|center|Models output directory]]

This setting allows you to define a directory where machine learning backends data is stored. Be sure this directory exists and is writable by the web server. This setting can be used by Moodle sites with multiple frontend nodes (a cluster) to specify a shared directory across nodes. This directory can be used by machine learning backends to store trained algorithms (its internal variables weights and stuff like that) to use them later to get predictions. Moodle cron lock will prevent multiple executions of the analytics tasks that train machine learning algorithms and get predictions from them.

== Scheduled tasks ==

Most analytics API processes are executed through [[Scheduled_tasks|scheduled tasks]]. These processes usually read the activity log table and can require some time to finish. You can find ''Train models'' and ''Predict models'' scheduled tasks listed in ''Administration > Site administration > Server > Scheduled tasks.'' It is recommended to edit the tasks schedule so they run nightly.

==Capabilities==

There are two analytics capabilities:

* [[Capabilities/moodle/analytics:managemodels|Manage models]] - allowed for the default role of manager only
* [[Capabilities/moodle/analytics:listinsights|List insights]] - allowed for the default roles of manager, teacher and non-editing teacher

To receive notifications and view insights, a user must have the list insights capability within the context used as the "Analysable" for the model. For example, the [[Students at risk of dropping out]] model operates within the context of a course. Insights will be generated for each enrolment within any course matching the criteria of the model (courses with a start date in the past and an end date in the future, with at least one teacher and student), and these insights will be sent to anyone with the list insights capability in that course.

Some models (e.g. the ''No teaching'' model) generate insights at the Site level. To receive insights from these models, the user must have a role assignment at the System level which includes the list insights capability.

'''Note''': Site administrators do '''not''' automatically receive insight notifications, though they can choose to view details of any insight notifications on the system. To enable site administrators to receive notifications of insights, assign an additional role that includes the list insights capability to the site administrator at the system level.

[[Category:Analytics]]

[[es:Configuraciones de analítica]]
[[de:Analytics-Einstellungen]]

Analytics settings

2021-11-11T17:46:37Z

Stronk7: Specify the versions to be used by different Moodle branches

{{Analytics}}
The Moodle learning analytics system requires some initial configuration before it can be used. You can access ''Analytics settings'' from ''Site administration > Analytics > Analytics settings''.

== Site information ==

Site information will be used to help learning analytics models take characteristics of the institution into account. This information is also reported as part of site data collection when you register your site. This will allow HQ to understand which areas in learning analytics are seeing the most use and prioritize development resources appropriately.

== Configure learning analytics settings ==

Analytics may be disabled from Site administration / Advanced features

They may then be configured from Site administration / Analytics.

=== Predictions processor ===

[[Image:analytics01_predictions_processor34.png|frame|center|Predictions processor selection]]

Prediction processors are the machine learning backends that process the datasets generated from the calculated indicators and targets and return predictions. Moodle core includes 2 prediction processors:

==== PHP predictions processor ====

The PHP processor is the default. There are no other system requirements to use this processor.

==== Python predictions processor ====

The Python processor is more powerful and it generates [https://www.tensorflow.org/get_started/summaries_and_tensorboard graphs that explain the model performance]. It requires setting up extra tools: Python itself (https://wiki.python.org/moin/BeginnersGuide/Download) and the moodlemlbackend python package. The package can be installed in the web server (in all the nodes if in a clustered environment) or in a separate server.

===== Versions =====

* Moodle 3.8 and up uses package 2.3.* (minimum 2.3.1)
* Moodle 3.9.11 and up uses package 2.6.* (minimum 2.6.4)
* Moodle 3.10.8 and up uses package 2.6.* (minimum 2.6.4)
* Moodle 3.11.4 and up uses package 2.6.* (minimum 2.6.4)
* Moodle 4.0 and up uses package 3.0.* (minimum 3.0.2)

===== Installed in the web server =====

The latest version of the [https://pypi.org/project/moodlemlbackend/ packages for '''Moodle 3.8''' and up] are compatible with '''Python 3.4, 3.5, 3.6 and 3.7'''. Note that the package should be available for both the Command Line Interface (CLI) user and the user who runs the web server (e.g. www-data).

# If necessary, install Python 3 (and pip for Python 3)
# Ensure that you use Python 3 to install the moodlemlbackend package (for VERSION, see the previous section):

sudo -H python3 -m pip install "moodlemlbackend==VERSION"
# You must also enter the path to the Python 3 executable in Site administration -> Server -> System paths:
[[File:path_to_python_3.png|frame|center|Enter system path for Python 3]]

===== Installed in a separate server =====

To install the python package in a separate server instead of installing it on the web server/s have some advantages:
* Keeps the python ML backend as an external service
* To keep a separated control of the resources the web server/s dedicate to serving Moodle and the resources dedicated to the python ML backend
* You can reuse the same ML server for multiple Moodle sites. Easier to setup and maintain than to install/upgrade the python package in all nodes in the cluster
* You can install the package as a new docker container in your dockerized environment
* You can serve the ML backend from AWS through the API gateway and AWS lambda, storing the trained model files in S3

On the other hand, it is expected that there can be some added latency in connecting to the python ML backend server.

The python backend is exposed as a Flask application. The Flask application is part of the official 'moodlemlbackend' Python package and its FLASK_APP script is 'webapp', in the root of the package. You are free to use the setup that better suits your existing infrastructure.

====== New server in your infrastructure ======

The python ML backend is exposed as a Flask application, which uses a WSGI server (https://wsgi.readthedocs.io/en/latest/what.html) to be exposed to the www. The official documentation on how to deploy a Flask app can be found in https://flask.palletsprojects.com/en/1.0.x/tutorial/deploy/.

* Use MOODLE_MLBACKEND_PYTHON_USERS environment var to set a list of users and password (comma-separated). The value is 'default:sshhhh' (user: default, password: sshhhh).
* Set MOODLE_MLBACKEND_PYTHON_DIR to the path you want to use to store the data generated by the package

====== Docker ======

https://hub.docker.com/r/moodlehq/moodle-mlbackend-python is the official moodle-mlbackend-python docker image. We use it internally at Moodle HQ for internal testing and you can use it as well. You may want more control over the image, if that is the case https://github.com/moodlehq/moodle-docker-mlbackend-python/blob/master/Dockerfile can serve as an example of what is needed to get the python moodlemlbackend package working.

* Use MOODLE_MLBACKEND_PYTHON_USERS environment var to set a list of users and passwords (comma-separated). The value is 'default:sshhhh' (user: default, password: sshhhh).

To run the docker container locally you can execute:

<code bash>
docker pull moodlehq/moodle-mlbackend-python:2.4.0-python3.7.5
# Note that you need to add --network=moodledocker_default if your are using moodle-docker and you want this container to be visible from the web server.
docker run -d -p 5000:5000 --name=mlbackendpython --rm --add-host=mlbackendpython:0.0.0.0 moodlehq/moodle-mlbackend-python:2.4.0-python3.7.5
</code>

Then add this to your config.php file:

<code php>
$CFG->pathtopython = 'python';
define('TEST_MLBACKEND_PYTHON_HOST', 'localhost'); // Change to "mlbackendpython" if your are using moodle-docker.
define('TEST_MLBACKEND_PYTHON_PORT', 5000);
define('TEST_MLBACKEND_PYTHON_USERNAME', 'default');
define('TEST_MLBACKEND_PYTHON_PASSWORD', 'sshhhh');
</code>

To check if it works, this command should not Skip any test:

<code bash>
vendor/bin/phpunit analytics/tests/prediction_test.php --verbose
</code>

====== AWS serverless service ======

You can serve the Flask application as a serverless application using the AWS API gateway and AWS lambda. The easiest way to do it is using Zappa https://github.com/Miserlou/Zappa to deploy the Flask application contained in the python ML package.

* Use MOODLE_MLBACKEND_PYTHON_USERS environment var to set a list of users and password (comma-separated). The value is 'default:sshhhh' (user: default, password: sshhhh).
* Set MOODLE_MLBACKEND_PYTHON_DIR to the path you want to use to store the data generated by the package
* Set these environment variables below to setup the S3 access:
** MOODLE_MLBACKEND_PYTHON_S3_BUCKET_NAME to the bucket name
**AWS_ACCESS_KEY_ID as usual
** AWS_SECRET_ACCESS_KEY as usual

Once this has been done, you can select the Python prediction processor as the default or for an individual model:
[[File:python_backend.png|frame|center|Predictions processor default]]

[[File:python_backend_at_model.png|frame|center|Predictions processor selection for an individual model]]

=== Log store ===
From Moodle version 2.7 and up, the “Standard logstore” is the default. If for some reason you also have data in the older “legacy logs,” you can enable the Moodle Learning Analytics system to access them instead.

=== Analysis intervals ===

Analysis intervals determine how often insights will be generated, and how much information to use for each calculation. Using proportional analysis intervals allows courses of different lengths to be used to train a single model.

Several analysis intervals are available for models in the system. In this setting, the analysis intervals that will be used to evaluate models are defined, e.g. so the best analysis interval identified by the evaluation process can be selected for the model. This setting does not restrict the analysis intervals that can be used for specific models.

[[Image:06_timesplitting.png|frame|center|Analysis intervals]]

Each analysis interval divides the course duration into segments. At the end of each defined segment, the predictions engine will run and generate insights. It is recommended that you only enable the analysis intervals you are interested in using; the evaluation process will iterate through all enabled analysis intervals, so the more analysis intervals enabled, the slower the evaluation process will be.

=== Models output directory ===

[[Image:03_models_output_directory.png|frame|center|Models output directory]]

This setting allows you to define a directory where machine learning backends data is stored. Be sure this directory exists and is writable by the web server. This setting can be used by Moodle sites with multiple frontend nodes (a cluster) to specify a shared directory across nodes. This directory can be used by machine learning backends to store trained algorithms (its internal variables weights and stuff like that) to use them later to get predictions. Moodle cron lock will prevent multiple executions of the analytics tasks that train machine learning algorithms and get predictions from them.

== Scheduled tasks ==

Most analytics API processes are executed through [[Scheduled_tasks|scheduled tasks]]. These processes usually read the activity log table and can require some time to finish. You can find ''Train models'' and ''Predict models'' scheduled tasks listed in ''Administration > Site administration > Server > Scheduled tasks.'' It is recommended to edit the tasks schedule so they run nightly.

==Capabilities==

There are two analytics capabilities:

* [[Capabilities/moodle/analytics:managemodels|Manage models]] - allowed for the default role of manager only
* [[Capabilities/moodle/analytics:listinsights|List insights]] - allowed for the default roles of manager, teacher and non-editing teacher

To receive notifications and view insights, a user must have the list insights capability within the context used as the "Analysable" for the model. For example, the [[Students at risk of dropping out]] model operates within the context of a course. Insights will be generated for each enrolment within any course matching the criteria of the model (courses with a start date in the past and an end date in the future, with at least one teacher and student), and these insights will be sent to anyone with the list insights capability in that course.

Some models (e.g. the ''No teaching'' model) generate insights at the Site level. To receive insights from these models, the user must have a role assignment at the System level which includes the list insights capability.

'''Note''': Site administrators do '''not''' automatically receive insight notifications, though they can choose to view details of any insight notifications on the system. To enable site administrators to receive notifications of insights, assign an additional role that includes the list insights capability to the site administrator at the system level.

[[Category:Analytics]]

[[es:Configuraciones de analítica]]
[[de:Analytics-Einstellungen]]

Configuration file

2021-09-09T14:22:48Z

Stronk7: fix filter_tex plugin name

{{Installing Moodle}}
The name for Moodle's configuration file is config.php. The file is located in the moodle directory. It is not included in the Moodle download packages and is created by the installation process from the template file config-dist.php (which is included in Moodle packages).

==config-dist.php==
Although the installation process creates the config.php file for you, there may be times when you want to do this yourself. A sample config file, called config-dist.php, is shipped with Moodle.

To get started simply copy config-dist.php to config.php, then edit config.php with you favourite editor. The file is very well commented. The important options (which you must supply) are all nearer the top. Other less common options are further down.

==Setting $CFG->wwwroot correctly==
This setting must be a fixed URL (a string constant) that points to your site. Do not try to set this with any PHP code that can generate a variable URL. This is not supported, can cause strange problems and will stop command line scripts working completely. If your site is accessed from different IP addresses this should be done with a split DNS, see [[Masquerading]]

If you change your site from http to https, you '''MUST''' update this setting. If you don’t, you will have problems - for example (but not limited to) css scripts won’t load properly and you will also experience problems with logging in to your site. Also see [[Transitioning_to_HTTPS]]

==Enabling password salting==

See [[Password salting]].

==Including passwords in backups==

Hashed user passwords are no longer saved in backup files containing user data.

If you really need passwords to be saved (in the rare case of restoring a [[Backup of user data|backup with user data]] to a different site), the following line may be added to config.php:

$CFG->includeuserpasswordsinbackup = true;

Note regarding restoring Moodle 2.5 backups to sites with old PHP versions:

Because bcrypt is not supported in PHP versions below 5.3.7, course backups made using the $CFG->includeuserpasswordsinbackup setting on a site using PHP version 5.3.7+ that are subsequently restored to a site with PHP version < 5.3.7 will require a password reset.

==Changing default block layout for new courses==

See [[Block layout]].

==Adding extra theme directory location==
It is possible to add an extra themes directory stored outside of $CFG->dirroot. This local directory does not have to be accessible from internet. Themes placed in the directory specified by these variables will then be available for selection using the theme selector.

For example, should you wish to place extra themes in a subdirectory called 'my_moodle_themes', your config.php might look like this:
<pre>
$CFG->wwwroot = 'http://my.moodle.site.edu';
$CFG->dirroot = '/var/www/my.moodle.site.edu/public_html';
$CFG->themedir = $CFG->dirroot . '/my_moodle_themes';
</pre>

==Disabling update notifications==

See [[Notifications]].

==Enabling debugging==

See [[Debugging]].

==Forcing the value of admin settings==

As explained in config-dist.php, it is possible to specify normal admin settings here, the point is that they can not be changed through the standard admin settings pages any more. Just set the value in config.php like:

<syntaxhighlight lang="php">
$CFG->showuseridentity = 'email,idnumber,username';
$CFG->preventexecpath = true;
$CFG->pathtodu = "/usr/bin/du";
$CFG->pathtodot = "/usr/bin/dot";
$CFG->pathtogs = "/usr/bin/gs";
</syntaxhighlight>

Configuration for plugins can also be forced by the syntax is different, eg continuing the example above for security to always hard coded paths to all executable files:

<syntaxhighlight lang="php">
$CFG->forced_plugin_settings['filter_tex']['pathconvert'] = '/usr/bin/convert';
$CFG->forced_plugin_settings['filter_tex']['pathdvips'] = '/usr/bin/dvips';
$CFG->forced_plugin_settings['filter_tex']['pathdvisvgm'] = '/usr/bin/dvisvgm';
$CFG->forced_plugin_settings['filter_tex']['pathlatex'] = '/usr/bin/latex';
</syntaxhighlight>

==See also==

* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=137889 Moodle Salting] forum discussion

[[de:Konfigurationsdatei]]
[[es:config.php]]
[[fr:Fichier de configuration]]
[[ja:設定ファイル]]

Administration via command line

2021-06-02T22:06:12Z

Stronk7: Content only applicable to previous version: Removing this from stable versions following the removal of code for 4.0 - MDL-71476

{{Installing Moodle}}
==Running CLI scripts==
If you have shell access to your web server, you may find various CLI (command line interface) scripts useful during Moodle administration. Core admin CLI tools are located in the <code>admin/cli/*</code> folder. Other plugins provide their CLI functionality via scripts in their own cli folder. For example, the enrol_db sync script is located in <code>enrol/db/cli/</code>.

To avoid problems with access control, you should run them as the owner of the web server process. It is especially important for CLI installation and upgrade as they create new files in moodledata directory and the web server has to have write access to them. In Linux distributions, the user that runs the web server is usually apache or wwrun or httpd or something similar. As a root, you will probably want to execute Moodle CLI scripts like this:

$ cd /path/to/your/moodle/dir
$ sudo -u apache /usr/bin/php admin/cli/somescript.php --params

Most of the scripts accept common --help (or -h) parameter to display the full usage information, for example:

$ sudo -u apache /usr/bin/php admin/cli/install.php --help

{{Note|These scripts are supposed to be run under the identity of the web server user. Examples on this page use the <tt>apache</tt> user for illustration. The particular value depends on your OS distribution and local set-up. Typical values may be <tt>apache</tt>, <tt>www-data</tt> or <tt>httpd</tt>.}}

== Upgrading ==

Moodle can be upgraded from the command line. As with the installation script, there is either interactive or non-interactive mode of the upgrade. The script itself does not put the site into the maintenance mode, you have to do it on your own. Also, the script does not backup any data (if you read this page, you probably have some own scripts to backup your moodledata and the database, right?)

$ sudo -u apache /usr/bin/php admin/cli/upgrade.php

Upgrading via command line is a very comfortable way of Moodle upgrade if you use Git checkout of the Moodle source code (see [[Git for Administrators]]). See the following procedure how to upgrade your site within several seconds to the most recent version while preserving your eventual local customizations tracked in git repository:

$ cd /var/www/sites/moodle/htdocs/
$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable
$ git pull
$ sudo -u apache /usr/bin/php admin/cli/upgrade.php
$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable

== Installation ==

There are two modes of installing Moodle from the command line. In interactive mode, the install script asks you for all data needed to properly set up new Moodle site. In non-interactive mode, you must provide all required data as the script parameters and then the new site is installed silently. The parameters can be passed in the interactive mode, too. The provided values are then used as the default values during the interactive session.

$ sudo -u apache /usr/bin/php admin/cli/install.php --lang=cs

If your arguments contain some specials characters for Linux based systems, don't forget to ''escape'' them with a backslash. For example, if you want to create an admin with ''pa$sword'' as password you should wrote ''pa\$sword'' instead!

If required, the database install may be skipped, with just config.php populated.

$ sudo -u apache /usr/bin/php admin/cli/install.php --skip-database

== Maintenance mode ==

To switch your site into the maintenance mode via CLI, you can use

$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable

To turn maintenance mode off, execute the same script with the --disable parameter:

$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable

If you don't want to enable maintenance mode immediately, but show a countdown to your users, execute the same script with the --enablelater parameter and the number of minutes which the countdown should run:

$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enablelater=10

This script will also create and remove the climaintenance.html file for "Offline" mode.

== Offline mode ==

In some situations, you may want to switch your Moodle site into offline mode so that it is not accessible via the web but you can not stop the web server completely (typically because there are other web pages and applications running there). If a file called <code>climaintenance.html</code> exists in the root folder of moodledata directory, Moodle will automatically display the contents of that file instead of any other page.

$ cd /var/www/sites/moodle/moodledata/
$ echo '<h1>Sorry, maintenance in progress</h1>' > climaintenance.html

You can prepare a nice formatted HTML page to inform your users about the server being down and keep in the moodledata directory under a name like <code>climaintenance.off</code> and rename it to the <code>climaintenance.html</code> if needed.

== Custom site defaults ==

During the install and upgrade via CLI, Moodle sets the administration variables to the default values. You can use different defaults. See MDL-17850 for details. Shortly, all you need to do is to add a file <code>local/defaults.php</code> into your Moodle installation. The format of the file is like

<code php>
<?php
$defaults['pluginname']['settingname'] = 'settingvalue'; // for plugins
$defaults['moodle']['settingname'] = 'settingvalue'; // for core settings
</code>

These defaults are used during install, upgrade and are also displayed as defaults on Site administration pages.

== Reset user password ==

If you happen to forget your admin password (or you want to set a password for any other user on the site), you can use reset_password.php script. The script sets the correctly salted password for the given user.

$ sudo -u apache /usr/bin/php admin/cli/reset_password.php

==Converting InnoDB tables to Barracuda==

Sites using MySQL with database tables using Antelope as the file format are recommended to convert the tables to the Barracuda file format.

This is because tables using Antelope as the file format cannot handle more than 10 text columns. This file formats only supports ''compact'' and ''redundant'' row formats for backward compatibility reasons. This may cause a problem on larger sites when restoring a course, in which case the following error will be displayed:

Row size too large (>8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help.

Barracuda is the newest innoDB file format. In addition to supporting ''compact'' and ''redundant'' row formats, Barracuda also supports ''compressed'' and ''dynamic'' row formats.

However, converting tables to Barracuda is only recommended, and not required, since not all MySQL users are affected. (It may only be a problem for larger sites.)

===Tool for converting tables===

A command line tool is included in Moodle for converting tables to Barracuda.

To view tables requiring conversion, use the list option:

$ php admin/cli/mysql_compressed_rows.php --list

Here is an example output:

mdl_data Compact (needs fixing)
mdl_data_fields Compact (needs fixing)
mdl_enrol_paypal Compact (needs fixing)

To proceed with the conversion, run the command using the fix option:

$ php admin/cli/mysql_compressed_rows.php --fix

Successful table conversion will be reported in the output, for example:

mdl_data ... Compressed
mdl_data_fields ... Compressed
mdl_enrol_paypal ... Compressed

Please note that the commands must be executed on your moodle directory. Once tables are fixed, the warning message will no longer be displayed.

For further information on InnoDB file formats see the [http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_antelope MySQL InnoDB glossary - Antelope] and the [http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_barracuda MySQL InnoDB glossary - Barracuda].

If you get errors due to having insufficient privileges to run these commands (this is quite likely) then the easiest solution is to generate the required SQL commands using,

$ php admin/cli/mysql_compressed_rows.php --showsql

You can then copy the generated SQL into your mysql client running as the 'root' user.

==Converting to the new character set and collation==

$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci

== Running cron via command line ==

In versions 1.x, you could execute admin/cron.php either from command line or via the web. Since Moodle 2.0, only admin/cli/cron.php script can be run via command line.

== Scheduled tasks ==

Scheduled tasks are automatically run by the cron script, but the specific tasks which run on each cron iteration are determined by the scheduled tasks configuration. It is possible to override the scheduled tasks configuration and run a single scheduled task immediately using the admin/tool/task/cli/schedule_task.php script.

This script accepts the following arguments:

--list - list all the known scheduled tasks. The tasks are listed by the class name used to run the task. This class name is required as the argument to the next option in order to run a specific task immediately.

--execute=<task> - Runs a single scheduled task immediately - regardless of scheduling settings. This will even run disabled tasks. Tasks will still use locking to prevent concurrent execution of the same task - even on clusters. The format of the <task> argument must be the same as returned by the --list option above.

--showsql - Shows sql queries before they are execute

--showdebugging - Shows developer debugging info

'''Note:''' You must escape the "\" with an extra \ when using the --execute command. Take the following for example:

<pre>php admin/tool/task/cli/schedule_task.php --list</pre>

will return something like:

<pre>
== List of scheduled tasks (http://yourserver.com/moodle) ==
\enrol_imsenterprise\task\cron_task 10 * * * * * ASAP
\logstore_legacy\task\cleanup_task * 5 * * * * ASAP
\logstore_standard\task\cleanup_task * 4 * * * * Wednesday, November 12, 2014, 4:35 AM
\mod_forum\task\cron_task * * * * * * ASAP
\core\task\automated_backup_task 50 * * * * * ASAP

...
</pre>

To run the first task in that list, you would execute

php admin/tool/task/cli/schedule_task.php --execute='\enrol_imsenterprise\task\cron_task'

Be aware of the single quotes. Without them, you would need to use double backlashes to avoid escaping by the shell.

==Database transfer==

A command line script for [[Database transfer]] may be found in ''admin/tool/dbtransfer/cli/migrate.php''.

==Purge caches==

You can purge caches using this script:

php admin/cli/purge_caches.php

==Kill all sessions==
If needed for administrative reasons, you can kill all user sessions using this script:

php admin/cli/kill_all_sessions.php

As a result, all users will be logged out from Moodle.

==Backup and restore of large courses==

See Backup via CLI in [[Course backup]] and Restore via CLI in [[Course restore]] (new in 3.10 onwards).

==Fix course / module sequences==

In rare cases (such as after upgrading from a very old version of Moodle), the course / section / module sequence data can be out of sync. This can cause various problems for affected courses, such as sections not appearing, backups failing, pages not displaying etc. There is a specific check to check for errors caused by this problem, and to fix the data in the database if they are found. To run this script please use the command below:

php admin/cli/fix_course_sequence.php -c=* --fix

This will check every course in Moodle and report which ones had errors and were fixed.

==Fix orphaned question categories==

When a quiz is created, a new question category for the quiz is automatically created. In versions of Moodle prior to 2.9.1, if the quiz is deleted, the question category and any questions in the category remain in database. These orphaned question categories may be fixed by running the admin/cli/fix_orphaned_question_categories.php script with the --fix option.

==Search and replace text==

This script can be used to search and replace text throughout the whole database. Use carefully and backup first always. More info in [[Search and replace tool]].

php admin/tool/replace/cli/replace.php --search=//oldsitehost --replace=//newsitehost

==Build theme CSS cache==

If Moodle is not running in theme designer mode it will keep a copy of the compiled CSS on local disk and serve that to the browser when it requests a page. If there isn't a copy on local disk then a copy will be built the first time a page within Moodle is requested.

With this script you can pre-compile the cached CSS files for themes within Moodle to avoid having a user wait for the theme to compile during the first page request.

php admin/cli/build_theme_css.php --themes=boost

==Get and set configuration values==

Displays the current value of the given setting, or set the given setting to the specified value.

$ php admin/cli/cfg.php [--component=<componentname>] [--json] [--shell-arg]
$ php admin/cli/cfg.php --name=<configname> [--component=<componentname>] [--shell-arg] [--no-eol]
$ php admin/cli/cfg.php --name=<configname> [--component=<componentname>] --set=<value>
$ php admin/cli/cfg.php --name=<configname> [--component=<componentname>] --unset
$ php admin/cli/cfg.php [--help|-h]

Examples:
$ php admin/cli/cfg.php --name=langmenu
will display the value of ''Display language menu'' in ''Site administration > Language > Language settings'' (0 for ''No'' or 1 for ''Yes'').
$ php cfg.php --name=maxsizetodownload --component=folder
will display the value of ''Maximum folder download size (MB)'' accessible from ''Site administration > Plugins > Activity modules > Folder''.
$ php admin/cli/cfg.php --name=langmenu --set=0
will disable the ''Language menu''.

==See also==

* MDL-35736 - Manage plugins via command line
* MDL-36237 - Resort course list via CLI
* [http://moosh-online.com/ MOOSH] - MOOdle SHell. It is a commandline tool that will allow you to perform most common Moodle tasks.

[[fr:Administration en ligne de commande]]
[[de:Administration über Kommandozeile]]
[[es:Administración por línea de comando]]
[[it:Amministrazione via linea di comando]]
[[ja:コマンドライン経由の管理]]

Upgrading

2021-05-17T00:09:47Z

Stronk7: Moodle 3.11 required Moodle 3.6

Environment - max input vars

2021-05-06T17:02:43Z

Stronk7: Add environment category

The PHP setting '''max_input_vars''' determines how many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

There are a lot of big or potentially big forms in Moodle, such as:
* Site administration tree search
* Editing roles
* Grading courses with big number of participants
* Large quizzes and quiz settings

The default value for max_input_vars in PHP is '''1000''', this is not enough for many cases.

If you are using PHP 7 the recommended value for the '''max_input_vars''' in Moodle is '''5000''' but you can still use Moodle with the lower value. Moodle code has a workaround that allows to submit the forms even with bigger limit however this workaround is not perfect. It is much better to increase the setting.

If you are using PHP 8 the minimum value of 5000 '''is required'''. By default PHP 8 sets to display startup errors (see [[https://php.watch/versions/8.0/startup-errors-enabled]]). This means that the warning about exceeding max_input_vars appears before the workaround even applied.

To change max_input_vars you can either set it in php.ini or modify it in runtime, for example for Apache you can create '''.htaccess''' file:
<code>
php_value max_input_vars 5000
</code>

[[Category:Environment|PHP]]

[[es:admin/environment/custom check/max input vars]]

Environment - PHP extension sodium

2021-05-06T12:25:04Z

Stronk7:

{{Environment}}

The php-sodium extension provides strong encryption capabilities in an easy and consistent way.

Note that, for sites not having the extension installed, a php-openssl based solution, considered suboptimal, is used, and this fallback will stop working in a few versions (Moodle 4.2). See MDL-71421 for more details.

Hence, it's highly recommended to start using php-sodium.

Please see [https://www.php.net/manual/book.sodium.php https://www.php.net/manual/book.sodium.php]

Please see [https://py-ipv8.readthedocs.io/en/latest/preliminaries/install_libsodium/]

[[Category:Environment|PHP]]

[[es:admin/environment/php extension/sodium]]

Environment - PHP extension sodium

2021-05-06T12:24:39Z

Stronk7: Some notes about php-sodium and current php-openssl fallback

{{Environment}}

The php-sodium extension provides strong encryption capabilities in an easy and consistent way.

Note that, for sites not having the extension installed, a php-openssl based solution, considered suboptimal, is used, and this fallback will stop working in a few versions (Moodle 4.2).

Hence, it's highly recommended to start using php-sodium.

Please see [https://www.php.net/manual/book.sodium.php https://www.php.net/manual/book.sodium.php]

Please see [https://py-ipv8.readthedocs.io/en/latest/preliminaries/install_libsodium/]

[[Category:Environment|PHP]]

[[es:admin/environment/php extension/sodium]]

Upgrading

2018-12-03T00:49:37Z

Stronk7: reorganize the section to avoid duplicating incomplete information. Always refer to the release notes for server and client requirements.

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Administration > Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.1 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/31/en/Upgrading_to_Moodle_3.1 upgrade to 3.1] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current version of the software through

wget http://sourceforge.net/projects/moodle/files/Moodle/stable{{Version2}}/moodle-latest-{{Version2}}.tgz

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the Migration documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. Ideally the files should not be writeable by your server.

chown -R www-data:www-data moodle (Linux debian - change to appropriate user and group for your OS version)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Administration > Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Administration > Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a succcessful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

The config.php file from your installation should work fine but if you take a look at config-dist.php that came with Moodle 3.0 there are more/different options available (e.g. database drivers and settings). It's a good idea to map your old config.php settings to a new one based on the 3.0 config-dist.php.

===Cron===

Cron has received a major update (MDL-25499) and now has support for both scheduled and ad hoc tasks.

The benefits of these changes are:
* The schedule for every task can be configured by the admin
* Tasks can run in parallel
* Cron processes use locking to prevent the same task running at the same time by different processes
* Clusters with multiple identical application nodes are supported, you can run cron on all of them

A result of this is that cron can be run much more often, which means (for example) forum posts can be sent out sooner. To take advantage of the new cron system it is now strongly recommended that administrators increase the frequency that cron is run to at least ''once per minute''.

You also may need to modify any automated scripts you have that are parsing the output from cron. It is no longer possible to simply monitor the output of cron for the string "Cron script completed correctly" (if that is what you were doing). An alternative is to monitor the output for the string "task failed:". If you detect that a task is failing, [[Cron#Debugging_Scheduled_Tasks|here]] are some tips for debugging the failure.

Before the upgrade, there may have been a cron task that was failing, which was preventing the rest of cron from being executed. A failure in any single task will no longer prevent the rest of the Moodle cron tasks from executing, so you may uncover previously masked bugs. It is a good idea to closely monitor the output from cron after the upgrade.

===Assignments===

The old assignment (2.2) module has been removed from core and has been replaced by a stub to support transparently remapping URLs and restoring course backups from the old module to the new one.

If you are still using the old assignment (2.2) module, after upgrading to Moodle 3.0 all assignment (2.2) activities will be hidden. You need to run the [[Assignment upgrade tool]] to un-hide the activities.

If you really, really need to keep using the old assignment (2.2) module, you should update the code to Moodle 3.0, and then replace the "mod/assignment" folder with the one from https://github.com/moodlehq/moodle-mod_assignment/releases before completing the upgrade.

==Possible issues that may affect you in Moodle {{Version}}==

* To use 'Run now' links in [[Scheduled tasks]], you need to set 'Path to PHP CLI' (pathtophp) in Site administration > Server > System paths.

''Items to be added...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.6%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.6%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

=== Moodle 3.1, 3.2, 3.3, 3.4 and 3.5 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/31/en/Upgrading Upgrading to Moodle 3.1]
* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]

==See also==

* [[Installation]]
* Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation help forum]
* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]