Beginning Administration 1 FAQ

There is always an element of frustration at the beginning of taking on a Moodle. For many of us, we are employed to do something else, but fall into this. While we have some knowledge or skills, we can often be stumped by the simple things. Not because we are not skilled, just we do not understand enough of the jargon surrounding Moodle to make it work for us. What many people have found is that they are pushing against a door that was never shut. Not a good analogy perhaps, but it does describe what can happen when we begin Administration of a Moodle.

Most of the questions and answers here can be located somewhere in the Forums, or the Moodle Docs, if you want to spend the time looking for them. All this FAQ does is concentrate some of the questions you may be asking in one place. Thanks to all the unknowing and unknown contributors.

This page has grown a bit quickly and is now over sized. So more pages have been added named Beginning Administration 2 FAQ and Beginning Administration 3 FAQ. A number of questions relating to specific, popular, areas have now been moved. One is the Front Page FAQ and the Xampp Installer FAQ, others will probably follow.

For the moment, ALL answers here relate specifically to Moodle 1.9.x and some earlier versions (e.g. 1.7 and 1.8). Moodle 2.0 questions are not answered here.

For more specific information about Moodle 2.0.x try Beginning Moodle 2.0 Administration.

Beginning Administration 2 FAQ

Xampp Installer FAQ

I want to create a new site in Moodle, but which version should I use? 1.9. or 2.0.

In December 2010 this is a tough call. If you pick 1.9.9 to .11, you should probably plan on upgrading to Moodle 2.0 after it has been out a while (say June 2011). There were many changes made to the Moodle's User Interface and underlying structure in 2.0. In any major new release there are always minor things that are discovered even after extensive testing.

Remember that moodle.org has switched to 2.0 and so have a few other large sites including demo.moodle.net, so it is stable. In the longer run, a new site might focus upon adding content to their new 2.0 site, stay away from any customization of underlying code and plan on upgrading every month or so. Then having used it for a while, consider what tweaks to make or add.

There is also the "old dog, new tricks" effect to consider. Do you want to start with one interface and code set, then switch later and have to relearn some things? You maybe fine, but what about your teachers? They are less likely to notice changes in a 2.0 build update and we can guarantee that going from 1.9x to 2.x is a big change that will not escape their notice.

UPDATE: May 2011. Moodle 2.0.3 has been released and v2.1 has been announced for release in the near future. It is now obvious that new installations of v2.0.x are considerably more advantageous to the User than beginning with a v1.9.12 then changing at some, usually unspecified, time in the future.

How can I get an overview of using Moodle?

There are any number of books about Moodle 1.9.x. Perhaps the most immediately useful book is the Using Moodle book by Helen Foster and Jason Cole. While aimed more at using rather than administration, this book is a handy tool to work out many things about how the administration of your Moodle impacts on how Moodle can be used.

What do I really need to know about HTML, Javascript, PHP and MySQL or networking to be a successful Administrator?

Not a lot. Certainly you should know something about HTML and there are lots of web sites and books on this subject. Generally speaking in Moodle, Javascript is a mid-level skill and, PHP and MySQL are advanced skills. If you are really interested in gaining more skills in these programs, there are lots of free to low cost to professional certification paths to follow. There are web sites around that will get you started with minimal cost. There are plenty of books as well. Individualized professional coaching/mentoring/consulting or certified training in several areas is obviously more expensive. Understanding Networking will also come in handy. The more your site is customized from the standard Moodle package, the more you may need these skills.

What tools do I need to use in the Administration of my Moodle

Different environments will allow to you use some different tools, but essentially, you can get away with just a text editor. There are any number of text editors, but use one that can save the files in a UTF-8 format. For Windows users, Notepad++, TextPad are two that come to mind and there are a lot more, but not Windows' native Notepad. (Windows Notepad is not fully UTF-8 compliant. Some of its own characters will not be read properly in PHP and Notepad may add additional spaces and end of line or end of file markers that will not be rendered in PHP or rendered badly, crashing the whole site.)

