Live Chat Software by Kayako
 News Categories
(19)Microsoft Technet (2)StarWind (4)TechRepublic (3)ComuterTips (1)SolarWinds (1)Xangati (1) (27)VMware (5)NVIDIA (9)VDI (1)pfsense vRouter (3)VEEAM (3)Google (2)RemoteFX (1) (1)MailCleaner (1)Udemy (1)AUGI (2)AECbytes Architecture Engineering Constrution (7)VMGuru (2)AUTODESK (1) (1)Atlantis Blog (7)AT.COM (2) (1) (14) (2)hadoop360 (3)bigdatastudio (1) (1) (3)VECITA (1) (1)Palo Alto Networks (4) (2) (1)Nhịp Cầu đầu tư (3)VnEconomy (1)Reuters (1)Tom Tunguz (1) (1)Esri (1) (1)tweet (1)Tesla (1) (6)ITCNews (1) (1) Harvard Business Review (1)Haravan (2) (1) (3) (3)IBM (1) (2) (1) (6) (1) (1) (4) (1) (1) (1) (1) (1) (1) (1) (5) (4) (1) (1) (1) (1) (2) (7) (1) (1) (1) (1) (2) (1) (2) (2) (2) (1) (7) (1) (1) (1) (1) (1) (1) (1)Engenius (1) (1) (1) (1) (1) (3) (6)
RSS Feed
How did a Moodle security vulnerability enable remote code execution?
Posted by Thang Le Toan on 20 August 2017 11:11 PM

A series of logic flaws in Moodle enabled attackers to remotely execute code on servers. Expert Michael Cobb explains how the Moodle security vulnerability can be exploited.

A vulnerability found in Moodle, an open source, PHP-based learning management system used by tens of thousands of universities internationally, left servers and their data open to compromise. According to the researcher that discovered the issue, the Moodle security vulnerability is actually made up of several small flaws, and it can enable attackers to execute PHP code on related servers. What does this vulnerability entail, and what can be done about it?

Netanel Rubin, security researcher and CEO of Vaultra, found that by exploiting a series of minor vulnerabilities, he could chain them together to remotely execute code on a server running Moodle.

Moodle is an open source learning management system that stores a lot of sensitive information, like students' grades, tests and private data, making it an attractive target for hackers. The Moodle security vulnerability is tracked as CVE-2017-2641 and Moodle Tracker issue MDL-58010.

The attack works on almost all Moodle versions, so administrators should move to the latest version, version 3.2.2, to fix the problem as soon as possible. Besides updating to the latest version, administrators should also check for any new administrators, plug-ins or templates within Moodle, and search for any new files in the file system in case the server has been compromised.

The coding and logic flaws that contributed to this Moodle security vulnerability are a consequence of the size and complexity of the Moodle system; it contains thousands of files, hundreds of different components and around two million lines of PHP code, written and updated by various different developers at different times.

A new function, update_user_preferences, was added to Moodle to replace the update_users function. It implemented a privilege check, so even if an attacker could change settings using user preferences, it would only work on their own privileges.

While the new function removed the possibility of changing every user attribute, the code failed to check which preference was being changed. The previous function used the setuserpref.php file to check that the preference that needed to be updated was listed in the ajax_updatable_user_prefs array, which defines the preferences that can be changed via Ajax to ensure no critical values can be altered.

Ironically, in an attempt to reduce any potential abuse of the user attribute update function, the new privilege check actually introduced this Moodle security vulnerability. It's possible the developer thought that user preferences could not be exploited to mount a full-scale attack, as they only affect the graphical user interface part of the system.

However, the lack of containment enables an object injection attack to update any row in the entire database, such as administrator accounts, passwords and site configuration. Rubin discovered that this and other false assumptions made during code development could be leveraged to eventually execute PHP code on the server.

Logic flaws can and will occur in any system featuring a large code base, particularly when it's developed over a long period of time by a changing team of developers.

According to Steve McConnell, author of Code Complete, software projects that reach 512,000 lines of code or more can see four to 100 coding errors per thousand lines of code. A typical web application utilizes multiple languages, such as Java, HTML, PHP, Python, CSS, third-party libraries and components, and so on, and there are very few developers that know or understand how to use and integrate each of them without introducing any security vulnerabilities.

