A discussion of open source eLearning tools covering Moodle, Alfresco, Mahara, and Kaltura amongst other technologies. Posts range from interesting anecdotes and adventures, to practical tips, to big picture discussions of trends and learning theory.
Showing posts with label Moodle administration. Show all posts
Showing posts with label Moodle administration. Show all posts
Configurable Reports is a popular plugin for Moodle that allows administrators to create custom reports for Moodle and make them available to their end users. In working with this plugin I have noticed that it can be difficult to track down all the variables and filters you can use in creating reports. Below are a list of all of the options.
Variables
%%CATEGORYID%%
%%COURSEID%%
%%CURRENTUSER%%
%%DEBUG%%
%%FILTER_VAR%%
%%STARTTIME%%','%%ENDTIME%%
%%USERID%%
%%WWWROOT%%
Filters
%%FILTER_CATEGORIES:
%%FILTER_COURSEMODULEID:
%%FILTER_COURSEMODULEFIELDS:
%%FILTER_COURSEMODULE:
%%FILTER_COURSES:
%%FILTER_COURSEENROLLEDSTUDENTS:
%%FILTER_USERS:
%%FILTER_ROLE:
%%FILTER_SEARCHTEXT:
%%FILTER_SEMESTER:
%%FILTER_STARTTIME:
%%FILTER_ENDTIME:
%%FILTER_SUBCATEGORIES:
%%FILTER_COURSEUSER:
%%FILTER_SYSTEMUSER:
%%FILTER_YEARHEBREW:
%%FILTER_YEARNUMERIC:
Using Variables
Variables can be used anywhere inside of your SQL query.
Using Filters
When using a filter you need at least one static WHERE condition then you list one or more filters. For example
You can technically add multiple filters, but once a user applies one filter to a report all filters for report are applied. So it can be a little tricky to have multiple filters on the same report. For example if you add a course and date filter to a report, then if you just want to filter by course you have to make sure your date filters are set to date range that covers all courses.
Many of the filters are hard code to be drop down menus which are sorted by database id number instead of alphabetically. This can be problematic if you have a large number of users, courses, or categories. However, you can use one search text filter per report, which can be used to work around the issue in some cases.
Many filters require a logical operator to specify how the filter works. For example
Mod_deflate is an Apache web server module that uses compression to reduce the bandwidth needed to send web pages between the server and the end user's computer.
See http://httpd.apache.org/docs/2.4/mod/mod_deflate.html
Modern web applications such as Moodle send a lot of text from HTML code, to CSS styles, to javascript, all of which can achieve high compression rates.
So how does reducing bandwidth usage make your website faster? It's actually a bit of a trick. The website itself probably isn't really faster in terms of the number of users or pages it has the capacity to generate. Each page probably will take about the same build time as before on the server. In fact if your server's undersized in terms of CPU resources it might even reduce the server's overall capacity. But for the end user the perceived responsiveness of the website is significantly increased. This is because it takes a lot less time for the page to be transported from the server to the user's computer. This can have a significant impact on user satisfaction and is relatively easy to setup for knowledgable administrators. On a recent engagement, I actually saw a 2-3 second improvement in page load times for the end user, even while accessing from the local campus network. Needless to say the Moodle administrator for this site was very happy with the improvement and you will be too!
This week I am going to talk about a method to enable course completions en-masse across a library of existing Moodle courses.
Stupid Moodle Tricks!
This is my pet name for these little tips, #stupidmoodletrick anyone? Think Letterman's stupid human tricks (video below). These are generally one-off tips, tricks, hacks to manipulate Moodle, generally as a time saver or to accomplish something Moodle isn't generally known to do.
So last week, a client asked me if I could help save them some time in converting some old Moodle 1.9 courses. Actually the more honest version is my lovely and dear wife, Michelle, volunteered that I could totally save the client hours of work by "changing a few database settings." And it turned out she was right!
The following assumes you a have already enabled course completion tracking in your site administration settings. Be aware all of these changes are accomplished by running the below queries directly on your Moodle database. As always when making these sort of changes, be sure you have a good backup and that you know how to recover it to make a working site. Things can and do go wrong and in unexpected ways. I also recommend you use a test site first to become familiar with the technique.
This method was tested on Moodle version 2.7.1+, and 2.7.2+. As with any method that directly interacts with the Moodle database, things almost certainly will change with new versions. It probably will also work with older Moodle 2 versions, but again test first.
Enable course completions on all courses
First we need to enable completion tracking for all courses.
update mdl_course set enablecompletion = 1 where 1;
Turn on activity completion for all course modules (ie activities and resources)
This query enables the setting for all course modules across the site. It sets 'Completion Tracking' to 'Show activity as completed when conditions are met.' It also sets 'Require view' as the criteria, as illustrated in the screenshot below.
update mdl_course_modules set completion = 2, completionview = 1 where 1;
In contrast, if you wanted to set the activity completion to be marked manually by the student, you would run the following query instead.
update mdl_course_modules set completion = 1 where 1;
Which results in the following settings
Limiting which type of modules are set
Let's say we only want to enable completion tracking for all quiz modules. We would first need to have a look at the mdl_modules table and find the id assigned to the quiz module. We can use the following query.
SELECT * from mdl_modules;
Results from my test site are shown below.
We can see that the quiz module id is set to 25. Be aware this will be different for different sites. For example, I tried this on another test site and the quiz id was set to 16.
So now we can create a query to only modify quiz modules.
update mdl_course_modules set completion = 2, completionview = 1 where module=25;
Turn on grade required completion element for all quiz modules
The completion grade requirement is stored by setting a value of 0 in the completiongradeitemnumber field. Knowing this we can set the value and combined with the where clause above to limit to only quizzes. This can be a very useful technique since many compliance courses will use a quiz grade as their completion criteria.
update mdl_course_modules set completiongradeitemnumber=0 where module=25;
Note that this method only changes the setting to require a grade. It doesn't require a specific grade which need additional manual setup in the Moodle grade book. I think setting a specific grade is considerably less trivial. Let me know in the comments if you have a query / method to do this.
The overall result of applying this technique for the requesting client was to save 800 course setting edits, and about 2,500 activity setting edits which probably would have taken several days to a week to do manually.
A note about method
When developing a #stupidmoodletrick, I use a throw away test site. I usually just use the Moodle all-in-one installer to create the site. I then setup the test site with whatever test users / courses, and settings which are needed for the scenario. I then have a look at the database. The all-in-one installer includes phpMyAdmin which is an easy way to have a look at the database structure in a graphical environment. Moodle is good about using descriptive names for its tables and fields. I try to identify which table I think will be used to save the information and which are likely fields. Then, I go into Moodle and manually change the setting manually. After this, I go back to the database and look at the changes made and attempt to determine what is getting set.
Next, I attempt to manually edit the database using the information I have learned. I make the edit and then I purge all caches in Moodle. Finally, I access Moodle again to confirm that I have achieved the desired result. I also look to see if anything appears to be broken. I repeat the process until I have a working method that doesn't break anything.
Note a more thorough method is to trace the actual Moodle queries in the source code, but I find I normally don't have to do this. In particular think of settings that may impact more than one table (related tables and fields), we want to avoid introducing later hard to find problems.
Earlier this week, I was working with a client whose Moodle server was full. They asked me to help figure out why it was full. This can be a challenging question when using Moodle 2.x due to the fact that files are saved in a single hashed space. In this client's case, 6 SCORM files were using 3/5 of all their storage. Here is the simple query I developed to create the list showing the original filename and path, the storage used in megabytes, the content hash (ie filename used in moodle data folder), and which component of Moodle owns the file. The output is sorted by largest files first with a limit of the 50 largest files.
SELECT DISTINCT filename, filepath, FORMAT( (filesize /1024 /1024), 1 ) AS filesize_MB, contenthash, component FROM `mdl_files` ORDER BY filesize DESC LIMIT 0 , 50
If you are a Remote-Learner hosting client you can run this query via your phpMyAdmin link contained in your customer kit, or request via our support portal.
During this research I also found that its is possible for a file to become orphaned. In this situation the file is still stored in the moodle data folder, but is no longer referenced in the mdl_files table of the database. Look for a future post on how to track down orphaned files.
Here are some simple settings that any Moodle administrator can change from the Site Administration menu that will help to improve his/her Moodle site's performance. Some of these changes come at the cost of functionality, so sometimes you have to pick between a particular feature and performance (or a faster server), but often these settings are just enabled out of curiosity with no discernible reward other than a slower site.
Automated backup setup
Disable Automated backup setup for courses by setting Active to disabled in the pull down menu. The Moodle course backup and restore feature, while a convenient mechanism for moving courses between Moodle sites, is not very efficient. As the number of courses and the size of the courses on your site increase, the scheduled course backup process takes longer and longer to complete. This can cause extreme site slowdowns while it's running. Additionally, it makes it harder for your server's backup system to complete its own nightly backups.
Many users mistakenly view this as a way to restore their Moodle site in the event of a disaster. While it's possible to use these course backups to restore most of a site, it's not ideal or guaranteed to work when you need it. Disaster recovery backups should be performed outside of the scheduled course backup feature.
Statistics
Make sure Enable statistics is unchecked. Many administrators discover this setting and turn it on simply to see what it does. A common scenario is that a site will be performing well for a year or more and then suddenly experience problems when this setting is enabled. This setting includes options for how long to allow the statistics gathering to run in one session and how far back to process. If you must run statistics make sure to limit how long you allow the process to run. I recommend letting it run no more than 2 hours per session.
Site administration / ▶ Advanced features
Upcoming versions of Moodle may have an improved version of statistics that should reduce the load on the server's database by several orders of magnitude. So if you really need this feature, keep your eyes on MDL-30643.
Theme designer mode
Disable Theme designer mode on production Moodle sites. Theme designer mode is a great Moodle version 2 feature, if you are updating your theme and want to quickly see the impact of changes. It does this by having the Moodle server tell web browsers to not cache any of the images, css, and javascript that make up your theme. When this feature is enabled, every page view for every user must download every media object directly from the Moodle server. This makes viewing pages very very slow and greatly increases the load on the server. Administrators often enabled this to update their theme and then forget to turn it off. The best practice is to develop your theme on a testing site and then move it over to production only after it has been completed.
Set Keep logs for and Grade history lifetime to 365 days or less. By default Moodle will keep both your logs and grade history forever. For long established sites, these logs start to become the majority of the database. I have seen cases where log tables consumed 90% or more of the database. As a general rule the more of your database that fits into your server RAM the faster your database will perform. By limiting the size of these logs, you can make your site much faster.
Site administration / ▶ Server / ▶ Cleanup
Note: If you have a really large log, it may make your site even slower while the cleanup runs. Consider changing this setting during a low-use time or during a maintenance window. In extreme cases, it can take several hours for the cleanup query to complete the first time.
Session Handling
Disable Use database for session information by unchecking the box. Starting with Moodle version 2 and above the default setting is to have database sessions enabled. In our infrastructure, we have seen much better performance using file based sessions rather than having the database handle them. This is dependent on the server setup, but it's worth disabling to see if your performance improves.
Site administration / ▶ Server / ▶ Session handling
Pro-tips
Below are some additional tips that take a bit more effort, but provide additional benefits related to ensuring great performance for your Moodle site.
Running multiple simultaneous manual course backups can sometimes cause problems. Avoid creating situations where many course backup / restores need to run at the same time. This is a common problem for the start of a new school term. Often instructors will be asked to duplicate their prior courses for the new term. Moodle doesn't provide any internal mechanism to queue backup requests so that they don't overwhelm your server. If enough instructors are doing this at the same time, it can make a Moodle site nearly unusable.
While all of these settings can be accessed from the Moodle interface, if you want to really make sure none of your site administrators accidentally sets one of these incorrectly, enter the desired value in your config.php file so that it cannot be enabled accidentally.
Consider starting with a clean install of Moodle once a year to have the smallest database footprint and ensure the best performance for your site.
