It seemed so easy ... I just wanted to do what so many others have successfully done before. But it just won't work.

I have a XOOPS website, http://www.tropictech.de . No problem there. But I thought about some bigger changes which I don't want to do online, so editing a local copy would be nice. Additionally, I'll move to another server in a few weeks so I thought this would be a good test.

What I did:
1. Make backup copies of my site and the sql database. I already did that more or less regularly (daily when I changed something at the site), so no problem here.

2. I first tried Xampp, but after that, tried Xsas, both with the same end result - the default Xsas site runs perfectly though.

3. Import the downloaded database to the MySQL at localhost. No problem here either, as the database is only 1.5mb currently. One of the many instructions i read suggested i should "analyse" and "repair" the database, but that didn't change the result.

4. Copy all the files of my site backup to the local directory where the "www" directory is. I first tried a subdirectory, then the main directory, no change.

5. Adjust mainfile.php, of course, to the new settings.

All I get is a blank white page!

Other things i tried (with no other result):
- removed all php.ini and .htaccess that are somewhere in my site
- exchanged all occurences of http://www.tropictech.de in the database to localhost
- setting the site http://www.tropictech.de to phpdebug before exporting the database
- recovery.php also returns a white page
- xoopsinfo.php also returns a white page
- absolutely nothing in the apache log (besides the note that the server started, of course)
- one of the MANY threads i read about the procedure suggested installing a local xoops, overwriting the files with the real site afterwards, and exchanging the database contents. installing a local XOOPS works, but only white pages after copying over the site content.
- removed the XOOPS protector
- of course no file or directory is write-protected

xoops 2.2.3, news 1.44, cbb 2.31, wf-downloads 2.05, XOOPS protector 2.37.
There simply MUST be something i have not thought about, but I am ready to give up if nobody has an idea.

Try empty templates_c and cache folders ;)

banned,

oh i just forgot to mention that in my "already tried" list

Been there experienced that ... there are some sites i really did not solve this problem for me too.

Additional things to try:

- default theme
- disable all modules and export then
- try another version of xampp (there are so many ones available on sf.net with different php / MySQL versions)

Make sure error reporting is on for PHP in the php.ini file.

If you can't get to the administration page, but have access to mysql, try the query "UPDATE xoops_config SET conf_value=1 WHERE conf_name = 'debug_mode'". Be sure to make sure "xoops_config" matches the name of the config table in your installation

If you still get nothing, you may have dropped a bit or two somewhere in the transfer(it happens) try uploading from your production site to your dev box again.

GL

thank you all but that didn't help either. the values in php.ini were already the ones you posted, debug_mode didn't change anything and the theme wasn't the problem, too. i didn't try different xampp versions as i think that you can install XOOPS 2.2.3 on the currently shipping xsas so copying an existing site into xsas *should* work.

i was able to pinpoint it down, though. i did the following: after downloading the database as plain-text .sql file, i opened it in my favorite editor (no, that is not notepad ) and copied and saved parts of it to other, smaller .sql files. i was able to categorize them by the the names of the sql table so i do now have 18 different files for different things on the site. this was the hardest part as the sql backup nearly has 10000 lines.

i installed a fresh XOOPS 2.2.3 site on the xsas, installed the modules i wanted, and copied the directories /themes, /images, /uploads and /modules/news/images from my online site. the site already looked quite a bit like the one that is online ...

then, of course, i made a backup of the database in its current form and then began importing the sql parts, one after the other. beginning with the files for cbb, users, polls, smilies, ranks and so on ... the site got filled with its content and without problems - until i got to the file containing system configuration entries.

that's where i am now, i know which 500 line part of the sql database makes trouble!
it contains the tables prefix_config, prefix_configcategory and prefix_configoption.

i was able to pin it down to the table prefix_config. that table is too big to find out which entry is the bad one though ...

at least, my advice to users not being able to copy their site the "normal way" ... export your database again, but unselect the yourprefix_config table. if importing that to your copied site works, you are extremely close to your original site. final adjustments can be made using the XOOPS admin section (of your copied site, of course) and looking at the original table will help you find out what settings you are missing.

if that doesn't work, you can also take the long way as i did ... breaking up the sql backup in several parts which make sense to you. and trying to import one at a time.

Hello,

Had the same issue and followed your thread. I took the hint of the X_config table and found the "bad_ips" field to have the value of "a:1:{i:0;s:9:"127.0.0.1";}". I updated 127.0.0.1 to 127.0.0.2 just for a test and ah ha it all came back...

Figure I'll deal with it in the admin section from here but thought it may help...