I logged in and was trying to get into the site admin to the users area and when I click on the drop down it doesn't work.
nnn
I got one of these on chrome but not on safari.
I got these errors after i tried searching for smthg.
Ok... open your browser's Javascript console (F12 + click console). Reproduce the problem. Any red errors?
Ok - I don't know anything about your hosting but I assume there's some way to work out how much disk space you have left?
Specifically, files are stored at wherever $CFG->dataroot is pointing to in Moodle's config.php. If Moodle is unable to write to that, weird things will happen. Anyway, it was just a thought.
Specifically, files are stored at wherever $CFG->dataroot is pointing to in Moodle's config.php. If Moodle is unable to write to that, weird things will happen. Anyway, it was just a thought.
I asked the server and they said there is no specific limit for my plan and I am at 15gb which is fine.
Today i tried searching the site admin since the drop down doesn't work and got this error:
This page isn’t working
www.mysite.com is currently unable to handle this request.
HTTP ERROR 500
I am on moodle 3.9 i think. could an old version of moodle be the reason why it's doing this? But i just checked another moodle site i got and it's on moodle 3.8 and it doesn't have this problem. drop downs work fine there
Pardon intrusion ... did a NON-EVASIVE curl -I query on https://course.FQDN and it flipped to https://www.course.FQDN as well as reported a 'content-security-policy: upgrade-insecure-requests;'
So 2 things ... in config.php file of the code what is the wwwurl variable set to? www.course.FQDN or course.FQDN.
And secondly, the content-security-policy thang above.
Doing a Google search for such issues shows:
"The upgrade-insecure-requests Content Security Policy (CSP) directive instructs browsers to automatically upgrade HTTP requests to HTTPS, addressing mixed content issues when migrating to HTTPS. It effectively tells the browser to treat all insecure URLs (HTTP) as if they were secure URLs (HTTPS). This is particularly useful for websites with many legacy URLs that need to be rewritten to use HTTPS"
Am guessing your site might have mixed content ... http:// along with https://
Your question about why one 3.x site was working and the other 3.x site not, might be due to mixed http with https. All should be https.
One should be able to go directly to:
https://site/admin/tool/httpsreplace/
And replace all http:// with https://
Error 500's are catch alls ... and about the only way one could get anything useful for them is to look at error log line just before the 500 lines for clues.
Your debug lines point to issues with cache.
You should also be able to go directly to:
https://site/admin/purgecaches.php
If that doesn't purge, one could do that manually via File browser in a panel. Remove the contents of moodledata/cache/ moodledata/muc/ moodledata/localcache/
That's contents of not the directories themselves.
'SoS', Ken
in config.php the only url thing i see is:
$CFG->wwwroot = 'https://www.my.site.com';
when i try to go to site.com/admin/purgecaches.php i will get the above pic of coding error detected...
moodledata/cache was empty
i don't see a moodledata/muc or a moodledata/localcache
the only other folders in there were also empty
In your screen shot, url showed course.domain.
"moodledata/cache was empty"
Shouldn't be empty!
"the only other folders in there were also empty"
I hope NOT moodledata/filedir/! That's the directory containing everything upload to the moodle and more!
Do you have command line access? If so, please issue:
df -h
at any cli prompt.
as well as:
uname -an
Do you have a site backup? :|
And nothing above those error 500 lines in logs?
'SoS', Ken
If the moodledata directory you are looking at is the same one as seen in the config.php file of the site, yes ... delete contents.
If your cron job is running, that moodle will begin to re-populate them ... even more when you begin to use the site. Site might be slow at first, but it will speed up.
Here's contents of a 4.4.8+ (Build: 20250417) moodledata directory (just updated it today via git ... note the build date)
System is Rocky9 so the web service user is 'apache' on my server. Yours is?
drwxrwxrwx. 2 apache apache 4096 Feb 10 2024 antivirus_quarantine
drwxrwxrwx. 4 apache apache 4096 Apr 17 17:56 cache
drwxr-xr-x. 3 apache apache 4096 Feb 16 2024 dkim
drwxrwxrwx. 2 apache apache 4096 Mar 5 08:03 environment
drwxrwsrwx. 258 apache apache 4096 Sep 30 2023 filedir
drwxrwxrwx. 2 apache apache 4096 Feb 10 2024 lang
drwxrwxrwx. 9 apache apache 4096 Apr 17 18:10 localcache
drwxrwxrwx. 2 apache apache 4096 Apr 17 17:52 muc
drwxrwxrwx. 3 apache apache 4096 Feb 23 16:41 repository
drwxrwxrwx. 2 apache apache 4096 Apr 17 18:21 sessions
drwxrwxrwx. 8 apache apache 4096 Apr 17 17:55 temp
drwxrwxrwx. 2 apache apache 4096 Apr 16 18:56 trashdir
Here's cache directory of same system:
-rw-rw-rw-. 1 apache apache 379 Apr 17 17:55 bootstrap.php
drwxrwxrwx. 3 apache apache 4096 Apr 17 17:55 cachestore_file
-rw-rw-rw-. 1 apache apache 731026 Apr 17 17:55 core_component.php
drwxrwxrwx. 2 apache apache 4096 Apr 17 18:00 simplepie
In admin/cli/ of that sites code:
php purge_caches.php
should work.
You say you have multiple sites on that server. How many? and strongly advise not leaving anything moodle if it's not used ... just confuses.
Are the cron jobs for all of your sites running as they should?
I have an executable bash shell script in /usr/local/bin/ called runallcrons
Looks like:
echo 'mdlandcli';
php /var/www/html/mdlandcli/admin/cli/cron.php
echo 'mdlsamples';
php /var/www/html/mdlsamples/admin/cli/cron.php
echo 'm44sb';
php /var/www/html/m44sb/admin/cli/cron.php
'SoS', Ken
I would first purge the cache from the command line (before deleting files manually). I suspect that will fix it.
cd [path to your moodle site root]
php admin/cli/purge_caches.php
https://docs.moodle.org/500/en/Administration_via_command_line#Purge_caches
If your cron job is not set up for Moodle then after you have purged caches you should run that too. Never having run cron is one way you might have found yourself in this situation.
cd [path to your moodle site root]
php admin/cli/cron.php
If you can't solve it, it might be a good idea to post a job on the Moodle jobs board.
cd [path to your moodle site root]
php admin/cli/purge_caches.php
https://docs.moodle.org/500/en/Administration_via_command_line#Purge_caches
If your cron job is not set up for Moodle then after you have purged caches you should run that too. Never having run cron is one way you might have found yourself in this situation.
cd [path to your moodle site root]
php admin/cli/cron.php
If you can't solve it, it might be a good idea to post a job on the Moodle jobs board.
So problem resolved?
Some things ....
To find version of Moodle if you can't get to admin/environment check. From command line:
cd /path/to/moodlecode/
fgrep '$release' version.php
Important to know version when upgrading.
http://www.syndrega.ch/blog/#php-and-dbms-compatibility-of-major-moodle-releases
Making sure cron is running ... again from command line:
cd /path/to/moodlecode/
php admin/cli/cron.php
Pay attention to any errors and especially adhoc task with the newer versions of moodle.
There are many cli only scripts in moodlecode/admin/cli/ that will help with issues.
https://docs.moodle.org/500/en/Administration_via_command_line
If you have a WAF, mod_security, CloudFlare, other in front of your moodle, updates and upgrades to core are much more easily performed via command lien on the server as those bypass the front end protections which sometimes interpret updates/upgrades as something malicious.
Performing checks and backups of the site can be performed via command line just prior to update or upgrade of core.
checks.php, check_database_schema.php, cron.php
Backups:
Here's an example. You would have to create the backups folder on the largest partition of your server and figure out paths - replace []'s in example below and if you note I include the
current version of moodle in the backup file name:
echo 'Currently: 4.4.8+ (Build: 20250417)';
tar -cvf /home/[customerid]/backups/moodle-code-448+-$(date +%Y%m%d%-H%M%S).tar [/path/to/moodlecode/
#echo 'running moodledata min';
tar -cvf /home/[customerid]/backups/moodle-data-min-448+-$(date +%Y%m%d%-H%M%S).tar /var/www/moodledata/filedir;
echo 'running db dump';
mysqldump -u root -p [nameofdb4moodle] > /home/[customerid]/backups/moodle-db-448+-$(date +%Y%m%d%-H%M%S).sql;
ls -l /home/[customerid]/backups/;
df -h;
The last line gets a check of free space.
It is well worth your time to learn a little command line!
'SoS', Ken
Everytime I contact them they say Moodle is beyond their scope and say i need a developer. I contacted them via chat 3 times about this and that's where it always ends. Not sure i can turn on debugging as I couldn't directly go to the purgecache.php page it just redirected to those red coding errors in the pic above.