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 :(

 
ronyDdeveloper replied on at Permalink Reply
ronyDdeveloper
It seems like the problem with the database import. Just make it sure that the database have same data like your local. You can do 1 thing, just export the database from your phpmyadmin panel of local host. And then import it to server. Also check in your config.php file whether the live site using the database is the same one that you have imported.

Rony
Ale replied on at Permalink Reply
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...
ronyDdeveloper replied on at Permalink Reply
ronyDdeveloper
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
Ale replied on at Permalink Reply
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:

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.
jj0 replied on at Permalink Reply
Thanks for your replies

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.
lackadaize replied on at Permalink Reply
lackadaize
have you had any luck with this? I'm having the same problem moving my database over.
jj0 replied on at Permalink Reply
No I have given up :(

I've started building it again from scratch, this time on the live server.
lackadaize replied on at Permalink Reply
lackadaize
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.
cmscss replied on at Permalink Reply
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:
$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
cmscss replied on at Permalink Reply
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.
cmscss replied on at Permalink Reply
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.
cmscss replied on at Permalink Reply
Have removed all packages incase this was causing the issue but still no luck.
cmscss replied on at Permalink Reply
Have noticed this in the Apache logs:
[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?