I'm experiencing some issues after upgrading from Moodle 4.1 to 4.2. Specifically, the editors are not functioning correctly. When attempting to edit courses, the form field for uploading course images doesn't fully load, rendering it impossible to upload or interact with any of the functions. Additionally, the "add activity" boxes aren't responsive when clicking on the plus icon.
I've also noticed the message about the database tables using Antelope as the file format. It recommends converting them to the Barracuda file format. However, I believe this message was present before the upgrade, and the site was functioning correctly.
I'm currently in touch with my hosting provider, Let's Host, to obtain shell access for the table conversion. However, I suspect this might not be the root cause of the issues.
Is anyone else experiencing similar problems or have any ideas on how to resolve this? Should I consider opening a new thread for this specific issue? Your input would be greatly appreciated.
For reference, here are some details about my hosting package and server:
- Hosting Package: basic_drcla_drcla
- Server Name: server
- cPanel Version: 110.0 (build 10)
- Apache Version: 2.4.57
- MySQL Version: 10.6.15-MariaDB
- Operating System: Linux
- Shared IP Address: 80.93.29.157
It sounds like there's a problem loading and/or running the JavaScript for pages. Open your browser's developer tools (for example, Web Console in Firefox) and see if there are any error messages.
I've also noticed the message about the database tables using Antelope as the file format.
I don't think this would cause problems like the ones you're describing.
Can you get to the PHP info page (.../admin/phpinfo.php) and tell us which version of PHP you have?
Hi Leon,
I am still stuck on the same issue with no solution so thank you so much for your reply. "It sounds like there's a problem loading and/or running the JavaScript for pages. " this sounds right. I am installing firefox now to do that.
I am using PHP Version 8.0.30.
Thank you again,
I am still stuck on the same issue with no solution so thank you so much for your reply. "It sounds like there's a problem loading and/or running the JavaScript for pages. " this sounds right. I am installing firefox now to do that.
I am using PHP Version 8.0.30.
Thank you again,
Hi Leon,
Thank you for your response and the suggestions. I've followed your advice and checked the browser's developer tools for error messages. It appears that there are some browser-related issues, as indicated by the error messages regarding Firefox and Safari profiles. These issues seem to be specific to my browser environment and not directly related to the Moodle site itself.
Regarding the PHP version, I've accessed the PHP info page (.../admin/phpinfo.php) on my Moodle site, and it reports the following PHP version: 8.0.30. It seems that the PHP version is within the recommended range for Moodle 4.2, so that may not be the root cause of the issues.
To provide further context, I've been experiencing two main problems with my Moodle site:
1. Editor Issues: I've been unable to use the editor to edit content within Moodle. This issue seems to affect all courses and activities.
2. Course Structure: After a recent upgrade, the course structure appeared to be jumbled up, with all course content appearing in a single topic rather than being organized as it should be.
To address the issues mentioned above, I initially performed a complete backup of the site. After the backup, I proceeded with the upgrade, which initially appeared to go smoothly. However, it wasn't until a student reported issues with course modules and I began investigating that I discovered these issues. Unfortunately, I've deleted the backups I created after a security concern arose, so I'm unable to restore the site to a previous state.
I hope this additional information helps shed some light on the situation. Your insights and suggestions are greatly appreciated. If you have any further advice or if there are specific Moodle-related troubleshooting steps I should take, please let me know.
Best regards,
Ruth
Thank you for your response and the suggestions. I've followed your advice and checked the browser's developer tools for error messages. It appears that there are some browser-related issues, as indicated by the error messages regarding Firefox and Safari profiles. These issues seem to be specific to my browser environment and not directly related to the Moodle site itself.
Regarding the PHP version, I've accessed the PHP info page (.../admin/phpinfo.php) on my Moodle site, and it reports the following PHP version: 8.0.30. It seems that the PHP version is within the recommended range for Moodle 4.2, so that may not be the root cause of the issues.
To provide further context, I've been experiencing two main problems with my Moodle site:
1. Editor Issues: I've been unable to use the editor to edit content within Moodle. This issue seems to affect all courses and activities.
2. Course Structure: After a recent upgrade, the course structure appeared to be jumbled up, with all course content appearing in a single topic rather than being organized as it should be.
To address the issues mentioned above, I initially performed a complete backup of the site. After the backup, I proceeded with the upgrade, which initially appeared to go smoothly. However, it wasn't until a student reported issues with course modules and I began investigating that I discovered these issues. Unfortunately, I've deleted the backups I created after a security concern arose, so I'm unable to restore the site to a previous state.
I hope this additional information helps shed some light on the situation. Your insights and suggestions are greatly appreciated. If you have any further advice or if there are specific Moodle-related troubleshooting steps I should take, please let me know.
Best regards,
Ruth
Potential causes of problems stopping the page's JavaScript working are:
- JavaScript not being served by the web server due to some misconfiguration, particularly if slash arguments are not enabled.
- Files from the previous Moodle version still being present. This can happen if the upgrade was performed by copying the new version's files over the old version's.
- An additional plugin that's not compatible with the current Moodle version, or has a bug.
- Some additional HTML configured in Moodle that uses incompatible JavaScript.
If we can see errors from the browser's console – assuming there are some – then maybe we'll find a clue to the next steps.
Hello Leon,
Thank you for your prompt response and insightful suggestions. I truly appreciate your input. I'm currently in the process of working through a comprehensive troubleshooting plan provided by another member, Ken, on the Moodle forum. His guidance involves performing various checks, backups, and system diagnostics via the command line. It's a bit of a learning curve for me, but I'm determined to follow through.
I'll definitely keep in mind your points about potential causes, especially regarding JavaScript issues. If I encounter any errors in the browser's console during this process, I'll make sure to document them for further analysis. Your support is incredibly reassuring. I feel fortunate to be part of this community, and your assistance is invaluable.
Thank you again for your time and insights.
Best regards,
Ruth
Thank you for your prompt response and insightful suggestions. I truly appreciate your input. I'm currently in the process of working through a comprehensive troubleshooting plan provided by another member, Ken, on the Moodle forum. His guidance involves performing various checks, backups, and system diagnostics via the command line. It's a bit of a learning curve for me, but I'm determined to follow through.
I'll definitely keep in mind your points about potential causes, especially regarding JavaScript issues. If I encounter any errors in the browser's console during this process, I'll make sure to document them for further analysis. Your support is incredibly reassuring. I feel fortunate to be part of this community, and your assistance is invaluable.
Thank you again for your time and insights.
Best regards,
Ruth
Dunno this for sure but many set ups are set to place an error_log file in the directory where the error occurs. No GUI interface to look at them all ... soooooo
Get into Terminal
cd public_html (if code is in moodle directory add /moodle/ to the cd command.
Next command to find all/any files named error_log
find ./* -name error_log
If that kicks out a list of error_log files, one has to view all of them.
Let's say that one of the error_log files found is in
/admin/error_log
Then cat that file - remember that means view/show.
cat ./admin/error_log [ENTER]
The most recent errors are at the end of that file.
Can't tell you what is more important than other lines or errors, but any error_log file and any line could be the clue to fixing!
'SoS', Ken
Ruth, you have double-posted, https://moodle.org/mod/forum/discuss.php?d=448076#p1812313, so now you have dis-jointed help.
In reply to Rick Jerz
Re: Serious issues after upgrading from Moodle 4.1 to 4.2
by Visvanath Ratnaweera -
Which https://moodle.org/mod/forum/discuss.php?d=448076#p1812494 bounces back.
In reply to Visvanath Ratnaweera
Re: Serious issues after upgrading from Moodle 4.1 to 4.2
by Ruth Ruane -
Hello Visvanath Ratnaweera, I apologise for the double posting. It won't happen again.
I wanted to provide you with an update on the ongoing situation with the drclaresacademy.com site.
I've been actively working on troubleshooting the issues I've been encountering. Here's what I've tried and what I've observed:
1. Clean Install Attempt: In an attempt to address the issues, I tried a clean install of the Moodle upgrade on top of the existing files. Unfortunately, due to the removal of previous backups related to a security concern, I couldn't restore the site to its pre-upgrade state. So, I installed Moodle anew on the existing files.
2. Theme-Related Observation: One noticeable observation is that outside of the Boost theme, I can now click on the activity chooser where I couldn't before. However, within the Boost theme, I cannot interact with the activity chooser popup. Furthermore, even when I'm using another theme, I still cannot click on the "X" to close the popup, and the only way to close it is by refreshing the page.
3. Boost Theme Influence: It's worth noting that Boost has become the default theme for Moodle, and it seems that this theme might be a factor contributing to the issue. Unfortunately, it's not possible to completely remove Boost or install it separately, as it's now an integral part of Moodle.
Despite these observations, the site remains unusable in its current state, and I'm still not receiving any error messages from moodle when installing and everything "should" work. I've also initiated the process of downloading the existing courses, as they are now in Moodle 4.2 format. In the worst-case scenario, I may need to consider a new build of Moodle and then attempt to restore the courses. I'm exploring every possible avenue to resolve this situation.
I remember when something similar happened with my larger and more important website that an image of the whole server taken prior to the upgrade was necessary, however in this case it would be too risky to my other website because so much time has elapsed and of course the security clean I did after being notified of the malware was done after the upgrade as well. So in this circumstance it is not feasible for me to request a server rollback.
I want to express my gratitude for your continued support and patience. If you have any further insights or recommendations, please do share them, as your expertise is been invaluable to me.
I wanted to provide you with an update on the ongoing situation with the drclaresacademy.com site.
I've been actively working on troubleshooting the issues I've been encountering. Here's what I've tried and what I've observed:
1. Clean Install Attempt: In an attempt to address the issues, I tried a clean install of the Moodle upgrade on top of the existing files. Unfortunately, due to the removal of previous backups related to a security concern, I couldn't restore the site to its pre-upgrade state. So, I installed Moodle anew on the existing files.
2. Theme-Related Observation: One noticeable observation is that outside of the Boost theme, I can now click on the activity chooser where I couldn't before. However, within the Boost theme, I cannot interact with the activity chooser popup. Furthermore, even when I'm using another theme, I still cannot click on the "X" to close the popup, and the only way to close it is by refreshing the page.
3. Boost Theme Influence: It's worth noting that Boost has become the default theme for Moodle, and it seems that this theme might be a factor contributing to the issue. Unfortunately, it's not possible to completely remove Boost or install it separately, as it's now an integral part of Moodle.
Despite these observations, the site remains unusable in its current state, and I'm still not receiving any error messages from moodle when installing and everything "should" work. I've also initiated the process of downloading the existing courses, as they are now in Moodle 4.2 format. In the worst-case scenario, I may need to consider a new build of Moodle and then attempt to restore the courses. I'm exploring every possible avenue to resolve this situation.
I remember when something similar happened with my larger and more important website that an image of the whole server taken prior to the upgrade was necessary, however in this case it would be too risky to my other website because so much time has elapsed and of course the security clean I did after being notified of the malware was done after the upgrade as well. So in this circumstance it is not feasible for me to request a server rollback.
I want to express my gratitude for your continued support and patience. If you have any further insights or recommendations, please do share them, as your expertise is been invaluable to me.
Apologies for the double post, Rick. I wasn't entirely sure if this thread was the right place to seek help, and I was admittedly a bit flustered. After nearly 20 hours of near-continuous troubleshooting, I realised I needed a well-deserved break. However, I'm still grappling with the issue.
Initially, I had a complete backup of the site, and following the upgrade, I thought everything had gone smoothly. I manage three Moodle sites, and this particular one is the least active. Consequently, it took me two days to discover that something was amiss when a student reported that her course modules were inaccessible to students, which appeared to have occurred during the upgrade. When I investigated further, I found that all the content from different course topics had somehow merged into a single topic, creating significant disarray.
Additionally, I encountered a more concerning problem: I lost the ability to add new activities or edit any courses, not just one but across the board. I tried various troubleshooting steps, including changing themes, altering course themes, testing it on smaller courses, backing up and restoring the course, and none of these measures resolved the issue.
Now, the situation has become more complex. During the time between the student reporting the issue and my backing up the site and performing the upgrade, another student from a different Moodle site reached out, explaining that her site was flagged by Malwarebytes and wouldn't load. In response, I took immediate action and discovered hidden malware within some old language files on the other Moodle site. I conducted a comprehensive scan and thoroughly cleaned my entire server—an action I had been postponing for quite some time. My server was in pristine condition at this point.
As a precaution, I decided to delete the previous backups and create new ones. Unfortunately, it was after I took this step that the issues with the site arose. In other words I have no backup of the site from before the upgrade.
I'm reaching out to the Moodle community for assistance in resolving these challenges. Any guidance or insights would be greatly appreciated.
Initially, I had a complete backup of the site, and following the upgrade, I thought everything had gone smoothly. I manage three Moodle sites, and this particular one is the least active. Consequently, it took me two days to discover that something was amiss when a student reported that her course modules were inaccessible to students, which appeared to have occurred during the upgrade. When I investigated further, I found that all the content from different course topics had somehow merged into a single topic, creating significant disarray.
Additionally, I encountered a more concerning problem: I lost the ability to add new activities or edit any courses, not just one but across the board. I tried various troubleshooting steps, including changing themes, altering course themes, testing it on smaller courses, backing up and restoring the course, and none of these measures resolved the issue.
Now, the situation has become more complex. During the time between the student reporting the issue and my backing up the site and performing the upgrade, another student from a different Moodle site reached out, explaining that her site was flagged by Malwarebytes and wouldn't load. In response, I took immediate action and discovered hidden malware within some old language files on the other Moodle site. I conducted a comprehensive scan and thoroughly cleaned my entire server—an action I had been postponing for quite some time. My server was in pristine condition at this point.
As a precaution, I decided to delete the previous backups and create new ones. Unfortunately, it was after I took this step that the issues with the site arose. In other words I have no backup of the site from before the upgrade.
I'm reaching out to the Moodle community for assistance in resolving these challenges. Any guidance or insights would be greatly appreciated.
Does your cPanel have a Terminal icon?
If so that is ssh access to your slice of the shared server .... which is also an issue depending upon how much resources and limitations there are on your slice of that server.
Some of the DB issues can be explored and some fixed using
the .php scripts in code/admin/cli/
Those, however, are command line only and thus the question about "Does your cPanel have a Terminal icon?"
the .php scripts in code/admin/cli/
Those, however, are command line only and thus the question about "Does your cPanel have a Terminal icon?"
IF so, it might be possible for you to make command line backups of what you have now.
Tar ball ball of code, tar ball of minimal moodledata/filedir, and an SQL dump of your DB.
Best to have any backups rather than none! 
Also, does your cPanel show a Git icon?
'SoS', Ken
Hi Ken,
Thanks for your response and suggestions. I appreciate your willingness to help.
To be honest, I'm not very comfortable with command line operations, my control panel does have a terminal icon. I've mainly been using the cPanel interface for managing my site, and I haven't explored the command line much. However, I wanted to share that I have full server access to WHM and can change any settings since I'm using a VPS.
Regarding the .php scripts in code/admin/cli/, I'm open to learning and trying new things if it can help resolve the issues I'm facing. If you could provide some guidance or steps on how to access the Terminal and use those .php scripts in code/admin/cli/ to create backups, I'd be willing to give it a shot.
As for the Git icon, it has Git™ Version Control but it says: Warning: Your system administrator must enable shell access to allow you to view clone URLS. - I am the systems administrator ( unfortunately perhaps). But at the moment my hosting providers are working with me to help me resolve this.
I'd like to mention that I currently don't have backups of my site due to an unexpected malware issue that arose on another site I manage. To ensure the security of my server, I decided to run a scan and clean up any potential threats. In the process, I deleted the backups I had made before realising there was an issue with my Dr. Clare's Academy site which I had upgraded the day before the security issue arose. It's a decision I made to prioritise security, but I understand that it puts me in a challenging situation regarding the current troubleshooting process. I'm hoping that, with the help of the community here, we can find a solution to the issues I'm experiencing and get the site back on track.
Thanks again for your assistance and patience.
Best regards, Ruth
Thanks for your response and suggestions. I appreciate your willingness to help.
To be honest, I'm not very comfortable with command line operations, my control panel does have a terminal icon. I've mainly been using the cPanel interface for managing my site, and I haven't explored the command line much. However, I wanted to share that I have full server access to WHM and can change any settings since I'm using a VPS.
Regarding the .php scripts in code/admin/cli/, I'm open to learning and trying new things if it can help resolve the issues I'm facing. If you could provide some guidance or steps on how to access the Terminal and use those .php scripts in code/admin/cli/ to create backups, I'd be willing to give it a shot.
As for the Git icon, it has Git™ Version Control but it says: Warning: Your system administrator must enable shell access to allow you to view clone URLS. - I am the systems administrator ( unfortunately perhaps). But at the moment my hosting providers are working with me to help me resolve this.
I'd like to mention that I currently don't have backups of my site due to an unexpected malware issue that arose on another site I manage. To ensure the security of my server, I decided to run a scan and clean up any potential threats. In the process, I deleted the backups I had made before realising there was an issue with my Dr. Clare's Academy site which I had upgraded the day before the security issue arose. It's a decision I made to prioritise security, but I understand that it puts me in a challenging situation regarding the current troubleshooting process. I'm hoping that, with the help of the community here, we can find a solution to the issues I'm experiencing and get the site back on track.
Thanks again for your assistance and patience.
Best regards, Ruth
You have the tools you need to improve managing the moodle sites via command line. And considering your situation, best to begin learning how to use CLI - especially considering you have no backups at all at this point. Having some backups is better than none.
So backup first - then other uses of php CLI scripts that might help.
Since I don't host where you host and how you host, I cannot give specific to your server directions ... 1,2,3,4. That, however, would be possible, IF ... IF ... you were to share your WHM credentials in a private message to me in moodle.org.
If not ... then generic direcitons ... you have to translate unknowns to what you see.
Here we go ... backups first.
Click Terminal Icon
You will see a black screen (a shell) open in the right panel
and there is a prompt.
First command:
pwd [ENTER]
stands for present working directory
Reason ... to find location and learn paths. You are in your home directory and have total access to any/all folders files at that location.
At this location, we are going to create a directory to use to store site backups:
mkdir backups [ENTER]
That has created an empty folder/directory called 'backups'
Path to that will be **something like**: /home/accountlogin/backups
where accountlogin is your account login name.
Am going to guess - you confirm - that you have a 'public_html' directory and inside there is where your moodle code resides.
So to confirm:
ls -l [ENTER] (like list long in PC lingo)
do you see a 'public_html' directory (left column in shows ownerships/permissions and has 'd' as first letter in that column.
If there is one there, cd public_html [ENTER] ... cd means change directories ...your prompt might now change to show that you are in public_html.
Is moodle located there? If it is, there will be a config.php file and a version.php file.
See what version of Moodle:
fgrep '$release' version.php [ENTER]
What does that show?
Now we need to gather info for backups from the config.php file.
cat config.php [ENTER] - cat command just displays file name given and it will scroll ... hopefully not off the screen.
Open a local text file on your workstation - Textedit MAC or if on a PC NotePad ... reason ... we are going copy the text shown in cat of config.php into the text file for reminders and for swtches we need for making a backup of the site.
DB server (localhost?), DB name, DB user, DB password, path to moodledata
Ok we are in public_html .. backups directory is one level up from public_html ...
From config.php we saw DB name, DB user, DB password.
Let's try making a sql dump (backup) of your DB for moodle):
issue:
mysqldump -u DBuser -p'DBpassword' DBname > ../backups/moodledb1.sql [ENTER]
You replace DB--- stuff above with info you have in the text file.
The -p' thing is necessary - have to enclose the password in between 'tics'. Also remember that linux is case senstive.
Use lower case letters for files ou create with NO spaces NOR special characters ... use alphanumeric only.
Did that work?
Next posting or we could move to direct email ... I'll PM you my address.
'SoS', Ken
Replying to own posting to 'keep things together' ...
Part 2
Backup of code and moodledata
You've clicked terminal, you are in your home directory where 'backups' directory is.
First we need to check to see if tar is on your server:
which tar [ENTER]
if it returns a path, we are good to go.
First command to backup moodle code which is in public_html
We are in your home directory where we can see the 'backups' directory.
tar -cvf ./backups/moodlecode.tar ./public_html/ [ENTER]
tar is the tape archive application
-cvf are switches c is create v is verbose (show what it's doing) and f we are working with a file(s).
That will scroll (the verbose) and might take a few minutes. Let it do its thing.
BE PATIENT! When it finishes, lets check if it created the backup of code:
ls -l ./backups/ [ENTER]
Does it show a moodlecode.tar file?
Good!
Now for moodledata - which will be larger than the code backup.
We probably need to check to make sure we have enough space left on the server
to make a backup of moodle data, so there's a command for that:
df -h [ENTER]
df = disk free (shows how much space is used and how much is free)
The -h is 'human' show the space usage/free in terms humans can understand.
We are going to assume you have enough space!
You copied the full path to moodledata to that text file you created, right?
*Might be something like*: /home/accountlogin/moodledata
Since we are in /home/accountlogin, see if it's there:
ls -ld moodledata [ENTER]
Is it there? Good to go then!
Command:
tar -cvf ./backups/moodledata.tar /full/path/to/moodledata [ENTER]
You replace '/full/path/to/moodledata' with the path to moodledata you got from config.php.
That will scroll and take longer than the code. BE PATIENT! Let it do its thing!
When it finishes, check to see that it's there:
ls -l ./backups/ [ENTER]
Do you see a moodledata.tar file there?
How large is it?
du ./backkups/moodledata.tar [ENTER]
du command to show disk usage.
the ./backups/moodledata.tar is both the path to the file and the file.
Let's check free space again:
df -h [ENTER]
Now we have a site backup ... fingers crossed.
Next up, a question ... how many courses were there in the site?
Reason ... if we can't recover the site, the next best option
is to see if we can't make course backups and save them to our backups directory.
Those, hopefully, can be restored to a new fresh moodle at same location as the old can't recover site.
First we need to check to see if tar is on your server:
which tar [ENTER]
if it returns a path, we are good to go.
First command to backup moodle code which is in public_html
We are in your home directory where we can see the 'backups' directory.
tar -cvf ./backups/moodlecode.tar ./public_html/ [ENTER]
tar is the tape archive application
-cvf are switches c is create v is verbose (show what it's doing) and f we are working with a file(s).
That will scroll (the verbose) and might take a few minutes. Let it do its thing.
BE PATIENT! When it finishes, lets check if it created the backup of code:
ls -l ./backups/ [ENTER]
Does it show a moodlecode.tar file?
Good!
Now for moodledata - which will be larger than the code backup.
We probably need to check to make sure we have enough space left on the server
to make a backup of moodle data, so there's a command for that:
df -h [ENTER]
df = disk free (shows how much space is used and how much is free)
The -h is 'human' show the space usage/free in terms humans can understand.
We are going to assume you have enough space!
You copied the full path to moodledata to that text file you created, right?
*Might be something like*: /home/accountlogin/moodledata
Since we are in /home/accountlogin, see if it's there:
ls -ld moodledata [ENTER]
Is it there? Good to go then!
Command:
tar -cvf ./backups/moodledata.tar /full/path/to/moodledata [ENTER]
You replace '/full/path/to/moodledata' with the path to moodledata you got from config.php.
That will scroll and take longer than the code. BE PATIENT! Let it do its thing!
When it finishes, check to see that it's there:
ls -l ./backups/ [ENTER]
Do you see a moodledata.tar file there?
How large is it?
du ./backkups/moodledata.tar [ENTER]
du command to show disk usage.
the ./backups/moodledata.tar is both the path to the file and the file.
Let's check free space again:
df -h [ENTER]
Now we have a site backup ... fingers crossed.
Next up, a question ... how many courses were there in the site?
Reason ... if we can't recover the site, the next best option
is to see if we can't make course backups and save them to our backups directory.
Those, hopefully, can be restored to a new fresh moodle at same location as the old can't recover site.
Part 3 will be how to backup a course to our backups directory ... IF we have enough space!
'SoS', Ken
Part 3 - backup courses.
this involves some DB queries and exporting those queries to text files
we can use to make course backups using the CLI .php scripts in code/admin/cli/
We will do this in public_html/admin/cli/
So cd public_html/admin/cli/
The script is backup.php ... let's make sure it's there:
ls -l backup.php
The scripts have help screens if you issue them with no optons/parameters.
So:
php ./backup.php [ENTER]
will show you the help screen.
but, we need to know 2 things ... a course ID number and the destination of the
course backup file.
We know the destination: /home/accountlogin/backups/
Now to get the course ID's we will have to make a query of the DB:
mysql -u $mddbuser -p$mddbpass -e "use $mddbname;select id from mdl_course;" > cids.txt;cat cids.txt
You substitute $ variables above with your site info.
That will create a text file called cids.txt - which is nothing more than a listing of the course ID's.
They may not be in sequence ... that's not unusual for a moodle.
Here's an example of what that might look like:
mysql: [Warning] Using a password on the command line interface can be insecure.
id
1
3
4
56
59
85
114
115
116
2
113
57
86
112
Course ID 1 is your front page and we cannot restore that.
So we will use the next number ... let's say that's 3 as in the example of cids.txt file.
Backup course ID 3:
In moodlecode/admin/cli/ where we can see backup.php:
command:
php backup.php --courseid=3 --destination=/home/accountlogin/backups/
Hopefully, when that finishes, there will be an .mbz file in /home/accountlogin/backups/
Check: ls -l /home/accountlogin/backups/*.mbz
A * is global all so command above would show all files that have the .mbz extension.
Is one there? Good! Next course.
Up Arrow on keyboard ... the command you just issued shows again.
Move the cursor to the course ID number and change the 3 to the next number in your list.
As per example above, that would be '4'.
Run the command ... let it finish. See if it's there. see above ... ok, next course.
Up Arrow again ... same except change 4 to 56 as per example.
[ENTER]
We do that until we have all course backups.
Now if something fails, it will tell you so copy and paste what it said to a local notepad text file, come back here and share that!
this involves some DB queries and exporting those queries to text files
we can use to make course backups using the CLI .php scripts in code/admin/cli/
We will do this in public_html/admin/cli/
So cd public_html/admin/cli/
The script is backup.php ... let's make sure it's there:
ls -l backup.php
The scripts have help screens if you issue them with no optons/parameters.
So:
php ./backup.php [ENTER]
will show you the help screen.
but, we need to know 2 things ... a course ID number and the destination of the
course backup file.
We know the destination: /home/accountlogin/backups/
Now to get the course ID's we will have to make a query of the DB:
mysql -u $mddbuser -p$mddbpass -e "use $mddbname;select id from mdl_course;" > cids.txt;cat cids.txt
You substitute $ variables above with your site info.
That will create a text file called cids.txt - which is nothing more than a listing of the course ID's.
They may not be in sequence ... that's not unusual for a moodle.
Here's an example of what that might look like:
mysql: [Warning] Using a password on the command line interface can be insecure.
id
1
3
4
56
59
85
114
115
116
2
113
57
86
112
Course ID 1 is your front page and we cannot restore that.
So we will use the next number ... let's say that's 3 as in the example of cids.txt file.
Backup course ID 3:
In moodlecode/admin/cli/ where we can see backup.php:
command:
php backup.php --courseid=3 --destination=/home/accountlogin/backups/
Hopefully, when that finishes, there will be an .mbz file in /home/accountlogin/backups/
Check: ls -l /home/accountlogin/backups/*.mbz
A * is global all so command above would show all files that have the .mbz extension.
Is one there? Good! Next course.
Up Arrow on keyboard ... the command you just issued shows again.
Move the cursor to the course ID number and change the 3 to the next number in your list.
As per example above, that would be '4'.
Run the command ... let it finish. See if it's there. see above ... ok, next course.
Up Arrow again ... same except change 4 to 56 as per example.
[ENTER]
We do that until we have all course backups.
Now if something fails, it will tell you so copy and paste what it said to a local notepad text file, come back here and share that!
And now we can work on fixing the site! :|
'SoS', Ken
Investigations via Command Line - all related to moodle.
Get into terminal
cd public_html
ls to see if one can see config.php and a version.php file.
If there is a moodle directory, cd moodle.
php -v
shows the command line version of PHP CLI the web server is using with the moodle.
mysql -V
shows the version of mysql or mariaDB client which should match the DB server.
In moodle code admin/cli/ so cd to that location.
php cfg.php > allsettings.txt
The above redirects all config settings of you moodle to a text file by the name shown above.
That file you can view and download by doing to:
https://yoursite/admin/cli/allsettings.txt
Once you have downloaded that file, good idea to remove it.
In moodlecode/admin/cli/
rm allsettings.txt
CLI environment check:
php checks.php [ENTER]
What does that show/say?
Check on the DB.
php mysql_compressed_rows.php
and
php mysql_collation.php
Both have help screens.
The later can fix DB collation if the DB collation isn't or doesn't match what's in config.php of site.
That's enough to get us started, I think.
Leon is correct ... you could have a mix of moodle code, but there is no easy way to determine.
Get into terminal
cd public_html
ls to see if one can see config.php and a version.php file.
If there is a moodle directory, cd moodle.
Then fgrep '$release' version.php
copy and paste that output to local NotePad text file.
php -v
shows the command line version of PHP CLI the web server is using with the moodle.
mysql -V
shows the version of mysql or mariaDB client which should match the DB server.
In moodle code admin/cli/ so cd to that location.
php cfg.php > allsettings.txt
The above redirects all config settings of you moodle to a text file by the name shown above.
That file you can view and download by doing to:
https://yoursite/admin/cli/allsettings.txt
Once you have downloaded that file, good idea to remove it.
In moodlecode/admin/cli/
rm allsettings.txt
CLI environment check:
php checks.php [ENTER]
What does that show/say?
Check on the DB.
php mysql_compressed_rows.php
and
php mysql_collation.php
Both have help screens.
The later can fix DB collation if the DB collation isn't or doesn't match what's in config.php of site.
That's enough to get us started, I think.
Leon is correct ... you could have a mix of moodle code, but there is no easy way to determine.
'SoS', Ken
Hi Ken,
Firstly, I want to express my sincere appreciation for the extensive guidance you've provided. Your detailed instructions are incredibly helpful, even for someone like me who's not very familiar with command line interfaces. I'm going to take it one step at a time, carefully following your instructions.
Your commitment to assisting me in this troubleshooting process is truly commendable. I am amazed at the amount of effort and time you've invested in helping me navigate through these challenges. It's going to be a bit of a crash course for me in the command line interface, but I understand its importance in my current situation.
I'll begin by creating the necessary backups as you've outlined, and then move on to the subsequent steps. Your step-by-step breakdown makes it much more manageable for me, and I'll be sure to keep you posted on the progress.
Once again, thank you for your invaluable support.
Best regards,
Ruth
Firstly, I want to express my sincere appreciation for the extensive guidance you've provided. Your detailed instructions are incredibly helpful, even for someone like me who's not very familiar with command line interfaces. I'm going to take it one step at a time, carefully following your instructions.
Your commitment to assisting me in this troubleshooting process is truly commendable. I am amazed at the amount of effort and time you've invested in helping me navigate through these challenges. It's going to be a bit of a crash course for me in the command line interface, but I understand its importance in my current situation.
I'll begin by creating the necessary backups as you've outlined, and then move on to the subsequent steps. Your step-by-step breakdown makes it much more manageable for me, and I'll be sure to keep you posted on the progress.
Once again, thank you for your invaluable support.
Best regards,
Ruth
Hi All, I just wanted to quickly weigh in to say thank you to everyone who gave me suggestions and help. Ken was no end of help! Thank you Ken! I ended up doing a new installation of Moodle. So complicated to go into. But I just wanted to say thanks. The issue wasn't solved but the thread can be closed.