Hello all,
I hope I choose the right forum...
We've recently changed our webserver in shared hosting. We migrated all applications, including some Moodle installations, using the Plesk Backup utility. Everything went fine: we just had to update in the config file some absolute paths from:
/home/httpd/vhosts/...
to:
/var/www/vhosts/...
Every install of Moodle started to work again, except for an issue we think is still dealing with the changed paths.
All our Moodle sites have problems with the item links under Users > Profiles: each link under this folder brings to a blank page... And we can't figure where the error is.
Has anyone a suggestion for this?
Thanks in advance
ADG,
You must have a different version of Moodle than I do. I have Moodle 1.9.1 on my handy dandy PC running Windows XP Pro. When I log in as admin and click on Users in the Administration menu, I get Authentication, Accounts, and Permissions. Under Accounts, there are six items, including Upload user pictures and User profile fields.
Anyway, when you move your mouse onto the Profiles item under Users, does your browser give you any indication what URL that item links to, like on the status bar? If so, what is it? If not, perhaps you can right click on it and select Properties or Copy Link Location from the pop-up menu. If you select the latter, just go to a blank text document (Notepad) or Word doc and paste. That will give you the URL. If none of these methods work, you might have to look at the HTML source code of the page. But it shouldn't come to that.
If the URL you find is what it was with the old server, either you didn't change the wwwroot setting in config.php (main Moodle directory), or you didn't run admin/replace.php to change the URLs in the database. See Moodle migration.
RLE
You must have a different version of Moodle than I do. I have Moodle 1.9.1 on my handy dandy PC running Windows XP Pro. When I log in as admin and click on Users in the Administration menu, I get Authentication, Accounts, and Permissions. Under Accounts, there are six items, including Upload user pictures and User profile fields.
Anyway, when you move your mouse onto the Profiles item under Users, does your browser give you any indication what URL that item links to, like on the status bar? If so, what is it? If not, perhaps you can right click on it and select Properties or Copy Link Location from the pop-up menu. If you select the latter, just go to a blank text document (Notepad) or Word doc and paste. That will give you the URL. If none of these methods work, you might have to look at the HTML source code of the page. But it shouldn't come to that.
If the URL you find is what it was with the old server, either you didn't change the wwwroot setting in config.php (main Moodle directory), or you didn't run admin/replace.php to change the URLs in the database. See Moodle migration.
RLE
RLE,
Thank you for your answer.
We are running Moodle 1.9.1 too. I'm sorry, I just translated from my language to what I thought it was in English... We also got in the Administration menu: Authentication, Accounts, Permissions (in Italian).
Under Accounts we have these item links:
- http://www.domain.it/moodle/admin/user.php
- http://www.domain.it/moodle/admin/user/user_bulk.php
- http://www.domain.it/moodle/user/editadvanced.php?id=-1
- http://www.domain.it/moodle/admin/uploaduser.php
- http://www.domain.it/moodle/admin/uploadpicture.php
- http://www.domain.it/moodle/user/profile/index.php
The latter is the only working URL under this menu. All other menu items seem to work. And of course all the URLs, either working or not, are correct.
We didn't need to change the wwwroot because in the new server we moved everything in the same way of the old (the Plesk backup is a dump indeed). We changed instead the dirroot and the dataroot which are absolute paths.
I didn't know about the admin/replace.php script... But I've already done the same thing in MySQL with a replace() command: now there are no occurencies in the DB for the string "/home/httpd/vhosts/".
The old and the new server are both LAMP: the difference is basically in the hardware... And in PHP: the old was PHP4.x, the new is PHP5.x.
Is it possible that PHP has anything to do whit this strange issue?
Thank you for your answer.
We are running Moodle 1.9.1 too. I'm sorry, I just translated from my language to what I thought it was in English... We also got in the Administration menu: Authentication, Accounts, Permissions (in Italian).
Under Accounts we have these item links:
- http://www.domain.it/moodle/admin/user.php
- http://www.domain.it/moodle/admin/user/user_bulk.php
- http://www.domain.it/moodle/user/editadvanced.php?id=-1
- http://www.domain.it/moodle/admin/uploaduser.php
- http://www.domain.it/moodle/admin/uploadpicture.php
- http://www.domain.it/moodle/user/profile/index.php
The latter is the only working URL under this menu. All other menu items seem to work. And of course all the URLs, either working or not, are correct.
We didn't need to change the wwwroot because in the new server we moved everything in the same way of the old (the Plesk backup is a dump indeed). We changed instead the dirroot and the dataroot which are absolute paths.
I didn't know about the admin/replace.php script... But I've already done the same thing in MySQL with a replace() command: now there are no occurencies in the DB for the string "/home/httpd/vhosts/".
The old and the new server are both LAMP: the difference is basically in the hardware... And in PHP: the old was PHP4.x, the new is PHP5.x.
Is it possible that PHP has anything to do whit this strange issue?
I add some information that might be useful.
There are some differences in PHP settings between the old server and the new one.
Apart from the new being PHP5 as I said, all typical settings (register_globals, display_errors, safe_mode, etc...) are quite the same. In the new server, PHP runs as an apache module, as it was in the old.
One setting instead has a difference and it could be of some importance: while the old server had a global session.save_path (something like a "/var/lib/php/session" value), the new one uses this local path:
/var/www/vhosts/domain.it/httpdocs/tmp
So the following is:
Open basedir: /var/www/vhosts/domain.it/httpdocs:/var/www/vhosts/domain.it/httpdocs/tmp
Can this help in any way?
There are some differences in PHP settings between the old server and the new one.
Apart from the new being PHP5 as I said, all typical settings (register_globals, display_errors, safe_mode, etc...) are quite the same. In the new server, PHP runs as an apache module, as it was in the old.
One setting instead has a difference and it could be of some importance: while the old server had a global session.save_path (something like a "/var/lib/php/session" value), the new one uses this local path:
/var/www/vhosts/domain.it/httpdocs/tmp
So the following is:
Open basedir: /var/www/vhosts/domain.it/httpdocs:/var/www/vhosts/domain.it/httpdocs/tmp
Can this help in any way?
ADG,
- replace() is not a command, it is a function. It lets you give it three strings, and its value will be the result of replacing all occurrences of the second string in the first string with the third string. That's all it does. By itself, it does not change any part of the database whatsoever. You could use it in an UPDATE query to change all occurrences of a string in a particular column of a particular table. But to do that for all text columns in every table, you would have to write a script. That's what admin/replace.php does.
- I take it that your dirroot is /var/www/vhosts/domain.it/httpdocs. In that case, your open_basedir (or your session.save_path) would not seem to be the cause of some of the Accounts menu item links not working while others do work. Because all the links you show start with that string when translated into the local filesystem pathname form. However, it looks like your open_basedir value is problematic, assuming your dataroot is outside your dirroot (as it must be for security reasons), because Moodle needs to be able to access files inside the data directory.
RLE,
1. you're right, I'm not a programmer and I'm not using the right terms. I executed the following SQL string:
UPDATE mdl_log SET info = REPLACE(info, '/home/httpd/vhosts/', '/var/www/vhosts/');
'mdl_log' were the only table and 'info' the unique field where I found any occurrencies for the string '/home/httpd/vhosts/' (Well, not exactly the unique occurences: I've changed manuallt the rest).
Anyway, in another installation I ran admin/replace.php successfully, but the problem with those links remains.
2. I confirm, my dataroot is outside the dirroot, althought it's not the most secure configuration: for every installation of Moodle we set a /moodle/ dir under httpdocs/ (the web root in Plesk) and a /moodledata/ dir also under httpdocs/ (thus: http://www.domain.it/moodle/ and http://www.domain.it/moodledata/). The dataroot is protected only by a .htaccess file and I also tried to see if the links worked without the htaccess file in this data dir.
I agree that the new webserver could have some problematic configurations... So I would like to know what should be changed by the hosting provider.
Thank you for your help.
1. you're right, I'm not a programmer and I'm not using the right terms. I executed the following SQL string:
UPDATE mdl_log SET info = REPLACE(info, '/home/httpd/vhosts/', '/var/www/vhosts/');
'mdl_log' were the only table and 'info' the unique field where I found any occurrencies for the string '/home/httpd/vhosts/' (Well, not exactly the unique occurences: I've changed manuallt the rest).
Anyway, in another installation I ran admin/replace.php successfully, but the problem with those links remains.
2. I confirm, my dataroot is outside the dirroot, althought it's not the most secure configuration: for every installation of Moodle we set a /moodle/ dir under httpdocs/ (the web root in Plesk) and a /moodledata/ dir also under httpdocs/ (thus: http://www.domain.it/moodle/ and http://www.domain.it/moodledata/). The dataroot is protected only by a .htaccess file and I also tried to see if the links worked without the htaccess file in this data dir.
I agree that the new webserver could have some problematic configurations... So I would like to know what should be changed by the hosting provider.
Thank you for your help.
Added infos:
1. in some old installations of Moodle (1.5.2 and 1.5.3+) everything seems to work fine;
2. in the 1.9.1 installations instead also the Cron scripts doesn't finish successfully. They all stops with the following messages:
1. in some old installations of Moodle (1.5.2 and 1.5.3+) everything seems to work fine;
2. in the 1.9.1 installations instead also the Cron scripts doesn't finish successfully. They all stops with the following messages:
Server Time: Mon, 16 Mar 2009 10:58:44 +0100 Starting activity modules Processing module function assignment_cron ...Does it help to target the problem?
ADG,
This is a response to both of your last two posts.
This is a response to both of your last two posts.
- That's good to know. But it raises the question: how did you find out that the only occurrence is in the info column of the mdl_log table? Also, I believe the migration instructions talk mainly about replacing the old URL (wwwroot) in the database with the new one, rather than pathnames (dirroot).
- Your right, that's not a secure configuration. The important thing is not that dataroot be outside of dirroot, but that it be outside the web document root, that is, the highest directory that is accessible to web browsers. The fact that you can access your data directory as http://www.domain.it/moodledata indicates that it is not in a secure location. Some hosting providers don't give you a choice but to locate all your directories within the web root; that's why you need to be able to keep the hackers away with .htaccess or an equivalent webserver configuration method (for example, for IIS).
- Okay. I'm not sure whether you are referring to the database replace problem, or the dataroot location problem, but it's good to know it works. But that doesn't mean it's secure!
- Yes, I would say you need to target the problem in order to find what's causing it before you can fix it. I just glanced at the source code of admin/cron.php. It executes a loop, going through all the modules you have installed, standard or not, and it looks in each one for a function called xxx_cron, where xxx is the name of the module. If it finds it, it tries to execute it. In your case, it was doing that for the assignment module (the alphabetically first standard module) when it stopped. So it never got to the other modules. Also, after that loop completes, it goes through another loop for all the blocks. Since it never completed the module loop, it never got to the block loop. There's lots of other stuff it does after the block loop, so it never got to those either. Apparently the problem is somewhere in the function assignment_cron, in mod/assignment/lib.php. In the cross-reference listing of moodle at http://xref.moodle.org/nav.html?index.html, its definition starts at line 2023 (this may vary slightly with the version). According to the comment near the beginning of that definition, its purpose is "Finds all assignment notifications that have yet to be mailed out, and mails them". One of the first things it does is it gets a list of assignment submissions dated roughly within the last 24 hours from the mdl_assignment_submissions table, and process this list in a loop. Each time through the loop, it displays the msg. "Processing assignment submission xx", where xx is the number in the id column of the table. Since your cron run never displayed that, it must have stopped before it got to that point, or there were no submissions.
RLE,
first of all, thanks again for your kind support.
1. I found the string to replace using the Search menu in phpMyAdmin: as far as I remember I found just some occurences in the 'mdl_log' table. In fact I still find occurences for the new path string "/var/www/vhosts/" in the 'mdl_log' table, 'info' field. No other.
Surely I didn't follow the Moodle Migration guide (I've also migrated Joomla and other CMS-based sites which now all work), but... The guide indicates quite the same steps I followed by myself.
Of course I rewrote all the dirroot and dataroot in config files for each site. No wwwroot had to be changed because after migration we changed also the DNS settungs.
2. I know, it's not the most secure config, but... years ago we hadn't the possibility to protect the dataroot but with a htaccess file. Now we have a useful folder above the web document root and we will change this after having solved the links problem.
Anyway at the moment any url like http://www.domain.it/moodledata is not accessible, because of the htaccess.
3. When speaking of the migrated sites which are based on some old Moodle versions, I was referring to the links problem: all links work fine in these sites and I changed only their config files. No other operations were performed, nothing on their databases.
To be more specific, the script admin/user.php runs fine in these old versions.
I told you this because I think it might help to target the problem in the new versions of Moodle, on the new server.
4. For the cron problem, I think is strictly related to these links problem: I guessed that the scripts stopped at the Accounts module... And as you stated, the Accounts module is the first to be performed.
I would address my attention to the only major difference we have between the old and the new server: the open basedir paths, as I wrote some posts before.
By the way, I'm going to upgrade to 1.9.4 an unused 1.9.1 Moodle installation. I will tell you what's happening with this.
first of all, thanks again for your kind support.
1. I found the string to replace using the Search menu in phpMyAdmin: as far as I remember I found just some occurences in the 'mdl_log' table. In fact I still find occurences for the new path string "/var/www/vhosts/" in the 'mdl_log' table, 'info' field. No other.
Surely I didn't follow the Moodle Migration guide (I've also migrated Joomla and other CMS-based sites which now all work), but... The guide indicates quite the same steps I followed by myself.
Of course I rewrote all the dirroot and dataroot in config files for each site. No wwwroot had to be changed because after migration we changed also the DNS settungs.
2. I know, it's not the most secure config, but... years ago we hadn't the possibility to protect the dataroot but with a htaccess file. Now we have a useful folder above the web document root and we will change this after having solved the links problem.
Anyway at the moment any url like http://www.domain.it/moodledata is not accessible, because of the htaccess.
3. When speaking of the migrated sites which are based on some old Moodle versions, I was referring to the links problem: all links work fine in these sites and I changed only their config files. No other operations were performed, nothing on their databases.
To be more specific, the script admin/user.php runs fine in these old versions.
I told you this because I think it might help to target the problem in the new versions of Moodle, on the new server.
4. For the cron problem, I think is strictly related to these links problem: I guessed that the scripts stopped at the Accounts module... And as you stated, the Accounts module is the first to be performed.
I would address my attention to the only major difference we have between the old and the new server: the open basedir paths, as I wrote some posts before.
By the way, I'm going to upgrade to 1.9.4 an unused 1.9.1 Moodle installation. I will tell you what's happening with this.
As we could have expected, upgrading to the 1.9.4 version does not solve the links problem.
Everything went fine, no error messages, but the links under Accounts still lead to a blank page.
Everything went fine, no error messages, but the links under Accounts still lead to a blank page.
Well, I just finished checking every single link in the Admin menu for two Moodle 1.9.x installations on the new server (two different domians).
For both sites, the followings are the only non-working links (they all lead to a blank page in less than a second):
under Users > Accounts :
http://www.domain.com/moodle/admin/user.php
http://www.domain.com/moodle/admin/user/user_bulk.php
http://www.domain.com/moodle/user/editadvanced.php?id=-1
http://www.domain.com/moodle/admin/uploaduser.php
http://www.domain.com/moodle/admin/uploadpicture.php
under Grades :
http://www.domain.com/moodle/grade/edit/outcome/index.php
http://www.domain.com/moodle/grade/edit/letter/edit.php
As far as I could check, every other link item and its respective page do work as expected. No problems at all.
Can anyone guess what those non-working links have in common?!
I'm going mad.
For both sites, the followings are the only non-working links (they all lead to a blank page in less than a second):
under Users > Accounts :
http://www.domain.com/moodle/admin/user.php
http://www.domain.com/moodle/admin/user/user_bulk.php
http://www.domain.com/moodle/user/editadvanced.php?id=-1
http://www.domain.com/moodle/admin/uploaduser.php
http://www.domain.com/moodle/admin/uploadpicture.php
under Grades :
http://www.domain.com/moodle/grade/edit/outcome/index.php
http://www.domain.com/moodle/grade/edit/letter/edit.php
As far as I could check, every other link item and its respective page do work as expected. No problems at all.
Can anyone guess what those non-working links have in common?!
I'm going mad.
I forgot to mention. Under Server > Debugging, I've also activated all the Debug messages options and no errors are displayed while opening the non-working links.
Back again, just to say that I solved this issue only by changing webserver (and provider).
They didn't find a solution to set open_basedir to be compatible with Moodle... I had no chance but to change hoster!
It was a hard work to migrate again all our Moodle sites, but with the new hoster I have no problems.
They didn't find a solution to set open_basedir to be compatible with Moodle... I had no chance but to change hoster!
It was a hard work to migrate again all our Moodle sites, but with the new hoster I have no problems.
This issue was solved.
If needed, please have a look to this thread which is much related.
Hope it helps anyone else.
If needed, please have a look to this thread which is much related.
Hope it helps anyone else.