To reduce the chances of developers introducing logic flaws or omitting security and validation checks, it should be a requirement that they add a minimum level of in-code comments using an agreed-upon comment style, along with more verbose supporting documentation. Wikipedia has a comprehensive list of comment styles.

Although time spent on commenting and documenting code will slow down development, it will ensure developers making changes in the future can fully understand what a function does, how it does it and what checks are required on the data it handles. It is important that functions receiving data passed by other functions don't carry the assumption that the data has already been validated, as the previous function may have validated it against a different set of requirements or rules.

A good example is a telephone number. A function to retrieve and display a user's telephone number from a database may well accept + and () symbols, but if that function then passes the data to a function that actually calls the number, these characters could cause the function to fail if they are not removed before being processed.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)

How does your enterprise eliminate logic flaws from code development?

Read more »

Moodle Site restore for low-tech users
Posted by Thang Le Toan on 03 July 2016 11:14 PM

This page is a work in progress in November 2010.

There are 3 areas of Moodle that should be backuped and thus can be restored:

  • The database (for example MySQL)
  • The files uploaded or created by Moodle (Moodledata directory)
  • The Moodle code itself

The location of these areas can be found in the Configuration file.

Restore database

Here are some ways to restore typical Moodledata bases such as MySQL


The phpMyAdmin restore process is about as simple as it's backup process. To restore:

Restoring a backup of a MySql database

  1. Open the database to restore
  2. Click the SQL tab.
  3. On the "SQL"-page , unclick the show query here again.
  4. Browse to your backup of the database.
  5. Click Go.



Restore files

There are 2 areas which can use the same techniques to backup and restore because they are stored in files and folders"


Read more »

Moodle Site restore
Posted by Thang Le Toan on 03 July 2016 11:13 PM

If you have followed the Site backup instructions and created a backup of a Moodle site, you may need to know how to restore the site backup you created.

There are 3 areas that could be restored individually or together:

  • Moodle code
  • Moodle uploaded or created files
  • Moodle database - MySQL, Progres or other

The location and names of these areas can be found in the Configuration file.


Command line (linux) restore

Here is a set of basic steps that make up the restore process.

1. Rename the original Moodle directory to something different (so you still have it) and copy the backed up Moodle directory or a newly downloaded Moodle directory in its place.

2. If you are running MySQL, a backup of the database should be a .sql, .gz or .tar.gz file. If it is .tar.gz or .gz you need to extract it until it is an sql file.

tar -xzvf moodlesqlfile.tar.gz

3. If you are running mysql, import the SQL file back into a newly created database on the MySQL server. Be careful here, some backups try to import right back into the same working database that Moodle is connected to. This causes database problems that damage a Moodle installation. The best thing to do is make a new database, restore the backed up database into it, and change the Moodle config.php file to connect to this new database (this way you still have the original database).

Once you have created the new database:

mysql -p new_database < moodlesqlfile.sql

For other databases, follow their instructions for restoring a backup.

Tools for site backup and restore

  • phpMyAdmin
  • MySQLdump

Tools for backing up data files

Restore with phpMyAdmin

Restoring a backup of a MySql database

  1. Open the database to restore
  2. Click the SQL tab.
  3. On the "SQL"-page , unclick the show query here again.
  4. Browse to your backup of the database.
  5. Click Go.



What are the pros and cons of course versus site backups?

Site backups are recommended in order to have all data saved with the best confidence and the shortest recovery time.

For a site administrator, automated course backups are more expensive in terms of time, CPU usage and storage. The recovery time to have a site running again takes longer than a site backup. However, teachers and site administrators might find a course backups as a way to create a "fresh" copy of a course that can be re-used (in older versions of Moodle, in newer versions see Import course data) or as a method to distribute a course(s) to other Moodle sites.

Why is my automated course backup much smaller in size than my manual course backup?

This is an intentional design decision. Because of the way files are stored in Moodle 2.x, there is no need to include the files in the backup if you are planning to restore them to the same Moodle site. Leaving them out saves huge amounts of disk space and makes the backup procedure much faster.

What data is not contained in course backups?

By selecting all the options when setting up the backup you can include almost all the data in the course. However you should be aware of the fact that some things are not backed up:

  • Quiz questions are only backed up if at least one question from their category has been added to a quiz.
  • Scales are only backed up if they are used by at least one activity.
  • Users' passwords are not backed up when the "Include enrolled users" option is selected.

Why is there no "all/none" feature when selecting items to backup?

