Moved site: Fatal error: Exception thrown w/o stack frame

[azurelink]

Greetings,

I just moved a client's Contao site to a new hosting server. We're accessing it through a temporary URL while we run tests, before re-pointing the nameserverrs to the new host. I modified the base URL in the config file and also did the same in the htaccess.

The site seems to run properly, except that when clicking through the menu items, occasionally a page will kick back the following error:

Fatal error: Exception thrown without a stack frame in Unknown on line 0

If I reload the page, it displays fine.

Being entirely new to Contao, I'm wondering what is causing this problem, and what I would need to do to fix it?
Will the problem go away once we are using the actual site URL? Could it be a server configuration error?

I ran the Contao check file on the server and it said the server was okay to run Contao.

Any help received is appreciated.

Best,
Kimo

[Ruud]

I looked up the error and two possible answers are:

1. The server is running out of quota (disk or something)[/*:m:26ryn3nw]
2. There IS an error in Contao, but for some reason it shows at your server where I have never had this problem. See here: http://www.compdigitec.com/labs/2009/08 ... on-line-0/[/*:m:26ryn3nw]

Sor perhaps make sure first you are not approaching any server limits during page load, otherwise find a repeatable way to produce the problem, test it in the online demo and post it as a bug.

According to the link I posted above the error is hard to debug (especially when it is not consistently showing ofcourse). But if you add in a lot of echo's you should be able to eventually pinpoint the exact location that throws the error. Whatever the code is trying to do there should be of help to get to the solution...

[azurelink]

Thanks Ruud,

New development: Now the site is not loading at all and is kicking back the following error:

Fatal error: Uncaught exception Exception with message Could not connect to the FTP server thrown in /home/myusername/public_html/system/libraries/FTP.php on line 104

I checked the FTP settings in the config.php and localconfig.php files. I also tried the root FTP credential, too, but the message didn't go away.

If you could please provide some insight about this, please let me know.

On a related note, I went back through the instructions for moving a site and realized that I did not run the install.php file. But I don't currently have the install password, so I'm going to do a new parallel installation and see if I can somehow merge the old files and database with the new install.

Do you know if running the install sets up some special config (besides the database connection) that might be causing these problems?

Thanks very much for your help.

Sincerely,
Kimo

[DyaGa]

azurelink

Please, check again your ftp host and ftp port values.

Also, you may try to not to use FTP connetcion. In localconfig.php file set this:

$GLOBALS['TL_CONFIG']['useFTP']  = false;

Do you know if running the install sets up some special config (besides the database connection) that might be causing these problems?

On remote server Intall tool can ask you to enter FTP connection options... and this can make a problem if you enter wrong values.

[azurelink]

Also, you may try to not to use FTP connetcion. In localconfig.php file set this:

$GLOBALS['TL_CONFIG']['useFTP']  = false;

Wow! Setting useFTP = false seems to have fixed the two errors. What ramifications would having useFTP set to false have? Can the site run that way, or would the admin not be able to upload image files through the CMS?

Do you know if running the install sets up some special config (besides the database connection) that might be causing these problems?

On remote server Intall tool can ask you to enter FTP connection options... and this can make a problem if you enter wrong values.

Okay, I understand. I didn't actually run the install.php file, in this case.

On another note, I re-ran the contao_check.php file — with the files on the server, this time — and I noticed that a large amount of the site files are listed as being "corrupt". Very weird. The site seems to run fine, now that the FTP-related
error messages aren't happening.

What do you suggest I do? Should I replace the files with the ones from my backup?

Thanks,
Kimo

[DyaGa]

What ramifications would having useFTP set to false have? Can the site run that way, or would the admin not be able to upload image files through the CMS?

The site can run that way. Everything should work.

On another note, I re-ran the contao_check.php file — with the files on the server, this time — and I noticed that a large amount of the site files are listed as being "corrupt". Very weird. The site seems to run fine, now that the FTP-related
error messages aren't happening.

What do you suggest I do? Should I replace the files with the ones from my backup?

There is a funny principle in programming: if it works than do not touch. So if everything works well, then let it work.

[Ruud]

What ramifications would having useFTP set to false have? Can the site run that way, or would the admin not be able to upload image files through the CMS?

It is the recommended and default setting. FTP should only be used if there are problems accessing or writing data. PHP safe mode is a setting that might prevent certain file operations. By using an FTP connection the problem is bypassed.

There is a funny principle in programming: if it works than do not touch. So if everything works well, then let it work.

I don't agree. If the files show as corrupt and you are using the correct check tool (differs per version) then I think you should try comparing a corrupt file with the original and see what the difference is exactly. If manual changes have been made, then don't update (which is a very bad idea in general). But if the files are corrupt, or simply out of date because they belong to another Contao version, then you should backup and update. The worst that can happen is the system not working and you restore the backup.

Not updating corrupt files might leave your site vulnerable to anything...