Installation on a Windows or a Linux server

There are a great many Moodle documentation pages on this subject. The available Xampp/Windows version of Moodle is workable, but for a larger production (a site with many users, courses and volume) Linux is the strongly recommended operating system. The simple truth is that it is easier to mirror and load share using Linux than Windows. Building and learning how to use Moodle is easier in Windows. However in the longer term, a Linux based installation is far stronger and thus a much better learning environment to start with for any Administrator. It is suggested that if you can, set up a Moodle in both environments, Ubuntu, SuseLinux and Debian are now relatively easy to install and configure. As for Windows, XP seems more stable than Vista. Windows 7 is reputed to be better than both earlier versions, but as Microsoft is intent on "automating" everything, it appears to be placing more stubborn blocks into the path of the installation of many useful applications. Use of Home versions in MS operating systems is not recommended for any production site.

Linux is probably better at things like clustering and mirroring. Moodle Clusters or Mirroring Moodle are two pages which are developing information about these topics that are useful for larger or more active sites.

Which leads me to which version of Moodle should I use then?

Obviously the constant updating processes available for Moodle should provide the opportunity for you to keep your Moodle current. But the reality is that we do not always have time to update to the latest release (consider reconstructing tweaks or going from 1.9 to 2.0). If you schedule regular updates, say one per month or one per quarter, this is still somewhat intensive. Most Moodle sites would be perfectly serviceable with a twice annual update, but it is entirely up to you, as the administrator, or the Moodle owners. It is a decision that should be made right at the outset of setting up the first Moodle. The best bet is to use the latest stable version, however often you want to update it. See the "I want to create a new site in Moodle, but which version should I use? 1.9. or 2.0." question.

Should I use a test site to try things out?

As a general tip, if you have a production site, that is a site that is being used by students or other enrolled persons on a regular basis, then it is a good investment to have a test site. This test site is used by you, the administrator, alone. In it, you can replicate your production site or any aspect of it, by taking a backup of something from your production site and restoring it to your test site. Try out something in this test Moodle first. This way you will always be on top of changes before you make them. If something goes wrong with your test site, it is simple to reinstall.

For some circumstances, the Windows Xaampp installer may be a better choice for a Windows environment, and while it may not replicate specific server environmental problems, it is handy for a lot of other things. As an alternative, in either a Linux or Windows environment, if you need something specific, once your site is working, back it up and then restore it under a different folder in the web root. As long as no-one knows it is there, and there are no public links to it, then you are the only one who may access it. Of course, you can always make sure that no-one but you can enter the test site. You may not want to do that on one server - due to hosting constraints, so you may chose to create a separate installation on a different computer, which does make it easier to wreck your test site then restore it quickly.

Top

Why am I just not getting how Permissions and Roles work?

A new site administrator's understanding of permissions and Roles is usually based on their networking environment knowledge. In short: we log in, we are given a set of permission based on that log in and these permissions determine what we can do in a single context. This "linear" explanation is based on what we see, not what really happens, of course.

In Moodle, permissions are also known as "capabilities" and they reside with the Role and can be dependent upon the users location/activity in Moodle. The log-in ID does not carry any traditional network permissions with it, but an initial Role. So stop worrying about trying to learn about permissions, concentrate on the Role and how that works. Once you have a solid grasp of each Role, then you can worry about setting permissions.

Roles are context based. The best advice is DO NOT assign any roles from the Front Page. If you assign a Role in the Front Page, that Role is assigned to every part of the site. A best practice is to only assign Roles within the context of a Course or a Category.

What different roles can apply to users as they log in and move around inside the Moodle?

Only one of many roles (a set of permissions) can be given to a users at log in. As the user moves to different pages, they can specifically or generically (if they belong to a group of users) be assigned new roles for that just that area, or context. Here are some concepts that might help.

Before anyone logs in to the Moodle, sitting at the log in page, or public front page, depending how you have set your Moodle up, they should have the role of "Guest". It is possible to change this but be careful.