This was enabled in MDL-32705 and is available in Moodle 2.3.2 onwards.

The process ends with: "Error: An error occurred deleting old backup data". What should I do?

This part of the backup (or restore) procedure tries to delete old info, used in previous executions, performing the following tasks:

  1. Delete old records from "backup_ids" table: Check the table exists, repair it and try again.
  2. Delete old records from "backup_files" table: Check the table exists, repair it and try again.
  3. Delete old files from "moodledata/temp/backup": Delete the dir completely and try again.
Backup error message

For points 1 & 2, there are various ways of repairing tables, including using MySQL Admin.

For point 3 see below:

The error message states that the "directory not empty" and gives the path to that directory. If you go there with an FTP program you can see what is there and clean up. It could be just some empty subfolders that were leftover. Deleting these has been able to help. One can also delete the dir "moodledata/temp/backup" completely. That can take a bit longer but may solve several problems at once.

The process ends with: "XML error: not well-formed (invalid token) at line YYYY". What can I do?

This problem can appear at any point in the restore process. It's caused when the XML parser detects something incorrect in the backup file that prevent correct operation. Usually, it's caused by some "illegal" characters added in the original course due to some copy/paste of text containing them (control characters, or invalid sequences...).

The best method to handle this issue is:

  • Unzip the problematic backup file under one empty folder.
  • Open the moodle.xml with Firefox. It will show you where (exact char) the problem is happening.
  • Edit the moodle.xml file with some UTF8-compatible editor and delete such characters. Save changes.
  • Test the moodle.xml file again with Firefox until no error was displayed.
  • Zip everything again (all the folder contents but not the folder itself!).
  • Restore the course. It should work now.
  • Restore still not working? See the next question.

Also, if possible, it's highly recommended to solve those problems in the original course too from Moodle itself. Once "repaired" there, problems will be out if you create new backup files in the future.

The process ends with: "moodle xml not found at root level of zip file". What can I do?

