Moved from local to live host and site not displaying
Permalink 1 user found helpful
I created my site on my local computer using bitnami and have tried transferring to live site on hostpapa. I followed the transfer documentation on here. I also have the concrete5 book, which offers the same instructions.
I installed concrete5 on hostpapa using softalicious.
I exported the database using the backup in concrete5 dashboard which I imported into hostpapa.
I uploaded all site files to hostpapa.
My sitehttp://www.phoenixdogrescue.co.uk does not display. I don't get any error message, it just doesn't pull in any data.
I don't know what else to check.
I've changed username and password in config file to what I believe them to be.
The database appears to be there, but don't know enough to check anything else with database.
All files appear to be in correct place.
Please can someone help me, I've been trying to upload this site now for over a week :(
I installed concrete5 on hostpapa using softalicious.
I exported the database using the backup in concrete5 dashboard which I imported into hostpapa.
I uploaded all site files to hostpapa.
My sitehttp://www.phoenixdogrescue.co.uk does not display. I don't get any error message, it just doesn't pull in any data.
I don't know what else to check.
I've changed username and password in config file to what I believe them to be.
The database appears to be there, but don't know enough to check anything else with database.
All files appear to be in correct place.
Please can someone help me, I've been trying to upload this site now for over a week :(
There could also be a difference how your localhost and the other hosting service handles database table names. What I mean that your local computer might have lower case table names, for example in local you have table "areapermissionassignments" but the other host is looking for camel-cased name "AreaPermissionAssignments". This is quite common when you are moving from Windows host to Linux. Also the fact that Concrete does not throw any visible error makes the problem quite hard to trace.
Renaming tables by hand a huge pain, but fortunately there's an add-on that will do most of the dirty work:
http://www.concrete5.org/marketplace/addons/database-case-sensitivi...
Renaming tables by hand a huge pain, but fortunately there's an add-on that will do most of the dirty work:
http://www.concrete5.org/marketplace/addons/database-case-sensitivi...
I'm sure this is not the problem. If it is a camel case issue, then there must display some error. But its not the case. But this one definitely will be a solution after pointing to the correct database.
Rony
Rony
I've seen many Concrete5 sites failing without *ANY* error messages after moving from server to another one that had different configuration on table names. The end result is just an blank page.
The original poster could open /concrete/dispatcher.php and add following line after the first the require()-function is called:
Save the file and try to open the site. If you see the text "Testing" on screen, move the die() command further down the code. This is kind if hard way finding out where the site crashes, but it's the best if you don't have any options.
The problem I've encountered happens when dispatcher line 72 loads /config/app.php, which then starts to load values from Config model (code looks like Config::getOrDefine(.....). As far as I know, the function getOrDefine leads to the first place where database connection is opened and IF the table names are incorrect, the site dies silently. You could get the error printed out by modifying the code in /concrete/core/models/config.php after the 176 where the class Concrete5_Model_ConfigStore's load() method starts.
The original poster could open /concrete/dispatcher.php and add following line after the first the require()-function is called:
die("Testing");
Save the file and try to open the site. If you see the text "Testing" on screen, move the die() command further down the code. This is kind if hard way finding out where the site crashes, but it's the best if you don't have any options.
The problem I've encountered happens when dispatcher line 72 loads /config/app.php, which then starts to load values from Config model (code looks like Config::getOrDefine(.....). As far as I know, the function getOrDefine leads to the first place where database connection is opened and IF the table names are incorrect, the site dies silently. You could get the error printed out by modifying the code in /concrete/core/models/config.php after the 176 where the class Concrete5_Model_ConfigStore's load() method starts.
Thanks for your replies
I tried the
It displayed testing right through the entire code until I put it at the end where we went back to displaying the site name and login with no content
I'm will try to export the db again tonight.
I tried the
die("Testing");
It displayed testing right through the entire code until I put it at the end where we went back to displaying the site name and login with no content
I'm will try to export the db again tonight.
have you had any luck with this? I'm having the same problem moving my database over.
No I have given up :(
I've started building it again from scratch, this time on the live server.
I've started building it again from scratch, this time on the live server.
I just manually changed everything to Camelcase through phpMyAdmin and it worked. It got rid of the blank screen and now I just have some directory issues but the database is connected. Good luck my friend.
I'm having this issue but in reverse - the site works on our DEV server but not in MAMP.
Yesterday I re-exported the database from DEV and the site worked - but this morning, the site has stopped working in MAMP again.
I tried the DIE suggestion above and it fails rendering at this point:
I'll export from the DEV server again but would love to know why this is happening before we take this site live - btw, all the table names are camel case on both the DEV server and in MAMP before/after a fresh import.
Does anyone else know what might be causing this?
Any pointers in the right direction would be much appreciated.
Cheers
Ben
Yesterday I re-exported the database from DEV and the site worked - but this morning, the site has stopped working in MAMP again.
I tried the DIE suggestion above and it fails rendering at this point:
$v->render($c);
I'll export from the DEV server again but would love to know why this is happening before we take this site live - btw, all the table names are camel case on both the DEV server and in MAMP before/after a fresh import.
Does anyone else know what might be causing this?
Any pointers in the right direction would be much appreciated.
Cheers
Ben
OK, so just switched the PHP version in MAMP from 5.4.4 to 5.3.14 and the site now renders.
Will update MAMP (there are many versions of php) and see which ones work and which don't.
Will update MAMP (there are many versions of php) and see which ones work and which don't.
While php 5.3.14 works on the front end, the dashboard doesn't.
Sorry, should've mentioned that while the front-end doesn't render, I can login to the dashboard.
Sorry, should've mentioned that while the front-end doesn't render, I can login to the dashboard.
Have removed all packages incase this was causing the issue but still no luck.
Have noticed this in the Apache logs:
So I guess something is causing Apache to crash each time?
[Thu May 23 11:43:08 2013] [notice] caught SIGTERM, shutting down [Thu May 23 11:43:12 2013] [notice] Digest: generating secret for digest authentication ... [Thu May 23 11:43:12 2013] [notice] Digest: done [Thu May 23 11:43:12 2013] [notice] Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8r DAV/2 PHP/5.4.10 configured -- resuming normal operations
So I guess something is causing Apache to crash each time?
Rony