Geeklog Forums

I have a Geeklog 1.51 site running on a host. I want to run it locally on my computer under wamp and also upgrade it to 1.72.

I did a full backup and a database backup via cpanel and downloaded both backups from the host. The backups are on a CD and on my local hard disk.. I also downloaded and installed Geeklog 1.72 ton my local computer.

Geeklog 1.72 appears to be working OK (I can add a story, etc). Only anomaly is that the Geeklog backup function doesn't work but that's no problem; I backed up the initial installation of the 1.72 database using phpMyAdmin.

I reviewed the instructions in both the "Geeklog - Documentation Installation Instructions" and "Migrating a Geeklog Site" which led to "Geeklog 1.5 Migrations". The "Geeklog 1.5 Migrations" script seems wrong because the form asks for the path to Themes and there is no single path to Themes in Geeklog 1.72.

I followed the instructions In Migrating a Geeklog Site; dropped the 1.72 database, replaced it with the downloaded 1.51 database, loaded the photos in the images folder and then ran the Geeklog 1.72 Install - Migrate script per the instructions. After selecting the "Migrate" button I was led to a blank screen on my Browser. I then ran the 1.5 Migration script and filled in a all of the required info but only a partial path for the Themes path. The result was a message that the migration was successful.

It wasn't successful (going to local host just brought up wamp). At that point I restored the original Geeklog 1.72 database and that is working OK again.

I think I have gone about this all wrong. What is the correct procedure?

That FAQ article is somewhat out of date. The easiest way to migrate a Geeklog site is to use the Migrate option that's built into the install script.

So unpack Geeklog in the location you want it, call up the install script and choose the Migrate option. You then have the option to either upload your database backup, use a copy in the "backups" directory of your install or migrate an existing database (so that you can import it by other means and then tell Geeklog to make the necessary changes directly in the db).

bye, Dirk

Dirk,

I think I understand but I'm not sure. Even though Geeklog 1.72 is now installed on my computer, I run the 1.72 install script on my local computer (via my browser) and select migrate. The menu that comes up has Database Hostname and I just put in "localhost" since it's running on my computer (though the installation is in c:/wamp/www).

I enter the database name of the current geeklog database that is running on my local computer and also the username for that database and the password for that database. Site URL and Admin Directory Path are already filled in for me. I select the database backup (Geeklog 1.51) file that I obtained from the host and hit "migrate".

When I next browse to local host, Geeklog 1.72 will start with the database that used to be at my host -- or do I have to run install - upgrade afterwards?

Sorry I'm so dense.

Howard

Yep, that's the process. The migration will also do the upgrade for you, so when the site comes up, it will be fully up to date and usable.

bye, Dirk

Dirk,

This is what happened on running the install -- migrate. It went to a blank page in my browser and when i browsed to local host I got this instead of geeklog.:


"( ! ) Warning: fopen(/home/larkfiel/public_html/logs/error.log) [function.fopen]: failed to open stream: No such file or directory in C:\wamp\www\lib-common.php on line 1968
Call Stack
# Time Memory Function Location
1 0.0012 500976 {main}( ) ..\index.php:0
2 0.0132 2240056 require_once( 'C:\wamp\www\lib-common.php' ) ..\index.php:35
3 0.0485 5081952 COM_handleError( ) ..\lib-common.php:0
4 0.0487 5082240 COM_errorLog( ) ..\lib-common.php:6601
5 0.0487 5083000 fopen ( ) ..\lib-common.php:1968
Unfortunately, an error has occurred rendering this page. Please try again later. "

I tried directly copying lib-common.php from the host backup into C:\wamp\www\ and then again browsing to localhost but got the same result as above.

Not sure what to try next. Also, is there some software that I can read lib-common into that will also show line numbers? Notepad is useless for that.

Thanks,

Howard

Not that I recommend Notepad for programing but you can get the line number by disabling word wrap in the menu and then enabling the status bar which will appear at the bottom (at least in Windows 7).

---

One of the Geeklog Core Developers.

Poking around in lib-common.php won't help here anyway, I guess.

Looks like an error occured that Geeklog wanted to log to error.log. But the path to error.log was still from your original webserver, i.e. the path was not "migrated" yet. In other words, an error occured and then, additionally, Geeklog had problems reporting the error. We need to figure out what the original problem was.

Try enabling root_debug in siteconfig.php so that it shows the error in the browser. Also see this FAQ article for more information and some other things you could try.

bye, Dirk

Dirk,

I enabled root debug in siteconfig.php and got the debug output. Below, is the first line and perhaps the first useful line of many many lines. This line was in bold. There are too many lines to send now.

"2 - require_once(/home/larkfiel/public_html/language/english.php) [function.require-once]: failed to open stream: No such file or directory @ C:\wamp\www\lib-common.php line 397"

However, "//homelarkfiel/public_html/language/english.php" is located on my host, not in my local computer. So if it is called an error will surely result.

Thanks for sticking with this.

Howard

By default geeklog store language file of the web root. So the missing language file must be in your C:\wamp\www\ geeklog-1.7.2\language\english.php
Did you live site (on your host) was installed with the language folder in the public-html directory?

Ben

---

I'm available to customise your themes or plugins for your Geeklog CMS

It sounds like your main path variable ($_CONF['path']) in siteconfig.php is not correct. On most installs it should not have public_html in it. It should be pointing to the root of Geeklog's main directory.

---

One of the Geeklog Core Developers.

