[Sorted!! - read how] Admin pages are blank...why?

[peterrodger]

Hi
I've just copied a web site from a remotely hosted server to my own web server in order to do some development work on it.  I can see the live web site (public pages) and the whole site works normally, until.... I try to log in as the admin.  I enter the username and password and press login and am presented with a completely blank screen showing this URL... http://www.mywebsite.com/admin/login/index.php.

I repeated the upload and the same thing happens.  I followed the WB "A to B" process to the letter, so I guess it must be a permission or an attribute that want some attention somewhere.  But where?  Any help or advice will be appreciated.

Thanks

[peterrodger]

Yes thanks, I checked the config.php file.  This is the content...

Code:

define('DB_TYPE', 'mysql');
define('DB_HOST', 'localhost');
define('DB_USERNAME', 'xxxx');
define('DB_PASSWORD', 'xxxx');
define('DB_NAME', 'xx');
define('TABLE_PREFIX', 'xxxx');

define('WB_PATH', dirname(__FILE__));
define('WB_URL', 'http://xx.xx.xxx.xxx/bb');
define('ADMIN_PATH', WB_PATH.'/admin');
define('ADMIN_URL', 'http://xx.xx.xxx.xxx/bb/admin');

require_once(WB_PATH.'/framework/initialize.php');

When I request the admin page, the login screen appears and I'm able to enter a username and login.  I click on "LOGIN" and a completely blank page appears.

The URL for the returned page should be http://xx.xx.xxx.xxx/admin/start/index.php, but in fact it displays http://xx.xx.xxx.xxx/admin/login/index.php (which was the URL of the previous (ie Login) page.  So the question seems to be 'why won't WB recognise the /start/index.php file?  I checked the server and all the required folders and files are there and the permissions all seem to be correct.

Incidentally, the "live" version of he site works perfectly and this is a clone of it.  The only difference between the tow is that the live one is hosted elsewhere on a Linux Apache box and the other (the clone) is hosted under my desk on a Windows Apache box.

I'm baffled, any thoughts please?

[peterrodger]

Whooops! I just double checked (in near desperation) the database tables only to discover that the very last table in the list ("xx_users) had not properly migrated to the local sever.  Well, that's the official reason - what actually happened was that I was careless and missed it!

If anyone scratched their heads in sympathy with this problem thanks and if you answered (Clara) thankyou very much.

[BerndJM]

Hi,

a short question at this point:
what tool you used for your database dump?

Regards Bernd

[peterrodger]

Hi Bernd
I just used PHPMyAdmin - I exported the selected tables from the live server into a text file and then copied and pasted them into an empty database on the development server.  I tried to at first to overwrite some existing tables on the dev server but it wouldn't work so empty databases are best - or at least don't bother trying to overwirite any existing tables - delete them first!

Just in case of problems, I had downloaded a bit of software called BigDump which has had good reviews but I didn't need it in the end.  (www.ozerov.de/bigdump.php)

Peter

[BerndJM]

Ah ok,
I see your way.

My first thought was you used the tool "MySQLdumper" which has still a bug. In multidump-mode it didn't export the last table of a database.

But "why the hell" you goes this way you described.
Wouldn't it be easier to export as SQL (with the option "overwrite existing tables") and import this SQL in the target-database ?

Regards Bernd

[peterrodger]

Wouldn't it be easier to export as SQL (with the option "overwrite existing tables") and import this SQL in the target-database ?

Yep, that's just what I did - except that because I had a client meeting in between the two halves of the process, I saved the copied SQL into a text file.

In the process either the last table got dropped whilst the "export" stuff did its job - or I carelessly missed the last table in the list.

Either way it wasted a lot of time and is fixed now.  Lesson learned!