https://docs.moodle.org/34/en/api.php?action=feedcontributions&user=Jsilve1&feedformat=atomMoodleDocs - User contributions [en]2024-03-28T10:08:04ZUser contributionsMediaWiki 1.39.6https://docs.moodle.org/34/en/index.php?title=LDAP_authentication&diff=81058LDAP authentication2011-02-03T19:20:36Z<p>Jsilve1: /* User lookup settings */</p>
<hr />
<div>Location: Settings link in ''Administration > Plugins > Authentication > Manage authentication'' in 2.0 onwards or ''Administration > Users > Authentication > Manage authentication'' in 1.9<br />
<br />
<br />
This document describes how to set up Lightweight Directory Access Protocol (LDAP) authentication in Moodle. We cover the basic, advanced and some trouble shooting sections to assist the user in the installation and administrating LDAP in Moodle. <br />
==Table of Contents==<br />
__TOC__<br />
==Basic Scenario==<br />
The simple and straightforward approach for most installations.<br />
<br />
===Assumptions===<br />
<br />
# Your Moodle site is located at '''http://your.moodle.site/'''<br />
# You have configured your PHP installation with the LDAP extension. It is loaded and activated, and it shows when you go to '''http://your.moodle.site/admin/phpinfo.php''' (logged in as user 'admin').<br />
# Your LDAP server has '''192.168.1.100''' as its IP address.<br />
# You are not using LDAP with SSL (also known as LDAPS) in your settings. This might prevent certain operations from working (e.g., you cannot update data if you are using MS Active Directory -- MS-AD from here on --), but should be OK if you just want to authenticate your users.<br />
# You don't want your users to change their passwords the first time they log in into Moodle.<br />
# You are using a single domain as the source of your authentication data in case you are using MS-AD (more on this in the Appendices).<br />
# You are using a top level distinguished name (DN) of '''dc=my,dc=organization,dc=domain''' as the root of your LDAP tree. <br />
# You have a non-privileged LDAP user account you will use to bind to the LDAP server. This is not necessary with certain LDAP servers, but MS-AD requires this and it won't hurt if you use it even if your LDAP server doesn't need it. Make sure '''this account and its password don't expire''', and make this password as strong as possible. Remember you only need to type this password once, when configuring Moodle, so don't be afraid of making it as hard to guess as possible. Let's say this user account has a DN of '''cn=ldap-user,dc=my,dc=organization,dc=domain''', and password '''hardtoguesspassword'''.<br />
# All of your Moodle users are in an organizational unit (OU) called '''moodleusers''', which is right under your LDAP root. That OU has a DN of '''ou=moodleusers,dc=my,dc=organization,dc=domain'''.<br />
# You '''don't''' want your LDAP users' passwords to be stored in Moodle at all.<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
===Configuring Moodle authentication===<br />
<br />
Log in as an admin user and go to Administration >> Users >> Authentication >> Manage authentication. In the table that appears, enable the "LDAP Server" authentication option (click on the closed eye to make it open) and then click on the associated 'Settings' link. You will get a page similar to this one:<br />
<br />
[[Image:auth_ldap_config_screenshot.jpg|center]]<br />
<br />
Now, you just have to fill in the values. Let's go step by step.<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====LDAP Server Settings====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Host URL<br />
| As the IP of your LDAP server is 192.168.1.100, type "'''ldap://192.168.1.100'''" (without the quotes), or just "'''192.168.1.100'''" (some people have trouble connecting with the first syntax, specially on MS Windows servers).<br />
|-<br />
| Version<br />
| Unless you are using a really old LDAP server, '''version 3''' is the one you should choose.<br />
|-<br />
| LDAP Encoding<br />
| Specify encoding used by LDAP server. Most probably utf-8.<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====Bind settings====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Hide passwords<br />
| As you '''don't''' want to store the users's password in Moodle's database, choose '''Yes''' here.<br />
|-<br />
| Distinguished Name<br />
| This is the distinguished name of the bind user defined above. Just type "'''cn=ldap-user,dc=my,dc=organization,dc=domain'''" (without the quotes).<br />
|-<br />
| Password<br />
| This is the bind user password defined above. Type "'''hardtoguesspassword'''" (without the quotes).<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====User lookup settings====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| User type<br />
| Choose: <br />
* '''Novel Edirectory''' if your LDAP server is running Novell's eDdirectory.<br />
* '''posixAccount (rfc2307)''' if your LDAP server is running a RFC-2307 compatible LDAP server (choose this is your server is running OpenLDAP, including Mac OS X server).<br />
* '''posixAccount (rfc2307bis)''' if your LDAP server is running a RFC-2307bis compatible LDAP server.<br />
* '''sambaSamAccount (v.3.0.7)''' if your LDAP server is running with SAMBA's 3.x LDAP schema extension and you want to use it.<br />
* '''MS ActiveDirectory''' if your LDAP server is running Microsoft's Active Directory (MS-AD)<br />
|-<br />
| Contexts<br />
| The DN of the context (container) where all of your Moodle users are found. Type '''ou=moodleusers,dc=my,dc=organization,dc=domain''' here. <br />
<br />
On a Mac OS X Server, this is usually '''cn=users,dc=my,dc=organization,dc=domain'''.<br />
|-<br />
| Search subcontexts<br />
| If you have any sub organizational units (subcontexts) hanging from '''ou=moodleusers,dc=my,dc=organization,dc=domain''' and you want Moodle to search there too, set this to '''yes'''. Otherwise, set this to '''no'''.<br />
|-<br />
| Dereference aliases<br />
| Sometimes your LDAP server will tell you that the real value you are searching for is in fact in another part of the LDAP tree (this is called an alias). If you want Moodle to 'dereference' the alias and fetch the real value from the original location, set this to '''yes'''. If you don't want Moodle to dereference it, set this to '''no'''. If you are using MS-AD, set this to '''no'''.<br />
|-<br />
| User attribute<br />
| The attribute used to name/search users in your LDAP tree. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in</u>.<br />
<br />
By the way, it's usually '''cn''' (Novell eDirectory and MS-AD) or '''uid''' (RFC-2037, RFC-2037bis and SAMBA 3.x LDAP extension), but if you are using MS-AD you could use '''sAMAccountName''' (the pre-Windows 2000 logon account name) if you need too.<br />
|-<br />
| Member attribute<br />
| The attribute used to list the members of a given group. This option takes a default value based on the ''User type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u><br />
<br />
By the way, the usual values are '''member''' and '''memberUid'''.<br />
|-<br />
| Member attribute uses dn<br />
| Whether the member attribute contains distinguished names (1) or not (0).This option takes a default value based on the ''User type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u><br />
|-<br />
| Object class<br />
| The type of LDAP object used to search for users. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in.</u><br />
* If you leave it blank, the filter "(objectClass=*)" will be used.<br />
* If you provide "objectClass=some-string", then it will provide "(objectClass=some-string)" as the filter.<br />
* If you provide a value that does not start with "(", it is assumed to be a value that should be set to "objectClass". So if you provide "some-string", then it will provide "(objectClass=some-string)" as the filter.<br />
* If you provide a string that starts with a "(", then it will pass that as is. So if you provide "(&(objectClass=user)(enabledMoodleUser=1))", then it will pass that as the filter. '''Note: This applies to Moodle 2.0. This only works for Moodle 1.9 with a patch. See discussion here: http://moodle.org/mod/forum/discuss.php?d=159653'''<br />
<br />
<br />
Here are the default values for each of the ''ldap_user_type'' values:<br />
* '''User''' for Novel eDirectory<br />
* '''posixAccount''' for RFC-2037 and RFC-2037bis<br />
* '''sambaSamAccount''' for SAMBA 3.0.x LDAP extension<br />
* '''user''' for MS-AD<br />
If you get an error about a problem with updating the ldap server (even if you have specified not to write changes back to the ldap server) try setting the ldap object class to * - see http://moodle.org/mod/forum/discuss.php?d=70566 for a discussion on this problem<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====Force change password====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Force change password<br />
| Set this to ''Yes'' if you want to force your users to change their password on the first login into Moodle. Otherwise, set this to ''no''. Bear in mind the password they are forced to change is the one stored in your LDAP server.<br />
<br />
<u>As you don't want your users to change their passwords in their first login, leave this set to ''No''</u><br />
|-<br />
| Use standard Change Password Page<br />
|<br />
* Setting this to ''Yes'' makes Moodle use it's own standard password change page, everytime users want to change their passwords.<br />
* Setting this to ''No'' makes Moodle use the the page specified in the field called "Password change URL" (see below).<br />
<br />
Bear in mind that changing your LDAP passwords from Moodle might require a LDAPS connection (this is actually a requirement for MS-AD). In addition to that, the bind user specified above must have the rights needed to change other users' passwords.<br />
<br />
Also, code for changing passwords from Moodle for anything but Novell eDirectory and Active Directory is almost not tested, so this may or may not work for other LDAP servers.<br />
|-<br />
| Password Format<br />
| Specify how the new password is encrypted before sending it to the LDAP server: Plain text, MD5 hash or SHA-1 hash. MS-AD uses plain text, for example.<br />
|-<br />
| Password change URL<br />
| Here you can specify a location at which your users can recover or change their username/password if they've forgotten it. This will be provided to users as a button on the login page and their user page. if you leave this blank the button will not be printed.<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====LDAP password expiration settings====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Expiration<br />
| <br />
* Setting this to ''No'' will make Moodle not to check if the password of the user has expired or not.<br />
* Setting this to ''LDAP'' will make Moodle check if the LDAP password of the user has expired or not, and warn her a number of days before the password expires.<br />
<br />
Current code only deals with Novell eDirectory LDAP server and MS-AD.<br />
<br />
<u>So unless you have Novell eDirectory server or MS-AD, choose ''No'' here.</u><br />
|-<br />
| Expiration warning<br />
| This value sets how many days in advance of password expiration the user is warned that her password is about to expire.<br />
|-<br />
| Expiration attribute.<br />
| The LDAP user attribute used to check password expiration. This option takes a default value based on the ''User type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u><br />
|-<br />
| Grace logins<br />
| This setting is specific to Novell eDirectory. If set to ''Yes'', enable LDAP gracelogin support. After password has expired the user can login until gracelogin count is 0.<br />
<br />
<u>So unless you have Novell eDirectory server and want to allow gracelogin support, choose ''No'' here.</u><br />
|-<br />
| Grace login attribute<br />
| This setting is currently not used in the code (and is specific to Novell eDirectory). <br />
<br />
<u>So you don't need to fill this in.</u><br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====Enable user creation====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Create users externally<br />
| New (anonymous) users can self-create user accounts on the external LDAP server and confirm them via email. If you enable this, remember to also configure module-specific options for user creation and to fill in some instructions in ''auth_instructions'' field in Administration >> Users >> Authentication >> Manage authentication. Otherwise the new users won't be able to self-create new accounts.<br />
<br />
As of now, only Novell eDirectory and MS-AD can create users externally.<br />
|-<br />
| Context for new users<br />
| Specify the context where users are created. This context should be different from other users' contexts to prevent security issues. <br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====Course creation====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Creators<br />
| The DN of the group that contains all of your Moodle creators. This is typically a posixGroup with a "memberUid" attribute for each user you want to be a creator. If your group is called ''creators'', type '''cn=creators,ou=moodleusers,dc=my,dc=organization,dc=domain''' here. Each memberUid attribute contains the CN of a user who is authorized to be a creator. Do not use the user's full DN (e.g., not '''memberUid: cn=JoeTeacher,ou=moodleusers,dc-my,dc=organizations,dc=domain''', but rather '''memberUid: JoeTeacher''').<br />
<br />
In eDirectory, the objectClass for a group is (by default) not '''posixGroup''' but '''groupOfNames,''' whose member attribute is '''member,''' not '''memberUid,''' and whose value is the full DN of the user in question. Although you can probably modify Moodle's code to use this field, a better solution is just to add a new '''objectClass''' attribute of '''posixGroup''' to your creators group and put the CNs for each creator in a '''memberUid''' attribute.<br />
<br />
In MS Active Directory, you will need to create a security group for your creators to be part of and then add them all. If your ldap context above is 'ou=staff,dc=my,dc=org' then your group should then be 'cn=creators,ou=staff,dc=my,dc=org'. If some of the users are from other contexts and have been added to the same security group, you'll have to add these as separate contexts after the first one using the same format.<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====Cron synchronization script====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Removed ext user<br />
| Specify what to do with internal user account during mass synchronization when user was removed from external source. Only suspended users are automatically revived if they reappear in ext source.<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====NTLM SSO====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| Enable<br />
| If you want to use NTLM SSO (see details at [[NTLM_authentication]]), choose ''Yes'' here. Otherwise, choose ''No''.<br />
|-<br />
| Subnet<br />
| Specify the subnets of the clients that will use NTLM SSO (see details at [[NTLM_authentication]]).<br />
|-<br />
| MS IE Fast Path?<br />
| If all of you clients (or most of them) are using MS Internet Explorer, you can set this option to bypasses certain steps of the SSO login and speed up login times. This only works with MS Internet Explorer, but deals with other browsers in a sensible way (they are automatically sent to the plain login page).<br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
====Data Mapping====<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| First name<br />
| The name of the attribute that holds the first name of your users in your LDAP server. This is usually '''givenName''' or '''displayName'''<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Surname<br />
| The name of the attribute that holds the surname of your users in your LDAP server. This is usually '''sn'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Email address<br />
| The name of the attribute that holds the email address of your users in your LDAP server. This is usually '''mail'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| City/town<br />
| The name of the attribute that holds the city/town of your users in your LDAP server. This is usully '''l''' (lowercase L) or '''localityName''' (not valid in MS-AD).<br />
<br />
<u>This setting is optional</u> <br />
|-<br />
| Country<br />
| The name of the attribute that holds the country of your users in your LDAP server. This is usully '''c''' or '''countryName''' (not valid in MS-AD).<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Language<br />
| '''preferredLanguage'''<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Description<br />
| '''description'''<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Webpage<br />
| <u>This setting is optional</u><br />
|-<br />
| ID Number<br />
| <br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Institution<br />
| <br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Department<br />
| The name of the attribute that holds the department name of your users in your LDAP server. This is usully '''departmentNumber''' (for posixAccount and maybe eDirectory) or '''department''' (for MS-AD).<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Phone 1<br />
| The name of the attribute that holds the telephone number of your users in your LDAP server. This is usually '''telephoneNumber'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Phone 2<br />
| The name of the attribute that holds an additional telephone number of your users in your LDAP server. This can be '''homePhone''', '''mobile''', '''pager''', '''facsimileTelephoneNumber''' or even others.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Address<br />
| The name of the attribute that holds the street address of your users in your LDAP server. This is usully '''streetAddress''' or '''street'.<br />
<br />
<u>This setting is optional</u><br />
|}<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
===Setting up regular automatic synchronisation using cron===<br />
There is a script located at /auth/ldap/auth_ldap_sync_users.php which will create or suspend/delete (see the setting above) all LDAP accounts automatically. Ideally, this is called from the command line once a day during a quiet time using exactly the same procedure as the standard [[Cron|cron]] job (so you will end up with two cron entries). It is important, however, to make sure that all of the above LDAP settings are working properly before you try this, as well as backing up your database and moodledata folders. Poor LDAP configuration could lead to users being wrongly deleted.<br />
<br />
If you find that the script is not running through all of your users properly and you have MS Active Directory + over 1000 users, this is because by default, MS AD only sends back 1000 users at a time. Follow the instructions [http://support.microsoft.com/kb/315071 here] to set the MaxPageSize setting to a number higher than your total number of users (both now and in future) to fix it. This is a forest-wide setting.<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
==Active Directory help==<br />
[[Active Directory]] is Microsoft's directory service. It is included in Windows 2000 Server and later versions of their operating system. For more information about subjects below, '''[[Active Directory|please go here]]'''.<br />
<br />
*Warning: The PHP LDAP module does not seem to be present<br />
*LDAP-module cannot connect any LDAP servers <br />
*Getting correct CNs for Contexts and Creators<br />
*Getting the right user_attribute<br />
*Installing ldp.exe Server Tool<br />
*Example Active Directory Configuration<br />
*Child Domains and the Global Catalog in MS Active Directory<br />
*Enabling the Global Catalog<br />
*Active Directory with Moodle 1.8<br />
*MS Active Directory + SSL<br />
<br />
==Advanced Scenarios - Multiple servers or locations==<br />
For larger installations with multiple LDAP servers, or multiple locations (contexts) in a LDAP tree.<br />
<br />
===Using multiple LDAP Servers===<br />
Entering more than one name in the ldap_host_url field can provide some sort of resilience to your system. Simply use the syntax :<br />
ldap://my.first.server ; ldap://my.second.server ; ...<br />
<br />
Of course, this will only work if all the servers share the same directory information, using a replication or synchronization mecanism once introduced in eDirectory and now generalized to the main LDAP-compatible directories.<br />
<br />
There is one drawback in Moodle 1.5 - 1.6 implementation of LDAP authentication : the auth_ldap_connect() function processes the servers sequentially, not in a round robin mode. Thus, if the primary server fails, you will have to wait for the connection to time out before switching to the following one.<br />
<br />
<br />
See also: [http://moodle.org/mod/forum/discuss.php?d=17198 Using multiple LDAP servers - Our students are on separate domain] discussion on the Using Moodle forum.<br />
<br />
===Using multiple user locations (contexts) in your LDAP tree===<br />
There is no need to use multiple user locations if your directory tree is flat, i.e. if all user accounts reside in a '''ou=people,dc=my,dc=organization,dc=domain''' or '''ou=people,o=myorg''' container. <br />
<br />
At the opposite, if you use the ACL mecanism to delegate user management, there are chances that your users will be stored in containers like '''ou=students,ou=dept1,o=myorg''' and '''ou=students,ou=dept2,o=myorg''' ...<br />
<br />
Then there is an alternative :<br />
* Look at the '''o=myorg''' level with the ldap_search_sub attribute set to '''yes'''.<br />
* Set the ldap_context to '''ou=students,ou=dept1,o=myorg ; ou=students,ou=dept2,o=myorg'''.<br />
<br />
Choosing between these two solutions supposes some sort of benchmarking, as the result depends heavily on the structure of your directory tree '''and''' on your LDAP software indexing capabilities. Simply note that there is a probability in such deep trees that two users share the same ''common name'' (cn), while having different ''distinguished names''. Then only the second solution will have a deterministic result (returning allways the same user).<br />
<br />
===Using LDAPS (LDAP + SSL)===<br />
====Enabling LDAPS on the LDAP server side====<br />
<br />
* [[Active_Directory#MS_Active_Directory_.2B_SSL|Enabling LDAPS on MS Active Directory ]]<br />
<br />
====Enabling LDAPS on the client side (Moodle server)====<br />
<br />
* If you are running Moodle on MS Windows, you need to tell PHP's OpenLDAP extension to disable SSL server certificate checking. You must create a directory called ''C:\OpenLDAP\sysconf''. In this directory, create a file called ''ldap.conf'' with the following content (If you are using certain versions of PHP 5.3.x you may need to place the file at other locations, [http://bugs.php.net/bug.php?id=48866 see PHP bug #48866]):<br />
<br />
TLS_REQCERT never<br />
<br />
* If you are running Moodle on Linux or any other Unix-like operating system, and you want to disable SSL server certificate checking, you need to edit the OpenLDAP client configuration file (usually /etc/ldap.conf or /etc/ldap/ldap.conf or even /etc/openldap/ldap.conf) and make sure you have a line like the following one:<br />
<br />
TLS_REQCERT never<br />
<br />
Now you should be able to use '''ldaps://''' when connecting to your LDAP server.<br />
<br />
If you have the certificate of the LDAPS server as a file and want to check the certificate for the connection, copy the certificate file to an arbitary directory (e.g. /etc/ldap/certificate.pem) on your client and change the content of the ''ldap.conf'' as follows:<br />
<br />
TLS_REQCERT demand<br />
TLS_CACERT /etc/ldap/certificate.pem<br />
<br />
When the requested server certificate is bad or not provided, the connection to the LDAPS server is immediately terminated.<br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
==Appendices==<br />
===ldap auth_user_create() only suports Novell===<br />
<br />
After configuring user authentication with ldap I realized ldap only support edir (Novell) when combining ldap an email user confirmation. For example in my case (I use openldap) I have the following error after filling the user form:<br />
<br />
auth: ldap auth_user_create() does not support selected usertype:"rfc2307" (..yet)<br />
<br />
<br />
<br />
=== Setting Resource Limits RedHat Directory Server ===<br />
<br />
Operational attributes can be set for the bind user DN using the command-line. <br />
One can simply use ldapmodify to add the following attributes:<br />
<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Attribute Name <br />
! Description<br />
|-<br />
| nsLookThroughLimit<br />
| Specifies how many entries are examined for a search operation. Giving this attribute a value of -1 indicates that there is no limit.<br />
|-<br />
| nsSizeLimit <br />
| Specifies the maximum number of entries the server returns to a client application in response to a search operation. Giving this attribute a value of -1 indicates that there is no limit.<br />
|-<br />
| nsTimeLimit <br />
| Specifies the maximum time the server spends processing a search operation. Giving this attribute a value of -1 indicates that there is no time limit.<br />
|-<br />
| nsIdleTimeout <br />
| Specifies the time a connection to the server can be idle before the connection is dropped. The value is given in seconds. Giving this attribute a value of -1 indicates that there is no limit.<br />
|}<br />
<br />
<pre> LDAP Console Command-Line<br />
<br />
ldapmodify -h redhat_dir_server -p 389 -D "cn=directory manager" -w secretpwd<br />
<br />
dn: uid=MoodleAdmin,ou=system,dc=myschool,dc=edu<br />
changetype: modify<br />
add:nsSizeLimit<br />
nsSizeLimit: 1000<br />
</pre> <br />
<br />
[[LDAP_authentication#Table of Contents|Table of Contents]]<br />
<br />
==See also==<br />
<br />
* [[NTLM_authentication]]<br />
* [[Active_Directory]]<br />
* [[LDAP enrolment]]<br />
* [http://download.moodle.org/download.php/docs/en/how-to_guides/ldap_auth_and_enrolment_set-up.pdf LDAP auth and enrolment set-up guide] (PDF 227KB)<br />
<br />
Using Moodle:<br />
* [http://moodle.org/mod/forum/view.php?id=42 User authentication forum]<br />
* [http://moodle.org/mod/forum/discuss.php?d=32168 PHP LDAP module does not seem to be present] forum discussion<br />
* [http://moodle.org/mod/forum/discuss.php?d=140901 Syncronisation with AUTH_LDAP_SYNC_USERS.PHP produces fewer accounts than it should] forum discussion<br />
* [http://moodle.org/mod/forum/discuss.php?d=17198 Using multiple LDAP servers] forum discussion<br />
<br />
<br />
[[Category:Authentication]]<br />
<br />
[[es:LDAP_authentication]]<br />
[[fr:Utiliser un serveur LDAP]]<br />
[[ja:LDAP認証]]<br />
[[zh:LDAP认证]]<br />
[[de:Authentifizierung über LDAP]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Password_salting&diff=65342Password salting2009-11-18T00:30:45Z<p>Jsilve1: </p>
<hr />
<div>==What is password salting?==<br />
<br />
Passwords are stored in Moodle in an encrypted form, called an '[http://en.wikipedia.org/wiki/MD5_hash md5 hash]'.<br />
<br />
[http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Password salting] is a way of making passwords more secure by adding a random string of characters to passwords before their md5 hash is calculated, which makes them harder to reverse (the longer the random string, the harder you make it).<br />
<br />
==Enabling password salting==<br />
<br />
To enable password salting in Moodle, add the following line to your [[Configuration file|config.php file]]:<br />
<br />
$CFG->passwordsaltmain = 'some long random string here with lots of characters';<br />
<br />
The [http://dev.moodle.org/gensalt.php Moodle Salt Generator] may be used to obtain a suitable long random string.<br />
<br />
''Note'': For security reasons the only way to enable password salting is by editing config.php - there is no way to do so in the Moodle interface.<br />
<br />
==Changing the salt==<br />
<br />
If for any reason you wish to change the salt, the old salt must be retained in config.php in addition to the new salt.<br />
<br />
<code>passwordsaltmain</code> should be changed to <code>passwordsaltalt1</code> (note that the exact expressions must be used) for the old salt as follows:<br />
<br />
$CFG->passwordsaltalt1 = 'old long random string';<br />
$CFG->passwordsaltmain = 'new long random string';<br />
<br />
If you change your salt again in the future, you must retain all the previous salts for some time (until every user has logged in at least once, so they start using the new salt). You can use $CFG->passwordsaltalt2, $CFG->passwordsaltalt3, etc. to keep up to 20 previous salts.<br />
<br />
''Warning: If you change the salt and do not retain the old one in config.php you will no longer be able to login to your site!''<br />
<br />
==Disabling password salting==<br />
<br />
'''Note''': Not Recommended! Once enabled, you should leave password salt enabled.<br />
<br />
To disable password salting in Moodle, you can delete, comment out, or change the value of passwordsaltmain to "empty"<br />
<br />
// EXAMPLE: set to empty string<br />
$CFG->passwordsaltmain = <nowiki>''</nowiki>;<br />
<br />
<br />
// EXAMPLE: comment out<br />
/*<br />
$CFG->passwordsaltmain = <nowiki>''</nowiki>;<br />
*/<br />
<br />
However, you are not done! You '''must also move the old salt to an "alt" value''', just like the "changing the salt" description, above:<br />
<br />
$CFG->passwordsaltalt1 = 'old long random string';<br />
$CFG->passwordsaltmain = <nowiki>''</nowiki>;<br />
<br />
==Importing users from another site==<br />
<br />
If you import users from another Moodle site which uses a password salt, you need to add the other site's salt to config.php too. Upto 20 alternate salts may be added<br />
<br />
$CFG->passwordsaltalt1, $CFG->passwordsaltalt2, ... $CFG->passwordsaltalt20<br />
<br />
==How does password salting work?==<br />
<br />
When a password is checked, the code looks for <code>CFG->passwordsaltmain</code>. If set, it appends the user's password to the salt before calculating the md5 hash.<br />
<br />
If the unsalted md5 hash of a user's password validates, it is assumed that the salt was set for the first time since the last time the user logged in. The user's password is upgraded, using the salt.<br />
<br />
If neither the unsalted md5 hash, or the salted md5 hash validates, the code looks for up to 20 alternate salts.<br />
<br />
If you change salts, in order not to orphan existing user accounts, you must enter the old salt into one of the alternate slots.<br />
<br />
When a user who has an "old salt" password logs in, the first test of their authentication with the new salt will fail... then the code will test any alternate salts, looking for one that allows the password to be proven valid.<br />
<br />
If a user is deemed valid, the system will upgrade the user's hashed password to the latest salt.<br />
<br />
[[Category:Security]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Cron&diff=60103Cron2009-07-17T11:56:11Z<p>Jsilve1: /* Using a cron command line in Unix */</p>
<hr />
<div>Cron assists some of Moodle's modules to perform tasks on a scheduled basis. For example, the cron process might tell Moodle to check all discussion forums so it can mail out copies of new posts to people who have subscribed to that forum. <br />
<br />
The primary Moodle script that does all this is located in the admin directory, and is called cron.php. However, it can not tell itself to run, so you need to set up a mechanism where this script is run regularly (eg every five or ten minutes). This provides a "heartbeat" so that the script can perform functions at periods defined by each module. This kind of regular mechanism is known as a '''cron service'''. The service can be part of a webhost or can be something run from a different server or computer.<br />
<br />
==Overview of cron==<br />
===Script overview===<br />
<br />
The cron.php script looks through the mdl_modules table (assuming the default table prefix is mdl_) in the Moodle database for modules scheduled to have their cron functions run; it then looks in each such module directory for a function called module-name_cron in the lib.php file and runs it. It also looks through the mdl_block table for blocks scheduled for their cron methods (object functions) to be run; it then, for each such block, runs the cron method for a new object associated with that block (I'm omitting details for the benefit of non-programmers; programmers can read admin/cron.php for themselves). These files (the lib.php files and the files where the block classes are defined) can contain cleanup functions, email functions or anything that needs to be run on a regular basis. For example, cron will trigger the system to create the backups of courses at the time specified in the administration settings. It also triggers any messaging module or forum email notifications, but not all functions are called each time the cron runs. Some functions, such as unenrolling students who have not logged in or deleting old copies of log files, are only run occasionally. The cron.php file has a section which will randomly call these core tasks approximately 1 in 5 times the cron runs.<br />
<br />
===Invocation===<br />
There are now (1.9) a number of options with respect to how one can invoke cron.php. First off, one can password the invocation of cron.php via its URL. This means whether one calls the script via a browser through an application like wget or curl, or via your own code to the web daemon, the script will not run unless the password is provided, and this would be transmitted in clear text.<br />
<br />
You can also now bar invocation by URL be selecting cronclionly. This sets Moodle so that cron.php cannot be invoked by the Moodle URL. See the illustration below. (Menu: Security/Site policies)<br />
<br />
[[Image:Moodelcronadmin.png]]<br />
<br />
While this is identified as CLI (command line interface) this is a bit misleading in that it does not mean that you have to be sitting at a shell account entering the command. If you enable this switch you can invoke cron.php through any set of batch or script files you wish, but it must be invoked via its correct location in the operating systems file structure. This can be especially frustrating for those not used to scripting in that environment is not typically provided.<br />
<br />
===Cron service location and timing===<br />
Note that the machine performing the cron '''does not need to be the same machine that is running Moodle'''. For example, if you have a limited web hosting service that does not have a cron service, then you might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.<br />
<br />
The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being queued for sending.<br />
<br />
===Testing cron and manual trigger===<br />
<br />
First, test that the script works by running it directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''<br />
<br />
If cron is called from the command line by any user logged in to your Moodle it will create a temporary admin environment in order to run and then log the user out. You can disable command line running of cron by disabling the appropriate section in the cron.php file.<br />
<br />
Now, you need to set up some of way of running the script automatically and regularly.<br />
<br />
==Managing Cron on Windows systems==<br />
<br />
There are two different ways for setting-up Moodle cron.php on Windows systems:<br />
<br />
*Use the '''Moodle Cron package'''. The simplest way is to use this little package [http://download.moodle.org/download.php/windows/MoodleCron-Setup.exe MoodleCron-Setup.exe], which makes this whole thing very easy by installing a small Windows service. Run it and forget about it! :-)<br />
*Use a '''Scheduled Task'''. If you prefer to use the built-in Windows Scheduler or are having trouble with moodle-cron-for-windows package, you can use wget for windows or php from the command line and setup a scheduled task. Just follow these steps:<br />
** Choose either the '''php.exe/php-win.exe (command line binary)''' or '''wget'''<br />
::The php.exe or php-win.exe binary (for PHP version 5 or later) is installed in your php folder (e.g. c:\php) will give you better performance when running the cron script.<br />
::If you want to use wget, download a compiled version of wget for windows from the native GNU Win32 ports (http://unxutils.sourceforge.net/), from Heiko Herold's wget for windows page (http://xoomer.virgilio.it/hherold/) or Bart Puype's wget for windows page (http://users.ugent.be/~bpuype/wget/). If you use Heiko Herold's package, copy all of the .DLL files to your C:\Windows\system32 directory. Copy the wget.exe file to c:\windows (this makes sure wget is always in the search path).<br />
:* Setup a '''Scheduled Task'''. <br />
:: - Go to Start >> Control Panel >> Scheduled Tasks >> Add Scheduled Task.<br />
:: - Click "Next" to start the wizard:<br />
:: - Click in the "Browse..." button and browse to c:\php\php.exe or c:\windows\wget.exe and click "Open"<br />
:: - Type "Moodle Cron" as the name of the task and select "Daily" as the schedule. Click "Next".<br />
:: - Select "12:00 AM" as the start time, perform the task "Every Day" and choose today's date as the starting date. Click "Next".<br />
:: - Enter the username and password of the user the task will run under (it doesn't have to be a priviledged account at all). Make sure you type the password correctly. Click "Next".<br />
:: - Mark the checkbox titled "Open advanced properties for this task when I click Finish" and click "Finish".<br />
:: - In the new dialog box, type the following in the "Run:" text box: <pre>c:\windows\wget.exe -q -O NUL http://my.moodle.site/moodle/admin/cron.php</pre> or <pre>c:\php\php-win.exe -f c:\moodle\admin\cron.php</pre> Replace "c:\moodle" with the path to your moodle directory or "my.moode.site" with the name of your site.<br><br><br />
:: - Click on the "Schedule" tab and there in the "Advanced..." button.<br />
:: - Mark the "Repeat task" checkbox and set "Every:" to 5 minutes, and set "Until:" to "Duration" and type "23" hours and "59" minutes.<br />
:: - Click "OK" and you are done.<br />
* '''Test your scheduled task'''. You can test that your scheduled task can run successfully by clicking it with the right button and chosing "Run". If everything is correctly setup, you will briefly see a DOS command window while wget/php executes and fetches the cron page and then it disappears. If you refresh the scheduled tasks folder, you will see the ''Last Run Time column'' (in detailed folder view) reflects the current time, and that the Last Result column displays "0x0" (everything went OK). If either of these is different, then you should recheck your setup.<br />
* '''Logging cron output'''. You may want to log the output of the cron script as it executes, in case you see the job is producing errors, backups are not being completed or users are experiencing delays in receiving forum emails. To do this, adjust the command so that it uses the php.exe and stores the output in a file called (for example c:\moodle\admin\cron.log). Here is an example of the php.exe command:<br />
<pre>c:\php\php.exe -f c:\moodle\admin\cron.php > c:\moodle\admin\cron.log</pre><br />
<br />
==Managing cron on web hosting services==<br />
<br />
Your web-based control panel may have a web page that allows you to set up a cron service process. <br />
<br />
===CPanel cron service===<br />
If you are using CPanel, login then look for "Advanced" category towards the bottom of the page. Click on Cron Jobs -> Advanced (Unix style). Enter the following for the cron to run every 30 minutes.<br />
<br />
Email address for output: emailaddress@mydomain.con<br />
Minute:*/30<br />
Hour:*<br />
Day:*<br />
Month:*<br />
Weekday:* <br />
<nowiki>Command: wget -q -O /dev/null http://www.mydomain.com/moodle/admin/cron.php</nowiki><br />
<br />
Click Commit Changes. Check your email for the output. <br />
<br />
[[Image:Cpanel-cron-setup.JPG]]<br />
<br />
===Other systems cron service===<br />
For other systems, look for a button called "Cron jobs". In there you can put the same sort of Unix commands as listed below.<br />
<br />
<br />
If you don't have permissions to run the 'wget' command on the server, you can use this php command:<br />
<br />
/usr/local/bin/php -q /real/path/to/script/admin/cron.php<br />
<br />
For example: <br />
<br />
/usr/local/bin/php -q /home/username/public_html/moodle/admin/cron.php<br />
<br />
If you don't know what is the real path of your Moodle folder you can use the PHP command realpath.<br />
<br />
Another alternative, if you do not have permission to run the 'wget' command, may be to use a curl command.<br />
<br />
For example:<br />
<br />
curl --silent --compressed http://mydomain.com/moodle/admin/cron.php<br />
<br />
==Using a cron command line in Unix==<br />
<br />
There are different command line programs you can use to call the page from the command line. Not all of them may be available on a given server.<br />
<br />
'''Note:''' The examples with wget, lynx, and similar are '''not''' the same as the "CLI only" cron checkbox, mentioned above (the configuration variable "cronclionly"). wget, lynx, and other similar utilities are Unix command-line HTTP clients, and thus running cron.php in this way is the same as running it in a browser, from Moodle's point of view.<br />
<br />
For example, you can use a Unix utility like 'wget':<br />
<br />
wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki><br />
<br />
Note in this example that the output is thrown away (to /dev/null).<br />
<br />
A number of users of Moodle have found that 'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:<br />
<br />
php <nowiki>http://example.com/moodle/admin/cron.php</nowiki><br />
<br />
The same thing using lynx:<br />
<br />
lynx -dump <nowiki>http://example.com/moodle/admin/cron.php</nowiki> > /dev/null<br />
<br />
Note in this example that the output is thrown away (to /dev/null).<br />
<br />
Alternatively, you can use a standalone version of PHP, compiled to be run on the command line. The disadvantage is that you need to have access to a command-line version of php. The advantage is that your web server logs aren't filled with constant requests to cron.php and you can run at a lower I/O and CPU priority.<br />
<br />
/opt/bin/php /web/moodle/admin/cron.php<br />
<br />
Example command to run at lower priority:<br />
<br />
ionice -c3 -p$$;nice -n 10 /usr/bin/php /moodle/admin/cron.php > /dev/null<br />
<br />
===Using the crontab program on Unix===<br />
<br />
All that Cpanel does is provide a web interface to a Unix utility known as crontab. If you have a command line, you can set up crontab yourself using the command:<br />
<br />
crontab -e<br />
<br />
and then adding one of the above commands like:<br />
<br />
*/30 * * * * wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki><br />
<br />
The first five entries are the times to run values, followed by the command to run. The asterisk is a wildcard, indicating any time. The above example means run the command ''wget -q -O /dev/null...'' every 30 minutes (*/30), every hour (*), every day of the month (*), every month (*), every day of the week (*). <br />
<br />
The "O" of "-O" is the capital letter not zero, and refers the output file destination, in this case "/dev/null" which is a black hole and discards the output. If you want to see the output of your cron.php then enter its url in your browser. <br />
<br />
* [http://linuxweblog.com/node/24 A basic crontab tutorial] <br />
* [http://www.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html Online version of the man page] <br />
<br />
For '''beginners''', "EDITOR=nano crontab -e" will allow you to edit the crontab using the [http://www.nano-editor.org/dist/v1.2/faq.html nano] editor. Ubuntu defaults to using the nano editor.<br />
<br />
Usually, the "crontab -e" command will put you into the 'vi' editor. You enter "insert mode" by pressing "i", then type in the line as above, then exit insert mode by pressing ESC. You save and exit by typing ":wq", or quit without saving using ":q!" (without the quotes). Here is an [http://www.unix-manuals.com/tutorials/vi/vi-in-10-1.html intro] to the 'vi' editor.<br />
<br />
==See also==<br />
<br />
Using Moodle forum discussions:<br />
*[http://moodle.org/mod/forum/discuss.php?d=41827 Cron - can someone give me a quick confirmation of function?]<br />
*[http://moodle.org/mod/forum/discuss.php?d=97684 Cronjob Question]<br />
*[http://moodle.org/mod/forum/discuss.php?d=97457 Slow cron : avoiding simultaneous cron]<br />
*[http://moodle.org/mod/forum/discuss.php?d=117168 Visibility of cron.php]<br />
<br />
[[Category:Installation]]<br />
<br />
[[es:Cron]]<br />
[[fr:Cron]]<br />
[[nl:Cron]]<br />
[[sk:Cron]]<br />
[[pl:Cron]]<br />
[[ja:Cron]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Cron&diff=60102Cron2009-07-17T11:54:52Z<p>Jsilve1: /* Using a cron command line in Unix */</p>
<hr />
<div>Cron assists some of Moodle's modules to perform tasks on a scheduled basis. For example, the cron process might tell Moodle to check all discussion forums so it can mail out copies of new posts to people who have subscribed to that forum. <br />
<br />
The primary Moodle script that does all this is located in the admin directory, and is called cron.php. However, it can not tell itself to run, so you need to set up a mechanism where this script is run regularly (eg every five or ten minutes). This provides a "heartbeat" so that the script can perform functions at periods defined by each module. This kind of regular mechanism is known as a '''cron service'''. The service can be part of a webhost or can be something run from a different server or computer.<br />
<br />
==Overview of cron==<br />
===Script overview===<br />
<br />
The cron.php script looks through the mdl_modules table (assuming the default table prefix is mdl_) in the Moodle database for modules scheduled to have their cron functions run; it then looks in each such module directory for a function called module-name_cron in the lib.php file and runs it. It also looks through the mdl_block table for blocks scheduled for their cron methods (object functions) to be run; it then, for each such block, runs the cron method for a new object associated with that block (I'm omitting details for the benefit of non-programmers; programmers can read admin/cron.php for themselves). These files (the lib.php files and the files where the block classes are defined) can contain cleanup functions, email functions or anything that needs to be run on a regular basis. For example, cron will trigger the system to create the backups of courses at the time specified in the administration settings. It also triggers any messaging module or forum email notifications, but not all functions are called each time the cron runs. Some functions, such as unenrolling students who have not logged in or deleting old copies of log files, are only run occasionally. The cron.php file has a section which will randomly call these core tasks approximately 1 in 5 times the cron runs.<br />
<br />
===Invocation===<br />
There are now (1.9) a number of options with respect to how one can invoke cron.php. First off, one can password the invocation of cron.php via its URL. This means whether one calls the script via a browser through an application like wget or curl, or via your own code to the web daemon, the script will not run unless the password is provided, and this would be transmitted in clear text.<br />
<br />
You can also now bar invocation by URL be selecting cronclionly. This sets Moodle so that cron.php cannot be invoked by the Moodle URL. See the illustration below. (Menu: Security/Site policies)<br />
<br />
[[Image:Moodelcronadmin.png]]<br />
<br />
While this is identified as CLI (command line interface) this is a bit misleading in that it does not mean that you have to be sitting at a shell account entering the command. If you enable this switch you can invoke cron.php through any set of batch or script files you wish, but it must be invoked via its correct location in the operating systems file structure. This can be especially frustrating for those not used to scripting in that environment is not typically provided.<br />
<br />
===Cron service location and timing===<br />
Note that the machine performing the cron '''does not need to be the same machine that is running Moodle'''. For example, if you have a limited web hosting service that does not have a cron service, then you might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.<br />
<br />
The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being queued for sending.<br />
<br />
===Testing cron and manual trigger===<br />
<br />
First, test that the script works by running it directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''<br />
<br />
If cron is called from the command line by any user logged in to your Moodle it will create a temporary admin environment in order to run and then log the user out. You can disable command line running of cron by disabling the appropriate section in the cron.php file.<br />
<br />
Now, you need to set up some of way of running the script automatically and regularly.<br />
<br />
==Managing Cron on Windows systems==<br />
<br />
There are two different ways for setting-up Moodle cron.php on Windows systems:<br />
<br />
*Use the '''Moodle Cron package'''. The simplest way is to use this little package [http://download.moodle.org/download.php/windows/MoodleCron-Setup.exe MoodleCron-Setup.exe], which makes this whole thing very easy by installing a small Windows service. Run it and forget about it! :-)<br />
*Use a '''Scheduled Task'''. If you prefer to use the built-in Windows Scheduler or are having trouble with moodle-cron-for-windows package, you can use wget for windows or php from the command line and setup a scheduled task. Just follow these steps:<br />
** Choose either the '''php.exe/php-win.exe (command line binary)''' or '''wget'''<br />
::The php.exe or php-win.exe binary (for PHP version 5 or later) is installed in your php folder (e.g. c:\php) will give you better performance when running the cron script.<br />
::If you want to use wget, download a compiled version of wget for windows from the native GNU Win32 ports (http://unxutils.sourceforge.net/), from Heiko Herold's wget for windows page (http://xoomer.virgilio.it/hherold/) or Bart Puype's wget for windows page (http://users.ugent.be/~bpuype/wget/). If you use Heiko Herold's package, copy all of the .DLL files to your C:\Windows\system32 directory. Copy the wget.exe file to c:\windows (this makes sure wget is always in the search path).<br />
:* Setup a '''Scheduled Task'''. <br />
:: - Go to Start >> Control Panel >> Scheduled Tasks >> Add Scheduled Task.<br />
:: - Click "Next" to start the wizard:<br />
:: - Click in the "Browse..." button and browse to c:\php\php.exe or c:\windows\wget.exe and click "Open"<br />
:: - Type "Moodle Cron" as the name of the task and select "Daily" as the schedule. Click "Next".<br />
:: - Select "12:00 AM" as the start time, perform the task "Every Day" and choose today's date as the starting date. Click "Next".<br />
:: - Enter the username and password of the user the task will run under (it doesn't have to be a priviledged account at all). Make sure you type the password correctly. Click "Next".<br />
:: - Mark the checkbox titled "Open advanced properties for this task when I click Finish" and click "Finish".<br />
:: - In the new dialog box, type the following in the "Run:" text box: <pre>c:\windows\wget.exe -q -O NUL http://my.moodle.site/moodle/admin/cron.php</pre> or <pre>c:\php\php-win.exe -f c:\moodle\admin\cron.php</pre> Replace "c:\moodle" with the path to your moodle directory or "my.moode.site" with the name of your site.<br><br><br />
:: - Click on the "Schedule" tab and there in the "Advanced..." button.<br />
:: - Mark the "Repeat task" checkbox and set "Every:" to 5 minutes, and set "Until:" to "Duration" and type "23" hours and "59" minutes.<br />
:: - Click "OK" and you are done.<br />
* '''Test your scheduled task'''. You can test that your scheduled task can run successfully by clicking it with the right button and chosing "Run". If everything is correctly setup, you will briefly see a DOS command window while wget/php executes and fetches the cron page and then it disappears. If you refresh the scheduled tasks folder, you will see the ''Last Run Time column'' (in detailed folder view) reflects the current time, and that the Last Result column displays "0x0" (everything went OK). If either of these is different, then you should recheck your setup.<br />
* '''Logging cron output'''. You may want to log the output of the cron script as it executes, in case you see the job is producing errors, backups are not being completed or users are experiencing delays in receiving forum emails. To do this, adjust the command so that it uses the php.exe and stores the output in a file called (for example c:\moodle\admin\cron.log). Here is an example of the php.exe command:<br />
<pre>c:\php\php.exe -f c:\moodle\admin\cron.php > c:\moodle\admin\cron.log</pre><br />
<br />
==Managing cron on web hosting services==<br />
<br />
Your web-based control panel may have a web page that allows you to set up a cron service process. <br />
<br />
===CPanel cron service===<br />
If you are using CPanel, login then look for "Advanced" category towards the bottom of the page. Click on Cron Jobs -> Advanced (Unix style). Enter the following for the cron to run every 30 minutes.<br />
<br />
Email address for output: emailaddress@mydomain.con<br />
Minute:*/30<br />
Hour:*<br />
Day:*<br />
Month:*<br />
Weekday:* <br />
<nowiki>Command: wget -q -O /dev/null http://www.mydomain.com/moodle/admin/cron.php</nowiki><br />
<br />
Click Commit Changes. Check your email for the output. <br />
<br />
[[Image:Cpanel-cron-setup.JPG]]<br />
<br />
===Other systems cron service===<br />
For other systems, look for a button called "Cron jobs". In there you can put the same sort of Unix commands as listed below.<br />
<br />
<br />
If you don't have permissions to run the 'wget' command on the server, you can use this php command:<br />
<br />
/usr/local/bin/php -q /real/path/to/script/admin/cron.php<br />
<br />
For example: <br />
<br />
/usr/local/bin/php -q /home/username/public_html/moodle/admin/cron.php<br />
<br />
If you don't know what is the real path of your Moodle folder you can use the PHP command realpath.<br />
<br />
Another alternative, if you do not have permission to run the 'wget' command, may be to use a curl command.<br />
<br />
For example:<br />
<br />
curl --silent --compressed http://mydomain.com/moodle/admin/cron.php<br />
<br />
==Using a cron command line in Unix==<br />
<br />
There are different command line programs you can use to call the page from the command line. Not all of them may be available on a given server.<br />
<br />
'''Note:''' The examples with wget, lynx, and similar are '''not''' the same as the "CLI only" cron checkbox, mentioned above. wget, lynx, and other similar utilities are Unix command-line HTTP clients, and thus running cron.php in this way is the same as running it in a browser, from Moodle's point of view.<br />
<br />
For example, you can use a Unix utility like 'wget':<br />
<br />
wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki><br />
<br />
Note in this example that the output is thrown away (to /dev/null).<br />
<br />
A number of users of Moodle have found that 'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:<br />
<br />
php <nowiki>http://example.com/moodle/admin/cron.php</nowiki><br />
<br />
The same thing using lynx:<br />
<br />
lynx -dump <nowiki>http://example.com/moodle/admin/cron.php</nowiki> > /dev/null<br />
<br />
Note in this example that the output is thrown away (to /dev/null).<br />
<br />
Alternatively, you can use a standalone version of PHP, compiled to be run on the command line. The disadvantage is that you need to have access to a command-line version of php. The advantage is that your web server logs aren't filled with constant requests to cron.php and you can run at a lower I/O and CPU priority.<br />
<br />
/opt/bin/php /web/moodle/admin/cron.php<br />
<br />
Example command to run at lower priority:<br />
<br />
ionice -c3 -p$$;nice -n 10 /usr/bin/php /moodle/admin/cron.php > /dev/null<br />
<br />
===Using the crontab program on Unix===<br />
<br />
All that Cpanel does is provide a web interface to a Unix utility known as crontab. If you have a command line, you can set up crontab yourself using the command:<br />
<br />
crontab -e<br />
<br />
and then adding one of the above commands like:<br />
<br />
*/30 * * * * wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki><br />
<br />
The first five entries are the times to run values, followed by the command to run. The asterisk is a wildcard, indicating any time. The above example means run the command ''wget -q -O /dev/null...'' every 30 minutes (*/30), every hour (*), every day of the month (*), every month (*), every day of the week (*). <br />
<br />
The "O" of "-O" is the capital letter not zero, and refers the output file destination, in this case "/dev/null" which is a black hole and discards the output. If you want to see the output of your cron.php then enter its url in your browser. <br />
<br />
* [http://linuxweblog.com/node/24 A basic crontab tutorial] <br />
* [http://www.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html Online version of the man page] <br />
<br />
For '''beginners''', "EDITOR=nano crontab -e" will allow you to edit the crontab using the [http://www.nano-editor.org/dist/v1.2/faq.html nano] editor. Ubuntu defaults to using the nano editor.<br />
<br />
Usually, the "crontab -e" command will put you into the 'vi' editor. You enter "insert mode" by pressing "i", then type in the line as above, then exit insert mode by pressing ESC. You save and exit by typing ":wq", or quit without saving using ":q!" (without the quotes). Here is an [http://www.unix-manuals.com/tutorials/vi/vi-in-10-1.html intro] to the 'vi' editor.<br />
<br />
==See also==<br />
<br />
Using Moodle forum discussions:<br />
*[http://moodle.org/mod/forum/discuss.php?d=41827 Cron - can someone give me a quick confirmation of function?]<br />
*[http://moodle.org/mod/forum/discuss.php?d=97684 Cronjob Question]<br />
*[http://moodle.org/mod/forum/discuss.php?d=97457 Slow cron : avoiding simultaneous cron]<br />
*[http://moodle.org/mod/forum/discuss.php?d=117168 Visibility of cron.php]<br />
<br />
[[Category:Installation]]<br />
<br />
[[es:Cron]]<br />
[[fr:Cron]]<br />
[[nl:Cron]]<br />
[[sk:Cron]]<br />
[[pl:Cron]]<br />
[[ja:Cron]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development_talk:Blocks&diff=53408Development talk:Blocks2009-03-29T01:06:30Z<p>Jsilve1: /* get_config() ?? */ new section</p>
<hr />
<div>This page is for reporting errors, suggesting improvements, etc. Feel free to contribute!<br />
<br />
== "Notifications" ==<br />
<br />
At this part: "At this point our block should be capable of being automatically installed in Moodle and added to courses; visit your administration page to install it and after seeing it in action come back to continue our tutorial."<br />
<br />
This is not clear since Moodle no longer has a single administration page.<br />
<br />
More to the point would say to go to the /admin/index.php page for your Moodle install. On my latest version of Moodle 1.8 the link in the Administration block is labeled "Notifications".<br />
<br />
== Splitting up ==<br />
<br />
I split the page up into sub pages because I got an error message that the page was over 32 KB. The three appendixes are now separate pages. --[[User:Frank Ralf|Frank Ralf]] 12:16, 26 January 2009 (CST)<br />
<br />
== Increasing readability ==<br />
* Colored the code <br />
* Inserted some line breaks <br />
* Amended the appendixes --[[User:Frank Ralf|Frank Ralf]] 16:24, 6 February 2009 (CST)<br />
* Started correcting the old links (Blocks_howto) --[[User:Frank Ralf|Frank Ralf]] 16:24, 6 February 2009 (CST)<br />
<br />
== New new settings.php method ==<br />
There is a new settings.php method to do this, I don't know that much about it, so could someone who does change this page please?--[[User:Mike Worth|Mike Worth]] 05:01, 28 January 2009 (CST)<br />
<br />
== block_simplehtml ==<br />
<br />
* I had to title my first file block_simplehtml.php to get it to install. Is this always true?<br />
* For answer see [[User talk:Colin Matheson]]. --[[User:Frank Ralf|Frank Ralf]] 08:54, 1 March 2009 (CST)<br />
<br />
== get_config() ?? ==<br />
<br />
No mention of get_config() anywhere?</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development:Blocks&diff=53371Development:Blocks2009-03-27T17:12:27Z<p>Jsilve1: /* I Just Hear Static */</p>
<hr />
<div>''' A Step-by-step Guide To Creating Blocks '''<br />
<br />
Original Author: Jon Papaioannou (pj@moodle.org)<br />
<br />
The present document serves as a guide to developers who want to create their own blocks for use in Moodle. It applies to the 1.5 development version of Moodle (and any newer) '''only''', as the blocks subsystem was rewritten and expanded for the 1.5 release. However, you can also find it useful if you want to modify blocks written for Moodle 1.3 and 1.4 to work with the latest versions (look at [[Development:Blocks/Appendix_B| Appendix B]]).<br />
<br />
The guide is written as an interactive course which aims to develop a configurable, multi-purpose block that displays arbitrary HTML. It's targeted mainly at people with little experience with Moodle or programming in general and aims to show how easy it is to create new blocks for Moodle. A certain small amount of PHP programming knowledge is still required, though. <br />
<br />
Experienced developers and those who just want a reference text should refer to [[Development:Blocks/Appendix_A| Appendix A]] because the main guide has a rather low concentration of pure information in the text.<br />
<br />
== Basic Concepts ==<br />
<br />
Through this guide, we will be following the creation of an "HTML" block from scratch in order to demonstrate most of the block features at our disposal. Our block will be named "SimpleHTML". This does not constrain us regarding the name of the actual directory on the server where the files for our block will be stored, but for consistency we will follow the practice of using the lowercased form "simplehtml" in any case where such a name is required. <br />
<br />
Whenever we refer to a file or directory name which contains "simplehtml", it's important to remember that ''only'' the "simplehtml" part is up to us to change; the rest is standardized and essential for Moodle to work correctly.<br />
<br />
Whenever a file's path is mentioned in this guide, it will always start with a slash. This refers to the Moodle home directory; all files and directories will be referred to with respect to that directory.<br />
<br />
== Ready, Set, Go! ==<br />
<br />
To define a "block" in Moodle, in the most basic case we need to provide just one source code file. We start by creating the directory ''/blocks/simplehtml/'' and creating a file named ''/blocks/simplehtml/'''''block_simplehtml.php''' which will hold our code. We then begin coding the block:<br />
<br />
<code php><br />
<?php<br />
class block_simplehtml extends block_base {<br />
function init() {<br />
$this->title = get_string('simplehtml', 'block_simplehtml');<br />
$this->version = 2004111200;<br />
}<br />
// The PHP tag and the curly bracket for the class definition <br />
// will only be closed after there is another function added in the next section.<br />
</code><br />
<br />
The first line is our block class definition; it must be named exactly in the manner shown. Again, only the "simplehtml" part can (and indeed must) change; everything else is standardized.<br />
<br />
Our class is then given a small method: [[Development:Blocks/Appendix_A#init.28.29| init()]]. This is essential for all blocks, and its purpose is to set the two class member variables listed inside it. But what do these values actually mean? Here's a more detailed description.<br />
<br />
[[Development:Blocks/Appendix_A#.24this-.3Etitle| $this->title]] is the title displayed in the header of our block. We can set it to whatever we like; in this case it's set to read the actual title from a language file we are presumably distributing together with the block. I 'll skip ahead a bit here and say that if you want your block to display '''no''' title at all, then you should set this to any descriptive value you want (but '''not''' make it an empty string). We will later see [[Development:Blocks#Eye_Candy| how to disable the title's display]].<br />
<br />
[[Development:Blocks/Appendix_A#.24this-.3Eversion| $this->version]] is the version of our block. This actually would only make a difference if your block wanted to keep its own data in special tables in the database (i.e. for very complex blocks). In that case the version number is used exactly as it's used in activities; an upgrade script uses it to incrementally upgrade an "old" version of the block's data to the latest. We will outline this process further ahead, since blocks tend to be relatively simple and not hold their own private data. <br />
<br />
In our example, this is certainly the case so we just set [[Development:Blocks/Appendix_A#.24this-.3Eversion| $this->version]] to '''YYYYMMDD00''' and forget about it.<br />
<br />
'''UPDATING:'''<br /> <br />
Prior to version 1.5, the basic structure of each block class was slightly different. Refer to [[Development:Blocks/Appendix_B| Appendix B]] for more information on the changes that old blocks have to make to conform to the new standard.<br />
<br />
== I Just Hear Static ==<br />
In order to get our block to actually display something on screen, we need to add one more method to our class (before the final closing brace in our file). The new code is:<br />
<br />
<code php> <br />
function get_content() {<br />
if ($this->content !== NULL) {<br />
return $this->content;<br />
}<br />
<br />
$this->content = new stdClass;<br />
$this->content->text = 'The content of our SimpleHTML block!';<br />
$this->content->footer = 'Footer here...';<br />
<br />
return $this->content;<br />
}<br />
} // Here's the closing curly bracket for the class definition<br />
// and here's the closing PHP tag from the section above.<br />
?> </code><br />
<br />
It can't get any simpler than that, can it? Let's dissect this method to see what's going on...<br />
<br />
First of all, there is a check that returns the current value of [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]] if it's not NULL; otherwise we proceed with "computing" it. Since the computation is potentially a time-consuming operation and it '''will''' be called several times for each block (Moodle works that way internally), we take a precaution and include this time-saver.<br />
Supposing the content had not been computed before (it was NULL), we then define it from scratch. The code speaks for itself there, so there isn't much to say. Just keep in mind that we can use HTML both in the text '''and''' in the footer, if we want to.<br />
<br />
At this point our block should be capable of being automatically installed in Moodle and added to courses; visit your administration page to install it (Click "Notifications" under the Site Administration Block) and after seeing it in action come back to continue our tutorial.<br />
<br />
== Configure That Out ==<br />
<br />
The current version of our block doesn't really do much; it just displays a fixed message, which is not very useful. What we 'd really like to do is allow the teachers to customize what goes into the block. This, in block-speak, is called "instance configuration". So let's give our block some instance configuration...<br />
First of all, we need to tell Moodle that we want it to provide instance-specific configuration amenities to our block. That's as simple as adding one more method to our block class:<br />
<br />
<code php><br />
function instance_allow_config() {<br />
return true;<br />
}<br />
</code><br />
<br />
This small change is enough to make Moodle display an "Edit..." icon in our block's header when we turn editing mode on in any course. However, if you try to click on that icon you will be presented with a notice that complains about the block's configuration not being implemented correctly. Try it, it's harmless.<br />
Moodle's complaints do make sense. We told it that we want to have configuration, but we didn't say ''what'' kind of configuration we want, or how it should be displayed. To do that, we need to create one more file: <span class="filename">/blocks/simplehtml/'''config_instance.html'''</span> (which has to be named exactly like that). For the moment, copy paste the following into it and save:<br />
<br />
<code php><br />
<table cellpadding="9" cellspacing="0"><br />
<tr valign="top"><br />
<td align="right"><br />
<?php print_string('configcontent', 'block_simplehtml'); ?>:<br />
</td><br />
<td><br />
<?php print_textarea(true, 10, 50, 0, 0, 'text', $this->config->text); ?><br />
</td><br />
</tr><br />
<tr><br />
<td colspan="2" align="center"><br />
<input type="submit" value="<?php print_string('savechanges') ?>" /><br />
</td><br />
</tr><br />
</table><br />
<br />
<?php use_html_editor(); ?><br />
</code><br />
<br />
It isn't difficult to see that the above code just provides us with a wysiwyg-editor-enabled textarea to write our block's desired content in and a submit button to save. But... what's $this->config->text? Well...<br />
Moodle goes a long way to make things easier for block developers. Did you notice that the textarea is actually named "text"? When the submit button is pressed, Moodle saves each and every field it can find in our '''config_instance.html''' file as instance configuration data. <br />
<br />
We can then access that data as '''$this->config->''variablename''''', where ''variablename'' is the actual name we used for our field; in this case, "text". So in essence, the above form just pre-populates the textarea with the current content of the block (as indeed it should) and then allows us to change it.<br />
<br />
You also might be surprised by the presence of a submit button and the absence of any <form> element at the same time. But the truth is, we don't need to worry about that at all; Moodle goes a really long way to make things easier for developers! We just print the configuration options we want, in any format we want; include a submit button, and Moodle will handle all the rest itself. The instance configuration variables are automatically at our disposal to access from any of the class methods ''except'' [[Development:Blocks/Appendix_A#init.28.29| init()]].<br />
<br />
In the event where the default behavior is not satisfactory, we can still override it. However, this requires advanced modifications to our block class and will not be covered here; refer to [[Development:Blocks/Appendix_A| Appendix A]] for more details.<br />
Having now the ability to refer to this instance configuration data through [[Development:Blocks/Appendix_A#.24this-.3Econfig| $this->config]], the final twist is to tell our block to actually ''display'' what is saved in its configuration data. To do that, find this snippet in ''/blocks/simplehtml/block_simplehtml.php'':<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = 'The content of our SimpleHTML block!';<br />
$this->content->footer = 'Footer here...';<br />
</code><br />
<br />
and change it to:<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = $this->config->text;<br />
$this->content->footer = 'Footer here...';<br />
</code><br />
<br />
Oh, and since the footer isn't really exciting at this point, we remove it from our block because it doesn't contribute anything. We could just as easily have decided to make the footer configurable in the above way, too. So for our latest code, the snippet becomes:<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = $this->config->text;<br />
$this->content->footer = '';<br />
</code><br />
<br />
After this discussion, our block is ready for prime time! Indeed, if you now visit any course with a SimpleHTML block, you will see that modifying its contents is now a snap.<br />
<br />
[[#top|Back to top of page]]<br />
<br />
== The Specialists ==<br />
<br />
Implementing instance configuration for the block's contents was good enough to whet our appetite, but who wants to stop there? Why not customize the block's title, too?<br />
<br />
Why not, indeed. Well, our first attempt to achieve this is natural enough: let's add another field to <span class="filename">/blocks/simplehtml/config_instance.html</span>. Here goes:<br />
<br />
<code php><br />
<tr valign="top"><br />
<td align="right"><p><br />
<?php print_string('configtitle', 'block_simplehtml'); ?>:</p><br />
</td><br />
<td><br />
<input type="text" name="title" size="30" value="<?php echo $this->config->title; ?>" /><br />
</td><br />
</tr><br />
</code><br />
<br />
We save the edited file, go to a course, edit the title of the block and... nothing happens! The instance configuration is saved correctly, all right (editing it once more proves that) but it's not being displayed. All we get is just the simple "SimpleHTML" title.<br />
<br />
That's not too weird, if we think back a bit. Do you remember that [[Development:Blocks/Appendix_A#init.28.29|init()]] method, where we set [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]]? We didn't actually change its value from then, and [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]] is definitely not the same as '''$this->config->title''' (to Moodle, at least). What we need is a way to update [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]] with the value in the instance configuration. But as we said a bit earlier, we can use [[Development:Blocks/Appendix_A#.24this-.3Econfig| $this->config]] in all methods ''except'' [[Development:Blocks/Appendix_A#init.28.29|init()]]! So what can we do?<br />
<br />
Let's pull out another ace from our sleeve, and add this small method to our block class:<br />
<br />
<code php><br />
function specialization() {<br />
if(!empty($this->config->title)){<br />
$this->title = $this->config->title;<br />
}else{<br />
$this->config->title = 'Some title ...';<br />
}<br />
if(empty($this->config->text)){<br />
$this->config->text = 'Some text ...';<br />
} <br />
}<br />
</code><br />
<br />
Aha, here's what we wanted to do all along! But what's going on with the [[Development:Blocks/Appendix_A#specialization.28.29| specialization()]] method?<br />
<br />
This "magic" method has actually a very nice property: it's ''guaranteed'' to be automatically called by Moodle as soon as our instance configuration is loaded and available (that is, immediately after [[Development:Blocks/Appendix_A#init.28.29|init()]] is called). That means before the block's content is computed for the first time, and indeed before ''anything'' else is done with the block. Thus, providing a [[Development:Blocks/Appendix_A#specialization.28.29| specialization()]] method is the natural choice for any configuration data that needs to be acted upon "as soon as possible", as in this case.<br />
<br />
== Now You See Me, Now You Don't ==<br />
<br />
Now would be a good time to mention another nifty technique that can be used in blocks, and which comes in handy quite often. Specifically, it may be the case that our block will have something interesting to display some of the time; but in some other cases, it won't have anything useful to say. (An example here would be the "Recent Activity" block, in the case where no recent activity in fact exists. <br />
<br />
However in that case the block chooses to explicitly inform you of the lack of said activity, which is arguably useful). It would be nice, then, to be able to have our block "disappear" if it's not needed to display it.<br />
<br />
This is indeed possible, and the way to do it is to make sure that after the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method is called, the block is completely void of content. Specifically, "void of content" means that both $this->content->text and $this->content->footer are each equal to the empty string (<nowiki>''</nowiki>). Moodle performs this check by calling the block's [[Development:Blocks/Appendix_A#is_empty.28.29| is_empty()]] method, and if the block is indeed empty then it is not displayed at all.<br />
<br />
Note that the exact value of the block's title and the presence or absence of a [[Development:Blocks/Appendix_A#hide_header.28.29| hide_header()]] method do ''not'' affect this behavior. A block is considered empty if it has no content, irrespective of anything else.<br />
<br />
== We Are Legion ==<br />
<br />
Right now our block is fully configurable, both in title and content. It's so versatile, in fact, that we could make pretty much anything out of it. It would be really nice to be able to add multiple blocks of this type to a single course. And, as you might have guessed, doing that is as simple as adding another small method to our block class:<br />
<br />
<code php><br />
function instance_allow_multiple() {<br />
return true;<br />
}<br />
</code><br />
<br />
This tells Moodle that it should allow any number of instances of the SimpleHTML block in any course. After saving the changes to our file, Moodle immediately allows us to add multiple copies of the block without further ado!<br />
<br />
There are a couple more of interesting points to note here. First of all, even if a block itself allows multiple instances in the same page, the administrator still has the option of disallowing such behavior. This setting can be set separately for each block from the Administration / Configuration / Blocks page.<br />
<br />
And finally, a nice detail is that as soon as we defined an [[Development:Blocks/Appendix_A#instance_allow_multiple.28.29| instance_allow_multiple()]] method, the method [[Development:Blocks/Appendix_A#instance_allow_config.28.29| instance_allow_config()]] that was already defined became obsolete. <br />
<br />
Moodle assumes that if a block allows multiple instances of itself, those instances will want to be configured (what is the point of same multiple instances in the same page if they are identical?) and thus automatically provides an "Edit" icon. So, we can also remove the whole [[Development:Blocks/Appendix_A#instance_allow_config.28.29| instance_allow_config()]] method now without harm. We had only needed it when multiple instances of the block were not allowed.<br />
<br />
[[#top|Back to top of page]]<br />
<br />
== The Effects of Globalization ==<br />
<br />
Configuring each block instance with its own personal data is cool enough, but sometimes administrators need some way to "touch" all instances of a specific block at the same time. In the case of our SimpleHTML block, a few settings that would make sense to apply to all instances aren't that hard to come up with. <br />
<br />
For example, we might want to limit the contents of each block to only so many characters, or we might have a setting that filters HTML out of the block's contents, only allowing pure text in. Granted, such a feature wouldn't win us any awards for naming our block "SimpleHTML" but some tormented administrator somewhere might actually find it useful.<br />
<br />
This kind of configuration is called "global configuration" and applies only to a specific block type (all instances of that block type are affected, however). Implementing such configuration for our block is quite similar to implementing the instance configuration. We will now see how to implement the second example, having a setting that only allows text and not HTML in the block's contents.<br />
First of all, we need to tell Moodle that we want our block to provide global configuration by, what a surprise, adding a small method to our block class:<br />
<br />
<code php> <br />
function has_config() {<br />
return TRUE;<br />
}<br />
</code><br />
<br />
Then, we need to create a HTML file that actually prints out the configuration screen. In our case, we 'll just print out a checkbox saying "Do not allow HTML in the content" and a "submit" button. Let's create the file <span class="filename">/blocks/simplehtml/config_global.html</span> which again must be named just so, and copy paste the following into it:<br />
<br />
[[Development_talk:Blocks|TODO: New settings.php method]] <br />
: Just to note that general documentation about admin settings is at [[Development:Admin_settings#Individual_settings]]. In the absence of documentation, you can look at blocks/course_list, blocks/online_users and blocks/rss_client. They all use a settings.php file.--[[User:Tim Hunt|Tim Hunt]] 19:38, 28 January 2009 (CST)<br />
<br />
<code php><br />
<div style="text-align: center;"><br />
<input type="hidden" name="block_simplehtml_strict" value="0" /><br />
<input type="checkbox" name="block_simplehtml_strict" value="1"<br />
<?php if(!empty($CFG->block_simplehtml_strict)) <br />
echo 'checked="checked"'; ?> /><br />
<?php print_string('donotallowhtml', 'block_simplehtml'); ?><br />
<p><br />
<input type="submit" value="<?php print_string('savechanges'); ?>" /><br />
</p><br />
</div><br />
</code><br />
<br />
True to our block's name, this looks simple enough. What it does is that it displays a checkbox named "block_simplehtml_strict" and if the Moodle configuration variable with the same name (i.e., $CFG->block_simplehtml_strict) is set and not empty (that means it's not equal to an empty string, to zero, or to boolean false) it displays the box as pre-checked (reflecting the current status). <br />
<br />
Why does it check the configuration setting with the same name? Because the default implementation of the global configuration saving code takes all the variables we have in our form and saves them as Moodle configuration options with the same name. Thus, it's good practice to use a descriptive name and also one that won't possibly conflict with the name of another setting. <br />
<br />
"block_simplehtml_strict" clearly satisfies both requirements.<br />
<br />
The astute reader may have noticed that we actually have ''two'' input fields named "block_simplehtml_strict" in our configuration file. One is hidden and its value is always 0; the other is the checkbox and its value is 1. What gives? Why have them both there?<br />
<br />
Actually, this is a small trick we use to make our job as simple as possible. HTML forms work this way: if a checkbox in a form is not checked, its name does not appear at all in the variables passed to PHP when the form is submitted. That effectively means that, when we uncheck the box and click submit, the variable is not passed to PHP at all. Thus, PHP does not know to update its value to "0", and our "strict" setting cannot be turned off at all once we turn it on for the first time. Not the behavior we want, surely.<br />
<br />
However, when PHP handles received variables from a form, the variables are processed in the order in which they appear in the form. If a variable comes up having the same name with an already-processed variable, the new value overwrites the old one. Taking advantage of this, our logic runs as follows: the variable "block_simplehtml_strict" is first unconditionally set to "0". Then, ''if'' the box is checked, it is set to "1", overwriting the previous value as discussed. The net result is that our configuration setting behaves as it should.<br />
<br />
To round our bag of tricks up, notice that the use of ''if(!empty($CFG->block_simplehtml_strict))'' in the test for "should the box be checked by default?" is quite deliberate. The first time this script runs, the variable '''$CFG->block_simplehtml_strict''' will not exist at all. After it's set for the first time, its value can be either "0" or "1". Given that both "not set" and the string "0" evaluate as empty while the sting "1" does not, we manage to avoid any warnings from PHP regarding the variable not being set at all, ''and'' have a nice human-readable representation for its two possible values ("0" and "1").<br />
<br />
=== config_save() ===<br />
<br />
Now that we have managed to cram a respectable amount of tricks into a few lines of HTML, we might as well discuss the alternative in case that tricks are not enough for a specific configuration setup we have in mind. Saving the data is done in the method [[Development:Blocks/Appendix_A#config_save.28.29| config_save()]], the default implementation of which is as follows:<br />
<br />
<code php> <br />
function config_save($data) {<br />
// Default behavior: save all variables as $CFG properties<br />
foreach ($data as $name => $value) {<br />
set_config($name, $value);<br />
}<br />
return TRUE;<br />
}<br />
</code><br />
<br />
As can be clearly seen, Moodle passes this method an associative array $data which contains all the variables coming in from our configuration screen. If we wanted to do the job without the "hidden variable with the same name" trick we used above, one way to do it would be by overriding this method with the following:<br />
<br />
<code php><br />
function config_save($data) {<br />
if(isset($data['block_simplehtml_strict'])) {<br />
set_config('block_simplehtml_strict', '1');<br />
}else {<br />
set_config('block_simplehtml_strict', '0');<br />
}<br />
return TRUE;<br />
}<br />
</code><br />
<br />
Quite straightfoward: if the variable "block_simplehtml_strict" is passed to us, then it can only mean that the user has checked it, so set the configuration variable with the same name to "1". Otherwise, set it to "0". Of course, this version would need to be updated if we add more configuration options because it doesn't respond to them as the default implementation does. Still, it's useful to know how we can override the default implementation if it does not fit our needs (for example, we might not want to save the variable as part of the Moodle configuration but do something else with it).<br />
<br />
So, we are now at the point where we know if the block should allow HTML tags in its content or not. How do we get the block to actually respect that setting?<br />
<br />
We could decide to do one of two things: either have the block "clean" HTML out from the input before saving it in the instance configuration and then display it as-is (the "eager" approach); or have it save the data "as is" and then clean it up each time just before displaying it (the "lazy" approach). The eager approach involves doing work once when saving the configuration; the lazy approach means doing work each time the block is displayed and thus it promises to be worse performance-wise. We shall hence go with the eager approach.<br />
<br />
[[#top|Back to top of page]]<br />
<br />
=== instance_config_save() ===<br />
<br />
Much as we did just before with overriding [[Development:Blocks/Appendix_A#config_save.28.29| config_save()]], what is needed here is overriding the method [[Development:Blocks/Appendix_A#instance_config_save.28.29| instance_config_save()]] which handles the instance configuration. The default implementation is as follows:<br />
<br />
<code php><br />
function instance_config_save($data) {<br />
$data = stripslashes_recursive($data);<br />
$this->config = $data;<br />
return set_field('block_instance', <br />
'configdata',<br />
base64_encode(serialize($data)),<br />
'id', <br />
$this->instance->id);<br />
}<br />
</code><br />
<br />
This may look intimidating at first (what's all this stripslashes_recursive() and base64_encode() and serialize() stuff?) but do not despair; we won't have to touch any of it. We will only add some extra validation code in the beginning and then instruct Moodle to additionally call this default implementation to do the actual storing of the data. Specifically, we will add a method to our class which goes like this:<br />
<br />
<code php><br />
function instance_config_save($data) {<br />
// Clean the data if we have to<br />
global $CFG;<br />
if(!empty($CFG->block_simplehtml_strict)) {<br />
$data->text = strip_tags($data->text);<br />
}<br />
<br />
// And now forward to the default implementation defined in the parent class<br />
return parent::instance_config_save($data);<br />
}<br />
</code><br />
<br />
At last! Now the administrator has absolute power of life and death over what type of content is allowed in our "SimpleHTML" block! Absolute? Well... not exactly. In fact, if we think about it for a while, it will become apparent that if at some point in time HTML is allowed and some blocks have saved their content with HTML included, and afterwards the administrator changes the setting to "off", this will only prevent subsequent content changes from including HTML. Blocks which already had HTML in their content would continue to display it!<br />
<br />
Following that train of thought, the next stop is realizing that we wouldn't have this problem if we had chosen the lazy approach a while back, because in that case we would "sanitize" each block's content just before it was displayed. <br />
<br />
The only thing we can do with the eager approach is strip all the tags from the content of all SimpleHTML instances as soon as the admin setting is changed to "HTML off"; but even then, turning the setting back to "HTML on" won't bring back the tags we stripped away. On the other hand, the lazy approach might be slower, but it's more versatile; we can choose whether to strip or keep the HTML before displaying the content, and we won't lose it at all if the admin toggles the setting off and on again. Isn't the life of a developer simple and wonderful?<br />
<br />
=== Exercise === <br />
We will let this part of the tutorial come to a close with the obligatory exercise for the reader: <br />
In order to have the SimpleHTML block work "correctly", find out how to strengthen the eager approach to strip out all tags from the existing configuration of all instances of our block, '''or''' go back and implement the lazy approach instead. <br />
(Hint: Do that in the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method.)<br />
<br />
=== UPDATING: === <br />
Prior to version 1.5, the file ''config_global.html'' was named simply ''config.html''. Also, the methods [[Blocks_Howto#method_config_save| config_save]] and [[Blocks_Howto#method_config_print| config_print]] were named '''handle_config''' and '''print_config''' respectively. Upgrading a block to work with Moodle 1.5 involves updating these aspects; refer to [[Blocks_Howto#appendix_b| Appendix B]] for more information.<br />
<br />
== Eye Candy ==<br />
<br />
Our block is just about complete functionally, so now let's take a look at some of the tricks we can use to make its behavior customized in a few more useful ways.<br />
<br />
First of all, there are a couple of ways we can adjust the visual aspects of our block. For starters, it might be useful to create a block that doesn't display a header (title) at all. You can see this effect in action in the Course Description block that comes with Moodle. This behavior is achieved by, you guessed it, adding one more method to our block class:<br />
<br />
<code php><br />
function hide_header() {<br />
return true;<br />
}<br />
</code><br />
<br />
One more note here: we cannot just set an empty title inside the block's [[Development:Blocks/Appendix_A#init.28.29| init()]] method; it's necessary for each block to have a unique, non-empty title after [[Development:Blocks/Appendix_A#init.28.29| init()]] is called so that Moodle can use those titles to differentiate between all of the installed blocks.<br />
<br />
Another adjustment we might want to do is instruct our block to take up a certain amount of width on screen. Moodle handles this as a two-part process: first, it queries each block about its preferred width and takes the maximum number as the desired value. Then, the page that's being displayed can choose to use this value or, more probably, bring it within some specific range of values if it isn't already. That means that the width setting is a best-effort settlement; your block can ''request'' a certain width and Moodle will ''try'' to provide it, but there's no guarantee whatsoever about the end result. As a concrete example, all standard Moodle course formats will deliver any requested width between 180 and 210 pixels, inclusive.<br />
<br />
To instruct Moodle about our block's preferred width, we add one more method to the block class:<br />
<br />
<code php><br />
function preferred_width() {<br />
// The preferred value is in pixels<br />
return 200;<br />
}<br />
</code><br />
<br />
This will make our block (and all the other blocks displayed at the same side of the page) a bit wider than standard.<br />
<br />
Finally, we can also affect some properties of the actual HTML that will be used to print our block. Each block is fully contained within a &lt;table&gt; element, inside which all the HTML for that block is printed. We can instruct Moodle to add HTML attributes with specific values to that container. This would be done to either a) directly affect the end result (if we say, assign bgcolor="black"), or b) give us freedom to customize the end result using CSS (this is in fact done by default as we 'll see below).<br />
<br />
The default behavior of this feature in our case will assign to our block's container the class HTML attribute with the value "sideblock block_simplehtml" (the prefix "block_" followed by the name of our block, lowercased). We can then use that class to make CSS selectors in our theme to alter this block's visual style (for example, ".sideblock.block_simplehtml { border: 1px black solid}").<br />
<br />
To change the default behavior, we will need to define a method which returns an associative array of attribute names and values. For example, the version<br />
<br />
<code php><br />
function html_attributes() {<br />
return array(<br />
'class' => 'sideblock block_'. $this->name(),<br />
'onmouseover' => "alert('Mouseover on our block!');"<br />
);<br />
}<br />
</code><br />
<br />
will result in a mouseover event being added to our block using JavaScript, just as if we had written the onmouseover="alert(...)" part ourselves in HTML. Note that we actually duplicate the part which sets the class attribute (we want to keep that, and since we override the default behavior it's our responsibility to emulate it if required). <br />
<br />
And the final elegant touch is that we don't set the class to the hard-coded value "block_simplehtml" but instead use the [[Development:Blocks/Appendix_A#name.28.29| name()]] method to make it dynamically match our block's name.<br />
<br />
== Authorized Personnel Only ==<br />
<br />
It's not difficult to imagine a block which is very useful in some circumstances but it simply cannot be made meaningful in others. An example of this would be the "Social Activities" block which is indeed useful in a course with the social format, but doesn't do anything useful in a course with the weeks format. There should be some way of allowing the use of such blocks only where they are indeed meaningful, and not letting them confuse users if they are not.<br />
<br />
Moodle allows us to declare which course formats each block is allowed to be displayed in, and enforces these restrictions as set by the block developers at all times. The information is given to Moodle as a standard associative array, with each key corresponding to a page format and defining a boolean value (true/false) that declares whether the block should be allowed to appear in that page format.<br />
<br />
Notice the deliberate use of the term ''page'' instead of ''course'' in the above paragraph. This is because in Moodle 1.5 and onwards, blocks can be displayed in any page that supports them. The best example of such pages are the course pages, but we are not restricted to them. For instance, the quiz view page (the first one we see when we click on the name of the quiz) also supports blocks.<br />
<br />
The format names we can use for the pages derive from the name of the script which is actually used to display that page. For example, when we are looking at a course, the script is <span class="filename">/course/view.php</span> (this is evident from the browser's address line). Thus, the format name of that page is '''course-view'''. It follows easily that the format name for a quiz view page is '''mod-quiz-view'''. This rule of thumb does have a few exceptions, however:<br />
<br />
# The format name for the front page of Moodle is '''site-index'''.<br />
# The format name for courses is actually not just '''course-view'''<nowiki>; it is </nowiki>'''course-view-weeks''', '''course-view-topics''', etc.<br />
# Even though there is no such page, the format name '''all''' can be used as a catch-all option.<br />
<br />
We can include as many format names as we want in our definition of the applicable formats. Each format can be allowed or disallowed, and there are also three more rules that help resolve the question "is this block allowed into this page or not?":<br />
<br />
# Prefixes of a format name will match that format name; for example, '''mod''' will match all the activity modules. '''course-view''' will match any course, regardless of the course format. And finally, '''site''' will also match the front page (remember that its full format name is '''site-index''').<br />
# The more specialized a format name that matches our page is, the higher precedence it has when deciding if the block will be allowed. For example, '''mod''', '''mod-quiz''' and '''mod-quiz-view''' all match the quiz view page. But if all three are present, '''mod-quiz-view''' will take precedence over the other two because it is a better match.<br />
# The character '''<nowiki>*</nowiki>''' can be used in place of any word. For example, '''mod''' and '''mod-*''' are equivalent. At the time of this document's writing, there is no actual reason to utilize this "wildcard matching" feature, but it exists for future usage.<br />
# The order that the format names appear does not make any difference.<br />
All of the above are enough to make the situation sound complex, so let's look at some specific examples. First of all, to have our block appear '''only''' in the site front page, we would use:<br />
<br />
<code php> <br />
function applicable_formats() {<br />
return array('site' => true);<br />
}<br />
</code><br />
<br />
Since '''all''' is missing, the block is disallowed from appearing in ''any'' course format; but then '''site''' is set to true, so it's explicitly allowed to appear in the site front page (remember that '''site''' matches '''site-index''' because it's a prefix).<br />
<br />
For another example, if we wanted to allow the block to appear in all course formats ''except'' social, and also to ''not'' be allowed anywhere but in courses, we would use:<br />
<br />
<code php> <br />
function applicable_formats() {<br />
return array(<br />
'course-view' => true, <br />
'course-view-social' => false);<br />
}<br />
</code><br />
<br />
This time, we first allow the block to appear in all courses and then we explicitly disallow the social format.<br />
For our final, most complicated example, suppose that a block can be displayed in the site front page, in courses (but not social courses) and also when we are viewing any activity module, ''except'' quiz. This would be:<br />
<br />
<code php><br />
function applicable_formats() {<br />
return array(<br />
'site-index' => true,<br />
'course-view' => true, <br />
'course-view-social' => false,<br />
'mod' => true, <br />
'mod-quiz' => false<br />
);<br />
}<br />
</code><br />
<br />
It is not difficult to realize that the above accomplishes the objective if we remember that there is a "best match" policy to determine the end result.<br />
<br />
'''UPDATING:''' <br /><br />
Prior to version 1.5, blocks were only allowed in courses (and in Moodle 1.4, in the site front page). Also, the keywords used to describe the valid course formats at the time were slightly different and had to be changed in order to allow for a more open architecture. Refer to [[Development:Blocks/Appendix_B| Appendix B]] for more information on the changes that old blocks have to make to conform to the new standard.<br />
<br />
== Lists and Icons ==<br />
<br />
In this final part of the guide we will briefly discuss an additional capability of Moodle's block system, namely the ability to very easily create blocks that display a list of choices to the user. This list is displayed with one item per line, and an optional image (icon) next to the item. An example of such a ''list block'' is the standard Moodle "admin" block, which illustrates all the points discussed in this section.<br />
<br />
As we have seen so far, blocks use two properties of [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]]: "text" and "footer". The text is displayed as-is as the block content, and the footer is displayed below the content in a smaller font size. List blocks use $this->content->footer in the exact same way, but they ignore $this->content->text.<br />
<br />
Instead, Moodle expects such blocks to set two other properties when the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method is called: $this->content->items and $this->content->icons. $this->content->items should be a numerically indexed array containing elements that represent the HTML for each item in the list that is going to be displayed. Usually these items will be HTML anchor tags which provide links to some page. $this->content->icons should also be a numerically indexed array, with exactly as many items as $this->content->items has. Each of these items should be a fully qualified HTML <img> tag, with "src", "height", "width" and "alt" attributes. Obviously, it makes sense to keep the images small and of a uniform size.<br />
<br />
In order to tell Moodle that we want to have a list block instead of the standard text block, we need to make a small change to our block class declaration. Instead of extending class '''block_base''', our block will extend class '''block_list'''. For example:<br />
<br />
<code php> <br />
class block_my_menu extends block_list {<br />
// The init() method does not need to change at all<br />
}<br />
</code><br />
<br />
In addition to making this change, we must of course also modify the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method to construct the [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]] variable as discussed above:<br />
<br />
<code php> <br />
function get_content() {<br />
if ($this->content !== NULL) {<br />
return $this->content;<br />
}<br />
<br />
$this->content = new stdClass;<br />
$this->content->items = array();<br />
$this->content->icons = array();<br />
$this->content->footer = 'Footer here...';<br />
<br />
$this->content->items[] = '<a href="some_file.php">Menu Option 1</a>';<br />
$this->content->icons[] = '<img src="images/icons/1.gif" class="icon" alt="" />';<br />
<br />
// Add more list items here<br />
<br />
return $this->content;<br />
}<br />
</code><br />
<br />
To summarize, if we want to create a list block instead of a text block, we just need to change the block class declaration and the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method. Adding the mandatory [[Development:Blocks/Appendix_A#init.28.29| init()]] method as discussed earlier will then give us our first list block in no time!<br />
<br />
[[#top|Back to top of page]]<br />
<br />
== Appendices ==<br />
<br />
The appendices have been moved to separate pages:<br />
<br />
* Appendix A: [[Development:Blocks/Appendix A|''block_base'' Reference]] <br />
* Appendix B: [[Development:Blocks/Appendix B|Differences in the Blocks API for Moodle Versions prior to 1.5]]<br />
* Appendix C: [[Development:Blocks/Appendix C|Creating Database Tables for Blocks (prior to 1.7)]]<br />
<br />
<br />
<br />
[[Category:Developer|Blocks]]<br />
[[Category:Tutorial]]<br />
<br />
[[es:Desarrollo de bloques]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Courses_block&diff=52016Courses block2009-03-04T16:07:48Z<p>Jsilve1: </p>
<hr />
<div>[[Image:CourseBlock.jpg|frame|My Courses block]]<br />
This page refers to the block "blocks/course_list". There are other, similar, blocks in existence, such as "blocks/myCourses"<br />
<br />
The '''Courses''' block lists and allows navigation between all of the courses in which the logged in user is a participant (as tutor and/or student). The block title shows as "My courses" and allows one-click access to a course's home page. <br />
<br />
There is a also the option to list ''All courses...'' available within the Moodle site. In 1.6 this will display a list of course types and a click on one of the types will reveal all the courses in that category. There is also a search all courses option on this page.<br />
<br />
A brand new user to a Moodle site, who has not enrolled in any course, will see the block title as "Course Categories". <br />
<br />
When a student enters an unassigned course using the course block, they will be asked to enroll.<br />
<br />
==See also==<br />
<br />
*[[Courses block configuration]]<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=92190 How to make users can only see their own courses?] forum discussion<br />
<br />
[[Category:Block]]<br />
<br />
[[de:Kurse_%28Block%29]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Code_syntax_highlighting&diff=51922Code syntax highlighting2009-03-03T19:10:21Z<p>Jsilve1: /* Instructions for use */</p>
<hr />
<div>You can color or highlight code snippets within Moodle resources, forum posts etc. To do so you must install the GeSHi (Generic Syntax Highlighter) Filter. This makes the power of GeSHi available in Moodle through the use of a pair of special tags.<br />
<br />
== Installing ==<br />
<br />
You can download the GeSHi filter from here:<br />
<br />
http://geshi.org/downloads/moodle-geshi-filter-0.1.0.zip<br />
<br />
To install, unzip that archive into your filter/ directory and then enable it in the admin filter configuration screen.<br />
<br />
== Instructions for use ==<br />
<br />
WARNING: (This warning applies to Moodle 1.9.4. It may apply to other versions, but I have not tested to confirm) The GeSHI filter, while it does work, when used in conjunction with the HTML Editor, can be quirky, frustrating, and difficult to use. See my reproducible example, below.<br />
<br />
Enclose your code in spans like so:<br />
<br />
<nowiki>[code lang]your code goes here [/code]<br />
[code lang linenumbers]your code with line numbers [/code]<br />
[code lang highlight=1,2,6-9]your code with lines 1, 2 and 6<br />
to 9 highlighted "extra" [/code]<br />
[code lang linenumbers start=4]start the line numbers at "4" [/code]</nowiki><br />
<br />
=== Reproducible Example ===<br />
<br />
To achieve good results in Moodle 1.9.4+, use the following steps:<br />
<br />
# Type the GeSHI open/close tags -- "[code php][/code]" -- into the HTML editor (change "php" to another language as required)<br />
#* No quotes, just SQUAREBRACKET-c-o-d-e-SPACE-p-h-p-SQUAREBRACKET<br />
# Highlight these open/close GeSHI tags and choose "preformatted"<br />
# Copy code from textual source<br />
# Paste into HTML editor using source-HTML mode (click the "<>" button to switch modes). Paste '''in-between the [code][/code] brackets'''<br />
# Save and return to course<br />
<br />
<br />
=== Supported languages ===<br />
<br />
* asm,<br />
* bash,<br />
* cpp,<br />
* [[CSS]]<br />
* lisp<br />
* matlab<br />
* [[HTML in Moodle]]<br />
* [[PHP]]<br />
* pascal<br />
* sql<br />
* xml<br />
<br />
and many others. See the GeSHi homepage for full details.<br />
<br />
=== Options ===<br />
<br />
See the examples above. This filter is still under development so things may change.<br />
<br />
== Demo ==<br />
<br />
The filter has recently been installed on Moodle.org and can be seen in use there. For example see this post:<br />
<br />
http://moodle.org/mod/forum/discuss.php?d=25413#195644<br />
<br />
The GeSHi homepage also has an interactive demo.<br />
<br />
http://qbnz.com/highlighter/demo.php<br />
<br />
== History ==<br />
<br />
This filter used to use <nowiki><span syntax="language">...</span></nowiki> as markers for code. However this changed after conflicts with the HTMLArea editor became apparent.<br />
<br />
== Development ==<br />
<br />
At this time this filter is under development. Suggestions for new features and bug reports are welcome, please post them in the [http://moodle.org/mod/forum/discuss.php?d=43266 discussion thread].<br />
<br />
== See also ==<br />
<br />
* [http://moodle.org/mod/forum/discuss.php?d=25413 Forum post introducing the Filter]<br />
* [http://moodle.org/mod/forum/discuss.php?d=43266 Forum thread for progress reports and feedback]<br />
* [http://qbnz.com/highlighter/ GeSHi homepage]<br />
<br />
[[Category:Administrator]]<br />
[[Category:Filter]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development:Blocks&diff=51365Development:Blocks2009-02-20T16:08:54Z<p>Jsilve1: /* Ready, Set, Go! */</p>
<hr />
<div>''' A Step-by-step Guide To Creating Blocks '''<br />
<br />
Original Author: Jon Papaioannou (pj@moodle.org)<br />
<br />
The present document serves as a guide to developers who want to create their own blocks for use in Moodle. It applies to the 1.5 development version of Moodle (and any newer) '''only''', as the blocks subsystem was rewritten and expanded for the 1.5 release. However, you can also find it useful if you want to modify blocks written for Moodle 1.3 and 1.4 to work with the latest versions (look at [[Development:Blocks/Appendix_B| Appendix B]]).<br />
<br />
The guide is written as an interactive course which aims to develop a configurable, multi-purpose block that displays arbitrary HTML. It's targeted mainly at people with little experience with Moodle or programming in general and aims to show how easy it is to create new blocks for Moodle. A certain small amount of PHP programming knowledge is still required, though. <br />
<br />
Experienced developers and those who just want a reference text should refer to [[Development:Blocks/Appendix_A| Appendix A]] because the main guide has a rather low concentration of pure information in the text.<br />
<br />
== Basic Concepts ==<br />
<br />
Through this guide, we will be following the creation of an "HTML" block from scratch in order to demonstrate most of the block features at our disposal. Our block will be named "SimpleHTML". This does not constrain us regarding the name of the actual directory on the server where the files for our block will be stored, but for consistency we will follow the practice of using the lowercased form "simplehtml" in any case where such a name is required. <br />
<br />
Whenever we refer to a file or directory name which contains "simplehtml", it's important to remember that ''only'' the "simplehtml" part is up to us to change; the rest is standardized and essential for Moodle to work correctly.<br />
<br />
Whenever a file's path is mentioned in this guide, it will always start with a slash. This refers to the Moodle home directory; all files and directories will be referred to with respect to that directory.<br />
<br />
== Ready, Set, Go! ==<br />
<br />
To define a "block" in Moodle, in the most basic case we need to provide just one source code file. We start by creating the directory <span class="filename">/blocks/simplehtml/</span> and creating a file named <span class="filename">/blocks/simplehtml/block_simplehtml.php</span> which will hold our code. We then begin coding the block:<br />
<br />
<code php><br />
<?php<br />
class block_simplehtml extends block_base {<br />
function init() {<br />
$this->title = get_string('simplehtml', 'block_simplehtml');<br />
$this->version = 2004111200;<br />
}<br />
// (Why don't the curly-braces match up? This class is closed in the code below)<br />
</code><br />
<br />
The first line is our block class definition; it must be named exactly in the manner shown. Again, only the "simplehtml" part can (and indeed must) change; everything else is standardized.<br />
<br />
Our class is then given a small method: [[Development:Blocks/Appendix_A#init.28.29| init()]]. This is essential for all blocks, and its purpose is to set the two class member variables listed inside it. But what do these values actually mean? Here's a more detailed description.<br />
<br />
[[Development:Blocks/Appendix_A#.24this-.3Etitle| $this->title]] is the title displayed in the header of our block. We can set it to whatever we like; in this case it's set to read the actual title from a language file we are presumably distributing together with the block. I 'll skip ahead a bit here and say that if you want your block to display '''no''' title at all, then you should set this to any descriptive value you want (but '''not''' make it an empty string). We will later see [[Development:Blocks#Eye_Candy| how to disable the title's display]].<br />
<br />
[[Development:Blocks/Appendix_A#.24this-.3Eversion| $this->version]] is the version of our block. This actually would only make a difference if your block wanted to keep its own data in special tables in the database (i.e. for very complex blocks). In that case the version number is used exactly as it's used in activities; an upgrade script uses it to incrementally upgrade an "old" version of the block's data to the latest. We will outline this process further ahead, since blocks tend to be relatively simple and not hold their own private data. <br />
<br />
In our example, this is certainly the case so we just set [[Development:Blocks/Appendix_A#.24this-.3Eversion| $this->version]] to '''YYYYMMDD00''' and forget about it.<br />
<br />
'''UPDATING:'''<br /> <br />
Prior to version 1.5, the basic structure of each block class was slightly different. Refer to [[Development:Blocks/Appendix_B| Appendix B]] for more information on the changes that old blocks have to make to conform to the new standard.<br />
<br />
== I Just Hear Static ==<br />
In order to get our block to actually display something on screen, we need to add one more method to our class (before the final closing brace in our file). The new code is:<br />
<br />
<code php><br />
function get_content() {<br />
if ($this->content !== NULL) {<br />
return $this->content;<br />
}<br />
<br />
$this->content = new stdClass;<br />
$this->content->text = 'The content of our SimpleHTML block!';<br />
$this->content->footer = 'Footer here...';<br />
<br />
return $this->content;<br />
}<br />
}<br />
?><br />
</code><br />
<br />
It can't get any simpler than that, can it? Let's dissect this method to see what's going on...<br />
<br />
First of all, there is a check that returns the current value of [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]] if it's not NULL; otherwise we proceed with "computing" it. Since the computation is potentially a time-consuming operation and it '''will''' be called several times for each block (Moodle works that way internally), we take a precaution and include this time-saver.<br />
Supposing the content had not been computed before (it was NULL), we then define it from scratch. The code speaks for itself there, so there isn't much to say. Just keep in mind that we can use HTML both in the text '''and''' in the footer, if we want to.<br />
<br />
At this point our block should be capable of being automatically installed in Moodle and added to courses; visit your administration page to install it and after seeing it in action come back to continue our tutorial.<br />
<br />
== Configure That Out ==<br />
<br />
The current version of our block doesn't really do much; it just displays a fixed message, which is not very useful. What we 'd really like to do is allow the teachers to customize what goes into the block. This, in block-speak, is called "instance configuration". So let's give our block some instance configuration...<br />
First of all, we need to tell Moodle that we want it to provide instance-specific configuration amenities to our block. That's as simple as adding one more method to our block class:<br />
<br />
<code php><br />
function instance_allow_config() {<br />
return true;<br />
}<br />
</code><br />
<br />
This small change is enough to make Moodle display an "Edit..." icon in our block's header when we turn editing mode on in any course. However, if you try to click on that icon you will be presented with a notice that complains about the block's configuration not being implemented correctly. Try it, it's harmless.<br />
Moodle's complaints do make sense. We told it that we want to have configuration, but we didn't say ''what'' kind of configuration we want, or how it should be displayed. To do that, we need to create one more file: <span class="filename">/blocks/simplehtml/'''config_instance.html'''</span> (which has to be named exactly like that). For the moment, copy paste the following into it and save:<br />
<br />
<code php><br />
<table cellpadding="9" cellspacing="0"><br />
<tr valign="top"><br />
<td align="right"><br />
<?php print_string('configcontent', 'block_simplehtml'); ?>:<br />
</td><br />
<td><br />
<?php print_textarea(true, 10, 50, 0, 0, 'text', $this->config->text); ?><br />
</td><br />
</tr><br />
<tr><br />
<td colspan="2" align="center"><br />
<input type="submit" value="<?php print_string('savechanges') ?>" /><br />
</td><br />
</tr><br />
</table><br />
<br />
<?php use_html_editor(); ?><br />
</code><br />
<br />
It isn't difficult to see that the above code just provides us with a wysiwyg-editor-enabled textarea to write our block's desired content in and a submit button to save. But... what's $this->config->text? Well...<br />
Moodle goes a long way to make things easier for block developers. Did you notice that the textarea is actually named "text"? When the submit button is pressed, Moodle saves each and every field it can find in our '''config_instance.html''' file as instance configuration data. <br />
<br />
We can then access that data as '''$this->config->''variablename''''', where ''variablename'' is the actual name we used for our field; in this case, "text". So in essence, the above form just pre-populates the textarea with the current content of the block (as indeed it should) and then allows us to change it.<br />
<br />
You also might be surprised by the presence of a submit button and the absence of any <form> element at the same time. But the truth is, we don't need to worry about that at all; Moodle goes a really long way to make things easier for developers! We just print the configuration options we want, in any format we want; include a submit button, and Moodle will handle all the rest itself. The instance configuration variables are automatically at our disposal to access from any of the class methods ''except'' [[Development:Blocks/Appendix_A#init.28.29| init()]].<br />
<br />
In the event where the default behavior is not satisfactory, we can still override it. However, this requires advanced modifications to our block class and will not be covered here; refer to [[Development:Blocks/Appendix_A| Appendix A]] for more details.<br />
Having now the ability to refer to this instance configuration data through [[Development:Blocks/Appendix_A#.24this-.3Econfig| $this->config]], the final twist is to tell our block to actually ''display'' what is saved in its configuration data. To do that, find this snippet in ''/blocks/simplehtml/block_simplehtml.php'':<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = 'The content of our SimpleHTML block!';<br />
$this->content->footer = 'Footer here...';<br />
</code><br />
<br />
and change it to:<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = $this->config->text;<br />
$this->content->footer = 'Footer here...';<br />
</code><br />
<br />
Oh, and since the footer isn't really exciting at this point, we remove it from our block because it doesn't contribute anything. We could just as easily have decided to make the footer configurable in the above way, too. So for our latest code, the snippet becomes:<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = $this->config->text;<br />
$this->content->footer = '';<br />
</code><br />
<br />
After this discussion, our block is ready for prime time! Indeed, if you now visit any course with a SimpleHTML block, you will see that modifying its contents is now a snap.<br />
<br />
== The Specialists ==<br />
<br />
Implementing instance configuration for the block's contents was good enough to whet our appetite, but who wants to stop there? Why not customize the block's title, too?<br />
<br />
Why not, indeed. Well, our first attempt to achieve this is natural enough: let's add another field to <span class="filename">/blocks/simplehtml/config_instance.html</span>. Here goes:<br />
<br />
<code php><br />
<tr valign="top"><br />
<td align="right"><p><br />
<?php print_string('configtitle', 'block_simplehtml'); ?>:</p><br />
</td><br />
<td><br />
<input type="text" name="title" size="30" value="<?php echo $this->config->title; ?>" /><br />
</td><br />
</tr><br />
</code><br />
<br />
We save the edited file, go to a course, edit the title of the block and... nothing happens! The instance configuration is saved correctly, all right (editing it once more proves that) but it's not being displayed. All we get is just the simple "SimpleHTML" title.<br />
<br />
That's not too weired, if we think back a bit. Do you remember that [[Development:Blocks/Appendix_A#init.28.29|init()]] method, where we set [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]]? We didn't actually change its value from then, and [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]] is definitely not the same as '''$this->config->title''' (to Moodle, at least). What we need is a way to update [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]] with the value in the instance configuration. But as we said a bit earlier, we can use [[Development:Blocks/Appendix_A#.24this-.3Econfig| $this->config]] in all methods ''except'' [[Development:Blocks/Appendix_A#init.28.29|init()]]! So what can we do?<br />
<br />
Let's pull out another ace from our sleeve, and add this small method to our block class:<br />
<br />
<code php><br />
function specialization() {<br />
if(!empty($this->config->title)){<br />
$this->title = $this->config->title;<br />
}else{<br />
$this->config->title = 'Some title ...';<br />
}<br />
if(empty($this->config->text)){<br />
$this->config->text = 'Some text ...';<br />
} <br />
}<br />
</code><br />
<br />
Aha, here's what we wanted to do all along! But what's going on with the [[Development:Blocks/Appendix_A#specialization.28.29| specialization()]] method?<br />
<br />
This "magic" method has actually a very nice property: it's ''guaranteed'' to be automatically called by Moodle as soon as our instance configuration is loaded and available (that is, immediately after [[Development:Blocks/Appendix_A#init.28.29|init()]] is called). That means before the block's content is computed for the first time, and indeed before ''anything'' else is done with the block. Thus, providing a [[Development:Blocks/Appendix_A#specialization.28.29| specialization()]] method is the natural choice for any configuration data that needs to be acted upon "as soon as possible", as in this case.<br />
<br />
== Now You See Me, Now You Don't ==<br />
<br />
Now would be a good time to mention another nifty technique that can be used in blocks, and which comes in handy quite often. Specifically, it may be the case that our block will have something interesting to display some of the time; but in some other cases, it won't have anything useful to say. (An example here would be the "Recent Activity" block, in the case where no recent activity in fact exists. <br />
<br />
However in that case the block chooses to explicitly inform you of the lack of said activity, which is arguably useful). It would be nice, then, to be able to have our block "disappear" if it's not needed to display it.<br />
<br />
This is indeed possible, and the way to do it is to make sure that after the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method is called, the block is completely void of content. Specifically, "void of content" means that both $this->content->text and $this->content->footer are each equal to the empty string (<nowiki>''</nowiki>). Moodle performs this check by calling the block's [[Development:Blocks/Appendix_A#is_empty.28.29| is_empty()]] method, and if the block is indeed empty then it is not displayed at all.<br />
<br />
Note that the exact value of the block's title and the presence or absence of a [[Development:Blocks/Appendix_A#hide_header.28.29| hide_header()]] method do ''not'' affect this behavior. A block is considered empty if it has no content, irrespective of anything else.<br />
<br />
== We Are Legion ==<br />
<br />
Right now our block is fully configurable, both in title and content. It's so versatile, in fact, that we could make pretty much anything out of it. It would be really nice to be able to add multiple blocks of this type to a single course. And, as you might have guessed, doing that is as simple as adding another small method to our block class:<br />
<br />
<code php><br />
function instance_allow_multiple() {<br />
return true;<br />
}<br />
</code><br />
<br />
This tells Moodle that it should allow any number of instances of the SimpleHTML block in any course. After saving the changes to our file, Moodle immediately allows us to add multiple copies of the block without further ado!<br />
<br />
There are a couple more of interesting points to note here. First of all, even if a block itself allows multiple instances in the same page, the administrator still has the option of disallowing such behavior. This setting can be set separately for each block from the Administration / Configuration / Blocks page.<br />
<br />
And finally, a nice detail is that as soon as we defined an [[Development:Blocks/Appendix_A#instance_allow_multiple.28.29| instance_allow_multiple()]] method, the method [[Development:Blocks/Appendix_A#instance_allow_config.28.29| instance_allow_config()]] that was already defined became obsolete. <br />
<br />
Moodle assumes that if a block allows multiple instances of itself, those instances will want to be configured (what is the point of same multiple instances in the same page if they are identical?) and thus automatically provides an "Edit" icon. So, we can also remove the whole [[Development:Blocks/Appendix_A#instance_allow_config.28.29| instance_allow_config()]] method now without harm. We had only needed it when multiple instances of the block were not allowed.<br />
<br />
== The Effects of Globalization ==<br />
<br />
Configuring each block instance with its own personal data is cool enough, but sometimes administrators need some way to "touch" all instances of a specific block at the same time. In the case of our SimpleHTML block, a few settings that would make sense to apply to all instances aren't that hard to come up with. <br />
<br />
For example, we might want to limit the contents of each block to only so many characters, or we might have a setting that filters HTML out of the block's contents, only allowing pure text in. Granted, such a feature wouldn't win us any awards for naming our block "SimpleHTML" but some tormented administrator somewhere might actually find it useful.<br />
<br />
This kind of configuration is called "global configuration" and applies only to a specific block type (all instances of that block type are affected, however). Implementing such configuration for our block is quite similar to implementing the instance configuration. We will now see how to implement the second example, having a setting that only allows text and not HTML in the block's contents.<br />
First of all, we need to tell Moodle that we want our block to provide global configuration by, what a surprise, adding a small method to our block class:<br />
<br />
<code php> <br />
function has_config() {<br />
return TRUE;<br />
}<br />
</code><br />
<br />
Then, we need to create a HTML file that actually prints out the configuration screen. In our case, we 'll just print out a checkbox saying "Do not allow HTML in the content" and a "submit" button. Let's create the file <span class="filename">/blocks/simplehtml/config_global.html</span> which again must be named just so, and copy paste the following into it:<br />
<br />
[[Development_talk:Blocks|TODO: New settings.php method]] <br />
: Just to note that general documentation about admin settings is at [[Development:Admin_settings#Individual_settings]]. In the absence of documentation, you can look at blocks/course_list, blocks/online_users and blocks/rss_client. They all use a settings.php file.--[[User:Tim Hunt|Tim Hunt]] 19:38, 28 January 2009 (CST)<br />
<br />
<code php><br />
<div style="text-align: center;"><br />
<input type="hidden" name="block_simplehtml_strict" value="0" /><br />
<input type="checkbox" name="block_simplehtml_strict" value="1"<br />
<?php if(!empty($CFG->block_simplehtml_strict)) <br />
echo 'checked="checked"'; ?> /><br />
<?php print_string('donotallowhtml', 'block_simplehtml'); ?><br />
<p><br />
<input type="submit" value="<?php print_string('savechanges'); ?>" /><br />
</p><br />
</div><br />
</code><br />
<br />
True to our block's name, this looks simple enough. What it does is that it displays a checkbox named "block_simplehtml_strict" and if the Moodle configuration variable with the same name (i.e., $CFG->block_simplehtml_strict) is set and not empty (that means it's not equal to an empty string, to zero, or to boolean false) it displays the box as pre-checked (reflecting the current status). <br />
<br />
Why does it check the configuration setting with the same name? Because the default implementation of the global configuration saving code takes all the variables we have in our form and saves them as Moodle configuration options with the same name. Thus, it's good practice to use a descriptive name and also one that won't possibly conflict with the name of another setting. <br />
<br />
"block_simplehtml_strict" clearly satisfies both requirements.<br />
<br />
The astute reader may have noticed that we actually have ''two'' input fields named "block_simplehtml_strict" in our configuration file. One is hidden and its value is always 0; the other is the checkbox and its value is 1. What gives? Why have them both there?<br />
<br />
Actually, this is a small trick we use to make our job as simple as possible. HTML forms work this way: if a checkbox in a form is not checked, its name does not appear at all in the variables passed to PHP when the form is submitted. That effectively means that, when we uncheck the box and click submit, the variable is not passed to PHP at all. Thus, PHP does not know to update its value to "0", and our "strict" setting cannot be turned off at all once we turn it on for the first time. Not the behavior we want, surely.<br />
<br />
However, when PHP handles received variables from a form, the variables are processed in the order in which they appear in the form. If a variable comes up having the same name with an already-processed variable, the new value overwrites the old one. Taking advantage of this, our logic runs as follows: the variable "block_simplehtml_strict" is first unconditionally set to "0". Then, ''if'' the box is checked, it is set to "1", overwriting the previous value as discussed. The net result is that our configuration setting behaves as it should.<br />
<br />
To round our bag of tricks up, notice that the use of ''if(!empty($CFG->block_simplehtml_strict))'' in the test for "should the box be checked by default?" is quite deliberate. The first time this script runs, the variable '''$CFG->block_simplehtml_strict''' will not exist at all. After it's set for the first time, its value can be either "0" or "1". Given that both "not set" and the string "0" evaluate as empty while the sting "1" does not, we manage to avoid any warnings from PHP regarding the variable not being set at all, ''and'' have a nice human-readable representation for its two possible values ("0" and "1").<br />
<br />
=== config_save() ===<br />
<br />
Now that we have managed to cram a respectable amount of tricks into a few lines of HTML, we might as well discuss the alternative in case that tricks are not enough for a specific configuration setup we have in mind. Saving the data is done in the method [[Development:Blocks/Appendix_A#config_save.28.29| config_save()]], the default implementation of which is as follows:<br />
<br />
<code php> <br />
function config_save($data) {<br />
// Default behavior: save all variables as $CFG properties<br />
foreach ($data as $name => $value) {<br />
set_config($name, $value);<br />
}<br />
return TRUE;<br />
}<br />
</code><br />
<br />
As can be clearly seen, Moodle passes this method an associative array $data which contains all the variables coming in from our configuration screen. If we wanted to do the job without the "hidden variable with the same name" trick we used above, one way to do it would be by overriding this method with the following:<br />
<br />
<code php><br />
function config_save($data) {<br />
if(isset($data['block_simplehtml_strict'])) {<br />
set_config('block_simplehtml_strict', '1');<br />
}else {<br />
set_config('block_simplehtml_strict', '0');<br />
}<br />
return TRUE;<br />
}<br />
</code><br />
<br />
Quite straightfoward: if the variable "block_simplehtml_strict" is passed to us, then it can only mean that the user has checked it, so set the configuration variable with the same name to "1". Otherwise, set it to "0". Of course, this version would need to be updated if we add more configuration options because it doesn't respond to them as the default implementation does. Still, it's useful to know how we can override the default implementation if it does not fit our needs (for example, we might not want to save the variable as part of the Moodle configuration but do something else with it).<br />
<br />
So, we are now at the point where we know if the block should allow HTML tags in its content or not. How do we get the block to actually respect that setting?<br />
<br />
We could decide to do one of two things: either have the block "clean" HTML out from the input before saving it in the instance configuration and then display it as-is (the "eager" approach); or have it save the data "as is" and then clean it up each time just before displaying it (the "lazy" approach). The eager approach involves doing work once when saving the configuration; the lazy approach means doing work each time the block is displayed and thus it promises to be worse performance-wise. We shall hence go with the eager approach.<br />
<br />
=== instance_config_save() ===<br />
<br />
Much as we did just before with overriding [[Development:Blocks/Appendix_A#config_save.28.29| config_save()]], what is needed here is overriding the method [[Development:Blocks/Appendix_A#instance_config_save.28.29| instance_config_save()]] which handles the instance configuration. The default implementation is as follows:<br />
<br />
<code php><br />
function instance_config_save($data) {<br />
$data = stripslashes_recursive($data);<br />
$this->config = $data;<br />
return set_field('block_instance', <br />
'configdata',<br />
base64_encode(serialize($data)),<br />
'id', <br />
$this->instance->id);<br />
}<br />
</code><br />
<br />
This may look intimidating at first (what's all this stripslashes_recursive() and base64_encode() and serialize() stuff?) but do not despair; we won't have to touch any of it. We will only add some extra validation code in the beginning and then instruct Moodle to additionally call this default implementation to do the actual storing of the data. Specifically, we will add a method to our class which goes like this:<br />
<br />
<code php><br />
function instance_config_save($data) {<br />
// Clean the data if we have to<br />
global $CFG;<br />
if(!empty($CFG->block_simplehtml_strict)) {<br />
$data->text = strip_tags($data->text);<br />
}<br />
<br />
// And now forward to the default implementation defined in the parent class<br />
return parent::instance_config_save($data);<br />
}<br />
</code><br />
<br />
At last! Now the administrator has absolute power of life and death over what type of content is allowed in our "SimpleHTML" block! Absolute? Well... not exactly. In fact, if we think about it for a while, it will become apparent that if at some point in time HTML is allowed and some blocks have saved their content with HTML included, and afterwards the administrator changes the setting to "off", this will only prevent subsequent content changes from including HTML. Blocks which already had HTML in their content would continue to display it!<br />
<br />
Following that train of thought, the next stop is realizing that we wouldn't have this problem if we had chosen the lazy approach a while back, because in that case we would "sanitize" each block's content just before it was displayed. <br />
<br />
The only thing we can do with the eager approach is strip all the tags from the content of all SimpleHTML instances as soon as the admin setting is changed to "HTML off"; but even then, turning the setting back to "HTML on" won't bring back the tags we stripped away. On the other hand, the lazy approach might be slower, but it's more versatile; we can choose whether to strip or keep the HTML before displaying the content, and we won't lose it at all if the admin toggles the setting off and on again. Isn't the life of a developer simple and wonderful?<br />
<br />
=== Exercise === <br />
We will let this part of the tutorial come to a close with the obligatory exercise for the reader: <br />
In order to have the SimpleHTML block work "correctly", find out how to strengthen the eager approach to strip out all tags from the existing configuration of all instances of our block, '''or''' go back and implement the lazy approach instead. <br />
(Hint: Do that in the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method.)<br />
<br />
=== UPDATING: === <br />
Prior to version 1.5, the file </nowiki><span class="filename">config_global.html</span> was named simply <span class="filename">config.html</span>. Also, the methods [[Blocks_Howto#method_config_save| config_save]] and [[Blocks_Howto#method_config_print| config_print]] were named '''handle_config''' and '''print_config''' respectively. Upgrading a block to work with Moodle 1.5 involves updating these aspects; refer to [[Blocks_Howto#appendix_b| Appendix B]] for more information.<br />
<br />
== Eye Candy ==<br />
<br />
Our block is just about complete functionally, so now let's take a look at some of the tricks we can use to make its behavior customized in a few more useful ways.<br />
<br />
First of all, there are a couple of ways we can adjust the visual aspects of our block. For starters, it might be useful to create a block that doesn't display a header (title) at all. You can see this effect in action in the Course Description block that comes with Moodle. This behavior is achieved by, you guessed it, adding one more method to our block class:<br />
<br />
<code php><br />
function hide_header() {<br />
return true;<br />
}<br />
</code><br />
<br />
One more note here: we cannot just set an empty title inside the block's [[Development:Blocks/Appendix_A#init.28.29| init()]] method; it's necessary for each block to have a unique, non-empty title after [[Development:Blocks/Appendix_A#init.28.29| init()]] is called so that Moodle can use those titles to differentiate between all of the installed blocks.<br />
<br />
Another adjustment we might want to do is instruct our block to take up a certain amount of width on screen. Moodle handles this as a two-part process: first, it queries each block about its preferred width and takes the maximum number as the desired value. Then, the page that's being displayed can choose to use this value or, more probably, bring it within some specific range of values if it isn't already. That means that the width setting is a best-effort settlement; your block can ''request'' a certain width and Moodle will ''try'' to provide it, but there's no guarantee whatsoever about the end result. As a concrete example, all standard Moodle course formats will deliver any requested width between 180 and 210 pixels, inclusive.<br />
<br />
To instruct Moodle about our block's preferred width, we add one more method to the block class:<br />
<br />
<code php><br />
function preferred_width() {<br />
// The preferred value is in pixels<br />
return 200;<br />
}<br />
</code><br />
<br />
This will make our block (and all the other blocks displayed at the same side of the page) a bit wider than standard.<br />
<br />
Finally, we can also affect some properties of the actual HTML that will be used to print our block. Each block is fully contained within a &lt;table&gt; element, inside which all the HTML for that block is printed. We can instruct Moodle to add HTML attributes with specific values to that container. This would be done to either a) directly affect the end result (if we say, assign bgcolor="black"), or b) give us freedom to customize the end result using CSS (this is in fact done by default as we 'll see below).<br />
<br />
The default behavior of this feature in our case will assign to our block's container the class HTML attribute with the value "sideblock block_simplehtml" (the prefix "block_" followed by the name of our block, lowercased). We can then use that class to make CSS selectors in our theme to alter this block's visual style (for example, ".sideblock.block_simplehtml { border: 1px black solid}").<br />
<br />
To change the default behavior, we will need to define a method which returns an associative array of attribute names and values. For example, the version<br />
<br />
<code php><br />
function html_attributes() {<br />
return array(<br />
'class' => 'sideblock block_'. $this->name(),<br />
'onmouseover' => "alert('Mouseover on our block!');"<br />
);<br />
}<br />
</code><br />
<br />
will result in a mouseover event being added to our block using JavaScript, just as if we had written the onmouseover="alert(...)" part ourselves in HTML. Note that we actually duplicate the part which sets the class attribute (we want to keep that, and since we override the default behavior it's our responsibility to emulate it if required). <br />
<br />
And the final elegant touch is that we don't set the class to the hard-coded value "block_simplehtml" but instead use the [[Development:Blocks/Appendix_A#name.28.29| name()]] method to make it dynamically match our block's name.<br />
<br />
== Authorized Personnel Only ==<br />
<br />
It's not difficult to imagine a block which is very useful in some circumstances but it simply cannot be made meaningful in others. An example of this would be the "Social Activities" block which is indeed useful in a course with the social format, but doesn't do anything useful in a course with the weeks format. There should be some way of allowing the use of such blocks only where they are indeed meaningful, and not letting them confuse users if they are not.<br />
<br />
Moodle allows us to declare which course formats each block is allowed to be displayed in, and enforces these restrictions as set by the block developers at all times. The information is given to Moodle as a standard associative array, with each key corresponding to a page format and defining a boolean value (true/false) that declares whether the block should be allowed to appear in that page format.<br />
<br />
Notice the deliberate use of the term ''page'' instead of ''course'' in the above paragraph. This is because in Moodle 1.5 and onwards, blocks can be displayed in any page that supports them. The best example of such pages are the course pages, but we are not restricted to them. For instance, the quiz view page (the first one we see when we click on the name of the quiz) also supports blocks.<br />
<br />
The format names we can use for the pages derive from the name of the script which is actually used to display that page. For example, when we are looking at a course, the script is <span class="filename">/course/view.php</span> (this is evident from the browser's address line). Thus, the format name of that page is '''course-view'''. It follows easily that the format name for a quiz view page is '''mod-quiz-view'''. This rule of thumb does have a few exceptions, however:<br />
<br />
# The format name for the front page of Moodle is '''site-index'''.<br />
# The format name for courses is actually not just '''course-view'''<nowiki>; it is </nowiki>'''course-view-weeks''', '''course-view-topics''', etc.<br />
# Even though there is no such page, the format name '''all''' can be used as a catch-all option.<br />
<br />
We can include as many format names as we want in our definition of the applicable formats. Each format can be allowed or disallowed, and there are also three more rules that help resolve the question "is this block allowed into this page or not?":<br />
<br />
# Prefixes of a format name will match that format name; for example, '''mod''' will match all the activity modules. '''course-view''' will match any course, regardless of the course format. And finally, '''site''' will also match the front page (remember that its full format name is '''site-index''').<br />
# The more specialized a format name that matches our page is, the higher precedence it has when deciding if the block will be allowed. For example, '''mod''', '''mod-quiz''' and '''mod-quiz-view''' all match the quiz view page. But if all three are present, '''mod-quiz-view''' will take precedence over the other two because it is a better match.<br />
# The character '''<nowiki>*</nowiki>''' can be used in place of any word. For example, '''mod''' and '''mod-*''' are equivalent. At the time of this document's writing, there is no actual reason to utilize this "wildcard matching" feature, but it exists for future usage.<br />
# The order that the format names appear does not make any difference.<br />
All of the above are enough to make the situation sound complex, so let's look at some specific examples. First of all, to have our block appear '''only''' in the site front page, we would use:<br />
<br />
<code php> <br />
function applicable_formats() {<br />
return array('site' => true);<br />
}<br />
</code><br />
<br />
Since '''all''' is missing, the block is disallowed from appearing in ''any'' course format; but then '''site''' is set to true, so it's explicitly allowed to appear in the site front page (remember that '''site''' matches '''site-index''' because it's a prefix).<br />
<br />
For another example, if we wanted to allow the block to appear in all course formats ''except'' social, and also to ''not'' be allowed anywhere but in courses, we would use:<br />
<br />
<code php> <br />
function applicable_formats() {<br />
return array(<br />
'course-view' => true, <br />
'course-view-social' => false);<br />
}<br />
</code><br />
<br />
This time, we first allow the block to appear in all courses and then we explicitly disallow the social format.<br />
For our final, most complicated example, suppose that a block can be displayed in the site front page, in courses (but not social courses) and also when we are viewing any activity module, ''except'' quiz. This would be:<br />
<br />
<code php><br />
function applicable_formats() {<br />
return array(<br />
'site-index' => true,<br />
'course-view' => true, <br />
'course-view-social' => false,<br />
'mod' => true, <br />
'mod-quiz' => false<br />
);<br />
}<br />
</code><br />
<br />
It is not difficult to realize that the above accomplishes the objective if we remember that there is a "best match" policy to determine the end result.<br />
<br />
'''UPDATING:''' <br /><br />
Prior to version 1.5, blocks were only allowed in courses (and in Moodle 1.4, in the site front page). Also, the keywords used to describe the valid course formats at the time were slightly different and had to be changed in order to allow for a more open architecture. Refer to [[Development:Blocks/Appendix_B| Appendix B]] for more information on the changes that old blocks have to make to conform to the new standard.<br />
<br />
== Lists and Icons ==<br />
<br />
In this final part of the guide we will briefly discuss an additional capability of Moodle's block system, namely the ability to very easily create blocks that display a list of choices to the user. This list is displayed with one item per line, and an optional image (icon) next to the item. An example of such a ''list block'' is the standard Moodle "admin" block, which illustrates all the points discussed in this section.<br />
<br />
As we have seen so far, blocks use two properties of [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]]: "text" and "footer". The text is displayed as-is as the block content, and the footer is displayed below the content in a smaller font size. List blocks use $this->content->footer in the exact same way, but they ignore $this->content->text.<br />
<br />
Instead, Moodle expects such blocks to set two other properties when the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method is called: $this->content->items and $this->content->icons. $this->content->items should be a numerically indexed array containing elements that represent the HTML for each item in the list that is going to be displayed. Usually these items will be HTML anchor tags which provide links to some page. $this->content->icons should also be a numerically indexed array, with exactly as many items as $this->content->items has. Each of these items should be a fully qualified HTML <img> tag, with "src", "height", "width" and "alt" attributes. Obviously, it makes sense to keep the images small and of a uniform size.<br />
<br />
In order to tell Moodle that we want to have a list block instead of the standard text block, we need to make a small change to our block class declaration. Instead of extending class '''block_base''', our block will extend class '''block_list'''. For example:<br />
<br />
<code php> <br />
class block_my_menu extends block_list {<br />
// The init() method does not need to change at all<br />
}<br />
</code><br />
<br />
In addition to making this change, we must of course also modify the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method to construct the [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]] variable as discussed above:<br />
<br />
<code php> <br />
function get_content() {<br />
if ($this->content !== NULL) {<br />
return $this->content;<br />
}<br />
<br />
$this->content = new stdClass;<br />
$this->content->items = array();<br />
$this->content->icons = array();<br />
$this->content->footer = 'Footer here...';<br />
<br />
$this->content->items[] = '<a href="some_file.php">Menu Option 1</a>';<br />
$this->content->icons[] = '<img src="images/icons/1.gif" class="icon" alt="" />';<br />
<br />
// Add more list items here<br />
<br />
return $this->content;<br />
}<br />
</code><br />
<br />
To summarize, if we want to create a list block instead of a text block, we just need to change the block class declaration and the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method. Adding the mandatory [[Development:Blocks/Appendix_A#init.28.29| init()]] method as discussed earlier will then give us our first list block in no time!<br />
<br />
== Appendices ==<br />
<br />
The appendices have been moved to separate pages:<br />
<br />
* Appendix A: [[Development:Blocks/Appendix A|''block_base'' Reference]] <br />
* Appendix B: [[Development:Blocks/Appendix B|Differences in the Blocks API for Moodle Versions prior to 1.5]]<br />
* Appendix C: [[Development:Blocks/Appendix C|Creating Database Tables for Blocks (prior to 1.7)]]<br />
<br />
<br />
<br />
[[Category:Developer|Blocks]]<br />
[[Category:Tutorial]]<br />
<br />
[[es:Desarrollo de bloques]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development:Blocks&diff=51364Development:Blocks2009-02-20T16:07:06Z<p>Jsilve1: /* Ready, Set, Go! */</p>
<hr />
<div>''' A Step-by-step Guide To Creating Blocks '''<br />
<br />
Original Author: Jon Papaioannou (pj@moodle.org)<br />
<br />
The present document serves as a guide to developers who want to create their own blocks for use in Moodle. It applies to the 1.5 development version of Moodle (and any newer) '''only''', as the blocks subsystem was rewritten and expanded for the 1.5 release. However, you can also find it useful if you want to modify blocks written for Moodle 1.3 and 1.4 to work with the latest versions (look at [[Development:Blocks/Appendix_B| Appendix B]]).<br />
<br />
The guide is written as an interactive course which aims to develop a configurable, multi-purpose block that displays arbitrary HTML. It's targeted mainly at people with little experience with Moodle or programming in general and aims to show how easy it is to create new blocks for Moodle. A certain small amount of PHP programming knowledge is still required, though. <br />
<br />
Experienced developers and those who just want a reference text should refer to [[Development:Blocks/Appendix_A| Appendix A]] because the main guide has a rather low concentration of pure information in the text.<br />
<br />
== Basic Concepts ==<br />
<br />
Through this guide, we will be following the creation of an "HTML" block from scratch in order to demonstrate most of the block features at our disposal. Our block will be named "SimpleHTML". This does not constrain us regarding the name of the actual directory on the server where the files for our block will be stored, but for consistency we will follow the practice of using the lowercased form "simplehtml" in any case where such a name is required. <br />
<br />
Whenever we refer to a file or directory name which contains "simplehtml", it's important to remember that ''only'' the "simplehtml" part is up to us to change; the rest is standardized and essential for Moodle to work correctly.<br />
<br />
Whenever a file's path is mentioned in this guide, it will always start with a slash. This refers to the Moodle home directory; all files and directories will be referred to with respect to that directory.<br />
<br />
== Ready, Set, Go! ==<br />
<br />
To define a "block" in Moodle, in the most basic case we need to provide just one source code file. We start by creating the directory <span class="filename">/blocks/simplehtml/</span> and creating a file named <span class="filename">/blocks/simplehtml/block_simplehtml.php</span> which will hold our code. We then begin coding the block:<br />
<br />
<code php><br />
<?php<br />
class block_simplehtml extends block_base {<br />
function init() {<br />
$this->title = get_string('simplehtml', 'block_simplehtml');<br />
$this->version = 2004111200;<br />
}<br />
}<br />
</code><br />
<br />
The first line is our block class definition; it must be named exactly in the manner shown. Again, only the "simplehtml" part can (and indeed must) change; everything else is standardized.<br />
<br />
Our class is then given a small method: [[Development:Blocks/Appendix_A#init.28.29| init()]]. This is essential for all blocks, and its purpose is to set the two class member variables listed inside it. But what do these values actually mean? Here's a more detailed description.<br />
<br />
[[Development:Blocks/Appendix_A#.24this-.3Etitle| $this->title]] is the title displayed in the header of our block. We can set it to whatever we like; in this case it's set to read the actual title from a language file we are presumably distributing together with the block. I 'll skip ahead a bit here and say that if you want your block to display '''no''' title at all, then you should set this to any descriptive value you want (but '''not''' make it an empty string). We will later see [[Development:Blocks#Eye_Candy| how to disable the title's display]].<br />
<br />
[[Development:Blocks/Appendix_A#.24this-.3Eversion| $this->version]] is the version of our block. This actually would only make a difference if your block wanted to keep its own data in special tables in the database (i.e. for very complex blocks). In that case the version number is used exactly as it's used in activities; an upgrade script uses it to incrementally upgrade an "old" version of the block's data to the latest. We will outline this process further ahead, since blocks tend to be relatively simple and not hold their own private data. <br />
<br />
In our example, this is certainly the case so we just set [[Development:Blocks/Appendix_A#.24this-.3Eversion| $this->version]] to '''YYYYMMDD00''' and forget about it.<br />
<br />
'''UPDATING:'''<br /> <br />
Prior to version 1.5, the basic structure of each block class was slightly different. Refer to [[Development:Blocks/Appendix_B| Appendix B]] for more information on the changes that old blocks have to make to conform to the new standard.<br />
<br />
== I Just Hear Static ==<br />
In order to get our block to actually display something on screen, we need to add one more method to our class (before the final closing brace in our file). The new code is:<br />
<br />
<code php><br />
function get_content() {<br />
if ($this->content !== NULL) {<br />
return $this->content;<br />
}<br />
<br />
$this->content = new stdClass;<br />
$this->content->text = 'The content of our SimpleHTML block!';<br />
$this->content->footer = 'Footer here...';<br />
<br />
return $this->content;<br />
}<br />
}<br />
?><br />
</code><br />
<br />
It can't get any simpler than that, can it? Let's dissect this method to see what's going on...<br />
<br />
First of all, there is a check that returns the current value of [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]] if it's not NULL; otherwise we proceed with "computing" it. Since the computation is potentially a time-consuming operation and it '''will''' be called several times for each block (Moodle works that way internally), we take a precaution and include this time-saver.<br />
Supposing the content had not been computed before (it was NULL), we then define it from scratch. The code speaks for itself there, so there isn't much to say. Just keep in mind that we can use HTML both in the text '''and''' in the footer, if we want to.<br />
<br />
At this point our block should be capable of being automatically installed in Moodle and added to courses; visit your administration page to install it and after seeing it in action come back to continue our tutorial.<br />
<br />
== Configure That Out ==<br />
<br />
The current version of our block doesn't really do much; it just displays a fixed message, which is not very useful. What we 'd really like to do is allow the teachers to customize what goes into the block. This, in block-speak, is called "instance configuration". So let's give our block some instance configuration...<br />
First of all, we need to tell Moodle that we want it to provide instance-specific configuration amenities to our block. That's as simple as adding one more method to our block class:<br />
<br />
<code php><br />
function instance_allow_config() {<br />
return true;<br />
}<br />
</code><br />
<br />
This small change is enough to make Moodle display an "Edit..." icon in our block's header when we turn editing mode on in any course. However, if you try to click on that icon you will be presented with a notice that complains about the block's configuration not being implemented correctly. Try it, it's harmless.<br />
Moodle's complaints do make sense. We told it that we want to have configuration, but we didn't say ''what'' kind of configuration we want, or how it should be displayed. To do that, we need to create one more file: <span class="filename">/blocks/simplehtml/'''config_instance.html'''</span> (which has to be named exactly like that). For the moment, copy paste the following into it and save:<br />
<br />
<code php><br />
<table cellpadding="9" cellspacing="0"><br />
<tr valign="top"><br />
<td align="right"><br />
<?php print_string('configcontent', 'block_simplehtml'); ?>:<br />
</td><br />
<td><br />
<?php print_textarea(true, 10, 50, 0, 0, 'text', $this->config->text); ?><br />
</td><br />
</tr><br />
<tr><br />
<td colspan="2" align="center"><br />
<input type="submit" value="<?php print_string('savechanges') ?>" /><br />
</td><br />
</tr><br />
</table><br />
<br />
<?php use_html_editor(); ?><br />
</code><br />
<br />
It isn't difficult to see that the above code just provides us with a wysiwyg-editor-enabled textarea to write our block's desired content in and a submit button to save. But... what's $this->config->text? Well...<br />
Moodle goes a long way to make things easier for block developers. Did you notice that the textarea is actually named "text"? When the submit button is pressed, Moodle saves each and every field it can find in our '''config_instance.html''' file as instance configuration data. <br />
<br />
We can then access that data as '''$this->config->''variablename''''', where ''variablename'' is the actual name we used for our field; in this case, "text". So in essence, the above form just pre-populates the textarea with the current content of the block (as indeed it should) and then allows us to change it.<br />
<br />
You also might be surprised by the presence of a submit button and the absence of any <form> element at the same time. But the truth is, we don't need to worry about that at all; Moodle goes a really long way to make things easier for developers! We just print the configuration options we want, in any format we want; include a submit button, and Moodle will handle all the rest itself. The instance configuration variables are automatically at our disposal to access from any of the class methods ''except'' [[Development:Blocks/Appendix_A#init.28.29| init()]].<br />
<br />
In the event where the default behavior is not satisfactory, we can still override it. However, this requires advanced modifications to our block class and will not be covered here; refer to [[Development:Blocks/Appendix_A| Appendix A]] for more details.<br />
Having now the ability to refer to this instance configuration data through [[Development:Blocks/Appendix_A#.24this-.3Econfig| $this->config]], the final twist is to tell our block to actually ''display'' what is saved in its configuration data. To do that, find this snippet in ''/blocks/simplehtml/block_simplehtml.php'':<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = 'The content of our SimpleHTML block!';<br />
$this->content->footer = 'Footer here...';<br />
</code><br />
<br />
and change it to:<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = $this->config->text;<br />
$this->content->footer = 'Footer here...';<br />
</code><br />
<br />
Oh, and since the footer isn't really exciting at this point, we remove it from our block because it doesn't contribute anything. We could just as easily have decided to make the footer configurable in the above way, too. So for our latest code, the snippet becomes:<br />
<br />
<code php><br />
$this->content = new stdClass;<br />
$this->content->text = $this->config->text;<br />
$this->content->footer = '';<br />
</code><br />
<br />
After this discussion, our block is ready for prime time! Indeed, if you now visit any course with a SimpleHTML block, you will see that modifying its contents is now a snap.<br />
<br />
== The Specialists ==<br />
<br />
Implementing instance configuration for the block's contents was good enough to whet our appetite, but who wants to stop there? Why not customize the block's title, too?<br />
<br />
Why not, indeed. Well, our first attempt to achieve this is natural enough: let's add another field to <span class="filename">/blocks/simplehtml/config_instance.html</span>. Here goes:<br />
<br />
<code php><br />
<tr valign="top"><br />
<td align="right"><p><br />
<?php print_string('configtitle', 'block_simplehtml'); ?>:</p><br />
</td><br />
<td><br />
<input type="text" name="title" size="30" value="<?php echo $this->config->title; ?>" /><br />
</td><br />
</tr><br />
</code><br />
<br />
We save the edited file, go to a course, edit the title of the block and... nothing happens! The instance configuration is saved correctly, all right (editing it once more proves that) but it's not being displayed. All we get is just the simple "SimpleHTML" title.<br />
<br />
That's not too weired, if we think back a bit. Do you remember that [[Development:Blocks/Appendix_A#init.28.29|init()]] method, where we set [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]]? We didn't actually change its value from then, and [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]] is definitely not the same as '''$this->config->title''' (to Moodle, at least). What we need is a way to update [[Development:Blocks/Appendix_A#.24this-.3Etitle|$this->title]] with the value in the instance configuration. But as we said a bit earlier, we can use [[Development:Blocks/Appendix_A#.24this-.3Econfig| $this->config]] in all methods ''except'' [[Development:Blocks/Appendix_A#init.28.29|init()]]! So what can we do?<br />
<br />
Let's pull out another ace from our sleeve, and add this small method to our block class:<br />
<br />
<code php><br />
function specialization() {<br />
if(!empty($this->config->title)){<br />
$this->title = $this->config->title;<br />
}else{<br />
$this->config->title = 'Some title ...';<br />
}<br />
if(empty($this->config->text)){<br />
$this->config->text = 'Some text ...';<br />
} <br />
}<br />
</code><br />
<br />
Aha, here's what we wanted to do all along! But what's going on with the [[Development:Blocks/Appendix_A#specialization.28.29| specialization()]] method?<br />
<br />
This "magic" method has actually a very nice property: it's ''guaranteed'' to be automatically called by Moodle as soon as our instance configuration is loaded and available (that is, immediately after [[Development:Blocks/Appendix_A#init.28.29|init()]] is called). That means before the block's content is computed for the first time, and indeed before ''anything'' else is done with the block. Thus, providing a [[Development:Blocks/Appendix_A#specialization.28.29| specialization()]] method is the natural choice for any configuration data that needs to be acted upon "as soon as possible", as in this case.<br />
<br />
== Now You See Me, Now You Don't ==<br />
<br />
Now would be a good time to mention another nifty technique that can be used in blocks, and which comes in handy quite often. Specifically, it may be the case that our block will have something interesting to display some of the time; but in some other cases, it won't have anything useful to say. (An example here would be the "Recent Activity" block, in the case where no recent activity in fact exists. <br />
<br />
However in that case the block chooses to explicitly inform you of the lack of said activity, which is arguably useful). It would be nice, then, to be able to have our block "disappear" if it's not needed to display it.<br />
<br />
This is indeed possible, and the way to do it is to make sure that after the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method is called, the block is completely void of content. Specifically, "void of content" means that both $this->content->text and $this->content->footer are each equal to the empty string (<nowiki>''</nowiki>). Moodle performs this check by calling the block's [[Development:Blocks/Appendix_A#is_empty.28.29| is_empty()]] method, and if the block is indeed empty then it is not displayed at all.<br />
<br />
Note that the exact value of the block's title and the presence or absence of a [[Development:Blocks/Appendix_A#hide_header.28.29| hide_header()]] method do ''not'' affect this behavior. A block is considered empty if it has no content, irrespective of anything else.<br />
<br />
== We Are Legion ==<br />
<br />
Right now our block is fully configurable, both in title and content. It's so versatile, in fact, that we could make pretty much anything out of it. It would be really nice to be able to add multiple blocks of this type to a single course. And, as you might have guessed, doing that is as simple as adding another small method to our block class:<br />
<br />
<code php><br />
function instance_allow_multiple() {<br />
return true;<br />
}<br />
</code><br />
<br />
This tells Moodle that it should allow any number of instances of the SimpleHTML block in any course. After saving the changes to our file, Moodle immediately allows us to add multiple copies of the block without further ado!<br />
<br />
There are a couple more of interesting points to note here. First of all, even if a block itself allows multiple instances in the same page, the administrator still has the option of disallowing such behavior. This setting can be set separately for each block from the Administration / Configuration / Blocks page.<br />
<br />
And finally, a nice detail is that as soon as we defined an [[Development:Blocks/Appendix_A#instance_allow_multiple.28.29| instance_allow_multiple()]] method, the method [[Development:Blocks/Appendix_A#instance_allow_config.28.29| instance_allow_config()]] that was already defined became obsolete. <br />
<br />
Moodle assumes that if a block allows multiple instances of itself, those instances will want to be configured (what is the point of same multiple instances in the same page if they are identical?) and thus automatically provides an "Edit" icon. So, we can also remove the whole [[Development:Blocks/Appendix_A#instance_allow_config.28.29| instance_allow_config()]] method now without harm. We had only needed it when multiple instances of the block were not allowed.<br />
<br />
== The Effects of Globalization ==<br />
<br />
Configuring each block instance with its own personal data is cool enough, but sometimes administrators need some way to "touch" all instances of a specific block at the same time. In the case of our SimpleHTML block, a few settings that would make sense to apply to all instances aren't that hard to come up with. <br />
<br />
For example, we might want to limit the contents of each block to only so many characters, or we might have a setting that filters HTML out of the block's contents, only allowing pure text in. Granted, such a feature wouldn't win us any awards for naming our block "SimpleHTML" but some tormented administrator somewhere might actually find it useful.<br />
<br />
This kind of configuration is called "global configuration" and applies only to a specific block type (all instances of that block type are affected, however). Implementing such configuration for our block is quite similar to implementing the instance configuration. We will now see how to implement the second example, having a setting that only allows text and not HTML in the block's contents.<br />
First of all, we need to tell Moodle that we want our block to provide global configuration by, what a surprise, adding a small method to our block class:<br />
<br />
<code php> <br />
function has_config() {<br />
return TRUE;<br />
}<br />
</code><br />
<br />
Then, we need to create a HTML file that actually prints out the configuration screen. In our case, we 'll just print out a checkbox saying "Do not allow HTML in the content" and a "submit" button. Let's create the file <span class="filename">/blocks/simplehtml/config_global.html</span> which again must be named just so, and copy paste the following into it:<br />
<br />
[[Development_talk:Blocks|TODO: New settings.php method]] <br />
: Just to note that general documentation about admin settings is at [[Development:Admin_settings#Individual_settings]]. In the absence of documentation, you can look at blocks/course_list, blocks/online_users and blocks/rss_client. They all use a settings.php file.--[[User:Tim Hunt|Tim Hunt]] 19:38, 28 January 2009 (CST)<br />
<br />
<code php><br />
<div style="text-align: center;"><br />
<input type="hidden" name="block_simplehtml_strict" value="0" /><br />
<input type="checkbox" name="block_simplehtml_strict" value="1"<br />
<?php if(!empty($CFG->block_simplehtml_strict)) <br />
echo 'checked="checked"'; ?> /><br />
<?php print_string('donotallowhtml', 'block_simplehtml'); ?><br />
<p><br />
<input type="submit" value="<?php print_string('savechanges'); ?>" /><br />
</p><br />
</div><br />
</code><br />
<br />
True to our block's name, this looks simple enough. What it does is that it displays a checkbox named "block_simplehtml_strict" and if the Moodle configuration variable with the same name (i.e., $CFG->block_simplehtml_strict) is set and not empty (that means it's not equal to an empty string, to zero, or to boolean false) it displays the box as pre-checked (reflecting the current status). <br />
<br />
Why does it check the configuration setting with the same name? Because the default implementation of the global configuration saving code takes all the variables we have in our form and saves them as Moodle configuration options with the same name. Thus, it's good practice to use a descriptive name and also one that won't possibly conflict with the name of another setting. <br />
<br />
"block_simplehtml_strict" clearly satisfies both requirements.<br />
<br />
The astute reader may have noticed that we actually have ''two'' input fields named "block_simplehtml_strict" in our configuration file. One is hidden and its value is always 0; the other is the checkbox and its value is 1. What gives? Why have them both there?<br />
<br />
Actually, this is a small trick we use to make our job as simple as possible. HTML forms work this way: if a checkbox in a form is not checked, its name does not appear at all in the variables passed to PHP when the form is submitted. That effectively means that, when we uncheck the box and click submit, the variable is not passed to PHP at all. Thus, PHP does not know to update its value to "0", and our "strict" setting cannot be turned off at all once we turn it on for the first time. Not the behavior we want, surely.<br />
<br />
However, when PHP handles received variables from a form, the variables are processed in the order in which they appear in the form. If a variable comes up having the same name with an already-processed variable, the new value overwrites the old one. Taking advantage of this, our logic runs as follows: the variable "block_simplehtml_strict" is first unconditionally set to "0". Then, ''if'' the box is checked, it is set to "1", overwriting the previous value as discussed. The net result is that our configuration setting behaves as it should.<br />
<br />
To round our bag of tricks up, notice that the use of ''if(!empty($CFG->block_simplehtml_strict))'' in the test for "should the box be checked by default?" is quite deliberate. The first time this script runs, the variable '''$CFG->block_simplehtml_strict''' will not exist at all. After it's set for the first time, its value can be either "0" or "1". Given that both "not set" and the string "0" evaluate as empty while the sting "1" does not, we manage to avoid any warnings from PHP regarding the variable not being set at all, ''and'' have a nice human-readable representation for its two possible values ("0" and "1").<br />
<br />
=== config_save() ===<br />
<br />
Now that we have managed to cram a respectable amount of tricks into a few lines of HTML, we might as well discuss the alternative in case that tricks are not enough for a specific configuration setup we have in mind. Saving the data is done in the method [[Development:Blocks/Appendix_A#config_save.28.29| config_save()]], the default implementation of which is as follows:<br />
<br />
<code php> <br />
function config_save($data) {<br />
// Default behavior: save all variables as $CFG properties<br />
foreach ($data as $name => $value) {<br />
set_config($name, $value);<br />
}<br />
return TRUE;<br />
}<br />
</code><br />
<br />
As can be clearly seen, Moodle passes this method an associative array $data which contains all the variables coming in from our configuration screen. If we wanted to do the job without the "hidden variable with the same name" trick we used above, one way to do it would be by overriding this method with the following:<br />
<br />
<code php><br />
function config_save($data) {<br />
if(isset($data['block_simplehtml_strict'])) {<br />
set_config('block_simplehtml_strict', '1');<br />
}else {<br />
set_config('block_simplehtml_strict', '0');<br />
}<br />
return TRUE;<br />
}<br />
</code><br />
<br />
Quite straightfoward: if the variable "block_simplehtml_strict" is passed to us, then it can only mean that the user has checked it, so set the configuration variable with the same name to "1". Otherwise, set it to "0". Of course, this version would need to be updated if we add more configuration options because it doesn't respond to them as the default implementation does. Still, it's useful to know how we can override the default implementation if it does not fit our needs (for example, we might not want to save the variable as part of the Moodle configuration but do something else with it).<br />
<br />
So, we are now at the point where we know if the block should allow HTML tags in its content or not. How do we get the block to actually respect that setting?<br />
<br />
We could decide to do one of two things: either have the block "clean" HTML out from the input before saving it in the instance configuration and then display it as-is (the "eager" approach); or have it save the data "as is" and then clean it up each time just before displaying it (the "lazy" approach). The eager approach involves doing work once when saving the configuration; the lazy approach means doing work each time the block is displayed and thus it promises to be worse performance-wise. We shall hence go with the eager approach.<br />
<br />
=== instance_config_save() ===<br />
<br />
Much as we did just before with overriding [[Development:Blocks/Appendix_A#config_save.28.29| config_save()]], what is needed here is overriding the method [[Development:Blocks/Appendix_A#instance_config_save.28.29| instance_config_save()]] which handles the instance configuration. The default implementation is as follows:<br />
<br />
<code php><br />
function instance_config_save($data) {<br />
$data = stripslashes_recursive($data);<br />
$this->config = $data;<br />
return set_field('block_instance', <br />
'configdata',<br />
base64_encode(serialize($data)),<br />
'id', <br />
$this->instance->id);<br />
}<br />
</code><br />
<br />
This may look intimidating at first (what's all this stripslashes_recursive() and base64_encode() and serialize() stuff?) but do not despair; we won't have to touch any of it. We will only add some extra validation code in the beginning and then instruct Moodle to additionally call this default implementation to do the actual storing of the data. Specifically, we will add a method to our class which goes like this:<br />
<br />
<code php><br />
function instance_config_save($data) {<br />
// Clean the data if we have to<br />
global $CFG;<br />
if(!empty($CFG->block_simplehtml_strict)) {<br />
$data->text = strip_tags($data->text);<br />
}<br />
<br />
// And now forward to the default implementation defined in the parent class<br />
return parent::instance_config_save($data);<br />
}<br />
</code><br />
<br />
At last! Now the administrator has absolute power of life and death over what type of content is allowed in our "SimpleHTML" block! Absolute? Well... not exactly. In fact, if we think about it for a while, it will become apparent that if at some point in time HTML is allowed and some blocks have saved their content with HTML included, and afterwards the administrator changes the setting to "off", this will only prevent subsequent content changes from including HTML. Blocks which already had HTML in their content would continue to display it!<br />
<br />
Following that train of thought, the next stop is realizing that we wouldn't have this problem if we had chosen the lazy approach a while back, because in that case we would "sanitize" each block's content just before it was displayed. <br />
<br />
The only thing we can do with the eager approach is strip all the tags from the content of all SimpleHTML instances as soon as the admin setting is changed to "HTML off"; but even then, turning the setting back to "HTML on" won't bring back the tags we stripped away. On the other hand, the lazy approach might be slower, but it's more versatile; we can choose whether to strip or keep the HTML before displaying the content, and we won't lose it at all if the admin toggles the setting off and on again. Isn't the life of a developer simple and wonderful?<br />
<br />
=== Exercise === <br />
We will let this part of the tutorial come to a close with the obligatory exercise for the reader: <br />
In order to have the SimpleHTML block work "correctly", find out how to strengthen the eager approach to strip out all tags from the existing configuration of all instances of our block, '''or''' go back and implement the lazy approach instead. <br />
(Hint: Do that in the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method.)<br />
<br />
=== UPDATING: === <br />
Prior to version 1.5, the file </nowiki><span class="filename">config_global.html</span> was named simply <span class="filename">config.html</span>. Also, the methods [[Blocks_Howto#method_config_save| config_save]] and [[Blocks_Howto#method_config_print| config_print]] were named '''handle_config''' and '''print_config''' respectively. Upgrading a block to work with Moodle 1.5 involves updating these aspects; refer to [[Blocks_Howto#appendix_b| Appendix B]] for more information.<br />
<br />
== Eye Candy ==<br />
<br />
Our block is just about complete functionally, so now let's take a look at some of the tricks we can use to make its behavior customized in a few more useful ways.<br />
<br />
First of all, there are a couple of ways we can adjust the visual aspects of our block. For starters, it might be useful to create a block that doesn't display a header (title) at all. You can see this effect in action in the Course Description block that comes with Moodle. This behavior is achieved by, you guessed it, adding one more method to our block class:<br />
<br />
<code php><br />
function hide_header() {<br />
return true;<br />
}<br />
</code><br />
<br />
One more note here: we cannot just set an empty title inside the block's [[Development:Blocks/Appendix_A#init.28.29| init()]] method; it's necessary for each block to have a unique, non-empty title after [[Development:Blocks/Appendix_A#init.28.29| init()]] is called so that Moodle can use those titles to differentiate between all of the installed blocks.<br />
<br />
Another adjustment we might want to do is instruct our block to take up a certain amount of width on screen. Moodle handles this as a two-part process: first, it queries each block about its preferred width and takes the maximum number as the desired value. Then, the page that's being displayed can choose to use this value or, more probably, bring it within some specific range of values if it isn't already. That means that the width setting is a best-effort settlement; your block can ''request'' a certain width and Moodle will ''try'' to provide it, but there's no guarantee whatsoever about the end result. As a concrete example, all standard Moodle course formats will deliver any requested width between 180 and 210 pixels, inclusive.<br />
<br />
To instruct Moodle about our block's preferred width, we add one more method to the block class:<br />
<br />
<code php><br />
function preferred_width() {<br />
// The preferred value is in pixels<br />
return 200;<br />
}<br />
</code><br />
<br />
This will make our block (and all the other blocks displayed at the same side of the page) a bit wider than standard.<br />
<br />
Finally, we can also affect some properties of the actual HTML that will be used to print our block. Each block is fully contained within a &lt;table&gt; element, inside which all the HTML for that block is printed. We can instruct Moodle to add HTML attributes with specific values to that container. This would be done to either a) directly affect the end result (if we say, assign bgcolor="black"), or b) give us freedom to customize the end result using CSS (this is in fact done by default as we 'll see below).<br />
<br />
The default behavior of this feature in our case will assign to our block's container the class HTML attribute with the value "sideblock block_simplehtml" (the prefix "block_" followed by the name of our block, lowercased). We can then use that class to make CSS selectors in our theme to alter this block's visual style (for example, ".sideblock.block_simplehtml { border: 1px black solid}").<br />
<br />
To change the default behavior, we will need to define a method which returns an associative array of attribute names and values. For example, the version<br />
<br />
<code php><br />
function html_attributes() {<br />
return array(<br />
'class' => 'sideblock block_'. $this->name(),<br />
'onmouseover' => "alert('Mouseover on our block!');"<br />
);<br />
}<br />
</code><br />
<br />
will result in a mouseover event being added to our block using JavaScript, just as if we had written the onmouseover="alert(...)" part ourselves in HTML. Note that we actually duplicate the part which sets the class attribute (we want to keep that, and since we override the default behavior it's our responsibility to emulate it if required). <br />
<br />
And the final elegant touch is that we don't set the class to the hard-coded value "block_simplehtml" but instead use the [[Development:Blocks/Appendix_A#name.28.29| name()]] method to make it dynamically match our block's name.<br />
<br />
== Authorized Personnel Only ==<br />
<br />
It's not difficult to imagine a block which is very useful in some circumstances but it simply cannot be made meaningful in others. An example of this would be the "Social Activities" block which is indeed useful in a course with the social format, but doesn't do anything useful in a course with the weeks format. There should be some way of allowing the use of such blocks only where they are indeed meaningful, and not letting them confuse users if they are not.<br />
<br />
Moodle allows us to declare which course formats each block is allowed to be displayed in, and enforces these restrictions as set by the block developers at all times. The information is given to Moodle as a standard associative array, with each key corresponding to a page format and defining a boolean value (true/false) that declares whether the block should be allowed to appear in that page format.<br />
<br />
Notice the deliberate use of the term ''page'' instead of ''course'' in the above paragraph. This is because in Moodle 1.5 and onwards, blocks can be displayed in any page that supports them. The best example of such pages are the course pages, but we are not restricted to them. For instance, the quiz view page (the first one we see when we click on the name of the quiz) also supports blocks.<br />
<br />
The format names we can use for the pages derive from the name of the script which is actually used to display that page. For example, when we are looking at a course, the script is <span class="filename">/course/view.php</span> (this is evident from the browser's address line). Thus, the format name of that page is '''course-view'''. It follows easily that the format name for a quiz view page is '''mod-quiz-view'''. This rule of thumb does have a few exceptions, however:<br />
<br />
# The format name for the front page of Moodle is '''site-index'''.<br />
# The format name for courses is actually not just '''course-view'''<nowiki>; it is </nowiki>'''course-view-weeks''', '''course-view-topics''', etc.<br />
# Even though there is no such page, the format name '''all''' can be used as a catch-all option.<br />
<br />
We can include as many format names as we want in our definition of the applicable formats. Each format can be allowed or disallowed, and there are also three more rules that help resolve the question "is this block allowed into this page or not?":<br />
<br />
# Prefixes of a format name will match that format name; for example, '''mod''' will match all the activity modules. '''course-view''' will match any course, regardless of the course format. And finally, '''site''' will also match the front page (remember that its full format name is '''site-index''').<br />
# The more specialized a format name that matches our page is, the higher precedence it has when deciding if the block will be allowed. For example, '''mod''', '''mod-quiz''' and '''mod-quiz-view''' all match the quiz view page. But if all three are present, '''mod-quiz-view''' will take precedence over the other two because it is a better match.<br />
# The character '''<nowiki>*</nowiki>''' can be used in place of any word. For example, '''mod''' and '''mod-*''' are equivalent. At the time of this document's writing, there is no actual reason to utilize this "wildcard matching" feature, but it exists for future usage.<br />
# The order that the format names appear does not make any difference.<br />
All of the above are enough to make the situation sound complex, so let's look at some specific examples. First of all, to have our block appear '''only''' in the site front page, we would use:<br />
<br />
<code php> <br />
function applicable_formats() {<br />
return array('site' => true);<br />
}<br />
</code><br />
<br />
Since '''all''' is missing, the block is disallowed from appearing in ''any'' course format; but then '''site''' is set to true, so it's explicitly allowed to appear in the site front page (remember that '''site''' matches '''site-index''' because it's a prefix).<br />
<br />
For another example, if we wanted to allow the block to appear in all course formats ''except'' social, and also to ''not'' be allowed anywhere but in courses, we would use:<br />
<br />
<code php> <br />
function applicable_formats() {<br />
return array(<br />
'course-view' => true, <br />
'course-view-social' => false);<br />
}<br />
</code><br />
<br />
This time, we first allow the block to appear in all courses and then we explicitly disallow the social format.<br />
For our final, most complicated example, suppose that a block can be displayed in the site front page, in courses (but not social courses) and also when we are viewing any activity module, ''except'' quiz. This would be:<br />
<br />
<code php><br />
function applicable_formats() {<br />
return array(<br />
'site-index' => true,<br />
'course-view' => true, <br />
'course-view-social' => false,<br />
'mod' => true, <br />
'mod-quiz' => false<br />
);<br />
}<br />
</code><br />
<br />
It is not difficult to realize that the above accomplishes the objective if we remember that there is a "best match" policy to determine the end result.<br />
<br />
'''UPDATING:''' <br /><br />
Prior to version 1.5, blocks were only allowed in courses (and in Moodle 1.4, in the site front page). Also, the keywords used to describe the valid course formats at the time were slightly different and had to be changed in order to allow for a more open architecture. Refer to [[Development:Blocks/Appendix_B| Appendix B]] for more information on the changes that old blocks have to make to conform to the new standard.<br />
<br />
== Lists and Icons ==<br />
<br />
In this final part of the guide we will briefly discuss an additional capability of Moodle's block system, namely the ability to very easily create blocks that display a list of choices to the user. This list is displayed with one item per line, and an optional image (icon) next to the item. An example of such a ''list block'' is the standard Moodle "admin" block, which illustrates all the points discussed in this section.<br />
<br />
As we have seen so far, blocks use two properties of [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]]: "text" and "footer". The text is displayed as-is as the block content, and the footer is displayed below the content in a smaller font size. List blocks use $this->content->footer in the exact same way, but they ignore $this->content->text.<br />
<br />
Instead, Moodle expects such blocks to set two other properties when the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method is called: $this->content->items and $this->content->icons. $this->content->items should be a numerically indexed array containing elements that represent the HTML for each item in the list that is going to be displayed. Usually these items will be HTML anchor tags which provide links to some page. $this->content->icons should also be a numerically indexed array, with exactly as many items as $this->content->items has. Each of these items should be a fully qualified HTML <img> tag, with "src", "height", "width" and "alt" attributes. Obviously, it makes sense to keep the images small and of a uniform size.<br />
<br />
In order to tell Moodle that we want to have a list block instead of the standard text block, we need to make a small change to our block class declaration. Instead of extending class '''block_base''', our block will extend class '''block_list'''. For example:<br />
<br />
<code php> <br />
class block_my_menu extends block_list {<br />
// The init() method does not need to change at all<br />
}<br />
</code><br />
<br />
In addition to making this change, we must of course also modify the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method to construct the [[Development:Blocks/Appendix_A#.24this-.3Econtent| $this->content]] variable as discussed above:<br />
<br />
<code php> <br />
function get_content() {<br />
if ($this->content !== NULL) {<br />
return $this->content;<br />
}<br />
<br />
$this->content = new stdClass;<br />
$this->content->items = array();<br />
$this->content->icons = array();<br />
$this->content->footer = 'Footer here...';<br />
<br />
$this->content->items[] = '<a href="some_file.php">Menu Option 1</a>';<br />
$this->content->icons[] = '<img src="images/icons/1.gif" class="icon" alt="" />';<br />
<br />
// Add more list items here<br />
<br />
return $this->content;<br />
}<br />
</code><br />
<br />
To summarize, if we want to create a list block instead of a text block, we just need to change the block class declaration and the [[Development:Blocks/Appendix_A#get_content.28.29| get_content()]] method. Adding the mandatory [[Development:Blocks/Appendix_A#init.28.29| init()]] method as discussed earlier will then give us our first list block in no time!<br />
<br />
== Appendices ==<br />
<br />
The appendices have been moved to separate pages:<br />
<br />
* Appendix A: [[Development:Blocks/Appendix A|''block_base'' Reference]] <br />
* Appendix B: [[Development:Blocks/Appendix B|Differences in the Blocks API for Moodle Versions prior to 1.5]]<br />
* Appendix C: [[Development:Blocks/Appendix C|Creating Database Tables for Blocks (prior to 1.7)]]<br />
<br />
<br />
<br />
[[Category:Developer|Blocks]]<br />
[[Category:Tutorial]]<br />
<br />
[[es:Desarrollo de bloques]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=LDAP_authentication&diff=46654LDAP authentication2008-11-12T21:18:18Z<p>Jsilve1: </p>
<hr />
<div>Location: Settings link in ''Administration > Users > [[Authentication]]''<br />
<br />
<div style="border: 1px dotted red; padding: 1em; background: #efefef"><br />
'''QUESTION: TO WHAT VERSION OF MOODLE DOES THE BULK OF THIS DOCUMENT APPLY?'''<br />
This should be explicitly stated. My guess so far is Moodle 1.6.<br />
<br />
For example, the screenshot on this page does not seem to be from a Moodle 1.8 or 1.9 site. Also, in Moodle 1.8/1.9, Authentication is at Admin->Authentication->Manage Auth.<br />
</div><br />
<br />
<br />
This document describes how to set up Lightweight Directory Access Protocol (LDAP) authentication in Moodle. We cover the basic, advanced and some trouble shooting sections to assist the user in the installation and administrating LDAP in Moodle. <br />
<br />
==Basic Scenario==<br />
The simple and straightforward approach for most installations.<br />
<br />
===Assumptions===<br />
<br />
# Your Moodle site is located at '''http://your.moodle.site/'''<br />
# You have configured your PHP installation with the LDAP extension. It is loaded and activated, and it shows when you go to '''http://your.moodle.site/admin/phpinfo.php''' (logged in as user 'admin').<br />
# Your LDAP server has '''192.168.1.100''' as its IP address.<br />
# You are not using LDAP with SSL (also known as LDAPS) in your settings. This might prevent certain operations from working (e.g., you cannot update data if you are using MS Active Directory -- MS-AD from here on --), but should be OK if you just want to authenticate your users.<br />
# You don't want your users to change their passwords the first time they log in into Moodle.<br />
# You are using a single domain as the source of your authentication data in case you are using MS-AD (more on this in the Appendices).<br />
# You are using a top level distinguished name (DN) of '''dc=my,dc=organization,dc=domain''' as the root of your LDAP tree. <br />
# You have a non-privileged LDAP user account you will use to bind to the LDAP server. This is not necessary with certain LDAP servers, but MS-AD requires this and it won't hurt if you use it even if your LDAP server doesn't need it. Make sure '''this account and its password don't expire''', and make this password as strong as possible. Remember you only need to type this password once, when configuring Moodle, so don't be afraid of making it as hard to guess as possible. Let's say this user account has a DN of '''cn=ldap-user,dc=my,dc=organization,dc=domain''', and password '''hardtoguesspassword'''.<br />
# All of your Moodle users are in an organizational unit (OU) called '''moodleusers''', which is right under your LDAP root. That OU has a DN of '''ou=moodleusers,dc=my,dc=organization,dc=domain'''.<br />
# You '''don't''' want your LDAP users' passwords to be stored in Moodle at all.<br />
<br />
===Configuring Moodle authentication===<br />
<br />
Log in as an admin user and go to Administration >> Users >> Authentication. In the drop down listbox titled "Choose an authentication method" select "Use an LDAP Server". You will get a page similar to this one:<br />
<br />
<br><br />
::: [[Image:auth_ldap_config_screenshot.jpg]]<br />
<br><br />
<br />
Now, you just have to fill in the values. Let's go step by step.<br />
<br><br />
<br><br />
<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
! Field name<br />
! Value to fill in<br />
|-<br />
| ldap_host_url<br />
| As the IP of your LDAP server is 192.168.1.100, type "'''ldap://192.168.1.100'''" (without the quotes), or just "'''192.168.1.100'''" (some people have trouble connecting with the first syntax, specially on MS Windows servers).<br />
|-<br />
| ldap_version<br />
| Unless you are using a really old LDAP server, '''version 3''' is the one you should choose.<br />
|-<br />
| ldap_preventpassindb<br />
| As you '''don't''' want to store the users's password in Moodle's database, choose '''Yes''' here.<br />
|-<br />
| ldap_bind_dn<br />
| This is the distinguished name of the bind user defined above. Just type "'''cn=ldap-user,dc=my,dc=organization,dc=domain'''" (without the quotes).<br />
|-<br />
| ldap_bind_pw<br />
| This is the bind user password defined above. Type "'''hardtoguesspassword'''" (without the quotes).<br />
|-<br />
| ldap_user_type<br />
| Choose: <br />
* '''Novel Edirectory''' if your LDAP server is running Novell's eDdirectory.<br />
* '''posixAccount (rfc2307)''' if your LDAP server is running a RFC-2307 compatible LDAP server (choose this is your server is running OpenLDAP).<br />
* '''posixAccount (rfc2307bis)''' if your LDAP server is running a RFC-2307bis compatible LDAP server.<br />
* '''sambaSamAccount (v.3.0.7)''' if your LDAP server is running with SAMBA's 3.x LDAP schema extension and you want to use it.<br />
* '''MS ActiveDirectory''' if your LDAP server is running Microsoft's Active Directory (MS-AD)<br />
|-<br />
| ldap_contexts<br />
| The DN of the context (container) where all of your Moodle users are found. Type '''ou=moodleusers,dc=my,dc=organization,dc=domain''' here.<br />
|-<br />
| ldap_search_sub<br />
| If you have any sub organizational units (subcontexts) hanging from '''ou=moodleusers,dc=my,dc=organization,dc=domain''' and you want Moodle to search there too, set this to '''yes'''. Otherwise, set this to '''no'''.<br />
|-<br />
| ldap_opt_deref<br />
| Sometimes your LDAP server will tell you that the real value you are searching for is in fact in another part of the LDAP tree (this is called an alias). If you want Moodle to 'dereference' the alias and fetch the real value from the original location, set this to '''yes'''. If you don't want Moodle to dereference it, set this to '''no'''. If you are using MS-AD, set this to '''no'''.<br />
|-<br />
| ldap_user_attribute<br />
| The attribute used to name/search users in your LDAP tree. This option takes a default value based on the ''ldap_user_type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in</u>.<br />
<br />
By the way, it's usually '''cn''' (Novell eDirectory and MS-AD) or '''uid''' (RFC-2037, RFC-2037bis and SAMBA 3.x LDAP extension), but if you are using MS-AD you could use '''sAMAccountName''' (the pre-Windows 2000 logon account name) if you need too.<br />
|-<br />
| ldap_memberattribute<br />
| The attribute used to list the members of a given group. This option takes a default value based on the ''ldap_user_type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u><br />
<br />
By the way, the usual values are '''member''' and '''memberUid'''.<br />
|-<br />
| ldap_objectclass<br />
| The type of LDAP object used to search for users. This option takes a default value based on the ''ldap_user_type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u><br />
<br />
Here are the default values for each of the ''ldap_user_type'' values:<br />
* '''User''' for Novel eDirectory<br />
* '''posixAccount''' for RFC-2037 and RFC-2037bis<br />
* '''sambaSamAccount''' for SAMBA 3.0.x LDAP extension<br />
* '''user''' for MS-AD<br />
If you get an error about a problem with updating the ldap server (even if you have specified not to write changes back to the ldap server) try setting the ldap object class to * - see http://moodle.org/mod/forum/discuss.php?d=70566 for a discussion on this problem<br />
|-<br />
| Force change password<br />
| Set this to ''Yes'' if you want to force your users to change their password on the first login into Moodle. Otherwise, set this to ''no''. Bear in mind the password they are forced to change is the one stored in your LDAP server.<br />
<br />
<u>As you don't want your users to change their passwords in their first login, leave this set to ''No''</u><br />
|-<br />
| Use standard Change Password Page<br />
|<br />
* Setting this to ''Yes'' makes Moodle use it's own standard password change page, everytime users want to change their passwords.<br />
* Setting this to ''No'' makes Moodle use the the page specified in the field called "Change password URL" (at the bottom of the configuration page).<br />
<br />
Bear in mind that changing your LDAP passwords from Moodle might require a LDAPS connection (this is true at least for MS-AD).<br />
<br />
Also, code for changing passwords from Moodle for anything but Novell eDirectory is almost not tested, so this may or may not work for other LDAP servers.<br />
|-<br />
| ldap_expiration<br />
| <br />
* Setting this to ''No'' will make Moodle not to check if the password of the user has expired or not.<br />
* Setting this to ''LDAP'' will make Moodle check if the LDAP password of the user has expired or not, and warn her a number of days before the password expires.<br />
<br />
Current code only deals with Novell eDirectory LDAP server, but there is a patch floating around to make it work with MS-AD too (search in the authentication forum).<br />
<br />
<u>So unless you have Novell eDirectory server (or use the patch), choose ''No'' here.</u><br />
|-<br />
| ldap_expiration_warning<br />
| This value sets how many days in advance of password expiration the user is warned that her password is about to expire.<br />
|-<br />
| ldap_exprireattr<br />
| The LDAP user attribute used to check password expiration. This option takes a default value based on the ''ldap_user_type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u><br />
|-<br />
| ldap_gracelogins<br />
| This setting is specific to Novell eDirectory. If set to ''Yes'', enable LDAP gracelogin support. After password has expired the user can login until gracelogin count is 0.<br />
<br />
<u>So unless you have Novell eDirectory server and want to allow gracelogin support, choose ''No'' here.</u><br />
|-<br />
| ldap_graceattr<br />
| This setting is currently not used in the code (and is specific to Novell eDirectory). <br />
<br />
<u>So you don't need to fill this in.</u><br />
|-<br />
| ldap_create_context<br />
|<br />
|-<br />
| ldap_creators<br />
| The DN of the group that contains all of your Moodle creators. This is typically a posixGroup with a "memberUid" attribute for each user you want to be a creator. If your group is called ''creators'', type '''cn=creators,ou=moodleusers,dc=my,dc=organization,dc=domain''' here. Each memberUid attribute contains the CN of a user who is authorized to be a creator. Do not use the user's full DN (e.g., not '''memberUid: cn=JoeTeacher,ou=moodleusers,dc-my,dc=organizations,dc=domain''', but rather '''memberUid: JoeTeacher''').<br />
<br />
In eDirectory, the objectClass for a group is (by default) not '''posixGroup''' but '''groupOfNames,''' whose member attribute is '''member,''' not '''memberUid,''' and whose value is the full DN of the user in question. Although you can probably modify Moodle's code to use this field, a better solution is just to add a new '''objectClass''' attribute of '''posixGroup''' to your creators group and put the CNs for each creator in a '''memberUid''' attribute.<br />
<br />
In MS Active Directory, you will need to create a security group for your creators to be part of and then add them all. If your ldap context above is 'ou=staff,dc=my,dc=org' then your group should then be 'cn=creators,ou=staff,dc=my,dc=org'. If some of the users are from other contexts and have been added to the same security group, you'll have to add these as separate contexts after the first one using the same format.<br />
|-<br />
| First name<br />
| The name of the attribute that holds the first name of your users in your LDAP server. This is usually '''givenName'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Surname<br />
| The name of the attribute that holds the surname of your users in your LDAP server. This is usually '''sn'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Email address<br />
| The name of the attribute that holds the email address of your users in your LDAP server. This is usually '''mail'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Phone 1<br />
| The name of the attribute that holds the telephone number of your users in your LDAP server. This is usually '''telephoneNumber'''.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Phone 2<br />
| The name of the attribute that holds an additional telephone number of your users in your LDAP server. This can be '''homePhone''', '''mobile''', '''pager''', '''facsimileTelephoneNumber''' or even others.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Department<br />
| The name of the attribute that holds the department name of your users in your LDAP server. This is usully '''departmentNumber''' (for posixAccount and maybe eDirectory) or '''department''' (for MS-AD).<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Address<br />
| The name of the attribute that holds the street address of your users in your LDAP server. This is usully '''streetAddress''' or '''street'.<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| City/town<br />
| The name of the attribute that holds the city/town of your users in your LDAP server. This is usully '''l''' (lowercase L) or '''localityName''' (not valid in MS-AD).<br />
<br />
<u>This setting is optional</u> <br />
|-<br />
| Country<br />
| The name of the attribute that holds the couuntry of your users in your LDAP server. This is usully '''c''' or '''countryName''' (not valid in MS-AD).<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Description<br />
| '''description'''<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| ID Number<br />
| <br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Language<br />
| '''preferredLanguage'''<br />
<br />
<u>This setting is optional</u><br />
|-<br />
| Instructions<br />
| <br />
|}<br />
<br />
The rest of the fields are common to all authentication methods and will not be discussed here..<br />
<br />
==Active Directory Troubleshooting Help==<br />
<br />
===Warning: The PHP LDAP module does not seem to be present. Please ensure it is installed and enabled.===<br />
This usually means that the main ldap dll or one of the supporting dlls are missing.<br />
Let's start with the main one itself. <br />
Browse to http://(moodleserver)/admin/phpinfo.php and examine the "Configuration File (php.ini) Path" field to determine which php.ini is being used and open it with an editor. Find the line 'extension=php_ldap.dll' and take out the semi-colon if it is there. That semi-colon will stop it loading the module all together! <br />
While you have that file open, search for 'extension_dir' and note which folder it is set to. Open that folder and ensure the php_ldap.dll file is in there. If it isn't then put it in there.<br />
If that still hasn't fixed it you are missing a supporting dll, but you don't get told that. To see what dlls are missing open the Command Prompt and navigate to the php directory and execute the following line 'php -m'. You should get some error messages now. Ugly, but at least they give you information! Find the dlls listed and copy them to the php directory. You may now need to restart the apache/httpd service. Run 'php -m' again and you should be error free and the message in Moodle should be gone now.<br />
<br />
===LDAP-module cannot connect any LDAP servers : Server: 'ldap://my.ldap.server/' Connection: 'Resource id #26' Bind result: ''===<br />
Getting this message when you are trying to log in is a result of incorrect details for the Bind user, or the user account having insufficient permissions in Active Directory. The best way to test and resolve this is use ldp.exe to test binding until it suceeds. There are instructions on installing ldp.exe below.<br />
Open the program and Connect to AD, giving the server name, then from the Connection menu choose Bind. Enter the details you think are correct and you will probably find that an error is returned. Try adjusting the accounts priveleges or another account until you are returned an "Authenticated as" message.<br />
Once you are sure your account can be used to bind to AD, check that the DN of that users name is correct. Expand the tree on the left until you find the user you used to bind. Right click on that item and choose Copy DN. Go to the User Authentication page in Moodle and paste the value into the ldap_bind_dn field. Add the password and you can now feel safe your user is binding sucessfully.<br />
<br />
===Getting correct CNs for Contexts and Creators===<br />
For those not familiar with AD this could be very confusing, and not that easy for some who are familiar with it. Again, ldp.exe is your friend. There are instructions on installing ldp.exe below.<br />
Open it up and expand the tree on the left until you find the group or user you want to use and right click on it and select Copy DN. Go back to the Moodle User Authentication page and paste that value into either ldap_contexts or ldap_creators.<br />
<br />
===Getting the right user_attribute===<br />
By default, Moodle uses an accounts cn (full name) to verify against, but most networks don't use a full given name for logon as it's too easy to guess and you can easily have two people with the same name. If this is the case for you too you need to tell Moodle to look at another field for the logon id.<br />
In ldp.exe navigate the tree on the left to find a user account, preferably your own. Double-click the item in the tree and full-details will be loaded into the screen on the right. Look down the details until you find your logon id and note the item listed against it. For me, and a lot of people, it is sAMAccountName. Copy this name and paste it into the ldap_user_attribute on the Moodle User Authentication page.<br />
There are instructions on installing ldp.exe below.<br />
<br />
===Installing ldp.exe Server Tool===<br />
ldp.exe comes as part of the Server Tools on most versions of Windows Server. Find your Windows Server installation disc and find a folder on it called Support\Tools. In there will be a SupTools.msi which will install the server tools if run. You should now have a folder under Program Files called Support Tools, in which will be ldp.exe. ldp.exe is also available in the Windows XP Support Tools, which you can download from Microsoft [http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en here]. Alternatively, a single download of ldp.exe is available [http://www.computerperformance.co.uk/w2k3/utilities/ldp.htm here].<br />
<br />
===Example Active Directory Configuration===<br />
Below is an example configuration for Active Directory. As detailed above, the values may vary based on your local Active Directory configuration, but should provide a good starting point for most cases.<br />
<br />
ldap_host_url = ldap://ads.example.com<br />
ldap_version = 3<br />
ldap_preventpassindb = yes<br />
ldap_bind_dn = bind-user@example.com<br />
ldap_bind_pw = bind-password<br />
ldap_user_type = MS ActiveDirectory<br />
ldap_contexts = ou=moodleusers,dc=example,dc=com<br />
ldap_user_attribute = sAMAccountName<br />
<br />
<br />
Note that the ldap_bind_dn value should work in either the CN=bin-user,CN=Users,DC=example,DC=com format as shown in the main instructions or the bind-user@example.com format shown in this example.<br />
<br />
==Advanced Scenarios - Multiple servers or locations==<br />
For larger installations with multiple LDAP servers, or multiple locations (contexts) in a LDAP tree.<br />
<br />
===Using multiple LDAP Servers===<br />
Entering more than one name in the ldap_host_url field can provide some sort of resilience to your system. Simply use the syntax :<br />
ldap://my.first.server ; ldap://my.second.server ; ...<br />
<br />
Of course, this will only work if all the servers share the same directory information, using a replication or synchronization mecanism once introduced in eDirectory and now generalized to the main LDAP-compatible directories.<br />
<br />
There is one drawback in Moodle 1.5 - 1.6 implementation of LDAP authentication : the auth_ldap_connect() function processes the servers sequentially, not in a round robin mode. Thus, if the primary server fails, you will have to wait for the connection to time out before switching to the following one.<br />
<br />
===Using multiple user locations (contexts) in your LDAP tree===<br />
There is no need to use multiple user locations if your directory tree is flat, i.e. if all user accounts reside in a '''ou=people,dc=my,dc=organization,dc=domain''' or '''ou=people,o=myorg''' container. <br />
<br />
At the opposite, if you use the ACL mecanism to delegate user management, there are chances that your users will be stored in containers like '''ou=students,ou=dept1,o=myorg''' and '''ou=students,ou=dept2,o=myorg''' ...<br />
<br />
Then there is an alternative :<br />
* Look at the '''o=myorg''' level with the ldap_search_sub attribute set to '''yes'''.<br />
* Set the ldap_context to '''ou=students,ou=dept1,o=myorg ; ou=students,ou=dept2,o=myorg'''.<br />
<br />
Choosing between these two solutions supposes some sort of benchmarking, as the result depends heavily on the structure of your directory tree '''and''' on your LDAP software indexing capabilities. Simply note that there is a probability in such deep trees that two users share the same ''common name'' (cn), while having different ''distinguished names''. Then only the second solution will have a deterministic result (returning allways the same user).<br />
<br />
===Using LDAPS (LDAP + SSL)===<br />
====MS Active Directory + SSL ====<br />
<br />
If the Certificate Authority is not installed you'll have to install it first as follows:<br />
# Click '''Start''' -> '''Control Panel''' -> '''Add or Remove programs.'''<br />
# Click '''Add/Remove Windows Components''' and select '''Certificate Services.'''<br />
# Follow the procedure provided to install the '''Certificate Authority'''. Enterprise level is a good choice.<br />
<br />
Verify that SSL has been enabled on the server by installing suptools.msi from Windows installation cd's \Support\tools directory. After support tools installation:<br />
# Select '''Start''' -> '''Run''', write '''ldp''' in the Open field.<br />
# From the ldp window select '''Connection''' -> '''Connect''' and supply valid hostname and port number '''636'''. Also select the SSL check box.<br />
<br />
If successful, you should get information about the connection.<br />
<br />
Next step is to tell PHP's OpenLDAP extension to disable SSL certificate checking. On Windows servers you're most likely using pre-compiled PHP version, where you must create a path ''C:\OpenLDAP\sysconf''. In this path create a file called "ldap.conf" with content:<br />
<br />
TLS_REQCERT never.<br />
<br />
Now you should be able to use '''ldaps://''' when connecting to MS-AD.<br />
<br />
==Appendices==<br />
<br />
===Child Domains and the Global Catalog in MS Active Directory===<br />
<br />
Moodle currently only has limited support for multiple domain controllers; specifically it expects each of the LDAP servers listed to contain identical sets of information. If you have users in multiple domains this presents an issue. One solution when working with MS-AD is to use the Global Catalog. The Global Catalog is designed to be a read-only, partial representation of an entire MS-AD forest, designed for searching the entire directory when the domain of the required object is not known.<br />
<br />
For example your organisation has a main domain example.org, staff and students are contained in two child domains staff.example.org and students.example.org. The 3 domains (example.org, staff.example.org and students.example.org) each have a domain controller (dc01, dc02 and dc03 respectively.) Each domain controller contains a full, writable, representation of only the objects that belong to its domain. However, assuming that the Global Catalog has been enabled (see below) on one of the domain controllers (for example dc01) a query to the Global Catalog would reveal matching objects from all three domains. The Global Catalog is automatically maintained through replication across the active directory forest, it can also be enabled on multiple servers (if, for example, you need redundancy / load balancing.)<br />
<br />
To make use of this in Moodle to allow logins from multiple domains is simple. The Global Catalog runs on port 3268 as opposed to 389 for standard LDAP queries. As a result, still assuming the Global Catalog is running on dc01, the ''''ldap_host_url'''' would be ''ldap://dc01.example.org:3268''. The rest of the settings are the same as for other MS-AS Auth setups.<br />
<br />
You should use the ''''ldap_contexts'''' setting to indicate the locations of individuals you wish to grant access. To extend the example above a little: In the example.org domain users are all in the'' 'Users' ''OU, in the staff.example.org domain users are in two OUs at the root of the domain,'' 'Support Staff' ''and'' 'Teaching Staff' '', and in the students.example.org domain students are in an OU indicating the year that they enrolled, all of which are under the'' 'Students' ''OU. As a result our ''''ldap_contexts'''' setting may look a little like this:'' 'OU=Users,DC=example,DC=org; OU=Support Staff,DC=staff,DC=example,DC=org; OU=Teaching Staff,DC=staff,DC=example,DC=org; OU=Students,DC=students,DC=example,DC=org''.' The ''''ldap_search_sub'''' option should be set to'' 'Yes' ''to allow moodle to search within the child OUs.<br />
<br />
Its worth noting that the Global Catalog only contains a partial representation of the attributes of each object, as defined in the Partial Attribute Set supplied by Microsoft. However common information likely to be of use to a general Moodle installation (Forename, Surname, Email Address, sAMAccountName etc) is included in the set. For specific needs the schema can be altered to remove or add various attributes.<br />
<br />
In most cases the Global Catalog is read-only, update queries must be made over the standard LDAP ports to the domain controller that holds the object in question (in our example, updating a student's details would require an LDAP query to the students.example.org domain controller - dc03, it would not be possible to update details by querying the Global Catalog.) The exception to this would be in an environment where there is only a single domain in the active directory forest; in this case the Global Catalog holds a writable full set of attributes for each object in the domain. However, for the purposes of Moodle authorisation, there would be no need to use the Global Catalog in this case.<br />
<br />
===Enabling the Global Catalog===<br />
<br />
The Global Catalog is available on Windows 2000 and Windows 2003 Active Directory servers. To enable, open the ‘Active Directory Sites and Services’ MMC (Microsoft Management Console) snap-in. Extend ‘Sites’ and then the name of the Site containing the active directory forest you wish to use. Expand the server you wish to enable the Global Catalog on, right click ‘NTDS settings’ and select the ‘Properties’ tab. To enable, simply click the ‘Global Catalog’ checkbox. Under a Windows 2000 server it is necessary to restart the server (although it won’t prompt you to); under Windows 2003 server it is not necessary to restart the server. In either case you will generally have to wait for the AD forest to replicate before the Global Catalog offers a representation of the entire AD forest. Changes made in Active Directory will also be subject to a short delay due to the latency involved with replication. If your AD servers are firewalled port 3268 will need to be opened for Global Catalog servers.<br />
If your organisation uses Microsoft Exchange then it its highly likely that at least one Domain Controller will already have Global Catalog enabled – Exchange 2000 and 2003 rely on the Global Catalog for address information, users also access the Global Catalog when using the GAL (Global Address List)<br />
<br />
===ldap auth_user_create() only suports Novell===<br />
<br />
After configuring user authentication with ldap I realized ldap only support edir (Novell) when combining ldap an email user confirmation. For example in my case (I use openldap) I have the following error after filling the user form:<br />
<br />
auth: ldap auth_user_create() does not support selected usertype:"rfc2307" (..yet)<br />
<br />
{{Moodle 1.9}}<br />
The previous comment only applies to Moodle 1.8 and below. Moodle 1.9 adds support for MS Active Directory too.<br />
<br />
=== Active Directory with Moodle 1.8===<br />
<br />
There is an issue with the PHP ldap options that are required for Active Directory access in version 1.8 of Moodle. <br />
<br />
Using moodle on a LAMP platform with authentication to Active Directory may give some errors. <br />
<br />
Check this bug [http://tracker.moodle.org/browse/MDL-10921 MDL-10921] or this post http://moodle.org/mod/forum/discuss.php?d=78316 for further information.<br />
<br />
==See also==<br />
<br />
*[http://moodle.org/mod/forum/view.php?id=42 Using Moodle: User authentication] forum<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=32168 PHP LDAP module does not seem to be present] forum discussion<br />
* [[LDAP enrolment]]<br />
<br />
[[Category:Authentication]]<br />
<br />
[[es:LDAP_authentication]]<br />
[[fr:Utiliser un serveur LDAP]]<br />
[[ja:LDAP認証]]<br />
[[zh:LDAP认证]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Upgrading&diff=42469Upgrading2008-08-22T17:13:03Z<p>Jsilve1: /* SQL dump caveats */</p>
<hr />
<div>Moodle is designed to upgrade cleanly from one version to the next. Please refer to [[Upgrading to Moodle 1.6]], [[Upgrading to Moodle 1.8]] or [[Upgrading to Moodle 1.9]] for particular considerations related to the upgraded version. <br />
<br />
Changes that have been made to the original code, such as installing a contributed module (non-standard module) or a site edit of a php file, may not upgrade. This includes modifications to standard themes, that will be overwritten during an upgrade.<br />
<br />
<br />
__TOC__<br />
<br />
When upgrading a Moodle installation you should follow these steps:<br />
<br />
==Check the requirements==<br />
Spend some time re-reading the [[Installing Moodle | installation documentation]] and documentation for the new version. Check the system requirements for the version you are upgrading to in ''Administration > Server > [[Environment]]''.<br />
<br />
== Backup important data ==<br />
<br />
Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.<br />
<br />
There are three areas that need backing up:<br />
<br />
=== 1. The Moodle software directory itself ===<br />
<br />
Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc<br />
<br />
=== 2. Your data directory ===<br />
<br />
This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.<br />
<br />
=== 3. Your database ===<br />
<br />
Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":<br />
<br />
mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2007-04-01.sql<br />
(The "-a" switch is deprecated and should be replaced by "--create-options")<br />
<br />
Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.<br />
<br />
If your database host is different from the host you want to execute the backup command (usually the web server), you have to specify it with the -h option to mysqldump:<br />
<br />
mysqldump -u username -p -h databasehost -C -Q -e -a moodle > moodle-backup-2007-04-01.sql <br />
<br />
You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. In Moodle v1.9 and greater, this is located in '''Site Administration''' -> '''Server''' -> '''Database'''. This interface can also be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.<br />
<br />
==== SQL dump caveats ====<br />
<br />
* Please note that there are a '''LOT''' of options possible for mysqldump. Please talk with your Systems Administrator (if you have one) or similar to see if there are site-specific flags you should use for your SQL dump.<br />
** For example, if your local installation is running MySQL 5.2 and you are moving to a system running MySQL 5.0 or 4.1, you really ought to use the "--compat=mysql40" flag. (This is not too uncommon of a situation given the nature of ISP hosting as compared to local user Moodle setups)<br />
* This seems obvious, but should be said outright: These instructions only work for dumping from MySQL! Postgresql, Oracle, and other database servers have different tools to dump databases.<br />
* Given the example mysql import lines, above, you really should use the --no-create-db flag. If your database locally is named something differently from the migration site, not including this flag could cause problems.<br />
<br />
== Install the new Moodle software ==<br />
<br />
=== Using a downloaded archive ===<br />
<br />
@Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.<br />
<br />
Linux<br />
mv moodle moodle.backup<br />
tar xvzf moodle-1.1.tgz<br />
<br />
Next, copy across your config.php, any other plugins such as custom themes, and your .htaccess file if you created one:<br />
<br />
cp moodle.backup/config.php moodle<br />
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme<br />
<br />
Don't forget to <br />
<br />
sudo chown www-data moodle/config.php<br />
<br />
if necessary.<br />
<br />
=== Using CVS ===<br />
<br />
You can use CVS for updating or upgrading your Moodle.<br />
First you need to do a CVS checkout in your (empty) Moodle root directory.<br />
<br />
You can use any of our [[CVS_for_Administrators#CVS_Servers|CVS Mirror servers]]. Just replace '''SERVER.cvs.moodle.org''' in the instructions below with the name of the mirror server you chose!.<br />
<br />
'''For Linux servers'''<br />
<br />
To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.<br />
<br />
<nowiki>cvs -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle login</nowiki><br />
No password for anonymous, so just hit the Enter button.<br />
<br />
Go to the directory where you want the Moodle root to come and type<br />
<br />
<nowiki>cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -r MOODLE_18_STABLE moodle</nowiki> <br />
(where MOODLE_18_STABLE is the desired version)<br />
<br />
To update, just go into the Moodle root directory and update to the new files:<br />
<br />
cvs update -dP<br />
To update to a new version type in the following and change 18 to whatever newest version upgrade number is<br />
cvs -Q update -dP -r MOODLE_18_STABLE<br />
<br />
Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.<br />
<br />
'''For Windows servers'''<br />
<br />
You can use Tortoise CVS to do the initial checkout and the updates.<br />
<br />
If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.<br />
<br />
Don't forget to visit the admin page after the CVS update process has completed.<br />
<br />
== Finishing the upgrade ==<br />
<br />
The last step is to trigger the upgrade processes within Moodle.<br />
<br />
To do this just visit the admin page of your installation e.g. ''<nowiki>http://example.com/moodle/admin</nowiki>''<br />
<br />
It doesn't matter if you are logged in as admin or not. If you are upgrading from some older versions you would not be able to login before the upgrade anyway.<br />
<br />
Moodle will automatically detect the new version and perform all the database or filesystem 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.<br />
<br />
Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!<br />
<br />
Please note that if you are running a large scale of moodle site (e.g. have more tha 10,000+ courses and 40,000+ users), make sure that you do your own performance profiling testing before you upgrade to Moodle 1.8.x, as there are still quite a few outstanding (unresolved) performance issues in 1.8.x for large user base installations.<br />
<br />
== Verify the upgrade (optional) ==<br />
<br />
If you wish to confirm that the database definitions in the upgraded database match the definitions of a new, clean install (which they should) you might like to look at [[Verify Database Schema]].<br />
<br />
==Upgrading more than one version==<br />
<br />
In general, it is recommended to upgrade via each version of Moodle, for example 1.7 -> 1.8 -> 1.9. An exception to this is when upgrading from 1.5 or 1.6, when it is recommended that 1.7 is skipped, in other words upgrade 1.5 -> 1.6 -> 1.8 -> 1.9. (The main reason for this recommendation is that the default roles settings obtained when upgrading to 1.7 are not ideal for 1.8 onwards.)<br />
<br />
==See also==<br />
<br />
*[[Installing Moodle]]<br />
*[[Installation FAQ]]<br />
*[[Upgrading to Moodle 1.6]]<br />
*[[Upgrading to Moodle 1.8]]<br />
*[[Upgrading to Moodle 1.9]]<br />
*Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation problems] forum<br />
*[http://otaru-jc.ac.jp/hagley/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial]<br />
*[http://youtube.com/watch?v=ufAmf_jm_p8 How to backup a whole Moodle site video]<br />
*Using Moodle forum discussions: [http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs], [http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7], [http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated], [http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg]<br />
<br />
[[Category:Installation]]<br />
<br />
[[es:Actualización de moodle]]<br />
[[fr:Mise à jour]]<br />
[[ja:アップグレード]]<br />
[[nl:Upgraden]]<br />
[[zh:升级]]<br />
[[pl:Aktualizacja]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Upgrading&diff=42468Upgrading2008-08-22T17:09:00Z<p>Jsilve1: /* SQL dump caveats */</p>
<hr />
<div>Moodle is designed to upgrade cleanly from one version to the next. Please refer to [[Upgrading to Moodle 1.6]], [[Upgrading to Moodle 1.8]] or [[Upgrading to Moodle 1.9]] for particular considerations related to the upgraded version. <br />
<br />
Changes that have been made to the original code, such as installing a contributed module (non-standard module) or a site edit of a php file, may not upgrade. This includes modifications to standard themes, that will be overwritten during an upgrade.<br />
<br />
<br />
__TOC__<br />
<br />
When upgrading a Moodle installation you should follow these steps:<br />
<br />
==Check the requirements==<br />
Spend some time re-reading the [[Installing Moodle | installation documentation]] and documentation for the new version. Check the system requirements for the version you are upgrading to in ''Administration > Server > [[Environment]]''.<br />
<br />
== Backup important data ==<br />
<br />
Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.<br />
<br />
There are three areas that need backing up:<br />
<br />
=== 1. The Moodle software directory itself ===<br />
<br />
Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc<br />
<br />
=== 2. Your data directory ===<br />
<br />
This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.<br />
<br />
=== 3. Your database ===<br />
<br />
Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":<br />
<br />
mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2007-04-01.sql<br />
(The "-a" switch is deprecated and should be replaced by "--create-options")<br />
<br />
Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.<br />
<br />
If your database host is different from the host you want to execute the backup command (usually the web server), you have to specify it with the -h option to mysqldump:<br />
<br />
mysqldump -u username -p -h databasehost -C -Q -e -a moodle > moodle-backup-2007-04-01.sql <br />
<br />
You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. In Moodle v1.9 and greater, this is located in '''Site Administration''' -> '''Server''' -> '''Database'''. This interface can also be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.<br />
<br />
==== SQL dump caveats ====<br />
<br />
* Please note that there are a '''LOT''' of options possible for mysqldump. Please talk with your Systems Administrator (if you have one) or similar to see if there are site-specific flags you should use for your SQL dump.<br />
** For example, if your local installation is running MySQL 5.2 and you are moving to a system running MySQL 5.0 or 4.1, you really ought to use the "--compat=mysql40" flag. (This is not too uncommon of a situation given the nature of ISP hosting as compared to local user Moodle setups)<br />
* This seems obvious, but should be said outright: These instructions only work for dumping from MySQL! Postgresql, Oracle, and other database servers have different tools to dump databases.<br />
<br />
== Install the new Moodle software ==<br />
<br />
=== Using a downloaded archive ===<br />
<br />
@Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.<br />
<br />
Linux<br />
mv moodle moodle.backup<br />
tar xvzf moodle-1.1.tgz<br />
<br />
Next, copy across your config.php, any other plugins such as custom themes, and your .htaccess file if you created one:<br />
<br />
cp moodle.backup/config.php moodle<br />
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme<br />
<br />
Don't forget to <br />
<br />
sudo chown www-data moodle/config.php<br />
<br />
if necessary.<br />
<br />
=== Using CVS ===<br />
<br />
You can use CVS for updating or upgrading your Moodle.<br />
First you need to do a CVS checkout in your (empty) Moodle root directory.<br />
<br />
You can use any of our [[CVS_for_Administrators#CVS_Servers|CVS Mirror servers]]. Just replace '''SERVER.cvs.moodle.org''' in the instructions below with the name of the mirror server you chose!.<br />
<br />
'''For Linux servers'''<br />
<br />
To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.<br />
<br />
<nowiki>cvs -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle login</nowiki><br />
No password for anonymous, so just hit the Enter button.<br />
<br />
Go to the directory where you want the Moodle root to come and type<br />
<br />
<nowiki>cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -r MOODLE_18_STABLE moodle</nowiki> <br />
(where MOODLE_18_STABLE is the desired version)<br />
<br />
To update, just go into the Moodle root directory and update to the new files:<br />
<br />
cvs update -dP<br />
To update to a new version type in the following and change 18 to whatever newest version upgrade number is<br />
cvs -Q update -dP -r MOODLE_18_STABLE<br />
<br />
Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.<br />
<br />
'''For Windows servers'''<br />
<br />
You can use Tortoise CVS to do the initial checkout and the updates.<br />
<br />
If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.<br />
<br />
Don't forget to visit the admin page after the CVS update process has completed.<br />
<br />
== Finishing the upgrade ==<br />
<br />
The last step is to trigger the upgrade processes within Moodle.<br />
<br />
To do this just visit the admin page of your installation e.g. ''<nowiki>http://example.com/moodle/admin</nowiki>''<br />
<br />
It doesn't matter if you are logged in as admin or not. If you are upgrading from some older versions you would not be able to login before the upgrade anyway.<br />
<br />
Moodle will automatically detect the new version and perform all the database or filesystem 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.<br />
<br />
Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!<br />
<br />
Please note that if you are running a large scale of moodle site (e.g. have more tha 10,000+ courses and 40,000+ users), make sure that you do your own performance profiling testing before you upgrade to Moodle 1.8.x, as there are still quite a few outstanding (unresolved) performance issues in 1.8.x for large user base installations.<br />
<br />
== Verify the upgrade (optional) ==<br />
<br />
If you wish to confirm that the database definitions in the upgraded database match the definitions of a new, clean install (which they should) you might like to look at [[Verify Database Schema]].<br />
<br />
==Upgrading more than one version==<br />
<br />
In general, it is recommended to upgrade via each version of Moodle, for example 1.7 -> 1.8 -> 1.9. An exception to this is when upgrading from 1.5 or 1.6, when it is recommended that 1.7 is skipped, in other words upgrade 1.5 -> 1.6 -> 1.8 -> 1.9. (The main reason for this recommendation is that the default roles settings obtained when upgrading to 1.7 are not ideal for 1.8 onwards.)<br />
<br />
==See also==<br />
<br />
*[[Installing Moodle]]<br />
*[[Installation FAQ]]<br />
*[[Upgrading to Moodle 1.6]]<br />
*[[Upgrading to Moodle 1.8]]<br />
*[[Upgrading to Moodle 1.9]]<br />
*Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation problems] forum<br />
*[http://otaru-jc.ac.jp/hagley/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial]<br />
*[http://youtube.com/watch?v=ufAmf_jm_p8 How to backup a whole Moodle site video]<br />
*Using Moodle forum discussions: [http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs], [http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7], [http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated], [http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg]<br />
<br />
[[Category:Installation]]<br />
<br />
[[es:Actualización de moodle]]<br />
[[fr:Mise à jour]]<br />
[[ja:アップグレード]]<br />
[[nl:Upgraden]]<br />
[[zh:升级]]<br />
[[pl:Aktualizacja]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Upgrading&diff=42467Upgrading2008-08-22T17:02:30Z<p>Jsilve1: /* 3. Your database */</p>
<hr />
<div>Moodle is designed to upgrade cleanly from one version to the next. Please refer to [[Upgrading to Moodle 1.6]], [[Upgrading to Moodle 1.8]] or [[Upgrading to Moodle 1.9]] for particular considerations related to the upgraded version. <br />
<br />
Changes that have been made to the original code, such as installing a contributed module (non-standard module) or a site edit of a php file, may not upgrade. This includes modifications to standard themes, that will be overwritten during an upgrade.<br />
<br />
<br />
__TOC__<br />
<br />
When upgrading a Moodle installation you should follow these steps:<br />
<br />
==Check the requirements==<br />
Spend some time re-reading the [[Installing Moodle | installation documentation]] and documentation for the new version. Check the system requirements for the version you are upgrading to in ''Administration > Server > [[Environment]]''.<br />
<br />
== Backup important data ==<br />
<br />
Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.<br />
<br />
There are three areas that need backing up:<br />
<br />
=== 1. The Moodle software directory itself ===<br />
<br />
Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc<br />
<br />
=== 2. Your data directory ===<br />
<br />
This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.<br />
<br />
=== 3. Your database ===<br />
<br />
Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":<br />
<br />
mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2007-04-01.sql<br />
(The "-a" switch is deprecated and should be replaced by "--create-options")<br />
<br />
Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.<br />
<br />
If your database host is different from the host you want to execute the backup command (usually the web server), you have to specify it with the -h option to mysqldump:<br />
<br />
mysqldump -u username -p -h databasehost -C -Q -e -a moodle > moodle-backup-2007-04-01.sql <br />
<br />
You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. In Moodle v1.9 and greater, this is located in '''Site Administration''' -> '''Server''' -> '''Database'''. This interface can also be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.<br />
<br />
==== SQL dump caveats ====<br />
<br />
* Please not that there are a '''LOT''' of options possible for mysqldump. Please talk with your Systems Administrator (if you have one) or similar to see if there are site-specific flags you should use for your SQL dump.<br />
** For example, if your local installation is running MySQL 5.2 and you are moving to a system running MySQL 5.0 or 4.1, you really ought to use the "--compat=mysql40" flag. (This is not too uncommon of a situation given the nature of ISP hosting as compared to local user Moodle setups)<br />
* This seems obvious, but should be said outright: These instructions only work for dumping from MySQL! Postgresql, Oracle, and other database servers have different tools to dump databases.<br />
<br />
== Install the new Moodle software ==<br />
<br />
=== Using a downloaded archive ===<br />
<br />
@Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.<br />
<br />
Linux<br />
mv moodle moodle.backup<br />
tar xvzf moodle-1.1.tgz<br />
<br />
Next, copy across your config.php, any other plugins such as custom themes, and your .htaccess file if you created one:<br />
<br />
cp moodle.backup/config.php moodle<br />
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme<br />
<br />
Don't forget to <br />
<br />
sudo chown www-data moodle/config.php<br />
<br />
if necessary.<br />
<br />
=== Using CVS ===<br />
<br />
You can use CVS for updating or upgrading your Moodle.<br />
First you need to do a CVS checkout in your (empty) Moodle root directory.<br />
<br />
You can use any of our [[CVS_for_Administrators#CVS_Servers|CVS Mirror servers]]. Just replace '''SERVER.cvs.moodle.org''' in the instructions below with the name of the mirror server you chose!.<br />
<br />
'''For Linux servers'''<br />
<br />
To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.<br />
<br />
<nowiki>cvs -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle login</nowiki><br />
No password for anonymous, so just hit the Enter button.<br />
<br />
Go to the directory where you want the Moodle root to come and type<br />
<br />
<nowiki>cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -r MOODLE_18_STABLE moodle</nowiki> <br />
(where MOODLE_18_STABLE is the desired version)<br />
<br />
To update, just go into the Moodle root directory and update to the new files:<br />
<br />
cvs update -dP<br />
To update to a new version type in the following and change 18 to whatever newest version upgrade number is<br />
cvs -Q update -dP -r MOODLE_18_STABLE<br />
<br />
Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.<br />
<br />
'''For Windows servers'''<br />
<br />
You can use Tortoise CVS to do the initial checkout and the updates.<br />
<br />
If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.<br />
<br />
Don't forget to visit the admin page after the CVS update process has completed.<br />
<br />
== Finishing the upgrade ==<br />
<br />
The last step is to trigger the upgrade processes within Moodle.<br />
<br />
To do this just visit the admin page of your installation e.g. ''<nowiki>http://example.com/moodle/admin</nowiki>''<br />
<br />
It doesn't matter if you are logged in as admin or not. If you are upgrading from some older versions you would not be able to login before the upgrade anyway.<br />
<br />
Moodle will automatically detect the new version and perform all the database or filesystem 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.<br />
<br />
Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!<br />
<br />
Please note that if you are running a large scale of moodle site (e.g. have more tha 10,000+ courses and 40,000+ users), make sure that you do your own performance profiling testing before you upgrade to Moodle 1.8.x, as there are still quite a few outstanding (unresolved) performance issues in 1.8.x for large user base installations.<br />
<br />
== Verify the upgrade (optional) ==<br />
<br />
If you wish to confirm that the database definitions in the upgraded database match the definitions of a new, clean install (which they should) you might like to look at [[Verify Database Schema]].<br />
<br />
==Upgrading more than one version==<br />
<br />
In general, it is recommended to upgrade via each version of Moodle, for example 1.7 -> 1.8 -> 1.9. An exception to this is when upgrading from 1.5 or 1.6, when it is recommended that 1.7 is skipped, in other words upgrade 1.5 -> 1.6 -> 1.8 -> 1.9. (The main reason for this recommendation is that the default roles settings obtained when upgrading to 1.7 are not ideal for 1.8 onwards.)<br />
<br />
==See also==<br />
<br />
*[[Installing Moodle]]<br />
*[[Installation FAQ]]<br />
*[[Upgrading to Moodle 1.6]]<br />
*[[Upgrading to Moodle 1.8]]<br />
*[[Upgrading to Moodle 1.9]]<br />
*Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation problems] forum<br />
*[http://otaru-jc.ac.jp/hagley/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial]<br />
*[http://youtube.com/watch?v=ufAmf_jm_p8 How to backup a whole Moodle site video]<br />
*Using Moodle forum discussions: [http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs], [http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7], [http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated], [http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg]<br />
<br />
[[Category:Installation]]<br />
<br />
[[es:Actualización de moodle]]<br />
[[fr:Mise à jour]]<br />
[[ja:アップグレード]]<br />
[[nl:Upgraden]]<br />
[[zh:升级]]<br />
[[pl:Aktualizacja]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=External_database_authentication&diff=41887External database authentication2008-08-12T18:56:39Z<p>Jsilve1: </p>
<hr />
<div>Location: Settings link in ''Administration > Users > [[Authentication]]''<br />
<br />
<br />
This method uses an external database table to check whether a given username and password is valid. If the account is a new one, then information from other fields may also be copied across into Moodle.<br />
<br />
This is done by mapping fields at the bottom of the database authentication page. Each data field in the user profile has a text field next to it. Enter the name of the column in the external database that maps to the profile data field.<br />
<br />
'''Update Local''' - Specifies that the external data will be entered into the local field in question<br />
* On Creation - specifies that this will only happen on the original login when the account is created for the first time.<br />
* On Every Login - specifies that changes in the external data will be updated on the local Moodle field in question the next time the user logs in again.<br />
<br />
'''Update External''' - Specifies just the opposite, meaning changes in the local Moodle field in question will update the corresponding field in the external database<br />
* Never - Specifies this is disabled<br />
* On Update - Enables this to happen if a change is made locally (additional configuration is probably required)<br />
<br />
'''Lock Value''' - Only determines whether the local user can make a change in the Moodle field and does not affect the two settings above.<br />
* Unlocked - A user can make changes locally in the Moodle field (assumably even if it contradicts the external database the next login would change it again if Update Local is set<br />
* Locked - A user can never make changes<br />
* Unlocked if empty - A user can only make changes if the field is not populated already from the external database (this would seem to indicate a user could only enter something into this field once and could not change it after saving)<br />
<br />
==Additional Notes==<br />
* Some of the things that apply to [[Upload users]] apply to the External database<br />
** Set password to "changeme" to force password reset<br />
*** If you do this, it is '''critical''' that you provide a URL to change the password!<br />
* Not all of the fields in the [[Upload users]] are available for the External Database authentication. The only available fields are the fields listed in the data mapping section of the admin page for the External Database connection.<br />
<br />
==See also==<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=45444 Special and characters con tilde (accute accent) when connected to external database] forum discussion<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=75519 HELP!--User Authentication problem] forum discussion<br />
<br />
[[Category:Authentication]]<br />
<br />
[[fr:Utiliser une base de données externe]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=External_database_authentication&diff=41886External database authentication2008-08-12T18:53:10Z<p>Jsilve1: </p>
<hr />
<div>Location: Settings link in ''Administration > Users > [[Authentication]]''<br />
<br />
<br />
This method uses an external database table to check whether a given username and password is valid. If the account is a new one, then information from other fields may also be copied across into Moodle.<br />
<br />
This is done by mapping fields at the bottom of the database authentication page. Each data field in the user profile has a text field next to it. Enter the name of the column in the external database that maps to the profile data field.<br />
<br />
'''Update Local''' - Specifies that the external data will be entered into the local field in question<br />
* On Creation - specifies that this will only happen on the original login when the account is created for the first time.<br />
* On Every Login - specifies that changes in the external data will be updated on the local Moodle field in question the next time the user logs in again.<br />
<br />
'''Update External''' - Specifies just the opposite, meaning changes in the local Moodle field in question will update the corresponding field in the external database<br />
* Never - Specifies this is disabled<br />
* On Update - Enables this to happen if a change is made locally (additional configuration is probably required)<br />
<br />
'''Lock Value''' - Only determines whether the local user can make a change in the Moodle field and does not affect the two settings above.<br />
* Unlocked - A user can make changes locally in the Moodle field (assumably even if it contradicts the external database the next login would change it again if Update Local is set<br />
* Locked - A user can never make changes<br />
* Unlocked if empty - A user can only make changes if the field is not populated already from the external database (this would seem to indicate a user could only enter something into this field once and could not change it after saving)<br />
<br />
==See also==<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=45444 Special and characters con tilde (accute accent) when connected to external database] forum discussion<br />
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=75519 HELP!--User Authentication problem] forum discussion<br />
<br />
[[Category:Authentication]]<br />
<br />
[[fr:Utiliser une base de données externe]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Turnitin_administration&diff=41523Turnitin administration2008-08-06T13:18:12Z<p>Jsilve1: /* Overview */</p>
<hr />
<div>{{Moodle 2.0}}<br />
[[Image:Turnitin_admin.gif|thumb|Turnitin administration]]<br />
Location: ''Administration > Modules > Activities > Turnitin''<br />
<br />
==Overview==<br />
Turnitin is a commercial paper submission system, you must have a paid subscription to this service to use this feature. This integration is part of Moodle 2.0, and there is a 3rd party patch available for Moodle 1.9 users.<br />
<br />
The patch for 1.9 is available in this forum thread:<br />
<br />
http://moodle.org/mod/forum/discuss.php?d=98199<br />
<br />
Look for "TII_Integration_Patch_Beta_2.zip" as an attachment to one of the posts from Dan Marsden.<br />
<br />
Direct link to the patches:<br />
<br />
* [http://moodle.org/file.php/5/moddata/forum/117/434181/TII_Integration_Patch.zip TII_Integration_Patch.zip] released 29-MAY-2008 (my birthday :) (NOTE: This is the first patch and should not be used. It is listed here for historical reasons only)<br />
* [http://moodle.org/file.php/5/moddata/forum/117/447205/TII_Integration_Patch_Beta_2.zip TII_Integration_Patch_Beta_2.zip] released 14-JUL-2008 (Bastille day!)<br />
<br />
==Activation of your Turnitin Account==<br />
# obtain a Turnitin Subscription from [http://www.turnitin.com www.turnitin.com]<br />
# obtain an API Integration secret key from Turnitin Rep. - once you have a Turnitin Subscription, to obtain this you will need to send an e-mail to your Turnitin Account Rep - obtaining this secret key is free.<br />
<br />
==Global Configuration of Turnitin==<br />
# Ensure Admin > Server > Environment indicates you have curl installed<br />
# in the page Admin > Modules > Activities > Turnitin set the following:<br />
## Tick the box "Use Turnitin Submission"<br />
## Enter your Turnitin Account ID <br />
## Enter your Turnitin Secret Key as obtained from your Turnitin Account Rep<br />
## Elect whether to send students an e-mail to allow them to login to the turnitin.com site to view their submissions (this isn't necessary, and will likely cause your students more confusion, as all the information available in the website is available from your moodle site.) - even if no e-mail is sent, students can visit turnitin.com and use the forgotten password functionality on the turnitin site to get their password sent via e-mail. Admins can disable this by adding a prefix to all email accounts created - see below for details.<br />
## Add an e-mail prefix if you don't want students to be able to access the reports on turnitin.com - it is advised that you allow the integration in moodle to control what your students see, however, if you allow them to login to turnitin.com they can bypass the settings made regarding when a report should be available. - it's also possible that they could potentially upload a file to turnitin.com instead of moodle, which you may not notice. It's reccommended that you put something in this box to make the e-mail addresses for students stored on the turnitin.com system invalid.<br />
## Set a Course Prefix - this is not compulsory, however if you have more than 1 Moodle site connecting to the Turnitin API - eg a testing site, and a production site, then a prefix MUST be set, because Turnitin will only allow 1 course with the same name - and only 1 assignment within that course with the same name. - you will potentially get conflicts if this is not set.<br />
## Set a username, email-address, firstname and surname of a user that does not already exist in your Turnitin account. Turnitin only allows 1 teacher to be assigned to a course, so the integration needs to use a "global teacher" usercode that becomes the default Teacher (Turnitin refer to teachers as "instructors") to all assignments created in your moodle install.<br />
## Set the Student Disclosure statement. - this is displayed to all students on the upload screen to notify them that the Turnitin system is in use.<br />
<br />
==Configuration of Turnitin inside Moodle Activity Modules==<br />
===Assignment Module===<br />
(currently only available with the advanced file upload and single upload types)<br />
* Create a new Assignment within your course.<br />
* Enable Turnitin Submission<br />
<br />
==Debugging==<br />
* when testing the turnitin integration you should make sure debugging is turned on, as it will provide information regarding the process.<br />
* error codes recieved from the turnitin API are also logged in the mdl_tii_files table, so you can view issues with a production system.<br />
* each file that is going to be submitted to turnitin is added to the table mdl_tii_files - the field tiicode gives the "status" of the file, - there are 3 "good" states for this field:<br />
# "pending" - this is a new file that has been uploaded to an activity module, and needs to be submitted to Turnitin (will happen next time cron runs)<br />
# "51" - this is the turnitin API code for Successful upload - this means the file has been uploaded to Turnitin and we are waiting on an originality score,<br />
# "success" - this is a file that has been submitted, and a score has been provided for it.<br />
Any other response code in this field indicates an error state. - There is a Turnitin API document in the forums somewhere that I uploaded that details these error codes, and their meaning, I will add them to this wiki page at some point to help with debugging.</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Turnitin_administration&diff=41522Turnitin administration2008-08-06T13:17:39Z<p>Jsilve1: /* Overview */</p>
<hr />
<div>{{Moodle 2.0}}<br />
[[Image:Turnitin_admin.gif|thumb|Turnitin administration]]<br />
Location: ''Administration > Modules > Activities > Turnitin''<br />
<br />
==Overview==<br />
Turnitin is a commercial paper submission system, you must have a paid subscription to this service to use this feature. This integration is part of Moodle 2.0, and there is a 3rd party patch available for Moodle 1.9 users.<br />
<br />
The patch for 1.9 is available in this forum thread:<br />
<br />
http://moodle.org/mod/forum/discuss.php?d=98199<br />
<br />
Look for "TII_Integration_Patch_Beta_2.zip" as an attachment to one of the posts from Dan Marsden.<br />
<br />
Direct link to the patches:<br />
<br />
* [http://moodle.org/file.php/5/moddata/forum/117/434181/TII_Integration_Patch.zip TII_Integration_Patch.zip] released 29-MAY-2008 (my birthday:) (NOTE: This is the first patch and should not be used. It is listed here for historical reasons only)<br />
* [http://moodle.org/file.php/5/moddata/forum/117/447205/TII_Integration_Patch_Beta_2.zip TII_Integration_Patch_Beta_2.zip] released 14-JUL-2008 (Bastille day!)<br />
<br />
==Activation of your Turnitin Account==<br />
# obtain a Turnitin Subscription from [http://www.turnitin.com www.turnitin.com]<br />
# obtain an API Integration secret key from Turnitin Rep. - once you have a Turnitin Subscription, to obtain this you will need to send an e-mail to your Turnitin Account Rep - obtaining this secret key is free.<br />
<br />
==Global Configuration of Turnitin==<br />
# Ensure Admin > Server > Environment indicates you have curl installed<br />
# in the page Admin > Modules > Activities > Turnitin set the following:<br />
## Tick the box "Use Turnitin Submission"<br />
## Enter your Turnitin Account ID <br />
## Enter your Turnitin Secret Key as obtained from your Turnitin Account Rep<br />
## Elect whether to send students an e-mail to allow them to login to the turnitin.com site to view their submissions (this isn't necessary, and will likely cause your students more confusion, as all the information available in the website is available from your moodle site.) - even if no e-mail is sent, students can visit turnitin.com and use the forgotten password functionality on the turnitin site to get their password sent via e-mail. Admins can disable this by adding a prefix to all email accounts created - see below for details.<br />
## Add an e-mail prefix if you don't want students to be able to access the reports on turnitin.com - it is advised that you allow the integration in moodle to control what your students see, however, if you allow them to login to turnitin.com they can bypass the settings made regarding when a report should be available. - it's also possible that they could potentially upload a file to turnitin.com instead of moodle, which you may not notice. It's reccommended that you put something in this box to make the e-mail addresses for students stored on the turnitin.com system invalid.<br />
## Set a Course Prefix - this is not compulsory, however if you have more than 1 Moodle site connecting to the Turnitin API - eg a testing site, and a production site, then a prefix MUST be set, because Turnitin will only allow 1 course with the same name - and only 1 assignment within that course with the same name. - you will potentially get conflicts if this is not set.<br />
## Set a username, email-address, firstname and surname of a user that does not already exist in your Turnitin account. Turnitin only allows 1 teacher to be assigned to a course, so the integration needs to use a "global teacher" usercode that becomes the default Teacher (Turnitin refer to teachers as "instructors") to all assignments created in your moodle install.<br />
## Set the Student Disclosure statement. - this is displayed to all students on the upload screen to notify them that the Turnitin system is in use.<br />
<br />
==Configuration of Turnitin inside Moodle Activity Modules==<br />
===Assignment Module===<br />
(currently only available with the advanced file upload and single upload types)<br />
* Create a new Assignment within your course.<br />
* Enable Turnitin Submission<br />
<br />
==Debugging==<br />
* when testing the turnitin integration you should make sure debugging is turned on, as it will provide information regarding the process.<br />
* error codes recieved from the turnitin API are also logged in the mdl_tii_files table, so you can view issues with a production system.<br />
* each file that is going to be submitted to turnitin is added to the table mdl_tii_files - the field tiicode gives the "status" of the file, - there are 3 "good" states for this field:<br />
# "pending" - this is a new file that has been uploaded to an activity module, and needs to be submitted to Turnitin (will happen next time cron runs)<br />
# "51" - this is the turnitin API code for Successful upload - this means the file has been uploaded to Turnitin and we are waiting on an originality score,<br />
# "success" - this is a file that has been submitted, and a score has been provided for it.<br />
Any other response code in this field indicates an error state. - There is a Turnitin API document in the forums somewhere that I uploaded that details these error codes, and their meaning, I will add them to this wiki page at some point to help with debugging.</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Turnitin_administration&diff=41521Turnitin administration2008-08-06T13:15:19Z<p>Jsilve1: /* Overview */</p>
<hr />
<div>{{Moodle 2.0}}<br />
[[Image:Turnitin_admin.gif|thumb|Turnitin administration]]<br />
Location: ''Administration > Modules > Activities > Turnitin''<br />
<br />
==Overview==<br />
Turnitin is a commercial paper submission system, you must have a paid subscription to this service to use this feature. This integration is part of Moodle 2.0, and there is a 3rd party patch available for Moodle 1.9 users.<br />
<br />
The patch for 1.9 is available in this forum thread:<br />
<br />
http://moodle.org/mod/forum/discuss.php?d=98199#p451281<br />
<br />
Look for "TII_Integration_Patch_Beta_2.zip" as an attachment to one of the posts from Dan Marsden.<br />
<br />
Direct link to the patches:<br />
<br />
* http://moodle.org/file.php/5/moddata/forum/117/434181/TII_Integration_Patch.zip released 29-MAY-2008 (my birthday:) (NOTE: This is the first patch and should not be used. It is listed here for historical reasons only)<br />
* http://moodle.org/file.php/5/moddata/forum/117/447205/TII_Integration_Patch_Beta_2.zip released 14-JUL-2008 (Bastille day!)<br />
<br />
==Activation of your Turnitin Account==<br />
# obtain a Turnitin Subscription from [http://www.turnitin.com www.turnitin.com]<br />
# obtain an API Integration secret key from Turnitin Rep. - once you have a Turnitin Subscription, to obtain this you will need to send an e-mail to your Turnitin Account Rep - obtaining this secret key is free.<br />
<br />
==Global Configuration of Turnitin==<br />
# Ensure Admin > Server > Environment indicates you have curl installed<br />
# in the page Admin > Modules > Activities > Turnitin set the following:<br />
## Tick the box "Use Turnitin Submission"<br />
## Enter your Turnitin Account ID <br />
## Enter your Turnitin Secret Key as obtained from your Turnitin Account Rep<br />
## Elect whether to send students an e-mail to allow them to login to the turnitin.com site to view their submissions (this isn't necessary, and will likely cause your students more confusion, as all the information available in the website is available from your moodle site.) - even if no e-mail is sent, students can visit turnitin.com and use the forgotten password functionality on the turnitin site to get their password sent via e-mail. Admins can disable this by adding a prefix to all email accounts created - see below for details.<br />
## Add an e-mail prefix if you don't want students to be able to access the reports on turnitin.com - it is advised that you allow the integration in moodle to control what your students see, however, if you allow them to login to turnitin.com they can bypass the settings made regarding when a report should be available. - it's also possible that they could potentially upload a file to turnitin.com instead of moodle, which you may not notice. It's reccommended that you put something in this box to make the e-mail addresses for students stored on the turnitin.com system invalid.<br />
## Set a Course Prefix - this is not compulsory, however if you have more than 1 Moodle site connecting to the Turnitin API - eg a testing site, and a production site, then a prefix MUST be set, because Turnitin will only allow 1 course with the same name - and only 1 assignment within that course with the same name. - you will potentially get conflicts if this is not set.<br />
## Set a username, email-address, firstname and surname of a user that does not already exist in your Turnitin account. Turnitin only allows 1 teacher to be assigned to a course, so the integration needs to use a "global teacher" usercode that becomes the default Teacher (Turnitin refer to teachers as "instructors") to all assignments created in your moodle install.<br />
## Set the Student Disclosure statement. - this is displayed to all students on the upload screen to notify them that the Turnitin system is in use.<br />
<br />
==Configuration of Turnitin inside Moodle Activity Modules==<br />
===Assignment Module===<br />
(currently only available with the advanced file upload and single upload types)<br />
* Create a new Assignment within your course.<br />
* Enable Turnitin Submission<br />
<br />
==Debugging==<br />
* when testing the turnitin integration you should make sure debugging is turned on, as it will provide information regarding the process.<br />
* error codes recieved from the turnitin API are also logged in the mdl_tii_files table, so you can view issues with a production system.<br />
* each file that is going to be submitted to turnitin is added to the table mdl_tii_files - the field tiicode gives the "status" of the file, - there are 3 "good" states for this field:<br />
# "pending" - this is a new file that has been uploaded to an activity module, and needs to be submitted to Turnitin (will happen next time cron runs)<br />
# "51" - this is the turnitin API code for Successful upload - this means the file has been uploaded to Turnitin and we are waiting on an originality score,<br />
# "success" - this is a file that has been submitted, and a score has been provided for it.<br />
Any other response code in this field indicates an error state. - There is a Turnitin API document in the forums somewhere that I uploaded that details these error codes, and their meaning, I will add them to this wiki page at some point to help with debugging.</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Turnitin_administration&diff=41520Turnitin administration2008-08-06T13:15:03Z<p>Jsilve1: /* Overview */</p>
<hr />
<div>{{Moodle 2.0}}<br />
[[Image:Turnitin_admin.gif|thumb|Turnitin administration]]<br />
Location: ''Administration > Modules > Activities > Turnitin''<br />
<br />
==Overview==<br />
Turnitin is a commercial paper submission system, you must have a paid subscription to this service to use this feature. This integration is part of Moodle 2.0, and there is a 3rd party patch available for Moodle 1.9 users.<br />
<br />
The patch for 1.9 is available in this forum thread:<br />
<br />
http://moodle.org/mod/forum/discuss.php?d=98199#p451281<br />
<br />
Look for "TII_Integration_Patch_Beta_2.zip" as an attachment to one of the posts from Dan Marsden.<br />
<br />
Direct link to the patches:<br />
<br />
http://moodle.org/file.php/5/moddata/forum/117/434181/TII_Integration_Patch.zip released 29-MAY-2008 (my birthday:) (NOTE: This is the first patch and should not be used. It is listed here for historical reasons only)<br />
http://moodle.org/file.php/5/moddata/forum/117/447205/TII_Integration_Patch_Beta_2.zip released 14-JUL-2008 (Bastille day!)<br />
<br />
==Activation of your Turnitin Account==<br />
# obtain a Turnitin Subscription from [http://www.turnitin.com www.turnitin.com]<br />
# obtain an API Integration secret key from Turnitin Rep. - once you have a Turnitin Subscription, to obtain this you will need to send an e-mail to your Turnitin Account Rep - obtaining this secret key is free.<br />
<br />
==Global Configuration of Turnitin==<br />
# Ensure Admin > Server > Environment indicates you have curl installed<br />
# in the page Admin > Modules > Activities > Turnitin set the following:<br />
## Tick the box "Use Turnitin Submission"<br />
## Enter your Turnitin Account ID <br />
## Enter your Turnitin Secret Key as obtained from your Turnitin Account Rep<br />
## Elect whether to send students an e-mail to allow them to login to the turnitin.com site to view their submissions (this isn't necessary, and will likely cause your students more confusion, as all the information available in the website is available from your moodle site.) - even if no e-mail is sent, students can visit turnitin.com and use the forgotten password functionality on the turnitin site to get their password sent via e-mail. Admins can disable this by adding a prefix to all email accounts created - see below for details.<br />
## Add an e-mail prefix if you don't want students to be able to access the reports on turnitin.com - it is advised that you allow the integration in moodle to control what your students see, however, if you allow them to login to turnitin.com they can bypass the settings made regarding when a report should be available. - it's also possible that they could potentially upload a file to turnitin.com instead of moodle, which you may not notice. It's reccommended that you put something in this box to make the e-mail addresses for students stored on the turnitin.com system invalid.<br />
## Set a Course Prefix - this is not compulsory, however if you have more than 1 Moodle site connecting to the Turnitin API - eg a testing site, and a production site, then a prefix MUST be set, because Turnitin will only allow 1 course with the same name - and only 1 assignment within that course with the same name. - you will potentially get conflicts if this is not set.<br />
## Set a username, email-address, firstname and surname of a user that does not already exist in your Turnitin account. Turnitin only allows 1 teacher to be assigned to a course, so the integration needs to use a "global teacher" usercode that becomes the default Teacher (Turnitin refer to teachers as "instructors") to all assignments created in your moodle install.<br />
## Set the Student Disclosure statement. - this is displayed to all students on the upload screen to notify them that the Turnitin system is in use.<br />
<br />
==Configuration of Turnitin inside Moodle Activity Modules==<br />
===Assignment Module===<br />
(currently only available with the advanced file upload and single upload types)<br />
* Create a new Assignment within your course.<br />
* Enable Turnitin Submission<br />
<br />
==Debugging==<br />
* when testing the turnitin integration you should make sure debugging is turned on, as it will provide information regarding the process.<br />
* error codes recieved from the turnitin API are also logged in the mdl_tii_files table, so you can view issues with a production system.<br />
* each file that is going to be submitted to turnitin is added to the table mdl_tii_files - the field tiicode gives the "status" of the file, - there are 3 "good" states for this field:<br />
# "pending" - this is a new file that has been uploaded to an activity module, and needs to be submitted to Turnitin (will happen next time cron runs)<br />
# "51" - this is the turnitin API code for Successful upload - this means the file has been uploaded to Turnitin and we are waiting on an originality score,<br />
# "success" - this is a file that has been submitted, and a score has been provided for it.<br />
Any other response code in this field indicates an error state. - There is a Turnitin API document in the forums somewhere that I uploaded that details these error codes, and their meaning, I will add them to this wiki page at some point to help with debugging.</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Turnitin_administration&diff=41519Turnitin administration2008-08-06T13:11:56Z<p>Jsilve1: /* Overview */</p>
<hr />
<div>{{Moodle 2.0}}<br />
[[Image:Turnitin_admin.gif|thumb|Turnitin administration]]<br />
Location: ''Administration > Modules > Activities > Turnitin''<br />
<br />
==Overview==<br />
Turnitin is a commercial paper submission system, you must have a paid subscription to this service to use this feature. This integration is part of Moodle 2.0, and there is a 3rd party patch available for Moodle 1.9 users.<br />
<br />
The patch for 1.9 is available in this forum thread:<br />
<br />
http://moodle.org/mod/forum/discuss.php?d=98199#p451281<br />
<br />
Look for "TII_Integration_Patch_Beta_2.zip" as an attachment to one of the posts from Dan Marsden.<br />
<br />
==Activation of your Turnitin Account==<br />
# obtain a Turnitin Subscription from [http://www.turnitin.com www.turnitin.com]<br />
# obtain an API Integration secret key from Turnitin Rep. - once you have a Turnitin Subscription, to obtain this you will need to send an e-mail to your Turnitin Account Rep - obtaining this secret key is free.<br />
<br />
==Global Configuration of Turnitin==<br />
# Ensure Admin > Server > Environment indicates you have curl installed<br />
# in the page Admin > Modules > Activities > Turnitin set the following:<br />
## Tick the box "Use Turnitin Submission"<br />
## Enter your Turnitin Account ID <br />
## Enter your Turnitin Secret Key as obtained from your Turnitin Account Rep<br />
## Elect whether to send students an e-mail to allow them to login to the turnitin.com site to view their submissions (this isn't necessary, and will likely cause your students more confusion, as all the information available in the website is available from your moodle site.) - even if no e-mail is sent, students can visit turnitin.com and use the forgotten password functionality on the turnitin site to get their password sent via e-mail. Admins can disable this by adding a prefix to all email accounts created - see below for details.<br />
## Add an e-mail prefix if you don't want students to be able to access the reports on turnitin.com - it is advised that you allow the integration in moodle to control what your students see, however, if you allow them to login to turnitin.com they can bypass the settings made regarding when a report should be available. - it's also possible that they could potentially upload a file to turnitin.com instead of moodle, which you may not notice. It's reccommended that you put something in this box to make the e-mail addresses for students stored on the turnitin.com system invalid.<br />
## Set a Course Prefix - this is not compulsory, however if you have more than 1 Moodle site connecting to the Turnitin API - eg a testing site, and a production site, then a prefix MUST be set, because Turnitin will only allow 1 course with the same name - and only 1 assignment within that course with the same name. - you will potentially get conflicts if this is not set.<br />
## Set a username, email-address, firstname and surname of a user that does not already exist in your Turnitin account. Turnitin only allows 1 teacher to be assigned to a course, so the integration needs to use a "global teacher" usercode that becomes the default Teacher (Turnitin refer to teachers as "instructors") to all assignments created in your moodle install.<br />
## Set the Student Disclosure statement. - this is displayed to all students on the upload screen to notify them that the Turnitin system is in use.<br />
<br />
==Configuration of Turnitin inside Moodle Activity Modules==<br />
===Assignment Module===<br />
(currently only available with the advanced file upload and single upload types)<br />
* Create a new Assignment within your course.<br />
* Enable Turnitin Submission<br />
<br />
==Debugging==<br />
* when testing the turnitin integration you should make sure debugging is turned on, as it will provide information regarding the process.<br />
* error codes recieved from the turnitin API are also logged in the mdl_tii_files table, so you can view issues with a production system.<br />
* each file that is going to be submitted to turnitin is added to the table mdl_tii_files - the field tiicode gives the "status" of the file, - there are 3 "good" states for this field:<br />
# "pending" - this is a new file that has been uploaded to an activity module, and needs to be submitted to Turnitin (will happen next time cron runs)<br />
# "51" - this is the turnitin API code for Successful upload - this means the file has been uploaded to Turnitin and we are waiting on an originality score,<br />
# "success" - this is a file that has been submitted, and a score has been provided for it.<br />
Any other response code in this field indicates an error state. - There is a Turnitin API document in the forums somewhere that I uploaded that details these error codes, and their meaning, I will add them to this wiki page at some point to help with debugging.</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development_talk:Groups&diff=38987Development talk:Groups2008-06-30T15:52:15Z<p>Jsilve1: New page: What are Groups? Groups of courses? Groups of people? This fundamental question isn't really addressed on this doc page. Thanks!</p>
<hr />
<div>What are Groups? Groups of courses? Groups of people? This fundamental question isn't really addressed on this doc page.<br />
<br />
Thanks!</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Podcasting&diff=38260Podcasting2008-06-25T02:38:46Z<p>Jsilve1: </p>
<hr />
<div>'''Podcasting''' is an easy way to deliver a series of audio files in such a way that people can subscribe and have all current and future 'episodes' downloaded automatically to their computer or media player. <br />
<br />
== Podcasting in Moodle ==<br />
<br />
There are two possibilities for podcasting using Moodle:<br />
<br />
* Starting from Moodle 1.6, simply use the discussion forums tool! If you create a discussion forum and activate RSS feeds for the forum, you can simply post messages with media files as attachments. These will be delivered as podcasts in the [[RSS in forums|RSS feed]]. (''Note:'' This works in some situations and not in others, possibly based on whether or not guest users are able to view the forum. Otherwise the media files may not be accessible by the podcast-receiving software.)<br />
* Use the optional [[Ipodcast module]] which creates a specific podcasting activity type in Moodle. The advantage of this method is that it includes extra ''metadata'' designed to work well with Apple's ''iTunes'' software (such as keywords and category labels).<br />
<br />
== Podcasting about Moodle ==<br />
<br />
You may also like to know that a podcast ''about'' Moodle is in preparation, tentatively called "[[Portal:mCast|mCast]]".<br />
<br />
== Software for receiving podcasts ==<br />
<br />
* Apple's [http://www.apple.com/itunes/ iTunes] is currently one of the more popular pieces of software for subscribing to podcasts <br />
* [http://juicereceiver.sourceforge.net/ Juice] (previously known as ''iPodder'') which is open-source and available on Windows and Macintosh.<br />
* [http://getsongbird.com/ Songbird], a truly cross-platform, Open Source media player.<br />
* [http://www.gnome.org/projects/rhythmbox/ Rhythmbox] for the Gnome Desktop<br />
* [http://amarok.kde.org/ Amarok] for KDE<br />
<br />
==See also==<br />
<br />
* [[Screencast]]<br />
* [http://en.wikipedia.org/wiki/Podcasting Wikipedia article on podcasting]<br />
* [http://www.apple.com/podcasting Apple webpage on podcasting]<br />
<br />
[[Category:Teacher]]<br />
[[Category:Administrator]]<br />
[[Category:RSS]]<br />
[[pl:Podcasting]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Podcasting&diff=38259Podcasting2008-06-25T02:34:54Z<p>Jsilve1: </p>
<hr />
<div>'''Podcasting''' is an easy way to deliver a series of audio files in such a way that people can subscribe and have all current and future 'episodes' downloaded automatically to their computer or media player. <br />
<br />
== Podcasting in Moodle ==<br />
<br />
There are two possibilities for podcasting using Moodle:<br />
<br />
* Starting from Moodle 1.6, simply use the discussion forums tool! If you create a discussion forum and activate RSS feeds for the forum, you can simply post messages with media files as attachments. These will be delivered as podcasts in the [[RSS in forums|RSS feed]]. (''Note:'' This works in some situations and not in others, possibly based on whether or not guest users are able to view the forum. Otherwise the media files may not be accessible by the podcast-receiving software.)<br />
* Use the optional [[Ipodcast module]] which creates a specific podcasting activity type in Moodle. The advantage of this method is that it includes extra ''metadata'' designed to work well with Apple's ''iTunes'' software (such as keywords and category labels).<br />
<br />
== Podcasting about Moodle ==<br />
<br />
You may also like to know that a podcast ''about'' Moodle is in preparation, tentatively called "[[Portal:mCast|mCast]]".<br />
<br />
== Software for receiving podcasts ==<br />
<br />
* Apple's [http://www.apple.com/itunes/ iTunes] is currently one of the more popular pieces of software for subscribing to podcasts <br />
* [http://juicereceiver.sourceforge.net/ Juice] (previously known as ''iPodder'') which is open-source and available on Windows and Macintosh.<br />
* [http://www.gnome.org/projects/rhythmbox/ Rhythmbox] for the Gnome Desktop<br />
* [http://amarok.kde.org/ Amarok] for KDE<br />
<br />
==See also==<br />
<br />
* [[Screencast]]<br />
* [http://en.wikipedia.org/wiki/Podcasting Wikipedia article on podcasting]<br />
* [http://www.apple.com/podcasting Apple webpage on podcasting]<br />
<br />
[[Category:Teacher]]<br />
[[Category:Administrator]]<br />
[[Category:RSS]]<br />
[[pl:Podcasting]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Site_policies&diff=37747Site policies2008-06-16T16:43:56Z<p>Jsilve1: /* Disable user profile images */</p>
<hr />
<div>Location: ''Administration > Security > Site policies''<br />
<br />
<br />
==Open to Google==<br />
<br />
Enabling this setting allows Google's search spiders guest access to your site. Any part of the site that allows guest access will then be searchable on Google. In addition, people coming in to your site via a Google search will automatically be logged in as a guest.<br />
<br />
==Maximum uploaded file size==<br />
<br />
Probably the most frequently asked question in the Moodle.org Using Moodle forums is "How do I increase the upload file size limit?"<br />
<br />
Upload file sizes are restricted in a number of ways - each one in this list restricts the following ones:<br />
<br />
1. The Apache server setting LimitRequestBody ... default in Apache 2.x or greater is set to 0 or an unlimited upload size<br />
<br />
2. The PHP site settings post_max_size and upload_max_filesize in php.ini : '''modify php.ini in web server directories''' ( apache2.x.x/bin/php.ini ) not in php directories :<br />
<br />
post_max_size = 128M; to increase limit to 128 Megabytes;<br />
upload_max_filesize = 128M; to increase limit to 128 Megabytes;<br />
max_execution_time = 600 ; Maximum execution time of each script, in seconds;<br />
<br />
3. The Moodle site-wide maximum uploaded file size setting: ''Administration > Security > Site policies > Maximum uploaded file size [128M]''.<br />
<br />
4. The Moodle course maximum uploaded file size setting in the course settings: ''Administration > Courses > Add/Edit courses > select Course category & edit each course > Maximum upload size [128M]''.<br />
<br />
5. Certain course activity module settings (for example, Assignment)<br />
<br />
==Enable messaging system==<br />
<br />
Click the checkbox to enable site-wide [[Messaging]].<br />
<br />
Note: If you enable the messaging system, all users will be able to send and receive messages at any time. Teachers can't choose whether or not messaging is allowed between students in their particular course.<br />
<br />
==Force users to login==<br />
<br />
If you turn this setting on all users must login before they even see the front page of the site.<br />
<br />
==Force users to login for profiles==<br />
<br />
Leave this set to Yes to keep anonymous visitors away from user profiles. (See the Using Moodle forum discussion [http://moodle.org/mod/forum/discuss.php?d=89061 3rd party spam exploit possible? Help please!].)<br />
<br />
==Enable trusted content==<br />
<br />
Please refer to [[Development:Trusttext cleaning bypass]] for further information.<br />
<br />
==Maximum time to edit posts==<br />
<br />
This sets the editing time for forum postings. The editing time is the amount of time users have to change forum postings before they are mailed to subscribers.<br />
<br />
Please refer to the forum discussions [http://moodle.org/mod/forum/discuss.php?d=28679 Editing a forum post after the 30 minutes deadline] and [http://moodle.org/mod/forum/discuss.php?d=5367 The philosophy underlying "no editing after 30 minutes"]<br />
<br />
==Blog visibility==<br />
<br />
To enable [[Blogs]], select the level to which user blogs can be viewed.<br />
<br />
By default, all site users can see all blogs. Blog visibility may be restricted so that users can only see blogs for people whom they share a course with or whom they share a group with.<br />
<br />
Note: This setting is for specifying the maximum context of the VIEWER not the poster. To limit blogging to specific users only, a [[Blogger role]] should be created and users assigned to it in the system context.<br />
<br />
==Enable tags functionality==<br />
<br />
{{Moodle 1.9}}From Moodle 1.9 onwards, users may [[Tags|tag]] themselves and create interest pages around those tags.<br />
<br />
==Keep tag name casing==<br />
<br />
If checked, then tags like the following will be displayed: SOCCER, gUiTaR, MacDonalds, music<br />
<br />
If unchecked, then all tags will be displayed as follows: Soccer, Guitar, Macdonalds, Music<br />
<br />
Notes:<br />
* For English, off is useful.<br />
* For Japanese, no changes are made either way.<br />
* For languages where this kind of capitalization changes the meaning, it is best to keep this option on.<br />
<br />
==Password policy==<br />
<br />
{{Moodle 1.9}}From Moodle 1.9 onwards, a password policy may be set up, ensuring users choose passwords of a certain length etc.<br />
<br />
There is a check box to determine if password complexity should be enforced or not, the option to set the minimum length of the password, the minimum number of digits, the minimum number of lowercase characters, the minimum number of uppercase characters and the minimum number of non alphanumeric characters.<br />
<br />
If a user enters a password that does not meet those requirements, they are given an error message indicating the nature of the problem with the entered password.<br />
<br />
Enforcing password complexity along with requiring users to change their initial password go a long way in helping ensure that users choose and are in fact using "good passwords".<br />
<br />
==Disable user profile images==<br />
<br />
From Moodle 1.9 onwards, the ability for users to change their profile images may be disabled.<br />
<br />
'''How???'''<br />
<br />
== See also ==<br />
<br />
*[[Administration FAQ]]<br />
<br />
[[Category:Administrator]]<br />
<br />
[[fr:Règles site]]<br />
[[hu:Portál alapelvei]]<br />
[[ja:サイトポリシー]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=User:Jeffrey_Silverman&diff=36890User:Jeffrey Silverman2008-05-29T17:26:48Z<p>Jsilve1: /* About Me */</p>
<hr />
<div>=About Me=<br />
I am a Sysadmin/IT Specialist at MoodleRooms, Inc., headquartered in Baltimore, MD.</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development_talk:Coding&diff=36889Development talk:Coding2008-05-29T17:25:21Z<p>Jsilve1: /* Single vs Double quotes */</p>
<hr />
<div>== Single quotes vs. double quotes: no noticable speed differences... ==<br />
<br />
As PHP 4.3.0 is now the minimum version, the speed issue of single quotes vs. double quotes is negligible. See http://phplens.com/lens/php-book/optimizing-debugging-php.php, under "Useless Optimizations". There might be other reasons, however. I like to use "". ' is more convinient if a string has a lot of "s it it, like 'I have no "issues" with the "quotations"'. --[[User:Samuli Karevaara|Samuli Karevaara]] 04:26, 10 October 2006 (CDT)<br />
: I see that Martin changed the rationale, so single quotes should be used with strings that have parsed variables in them. However, Tim changed the example back to use double quotes :-) --[[User:Samuli Karevaara|Samuli Karevaara]] 00:13, 17 March 2008 (CDT)<br />
<br />
== Using clone() ==<br />
<br />
Unless I'm mistaken, there are some cases where we should use Moodle's full_clone() method. Maybe someone could clarify this...<br />
: Probably this bit under the item 9: "If the thing you want to copy is not an object, but may contain objects (eg an array of objects) then use fullclone() instead." --[[User:Samuli Karevaara|Samuli Karevaara]] 00:18, 17 March 2008 (CDT)<br />
<br />
== Single vs Double quotes ==<br />
<br />
According to the PHP.net manual page referenced, the memory usage issue for strings is not with single v double quotes, but with parsed variables in strings vs concatenated variables in strings.<br />
<br />
As a PHP developer, I find it is overall much better to use double quotes for strings if for no other reason than that you can stick newlines (\n) in. Putting newlines in makes HTML debugging MUCH easier.<br />
<br />
Just my $0.02.<br />
<br />
Thanks!<br />
<br />
(...some time later...) One more bit about quotes and parsed variables and speed optimizations.<br />
<br />
Benchmarks have shown that<br />
* there is no noticeable difference between single and double quotes for plain strings<br />
* There is no noticable difference between single and double quotes with concatenated vars (e.g. "string".$num vs 'string'.$num)<br />
* There IS, however, a performance penalty when double-quoted strings have a variable in them that needs to be parsed (e.g. "string$num")<br />
<br />
I noticed this problem as I was persusing some parts of Moodle 1.8 (the gradebook). Now, I know gradebook has been rewritten for 1.9, but it seems to me that all the occurrences of things like this:<br />
<br />
<pre>$thing = $preferences["$CFG->blah"];</pre><br />
<br />
Should have the double quotes removed! Having quotes in situations like that is ONLY adding a performance penalty, with no coding, readability, or other benefit at all.<br />
<br />
hmm... Mayhap this has been addressed already? I don't know. But I thought I would mention it. Also, this last bit might not have anything to do with the "coding style" guidlines, but I was already talking about single v double quotes so I thought I would add this also.<br />
<br />
== Classes and their methods ==<br />
<br />
There is nothing regarding classes and methods naming style. Is there an agreement on how to name classes and methods? I mean should I use "class lower_case_name" or "class CamelCaseName". And similar to methods - shall I type "function say_hello()" or "function sayHello()" if the function is a method of a class? --[[User:David Mudrak|David Mudrak]] 17:30, 10 May 2008 (CDT)<br />
<br />
: After a skype chat with Eloy and Petr, I added info about using lowercase in this case. --[[User:David Mudrak|David Mudrak]] 14:30, 11 May 2008 (CDT)<br />
<br />
No Camel Case. classes and methods should follow the same rules as functions: words_separated_by_underscores.--[[User:Tim Hunt|Tim Hunt]] 03:13, 12 May 2008 (CDT)</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development_talk:Coding&diff=36888Development talk:Coding2008-05-29T17:24:43Z<p>Jsilve1: /* Single vs Double quotes */</p>
<hr />
<div>== Single quotes vs. double quotes: no noticable speed differences... ==<br />
<br />
As PHP 4.3.0 is now the minimum version, the speed issue of single quotes vs. double quotes is negligible. See http://phplens.com/lens/php-book/optimizing-debugging-php.php, under "Useless Optimizations". There might be other reasons, however. I like to use "". ' is more convinient if a string has a lot of "s it it, like 'I have no "issues" with the "quotations"'. --[[User:Samuli Karevaara|Samuli Karevaara]] 04:26, 10 October 2006 (CDT)<br />
: I see that Martin changed the rationale, so single quotes should be used with strings that have parsed variables in them. However, Tim changed the example back to use double quotes :-) --[[User:Samuli Karevaara|Samuli Karevaara]] 00:13, 17 March 2008 (CDT)<br />
<br />
== Using clone() ==<br />
<br />
Unless I'm mistaken, there are some cases where we should use Moodle's full_clone() method. Maybe someone could clarify this...<br />
: Probably this bit under the item 9: "If the thing you want to copy is not an object, but may contain objects (eg an array of objects) then use fullclone() instead." --[[User:Samuli Karevaara|Samuli Karevaara]] 00:18, 17 March 2008 (CDT)<br />
<br />
== Single vs Double quotes ==<br />
<br />
According to the PHP.net manual page referenced, the memory usage issue for strings is not with single v double quotes, but with parsed variables in strings vs concatenated variables in strings.<br />
<br />
As a PHP developer, I find it is overall much better to use double quotes for strings if for no other reason than that you can stick newlines (\n) in. Putting newlines in makes HTML debugging MUCH easier.<br />
<br />
Just my $0.02.<br />
<br />
Thanks!<br />
<br />
(...some time later...) One more bit about quotes and parsed variables and speed optimizations.<br />
<br />
Benchmarks have shown that<br />
* there is no noticeable difference between single and double quotes for plain strings<br />
* There is no noticable difference between single and double quotes with concatenated vars (e.g. "string".$num vs 'string'.$num)<br />
* There IS, however, a performance penalty when double-quoted strings have a variable in them that needs to be parsed (e.g. "string$num")<br />
<br />
I noticed this problem as I was persusing some parts of Moodle 1.8 (the gradebook). Now, I know gradebook has been rewritten for 1.9, but it seems to me that all the occurrences of things like this:<br />
<br />
$thing = $preferences["$CFG->blah"];<br />
<br />
Should have the double quotes removed! Having quotes in situations like that is ONLY adding a performance penalty, with no coding, readability, or other benefit at all.<br />
<br />
hmm... Mayhap this has been addressed already? I don't know. But I thought I would mention it. Also, this last bit might not have anything to do with the "coding style" guidlines, but I was already talking about single v double quotes so I thought I would add this also.<br />
<br />
== Classes and their methods ==<br />
<br />
There is nothing regarding classes and methods naming style. Is there an agreement on how to name classes and methods? I mean should I use "class lower_case_name" or "class CamelCaseName". And similar to methods - shall I type "function say_hello()" or "function sayHello()" if the function is a method of a class? --[[User:David Mudrak|David Mudrak]] 17:30, 10 May 2008 (CDT)<br />
<br />
: After a skype chat with Eloy and Petr, I added info about using lowercase in this case. --[[User:David Mudrak|David Mudrak]] 14:30, 11 May 2008 (CDT)<br />
<br />
No Camel Case. classes and methods should follow the same rules as functions: words_separated_by_underscores.--[[User:Tim Hunt|Tim Hunt]] 03:13, 12 May 2008 (CDT)</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Development_talk:Coding&diff=33502Development talk:Coding2008-03-12T16:24:59Z<p>Jsilve1: Single vs Double quotes</p>
<hr />
<div>== Single quotes vs. double quotes: no noticable speed differences... ==<br />
<br />
As PHP 4.3.0 is now the minimum version, the speed issue of single quotes vs. double quotes is negligible. See http://phplens.com/lens/php-book/optimizing-debugging-php.php, under "Useless Optimizations". There might be other reasons, however. I like to use "". ' is more convinient if a string has a lot of "s it it, like 'I have no "issues" with the "quotations"'. --[[User:Samuli Karevaara|Samuli Karevaara]] 04:26, 10 October 2006 (CDT)<br />
<br />
== Using clone() ==<br />
<br />
Unless I'm mistaken, there are some cases where we should use Moodle's full_clone() method. Maybe someone could clarify this...<br />
<br />
== Single vs Double quotes ==<br />
<br />
According to the PHP.net manual page referenced, the memory usage issue for strings is not with single v double quotes, but with parsed variables in strings vs concatenated variables in strings.<br />
<br />
As a PHP developer, I find it is overall much better to use double quotes for strings if for no other reason than that you can stick newlines (\n) in. Putting newlines in makes HTML debugging MUCH easier.<br />
<br />
Just my $0.02.<br />
<br />
Thanks!</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=User:Jeffrey_Silverman&diff=26395User:Jeffrey Silverman2007-08-28T14:03:31Z<p>Jsilve1: </p>
<hr />
<div>=About Me=<br />
I am a developer at The Johns Hopkins University in Baltimore, MD. I work for (this is long) Whiting School of Engineering's Engineering Programs for Professionals On-line Programs. (i.e. "Distance Ed")</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Blackboard_migration&diff=26394Blackboard migration2007-08-28T14:01:57Z<p>Jsilve1: /* Example Migration of One Test Course */</p>
<hr />
<div>A [http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard content conversion tool] is available. It was designed to migrate Blackboard 6.1 to Moodle 1.4+ - it may be possible to make it work with other versions.<br />
<br />
According to Michael Penney in the forum discussion [http://moodle.org/mod/forum/discuss.php?d=1565 Migrating 10000 students from Blackboard to Moodle?] <br />
<br />
:''"It works pretty well with a couple of caveats:''<br />
<br />
:''1) It doesn't import all Blackboard question types: at CSU H, we wrote an essay question type and a 'rendered match' question type and a BB pool importer, we'd like to work with SF and others to get our qtype importer into theirs.''<br />
<br />
:''2) SF's tool is designed to make you think about your course when you import it and redesign it. That is a nice idea, however it can be pretty time consuming when you have hundreds of documents in a course (<rant>Blackboard's poor content development tools encourage what I call the 'datadump' course format, instead of delivering information in an effective elearning tool like Moodle's lesson, with BB folks tend to post hundreds of office documents and then massive quizzes about them</rant>).''"<br />
<br />
We recently migrated about 200 courses from Blackboard 6 to Moodle 1.5+, and I made a [http://instructor.metrotech.org/~mcampbell/Converting%20Blackboard%20to%20Moodle.ppt PowerPoint] for this routine. I've been asked to make a Captivate just on the import routine and will work on that.<br />
<br />
==Example Migration of One Test Course==<br />
'''by [[User:Jeffrey Silverman|Jeff Silverman]], The Johns Hopkins University'''<br />
''(Note: I am a novice Moodler. This is a description of what I did to move a single exported BlackBoard course to my out-of-the-box Moodle test installation. I had a number of questions about the process and I hope this example helps answer them for someone else.)''<br />
<br />
===When===<br />
This test procedure was performed during the week of 20-Aug-2007<br />
<br />
===Versions===<br />
* Moodle 1.8<br />
* BlackBoard 7.1 "basic" (unconfirmed)<br />
<br />
===Procedure===<br />
# Export course content from Bb. This step was done by someone else! I do not know how to do this, what options were chosen, etc. I do know that I got a .zip file that I think is a "Course Archive".<br />
# Import course into Moodle. (Needs to be done by a user with the necessary privileges. I have only one user in my Moodle installation, the "Admin" user, and he (she?) is the "Site Administrator").<br />
## Create new course<br />
## Go to "Restore" under the course administrative tools<br />
## Choose a file to upload; upload the Bb .zip file<br />
## Choose "import" -- in another page or two you will get to say to restore this as a "New Course"<br />
<br />
===Questions===<br />
Some of my questions were as follows:<br />
<br />
# Do you have to create a new course?<br />
## Aparent answer: YES. Personally, I found this very counter-intuitive, as "importing a course" or "restore from backup" or other similar administrative tasks seem to me to be on a level outside a specific course. For example, having the "Restore" feature only available in the admin tools for a particular course makes it seem like the restoration will only work for that course -- but that is not true. You can use any course's "Restore" link in the admin tools and choose "Create a New Course" mid-way through the retoration procedure. But creating a new course from backup that has nothing to do with the course in which one has clicked the "Restore" link is, like I said, counter-intuitive. And, to top it off, I could find no mention of this until I had already clicked on "Restore". Looks like I need to add some information to the "administrative tools" or "backup/restore" docs, hm? :)<br />
# Is there a specific "Bb-to-Moodle" conversion tool?<br />
## Answer: NO. Unlike the WebCT-to-Moodle conversion, [[http://moodle.org/mod/data/view.php?d=13&rid=94 which requires a specific add-on]], Bb conversion is now built in.<br />
# What format does the Bb export have to be in?<br />
# What versions of Bb and Moodle will this work for?<br />
# There is a tool floating around called "[[http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard Content Conversion Tool (CCT)]]" that sounds useful for converting Bb to Moodle. Do I need it?<br />
## Answer: NO. Actually, I had a bunch of questions about that tool, too, but ultimately I did not need it.<br />
### Does the CCT run on the server where Bb is running?<br />
### Does it interact, somehow, directly with the Bb instance?<br />
### Or does it run on the Moodle server and do the import from Bb into Moodle?<br />
# Others...<br />
<br />
==See also==<br />
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=78521 Migrate a course from Blackboard to Moodle] forum discussion<br />
<br />
[[Category:Administrator]]<br />
[[Category:Developer]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Blackboard_migration&diff=26393Blackboard migration2007-08-28T14:00:44Z<p>Jsilve1: </p>
<hr />
<div>A [http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard content conversion tool] is available. It was designed to migrate Blackboard 6.1 to Moodle 1.4+ - it may be possible to make it work with other versions.<br />
<br />
According to Michael Penney in the forum discussion [http://moodle.org/mod/forum/discuss.php?d=1565 Migrating 10000 students from Blackboard to Moodle?] <br />
<br />
:''"It works pretty well with a couple of caveats:''<br />
<br />
:''1) It doesn't import all Blackboard question types: at CSU H, we wrote an essay question type and a 'rendered match' question type and a BB pool importer, we'd like to work with SF and others to get our qtype importer into theirs.''<br />
<br />
:''2) SF's tool is designed to make you think about your course when you import it and redesign it. That is a nice idea, however it can be pretty time consuming when you have hundreds of documents in a course (<rant>Blackboard's poor content development tools encourage what I call the 'datadump' course format, instead of delivering information in an effective elearning tool like Moodle's lesson, with BB folks tend to post hundreds of office documents and then massive quizzes about them</rant>).''"<br />
<br />
We recently migrated about 200 courses from Blackboard 6 to Moodle 1.5+, and I made a [http://instructor.metrotech.org/~mcampbell/Converting%20Blackboard%20to%20Moodle.ppt PowerPoint] for this routine. I've been asked to make a Captivate just on the import routine and will work on that.<br />
<br />
==Example Migration of One Test Course==<br />
'''by [[User:Jeffrey Silverman]], The Johns Hopkins University'''<br />
''(Note: I am a novice Moodler. This is a description of what I did to move a single exported BlackBoard course to my out-of-the-box Moodle test installation. I had a number of questions about the process and I hope this example helps answer them for someone else.)''<br />
<br />
===When===<br />
This test procedure was performed during the week of 20-Aug-2007<br />
<br />
===Versions===<br />
* Moodle 1.8<br />
* BlackBoard 7.1 "basic" (unconfirmed)<br />
<br />
===Procedure===<br />
# Export course content from Bb. This step was done by someone else! I do not know how to do this, what options were chosen, etc. I do know that I got a .zip file that I think is a "Course Archive".<br />
# Import course into Moodle. (Needs to be done by a user with the necessary privileges. I have only one user in my Moodle installation, the "Admin" user, and he (she?) is the "Site Administrator").<br />
## Create new course<br />
## Go to "Restore" under the course administrative tools<br />
## Choose a file to upload; upload the Bb .zip file<br />
## Choose "import" -- in another page or two you will get to say to restore this as a "New Course"<br />
<br />
===Questions===<br />
Some of my questions were as follows:<br />
<br />
# Do you have to create a new course?<br />
## Aparent answer: YES. Personally, I found this very counter-intuitive, as "importing a course" or "restore from backup" or other similar administrative tasks seem to me to be on a level outside a specific course. For example, having the "Restore" feature only available in the admin tools for a particular course makes it seem like the restoration will only work for that course -- but that is not true. You can use any course's "Restore" link in the admin tools and choose "Create a New Course" mid-way through the retoration procedure. But creating a new course from backup that has nothing to do with the course in which one has clicked the "Restore" link is, like I said, counter-intuitive. And, to top it off, I could find no mention of this until I had already clicked on "Restore". Looks like I need to add some information to the "administrative tools" or "backup/restore" docs, hm? :)<br />
# Is there a specific "Bb-to-Moodle" conversion tool?<br />
## Answer: NO. Unlike the WebCT-to-Moodle conversion, [[http://moodle.org/mod/data/view.php?d=13&rid=94 which requires a specific add-on]], Bb conversion is now built in.<br />
# What format does the Bb export have to be in?<br />
# What versions of Bb and Moodle will this work for?<br />
# There is a tool floating around called "[[http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard Content Conversion Tool (CCT)]]" that sounds useful for converting Bb to Moodle. Do I need it?<br />
## Answer: NO. Actually, I had a bunch of questions about that tool, too, but ultimately I did not need it.<br />
### Does the CCT run on the server where Bb is running?<br />
### Does it interact, somehow, directly with the Bb instance?<br />
### Or does it run on the Moodle server and do the import from Bb into Moodle?<br />
# Others...<br />
<br />
==See also==<br />
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=78521 Migrate a course from Blackboard to Moodle] forum discussion<br />
<br />
[[Category:Administrator]]<br />
[[Category:Developer]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Blackboard_migration&diff=26392Blackboard migration2007-08-28T13:56:40Z<p>Jsilve1: </p>
<hr />
<div>A [http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard content conversion tool] is available. It was designed to migrate Blackboard 6.1 to Moodle 1.4+ - it may be possible to make it work with other versions.<br />
<br />
According to Michael Penney in the forum discussion [http://moodle.org/mod/forum/discuss.php?d=1565 Migrating 10000 students from Blackboard to Moodle?] <br />
<br />
:''"It works pretty well with a couple of caveats:''<br />
<br />
:''1) It doesn't import all Blackboard question types: at CSU H, we wrote an essay question type and a 'rendered match' question type and a BB pool importer, we'd like to work with SF and others to get our qtype importer into theirs.''<br />
<br />
:''2) SF's tool is designed to make you think about your course when you import it and redesign it. That is a nice idea, however it can be pretty time consuming when you have hundreds of documents in a course (<rant>Blackboard's poor content development tools encourage what I call the 'datadump' course format, instead of delivering information in an effective elearning tool like Moodle's lesson, with BB folks tend to post hundreds of office documents and then massive quizzes about them</rant>).''"<br />
<br />
We recently migrated about 200 courses from Blackboard 6 to Moodle 1.5+, and I made a [http://instructor.metrotech.org/~mcampbell/Converting%20Blackboard%20to%20Moodle.ppt PowerPoint] for this routine. I've been asked to make a Captivate just on the import routine and will work on that.<br />
<br />
==Example Migration of One Test Course==<br />
'''by [[User:Jeffrey Silverman]], The Johns Hopkins University'''<br />
''(Note: I am a novice Moodler. This is a description of what I did to move a single exported BlackBoard course to my out-of-the-box Moodle test installation. I had a number of questions about the process and I hope this example helps answer them for someone else.)''<br />
<br />
When: This test procedure was performed during the week of 20-Aug-2007<br />
<br />
Versions:<br />
* Moodle 1.8<br />
* BlackBoard 7.1 "basic" (unconfirmed)<br />
<br />
# Export course content from Bb. This step was done by someone else! I do not know how to do this, what options were chosen, etc. I do know that I got a .zip file that I think is a "Course Archive".<br />
# Import course into Moodle. (Needs to be done by a user with the necessary privileges. I have only one user in my Moodle installation, the "Admin" user, and he (she?) is the "Site Administrator").<br />
## Create new course<br />
## Go to "Restore" under the course administrative tools<br />
## Choose a file to upload; upload the Bb .zip file<br />
## Choose "import" -- in another page or two you will get to say to restore this as a "New Course"<br />
<br />
Some of my questions were as follows:<br />
<br />
# Do you have to create a new course?<br />
** Aparent answer: YES. Personally, I found this very counter-intuitive, as "importing a course" or "restore from backup" or other similar administrative tasks seem to me to be on a level outside a specific course. For example, having the "Restore" feature only available in the admin tools for a particular course makes it seem like the restoration will only work for that course -- but that is not true. You can use any course's "Restore" link in the admin tools and choose "Create a New Course" mid-way through the retoration procedure. But creating a new course from backup that has nothing to do with the course in which one has clicked the "Restore" link is, like I said, counter-intuitive. And, to top it off, I could find no mention of this until I had already clicked on "Restore". Looks like I need to add some information to the "administrative tools" or "backup/restore" docs, hm? :)<br />
# Is there a specific "Bb-to-Moodle" conversion tool?<br />
** Answer: NO. Unlike the WebCT-to-Moodle conversion, [[http://moodle.org/mod/data/view.php?d=13&rid=94 which requires a specific add-on]], Bb conversion is now built in.<br />
# What format does the Bb export have to be in?<br />
# What versions of Bb and Moodle will this work for?<br />
# There is a tool floating around called "[[http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard Content Conversion Tool (CCT)]]" that sounds useful for converting Bb to Moodle. Do I need it?<br />
* Answer: NO. Actually, I had a bunch of questions about that tool, too, but ultimately I did not need it.<br />
** Does the CCT run on the server where Bb is running?<br />
** Does it interact, somehow, directly with the Bb instance?<br />
** Or does it run on the Moodle server and do the import from Bb into Moodle?<br />
# Others...<br />
<br />
==See also==<br />
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=78521 Migrate a course from Blackboard to Moodle] forum discussion<br />
<br />
[[Category:Administrator]]<br />
[[Category:Developer]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=Blackboard_migration&diff=26281Blackboard migration2007-08-24T16:44:37Z<p>Jsilve1: </p>
<hr />
<div>A [http://moodle.org/mod/forum/discuss.php?d=32049 Blackboard content conversion tool] is available. It was designed to migrate Blackboard 6.1 to Moodle 1.4+ - it may be possible to make it work with other versions.<br />
<br />
According to Michael Penney in the forum discussion [http://moodle.org/mod/forum/discuss.php?d=1565 Migrating 10000 students from Blackboard to Moodle?] <br />
<br />
:''"It works pretty well with a couple of caveats:''<br />
<br />
:''1) It doesn't import all Blackboard question types: at CSU H, we wrote an essay question type and a 'rendered match' question type and a BB pool importer, we'd like to work with SF and others to get our qtype importer into theirs.''<br />
<br />
:''2) SF's tool is designed to make you think about your course when you import it and redesign it. That is a nice idea, however it can be pretty time consuming when you have hundreds of documents in a course (<rant>Blackboard's poor content development tools encourage what I call the 'datadump' course format, instead of delivering information in an effective elearning tool like Moodle's lesson, with BB folks tend to post hundreds of office documents and then massive quizzes about them</rant>).''"<br />
<br />
We recently migrated about 200 courses from Blackboard 6 to Moodle 1.5+, and I made a [http://instructor.metrotech.org/~mcampbell/Converting%20Blackboard%20to%20Moodle.ppt PowerPoint] for this routine. I've been asked to make a Captivate just on the import routine and will work on that.<br />
<br />
==Example Migration of One Test Course==<br />
'''by [[User:Jeffrey Silverman]], The Johns Hopkins University'''<br />
''(Note: I am a novice Moodler. This is a description of what I did to move a single exported BlackBoard course to my out-of-the-box Moodle test installation. I had a number of questions about the process and I hope this example helps answer them for someone else.)''<br />
<br />
When: This test procedure was performed during the week of 20-Aug-2007<br />
<br />
Versions:<br />
* Moodle 1.8<br />
* BlackBoard 7.1 "basic" (unconfirmed)<br />
<br />
# Export course content from Bb. This step was done by someone else! I do not know how to do this, what options were chosen, etc. I do know that I got a .zip file that I think is a "Course Archive".<br />
# Import course into Moodle. (Needs to be done by a user with the necessary privileges. I have only one user in my Moodle installation, the "Admin" user, and he (she?) is the "Site Administrator").<br />
## Create new course<br />
## Go to "Restore" under the course administrative tools<br />
## Choose a file to upload; upload the Bb .zip file<br />
## Choose "import" -- in another page or two you will get to say to restore this as a "New Course"<br />
<br />
So my questions were as follows:<br />
<br />
# Do you have to create a new course?<br />
# Others.... I will update this later after I put out this fire...<br />
<br />
[[Category:Administrator]]<br />
[[Category:Developer]]</div>Jsilve1https://docs.moodle.org/34/en/index.php?title=User:Jeffrey_Silverman&diff=26280User:Jeffrey Silverman2007-08-24T16:42:34Z<p>Jsilve1: </p>
<hr />
<div>I am a developer at The Johns Hopkins University in Baltimore, MD.</div>Jsilve1