If you are restoring from a zip file backup make sure the moodle.xml file is at the root level. To ensure this:

  1. Unzip the backup file of the course (example:
  2. Once the file is unzipped, open the folder (example: mycourse).
  3. Select the folders within the mycourse folder AND the moodle.xml file and create a zip of those item (example:
  4. Upload the new zip file (example: and restore from that.

If the backup file is guaranteed to be correct, check paths to external files (zip, unzip). Incorrect settings also lead to this error message (see the Using Moodle forum discussion moodle.xml not found in root... and MDL-14812).

The process ends with: "An error occurred while copying the zip file..."

This problem is most likely caused by a permissions issue in the destination directory. Backup files are copied to "XXX/backupdata" under your dataroot directory (where XXX is the id of the course being backed up).

The problem could also be caused by a disk being full, though this is far less likely.

To obtain precise information about what's happening, you can enable debug messages in Administration > Server > Debugging (select the maximum level - DEVELOPER) and/or check the web server error logs.

I Still get an XML error. How can I clean the borked XML file?

In some cases XML backup files may contain characters causing the restore process to abort, even after the steps described in the previous question. In such cases you may want to try the following:

  • Unzip the problematic Moodle backup file under one empty folder. Moodle will create the course file folders as long as the unclean moodle.xml file. Please unzip using the Moodle unzip feature.
  • Rename the unclean moodle.xml file to moodle-unclean.xml.
  • If you don't have access to your Moodle server's command prompt, using the Moodle zip feature, zip the moodle-unclean.xml file only, download the zip file locally and unzip it. It is very important to download the xml file in zipped format to avoid unwanted character encoding when transferring from an operating system to another.
  • Move the downloaded Atlassian XML Cleaner Utility in the same folder where is your moodle-unclean.xml file.
  • Issue the following command from the command prompt:
java -jar atlassian-xml-cleaner-0.1.jar moodle-unclean.xml > moodle.xml
  • If you launched the utility on your local computer, zip the just created (and hopefully cleaned) moodle.xml file and upload it in the same place from where you downloaded the moodle-unclean.xml file. Once uploaded, unzip it using the Moodle unzip feature.
  • Zip everything again (all the folder contents but the folder itself!).
  • Restore the course. It should work now.

What does "Some of your courses weren't saved!!" mean?

There are three possible causes of this problem:

  1. Error - this happens when the backup procedure has found an error and so hasn't finished the backup of a particular course. These are "controlled" errors and the scheduled backup continues with the next course.
  2. Unfinished - this happens when the backup procedure dies without knowing why. When the cron is next executed it detects that the last execution went wrong, and continues skipping the problematic course. A possible solution would be to raise the PHP/Apache limit in your installation (memory, time of execution...). By taking a look to your log tables you should be able to see if the "crash" is happening at exact time intervals (usually a problem with the max_execution_time php's variable), or if there is some exact point were all the courses are breaking.
  3. Skipped - this happens when a course is unavailable to students and has not been changed in the last month (31 days). This isn't an error situation - it's a feature, especially useful for sites with many unavailable old courses, saving process time.

Why are some courses being skipped?

Course backups automatically skip courses which are unavailable to students and have not been changed in the time period specified in 'Skip courses not modified' in Settings > Site administration > > Courses > Backups > Automated backup setup (by default 30 days).

Why does restore stop, rather than completing?

Attempting to restore a course to an older version of Moodle than the one the course was backed up on can result in the restore process failing to complete. To ensure a successful restore, make sure that the version of Moodle you are restoring the course to is the same, or newer, than the one the course was backed up on.

If it stop unexpectedly with no errors shown try again with Debugging switched on. Any errors you now see can help experts in the support forums diagnose your problem. You can also check the discussion links in the See also section below for further advice.

Restore stops with the message "Trying to restore user xxxx from backup file will cause conflict"

Error message in Moodle 2.0

This message is displayed when:

  1. The target site has a user xxxx (xxxx being the username)
  2. The backup archive being restored also contains a user xxxx (same username)
  3. After various comparisons, Moodle has determined that the target site user xxxx and the backup user xxxx aren't the same person.

If 1, 2 and 3 are all true, the restore process stops in order to prevent the backup user xxxx's activities (forum posts, quiz attempts, assignment uploads, etc) from being associated with the target site user xxxx.

These checks and behaviour were introduced in Moodle 1.9.x and continue being valid under 2.0. It's common for the user in question to be the "admin" user (which exists in practically all Moodle installations).

There are two possible methods to make the xxxx users match (and avoid the conflict):

a) Modify the backup archive users.xml file and make the email or firstaccess fields match the ones in target site.
b) Modify the target site and set the user email or firstaccess fields to match the ones in backup archive users.xml file.

Method a) is recommended so the restore process will match both xxxx users and all activities in the backup file belonging to xxxx will be associated to the already existing target site user xxxx user.

 NOTE: When using method a) be aware that the moodle-filename-backup.mbz is a zip file and can be renamed to and unzipped. 
 When editing is complete, rezip and then rename using the original file name with the "*.mbz" extention.

Why are certain course links broken in a restored course?

Inter-activity links must be absolute (full) URLs e.g.

in order to be processed properly during backup and restore. Any relative URLs e.g.






will result in broken links when the course is restored.

I have a very large course, over 2GB, and the backup process stops.

Larger courses can be restored in Moodle, but sometimes it needs a bit of tweaking to get it right. Moodle backup files are *.mbz fies and can be renamed to zip files. They can be unzipped, then edited, rezipped and restored. It does not matter if you are using a Linux or Windows or Mac server, a local host or anything else, the technique is the same.

The editing comes in two different ways, one is the resources, activities, quizzes, images. video files and so on are listed, written and referred to in the moodle.xml file. You can find the starting point and the end point of each resouce that you can delete out of the xml file.

The xml might look something like this:

 <file id="111">    <contenthash>b11ac9bc0cebee17acfd28d13b548331f76645bc</contenthash>
   <author>Fred Nurks</author>

When editing, make sure all this is deleted, everything between the <file></file> tags.

The second part of editing is locating the actual resouce if it is an image, a separate file or video then deleting it. Really large mbz files tend to have a lot of videos, often flv files, or uncompressed images, like tiffs. They can be found, and deleted easily, in the directory tree of the backup.

You can then rezip the edited file, rename it to an mbz and, if you have edited it right, it should restore. You can use the original file to break down really large backups over and over into four or five smaller mbz files, as many as you like.

It is recommended that you test the technique first on a smaller file, it is easier to follow and gets you used to xml structuring and so on. Say one course with a couple of pages, a number of different image types, a couple of videos will help you immensely.