In Moodle, when anyone with a user name and password logs into the Moodle, they become an "Authenticated User". How they are authenticated is different from their Role. At this point the contextual nature of Roles kicks in and determines permissions for every user, everywhere a User goes in the site a context is applied.

For reasons explained below, you may want your Users to become "Students" while in the Front Page. (Be careful here, read on below before assigning roles.)

When they click to go to a Category page, they revert to an "Authenticated User". Once there, their User Name is scanned and their permissions are calculated and if they have permissions, they can have sufficient rights to be a "Teacher" or a "Course Creator" or even an "Administrator", but for most people it will probably remain at Authenticated User.

When they click to go to a Course, they may have the rights to be an "Administrator", a "Course Creator", a "Teacher" or a "Student" in that Course.

This does not mean they have any of those rights in any other Category or Course. The Role assigned in one context may not apply in any other context.

How can I be sure I am assigning Roles correctly?

Assigning Roles should be based purely on the page or activity (the context) and the role you want that person(s) to play.

The first question is "what do I want this person to be able to do?" For most people using the Moodle, the obvious Role will be that of Student. Others will need to be Course Creators or Teachers. Some Teachers will be Course Creators. Really, the first question should be "what do I want this person to be able to do HERE?"

Essentially, if you get it wrong, then your courses can be wrecked. The basic rules are simple, "Do not assign a role in the Front Page." and "Assign roles in the context of the course or Category."

Be aware, if you create an Administrator role in a Category, that will apply across all sub-Categories and Courses in that Category. It will not apply to ANY other Category, sub-Categories or Courses. If someone is assigned the Role of "Teacher" at a Category level, that Role will apply in ALL sub-Categories and Courses in that Category.

Top

I changed some Roles and things have gone terribly wrong, I cannot log in as Administrator

Chances are you have changed your Administrator Role, happens all the time and is easily fixed - if you have kept backups of your database. This problem is often caused by changing the default role for all users. Sometimes Administrators include themselves as part of the Role change - thus the problem. Open phpMyAdmin, and if you do not have it installed then do so, but if you are on a network use the full version, not the Moodle plugin - for your own security. Open the database and go to mdl_user table. Check for your own id and make sure you know your own id number. Go to the mdl_role_assignments table and look for YOUR USER ID. Be careful here, your user id number is not the same as the id number in this table, it should be showing in the userid field. If it is there, and the fields "roleid" and "contextid" should both read 1. If not then edit the row to show those values.