Ben, Admin,

In my host site the "language" folder is located in the same folder as the "public_html" folder". In my local site the "language" folder is located in the same folder (wamp) as my "www" folder. So they both seem to be in the root.

I have looked in C:/wamp/www/siteconfig.php and it ($CONF("path" points to 'C:/wamp' Looks OK.

However, I have just browsed to the host site and found that the "language" folder is duplicated in "public_html".

I will try to add a copy of the "language" folder into my "www" folder.

Thanks for the input.

Howard


.

Adding a copy of the language file to the "www" folder didn't help. Got the same debug message from the siteconfig root debug --- "2 - require_once(/home/larkfiel/public_html/language/english.php) [function.require-once]: failed to open stream: No such file or directory @ C:\wamp\www\lib-common.php line 397"

I don't understand why geeklog is trying to access the host root rather than the local root since the data in siteconfig (located in C:\wamp\www\) seems to be OK.

Is there any other reason for geeklog to be trying to get to the original host's root?

Howard

The migration should have taken care of all those path changes, i.e. replaced those that are used on your host with your local paths - that's (almost) the entire point of that option. Not sure why it's not working for you.

The language file uses $_CONF['path_language'], which is stored in the database. Looks like that didn't get updated. If you're familiar with phpMyAdmin, you could try looking at the gl_conf_values table and see if you can find that option. Note that it contains a PHP serialized string, i.e. the number in front of the path is the string length and needs to be adjusted accordingly when you make changes.

As I said, I have no idea why it didn't work. I've done (literally) dozens of migrations of different databases just last weekend while testing some things in Geeklog and I never ran into such a problem. Odd

bye, Dirk

Dirk,

Today, I decided to try and be scientific about why things weren't working. This is what I did via PHP_MyAdmin and Open Office searches:

1) I put the sql database that I was running locally with the 1.72 geeklog as installed from the geeklog site into Open Office (via an export to a file) and found the embedded path notations for paths, language, logs, data, images, etc. They pointed to a path of 'wamp/www' for path 'public_html' and 'images' but to 'wamp' for their other respective folders. Good.

2) I then did the same thing with my local copy of the host backup of the 1.51 geeklog database and found, as I expected, that the same variables were pointed to folders in 'home/larkfiel/public_html/'. Good.

3) Then I did a migrate pointing to the file in 2) above.and via an export looked at the new migrated file. Bad. The file was radically changed but the same path references were in there as before! I thought they would change. No, they still pointed to 'home/larkfiel/public_html'. Yet, the Migrate said that the export was successful -- but it finished with just a blank page in my browser.

I must be doing something radically wrong but I can't figure out what it is.

Howard

Dirk,

I also followed up on your suggestion of using php_my Admin to look at the gl_conf_values in the database that had been "migrated". Even though the Migrate said it had been successful, everything still pointed to the host paths rather than the local paths. This confirmed what I found yesterday using Open Office to search through the database..

One possibility that I just thought of: When I downloaded the host backup, MS Security Essentials found a couple of backdoors that it quarantined and also 2 tools that it quarantined. Is it possible the tool signatures are for tools being used by the migrate.software? The two tool signatures that were quarantined were "Tool:Linux/Psybnc.A" and "Hack Tool:Linux/Xhide.h". Could one or both of them be needed for the migrate? Could the migrate software be calling for a module that is being quarantined?

I'm pretty sure that the migrate software is not having trouble accessing the databases because the downloaded host database is radically changed by the migrate; just the paths aren't changed.

Howard

Not sure I understand.

When you say you downloaded the host backup - what did that backup include? You would only need a copy of the database and run that through the install script of a fresh local Geeklog install (actually, not really an install - just the files, since the migration would be the install).

The "migrate software" is just a bunch of PHP scripts in public_html/admin/install. There shouldn't be anything in there that should trigger a virus warning, but with anti-virus software you'll never now ...

Can you identify the files that triggered the warning?

Btw, if that's an option, I could have a look at a copy of your database backup.

bye, Dirk

Dirk,

I downloaded the host files for two reasons. First, just to have a copy for backup purposes and second, so that I could follow the migrate instructions and place copies of the photos in the 'articles' and 'user photos' folders from the host site into the local images folder. I assumed that this had to be done before the migrate.

Do you want a copy of the host database before it's used for the migrate or after it's been modified on the local computer by the migrate? How can I get a copy of it to you?

Howard

I'd be interested in the original, so that I can try running the migration myself. My email address is in almost every .php file in Geeklog

bye, Dirk

To close this thread out:

1) Dirk, the Geeklog install instructions for the install of Geeklog 1.72 on my local computer and for the migration of the Geeklog 1.51 website from my host to my local computer were all OK! Unfortunately, I followed them exactly many times and the migration failed each time!


2) I haven't yet investigated every feature, but at a first overview the migrated site is now operating well on my local computer.

3) The original problem was that I carelessly installed the 32 bit version of wamp on a 64 bit machine and the install program didn't complain! When I removed the 32 bit version and installed the 64 bit version of wamp and went through the identical procedures it led to a successful migration.

Thanks for letting me know that you were able to perform the migration -- that led me in the right direction to solve the problem.

Howard

Sorry for not getting back to you after your last email. I wanted to try out some things but got sidetracked ...

So you're saying that the migration (the one built into the install script) finally worked for you? That's good to hear, since I had no idea what was going wrong there.

Thanks for your feedback.

bye, Dirk