You do not have to worry about permissions in Windows or Xos servers, or concern yourself with editing rights usually. However, you may be required to ensure you are the owner fo the files being edited.

 NOTE: Before re-zipping, check to make sure you have removed all references to the pages/files/resources you have deleted in the moodle-backup.xml file as well. here msay be none, but check anyway.

How can I extract original files from a Moodle backup file?

If you really want to get original files from the backup file (an ".mbz" file) you downloaded (using the backup and restore feature), you can do so in much the same way as is suggested above.

The backup file can actually be opened with any zip/unzip program you can download. Once you open the file, you need to extract:

   The files.xml file.
   The files directory (folder).

Next step would be to open the "files.xml" file in a text editor, and:

   Search for the name of each file you want to get.
   Take note of the value of the corresponding contenthash tag.
   In the "files" folder you extracted, locate the file whose name is the same as the value of the contenthash and which will always be located in a folder whose name corresponds to the two first characters of the file name.

For example, let's assume there is a "backup_courses-120730.mbz" file of which the "files.xml" file and the "files" folder have been extracted. There is a PDF file named "Leadership.pdf" that is required for another purpose.

Open the files.xml file and:

1. Search for the string "Leadership.pdf", which in this case is found under the following <file id...> group tag:

 <file id="12345">

2. Take note of the corresponding contenthash value: fb6cf43a9b2d432403c70a2cb4c340dbb6225631.

3. As the first two characters of the contenthash are "fb", open the "fb" folder inside the "files" directory (which was previously extracted), and there is a file named "fb6cf43a9b...". Rename that file as "Leadership.pdf", and then move it to another location. Repeat this for all the files required, using the correct contenthash value of course.

What happens if I restore a backup containing an assignment from Moodle 2.2 and older?

The assignment activity module was completely rewritten in Moodle 2.3. Thus, assignments from Moodle 2.2 and older (e.g. from Moodle 1.9) need to be upgraded in order to continue being usable. See the section 'Restoring course backups from Moodle 2.2 and older' in Assignment upgrade tool for details of what to do

Read more »

MOODLE Site Backup for Low-tech Users
Posted by Thang Le Toan on 03 July 2016 10:51 PM

This page is written for Moodle site administrators who are interested in learning about site backup and restore process, but who are not familiar with code, command lines or website administration. For others please see Site backup.

A complete Moodle site backup involves 3 things: the Moodle code, the moodledata folder and the MySQL tables. A course backup and download off site is always a best practice but it only involves parts of the moodledata folder and SQL table.

TIP: Please remember there are many different configurations for webservers and Moodle sites. Most of the instructions below should start with the words "Generally speaking".

Before disaster strikes

"Do not gamble what you can not afford to lose": think carefully about how often you will backup things and where.

When a major Website disaster happens, you may need to restore the three parts:

  • moodledata folder - sometimes called the: data files, Moodle files, data directory, uploaddata, dataroot, or simply moodledata (in lowercase). It is not called the "database".
  • MySQL or PostgreSQL database - We will refer to the MySQL database. There are other SQL database flavors which will work with Moodle.
  • Moodle code - location of Moodle code.

Thus it is a good idea to first know how to backup these parts so you can restore them to a new or existing webserver.

Course Backups - better than nothing

As the site administrator, you probably have set an automatic course backup in your site settings. Sometimes site administrators forget that these backups should be copied to a safe place other than their webserver. Teachers maybe encouraged to download their course(s) backups to their computer on a weekly basis.

The course backups and restores only deal with parts of the moodledata folder and MySQL tables. For example, they may include reference to a default theme or a contributed code module, but not the actual code or information that will make them work.

Backup up key folders

You will need a program and rights to go into your website files to make a backup. You can copy the folder to another off site location, or zip the folders and copy that zip file to another location.

An FTP (file transfer protocol) program might be useful. There are free programs such as CyberDuck and FileZilla. A FTP program copies a file from "there" (the server) to “here” (your desktop). Usually this is as simple as a drag and drop and then waiting for the files to transfer.

Some webhosts will have an interface that will allow you to create a zip or tar file and download it from the server to your desktop, similar to a FTP program.

Back up your moodledata folder

Use your program to copy (that is, drag and drop) the directory called “moodledata” or the zip or tar file you created that contains this folder. This folder was named and created in the install process. It usually located in a public directory, not in the same directory as the moodle code folder.

Backup the moodle code folder