If your id is not there then try these values starting from the "id" field on a line you know is no longer used or add a line into the table using the "Insert" page: id = (lastid + 1 - this may be an auto-incrementing field so be careful) 1, 1, (your userid number here) 0, 0, 0, (timevalue here, just copy the previous line's value), 0, (copy enrol value from previous line), 0. The entire line should read something like: 21, 1, 1, 352, 0, 0, 0, 1276947170, 0, manual, 0)

NOTE: This worked in a limited test on a Windows server and with XP, and should work if you write the SQL Insert statement correctly. The emphasis is on the "should", because this has not been tested, yet, on a large production server. This is why you need a backup of your database - in case this goes wrong. No guarantee here, sorry.

The only other, and admittedly faster, alternative is to delete the existing database and use your backup.

How do I set the maximum upload file size limit?

This is probably the most frequently asked question, and the answer is not that straightforward. The changes that need be made are the same in all versions of Moodle, just in different OS' they need be made in different places. Upload file sizes are restricted in a number of ways and each one in this list restricts the following ones:

 Server level
 Moodle site level
 Course level
 Activity level

Perhaps the best place to find this information is at File upload size There is a full explanation for a number of different OSs but there are a few missing.

This is a contentious issue, mainly because you might think that it should be set inside the Moodle. Unfortunately, this is not so, these are environment issues that need to be set in the server and PHP folders, Moodle cannot work outside itself.

The previous answer is OK if you control the server, but I am hosted, what can I do to override limitations set by my Host?

Before doing this, consult with your host, they may have very different ideas about what your Moodle should be permitted - try not to tread on their toes - they may get annoyed at you breaching your user conditions. In an Apache server, you can create a file called .htaccess which can allow you to override some of the limitations set by PHP on your Moodle. Be aware that this file only applies to your Moodle, and nothing else. Your host will often place a .htaccess file into your root folder which will usually read something like:

 deny from all
 AllowOverride None

These are security related, so there is no need to delete them or otherwise edit them. To overwrite set values in the hosts php.ini file, you may want to use:

 php_value upload_max_filesize 512M
 php_value post_max_size 512M 

To overwrite boolean or logical settings use:

 php_flag register_globals off

or

 php_flag register_globals 0

Something similar can be done in IIS, but it is a lot more complex.

Thanks Muano

We have an older version of Moodle, but as a new Administrator, I want to upgrade to the latest version, but how?

Practice first before Upgrading a production site! There are risks in upgrading any software package. Also, as a new administrator, you may not completely understand what has been installed on your production Moodle site. A combination of upgrading a version 1.6 site to 1.9 that has 6 Contributed code modules added to it can be a complicated process. Upgrading from Moodle 1.9.x to Moodle 2.0 may be a little more problematic, there are a large number of database changes, as well as a number of changes to backup files that may cause some heartburn for people.

The quickest way would be to backup your current database, and see "What is the best way of updating my Moodle?". Remember though, do the next new administrator a favor and document your process and all changes you make.

One issue will be problems in the database. Some tables may have incrementally changed so restoring may become a lot more difficult than it should be. It may be less difficult in the long run to create a new site, then back up each course from the old site and restore each course to the new site. Or if you have a knowledge of SQL, you may be able to create your own SQL queries to rewrite the older tables and store the data in a format the new database can accept.

Top

What is the best way of updating my Moodle?

There is no "best way" as such, there are a number of different methods. Perhaps the simplest way is to recognise that you can utilize the "connectionless" nature of Moodle. (Simple as in this should work anywhere, but you may want to check out other methods as well.)

Moodle comes in three parts

1. The Moodle database - managed by one of four DBMS like MySQL, Postgres, MSSQL or Oracle.
2. The moodledata folder - which holds uploaded files
3. The Moodle code folder.

When updating your Moodle, first things first, backup everything in each of these folders - just in case.

If you are not sure how to do this, look at the Backup and Restore FAQ before doing anything.

Download and install the new version of Moodle to a folder that will not overwrite your existing Moodle, giving the database another name. Check that it works. You may want to think about putting it onto a different drive, or different computer even.

Copy the config.php file of your older installation, to a place it will not be overwritten during the update. Copy the code base of the new installation into the folder of your older production site, returning the copied older Moodle's config.php file.

Things that can go wrong:

• You unzip the new installation and when installing it overwrites your existing moodledata folder. Copy back your earlier version, overwriting the newer.
• You overwrite the existing database. Restore your backup.

Suggested by Tim Hunt.

How to diagnose a Hacked Moodle Site?

This item is not designed to frighten anyone about Moodle security, just sometimes a hacker can be a little better than our protective systems. Like any popular web based program, Moodle is in a constant game of "catch-up" with latest hacker techniques. Please check the Security page for more tips and procedures.

First thing to do is to check the config.php file in your Moodle folder. This controls the basic settings. Check for anything that is written between these two lines:

<?php /// Moodle Configuration File
 
unset($CFG);

If something is there delete it. Once it is deleted, check the file permissions and make sure that the file is owned by the administrator and is set for read only.

There are other ways Moodle has been hacked, but usually, the files targeted are the config.php and index.php. Unfortunately, sometimes all the .php files are attacked. Upgrading Moodle, backing up everything, checking permissions and folder locations are some of the things you can do to either reduce the risk or recover quickly. With a large installed base of users and an active community, most hacks are discovered and reported quickly, and solutions found.

For more information, go to Hacked site recovery page. This offers more detailed information.

How do I set Moodle & Moodledata folder permissions in the server environment.

You should already have gone through the Installing Moodle guide and this should have provided you with some information. However, due to the manner in which Moodle has been created, the documentation tends to concentrate on the LAMP configuration.

The other question is how can I set permissions in IIS.

This discussion in the Using Moodle Forum about this topic could be really valuable for IIS users.

Help! My site broke - How do I fix it?

Moodle was made to be broken - seriously. Quite often these statements are made:

My site has suddenly broken, only the header will display on any page except for user login.

As soon as anyone is logged in, only the header shows.

The site was working perfectly but not now.

Or variations on that theme.

Why these things happen is usually you have done something or changed something or someone else has done it and the site falls over. You can spend hours trying to fix it, but in most cases it is just better to dump it and start again, a lot less time consuming.

1. Completely delete your entire Moodle, everything must go.
2. Reinstall Moodle using exactly the same settings you started with.
3. Overwrite the database from your Site backup.

Alternatively, you can do a Site restore from your Site backup.

This is why you must backup regularly. The bigger the database, the more frequent the backups required.

TIP: Keep two Moodles, one public and one private. Do things to the private Moodle and test them out. If it works then you can employ the same change in your public Moodle. If it doesn't then you have not damaged anything. It is much easier to deliberately break and repair or re-install your small private Moodle than to try and do it to a public Moodle.

Another reason a site is broken is because it has been hacked, which is another issue.

I am having trouble with blocks, I can't see them, what do I do?

The Blocks FAQ will provide many answers here and what follows may not necessarily be the right answer. Log into your Moodle as normal and then type this:

http://www.mysitename.org/]admin/blocks.php

into the address bar. This will take you directly to the blocks page and you will be able to reset any hidden block.

I have a valid web address, but as I install, I am getting an error message telling me I do not.

Chances are that it is the config.php file that is pointing in the wrong direction. If you can use a text editor that can save in a UTF-8 format, open the config.php file and it may read something like:

 $CFG->wwwroot   = 'localhost';
 $CFG->dirroot   = 'var/www/Moodle/moodle';
 $CFG->dataroot  = 'var/www/Moodle/moodledata';
 

when it should look something like:

   $CFG->wwwroot = 'http://yourwebsiteURL';
   $CFG->dirroot = '/home/yourAccountName/public_html';
   $CFG->dataroot = '/home/yourAccountName/moodledata';
   

If you are being hosted then the provider may allow you access to something like CPanel in a Linux environment.

This will also repair the error message:

 The 'Data Directory' you specified could not be found or created. 
 Either correct the path or create that directory manually.

In a Windows environment it may look something like:

   $CFG->wwwroot = 'http://yourwebsiteURL';
   $CFG->dirroot   = 'C:\Moodle\server\moodle';
   $CFG->dataroot  = 'C:\Moodle\server/moodledata';

I can not login and get the error message "Unfortunately, cookies are currently not enabled in your browser"

With all these kinds of errors the first thing to do is to check the config.php file. Make sure that the file is pointing to the right places. It should look something like:

  $CFG->wwwroot = 'http://yourwebsiteURL';
  $CFG->dirroot = '/home/yourAccountName/public_html';
  $CFG->dataroot = '/home/yourAccountName/moodledata';
  

Another possible cause of this problem is that sessions are not configured properly on the server. You can test this by calling the script http://yourserver/moodle/lib/session-test.php.

If your server is on shared hosting check that you have sufficient disk space quota. An insufficient quota will prevent new sessions being created and nobody will be able to login.

Carefully check the permissions in your 'moodledata' area. The web server needs to be able to write to the 'sessions' subdirectory.

Finally, check the bottom of the config.php file. Make sure there is nothing after the ?>, this means no characters, no spaces, no carriage returns. If the ?> is on line 26 and the debug error says config.php line 28, you have extra lines.

Top

I have just taken over a Moodle and now can't log in to it as Admin and others get the message "Your session has timed out. Please login again.".

You should already know the version of Moodle you are using, (if you are not sure then go to Notifications and in the bottom left corner of the centre block you will see the Version + (build number)).

If you are using v1.6, you may want to consider dropping the site entirely. Reinstalling a newer version should solve the essential problem. v1.6 experimented with cookieless sessions which work by appending a session id to either every url or to hidden form fields in html pages. This allowed php to track every session and record it. The problem is that that data is stored in the moodledata folder, and that takes up space which eventually takes up so much room the server will object and deny people access. To immediately solve this problem enter the /moodledata/sessions folder and delete all the "session" files.

If this is the problem, then you may be getting messages from your ISP telling you that you are now over quota, so you need to reduce the amount of filespace that your Moodle is occupying.

If you are already using a later version of Moodle, then you should be communicating with your ISP to see what the problem may be. Alternatively, you may be able to access the log files, in which case you may be able to query each element of the Moodle.

It is also recommended that you constantly update your Moodle site. You can start considering this option using CVS files.

Top

All students are enrolling in every course

Your site is probably assigning a student role initially to all new users. You might want to change this setting. This is another example of the contextual nature of Roles and what is discussed here is in the context of the entire site.

First check to see who is assigned the student role at the site level. Go to the site administration block > users > permissions > assign system roles - there should be nobody in the student role. Move users you do not want to have student role (be able to enroll in all courses in the entire site), out of this role into the Potential user column.

To change the default user role, in the site Administration > Users > Permissions > User Policies, look for "Default role for all users". Make sure the default user is "Authenticated user" and not "Student".

Confused about why this is logical? We have been checking the default user setting for the 'entire Moodle site. In MoodleSpeak, the site context always applies until another context specifically changes the role. Remember, students take courses. Some sites want all new users to be able to be automatically enrolled in all site courses. So from the first moment that users logs into these sites, the site role default is that of student. Other Moodle sites want to be more selective. Thus they might assign the default site role as "authenticated user". This will allow each course to determine the new role (probably a student role) when the user tries to enter it.

In correcting the student issue, you may have created another problem - your Site news forum has disappeared. See below.

Top

My site news forum disappeared from the front page for students

The site news forum disappeared from the Front Page after a successful log in for your students. You have forced all logged in users to be subscribed via the forum settings. Check to see if some or all of your users are no longer "students" or teachers in the Context of the Front Page.

Go to Site Administration block > Front Page > Front Page settings> Default frontpage role. Change to Student. Remember this is a change to a different area of Moodle than that described above. This change occurs specifically in the context of the front page, and is not a site wide change.

This affects a number of things. Please note that the default front page role is like a role in a course and it does not apply to other courses. Ths is different to the assigned roles in the front page.

I just migrated my Moodle to a server and now no-one can see it. What happened?

Usually the issue is a simple one and can be fixed with your text editor and a special program:

1. Open your text editor and navigate to your config.php file in the Moodle root.
2. Look for the line $CFG->wwwroot = 'http://localhost/';
3. Change the "localhost" to your server IP address, e.g.$CFG->wwwroot = 'http://10.45.78.165/';
4. Save and exit your file editor
5. Run the ./admin/replace.php because your image links will still point to localhost
   1. So put http://localhost/ in the first box (your old address)
   2. Put http://10.45.78.165/ in the second box (your new address)
   3. After you are sure the above is exactly correct, click on "Yes, do it now".

This should now work. What it should also do is to update all your internal links, courses, images and everything to reflect the IP address.

The same process is used when you have installed to your own server and want to make it available to your Users, but if you have no courses, then you do not have to run the replace.php file.

See also

• Beginning Administration FAQs - 2
• Beginning Administration FAQs - 3
• Beginning Administration FAQs - 4
• Front Page FAQ
• Installation FAQ
• Administration FAQ
• Xampp Installer FAQ
• | Beginning Moodle 2.0 Administration

• Index of all Administrator-related pages