Use your program to copy (that is, drag and drop) the directory that contains the moodle code. This directory is usually called "moodle" and maybe in the public root (htdocs). You may have created a tar or zip file of this directory and it's contents.

Tip: Some sites only use the standard install package. And some of the site administrators of these sites like to use a clean install of their Moodle code, instead of using a backup as described above. A potential problem with this practice may involve sites that have added modules or tweaked the standard Moodle, because these things will not be in a standard install.

Backup the MySQL database

Backing up the MySQL database is a different process and uses a different type of program. Here is a video of the process.

MySQL can be thought of as a series of databases. Each database is made up of tables that share a common prefix in their name. Each table has records. The Moodle intaller creates the Moodle tables prefix. A typical prefix is "mdl_". The goal is to backup these tables.

Open phpMyAdmin

phpMyAdmin can be installed as part of the Moodle interface. When installed it can be found in the site administration block>Server>database. Many webhosts will use a program called cPanel, or have a link to program that can manage the MySQL database such as phpMyAdmin. We will use phpMyAdmin.

Open phpMyAdmin. In the left pane, you will see your database(s) listed. Normally, the name of a Moodle database will be something like mdl_ or have the description Moodle. Click on the database you want to back up.

The page will refresh. In the left column you should see all (around 200) the tables with the prefix of mdl_ (or what ever they were named when the Moodle site was installed). Along along the top you will now see a row of buttons. Click on the button Export.

You will see boxes with options in them (see below).

Enlarge to see an example of phpMyAdmin screen shot
  • Check “Select all. ” In the Structure box
  • Click “Add DROP TABLE, etc.”
  • When in doubt, leave a setting at it's default
  • Go down to the bottom and find “Save as file”

it is a good idea to today’s date to the default name.

  • Select the compression method (here we selected gzipped)
  • Press Go in the lower right corner

A popup window will ask you whether you want to save the exported file. Click OK (Save). Wait for the process to finish.

phpMyAdmin will zip a copy of your database and send it to your home computer’s desktop.


Tips and tricks

Useful and free books

Every Moodler should download the free book Using Moodle 2nd edition in .pdf. It tells you all about how to create Moodle courses. Its final chapter (16) describes basic system administration, including how to automate the backing up of your courses. That automated course backup is really simple and you should do it.

The rest of Using Moodle’s final chapter explains the administration settings on Moodle’s front page. All those explanations are vital. However, Using Moodle does not tell you how to backup your whole site.

Beginning administration FAQs

It is a good idea to reread the two Moodle FAQs: Beginning_Administration_FAQ and Beginning_Administration_2_FAQ


cPanelis a common webhost interface, where you manage what you have on your hosted server space.

You probably used cPanel when you installed Moodle. It includes File Manager. In addition, cPanel includes phpMyAdmin that we discussed above.

Another Site Backup

It is a good practice for a site administrator to have a test site not on their production server. If you have a spare computer capable of Internet connection, you can create a backup/test Moodle site. This is a great way to develop your abilities and test the process without using your production site. See one of the Complete install packages.

TIP: Create two different webservers as localhosts with the complete install packages. Turn on one and set it up as your production server. Turn it off and turn on the other webserver as perform the restore process on it. Hopefully you will not need to do this on your real production server, but you can practice.


What else should you back up?

There are a few webserver files that might be handy to have.

Moodle software is supported by three other types of software packages: a webserver (Apache), the PHP code processor and a database(MySQL) server. These will be installed on the webserver. A webhost will generally maintain and updates these and other packages. These programs work with Moodle code and communicate with each other.

It’s good to read the Site Backup FAQ [1] You will not understand everything, but that’s OK.

Experienced system administrators back up their sites according to instructions here: [2] But that page assumes that readers can write Unix/Linux commands and php code. We have give you a simplier alternative above.

Backing Up before an upgrade or adding a new module

Backing up prior to upgrading Moodle, needs special attention to details. Remember, when you upgrade Moodle, it will change the Moodle code, and probably the MySQL tables and perhaps things in the moodledata folder. This is also true if you are tweaking the code or adding contributed code. The old parts may not be compatible the new.

If for some reason the install does not work, you will probably want to roll things back by restoring the backups you made of MySQL, the Moodle code and moodledata.

You can see a forum discussion of this issue, reguarding Fantastico to install Moodle, here

Read more »

Help Desk Software by Kayako